[Lazarus] Position of second Source editor Window not saved

[Michael Schnell]

On 20/04/2010 14:19, Hans-Peter Diettrich wrote:
> Martin schrieb:
>>>> 2- the user experience during usage
>>>
>>> Sometimes it could be a bit less sensitive to errors in related 
>>> components. 
>> Which related components? Or are you speaking of codetool navigation?
>
> I frequently get FPDoc messages, when scrolling through source code. 
> It's nasty to click them away.
>
> The crashes, observed while editing (cut&paste), may be related to 
> some other tool (auto format...), but occured only last week, no more 
> now.

indeed, there were some revisions where the fpdoc editor did not get all 
editor-change updates. But that would have only applied, if you actually 
had more than one window open.

Also, I always had sporadic fpdoc editor issues (this or that not found) 
=> long before I started on the multi editor


>>> But except for the current multi-window redesign, the editor and IDE 
>>> was usable since 0.9.26, and has become very stable since 0.9.28 :-)
>>
>> In which way is the current redesign not working or making the IDE 
>> unstable? Sure there were individual revisions that exposed some bugs 
>> => that is what it says on the label: current SVN is not a released 
>> version...
>
> I had some crashes in the last weeks, but now it seems to have widely 
> stabilized :-)

Well as I said => SVN. it has temporary issues.


>> Except for, if you do not like extra windows, you do not use the 
>> feature => that still means the IDE is working and usable.
>
> I *need* multiple editor windows, missed them since my first contact 
> with Lazarus! That's how I came to docking, in anticipation of 
> multiple code explorers, dockable to the editor windows.
>
> With a more general use of docking, the SynEdits could be replaced by 
> other editor components. Not that I don't like the SynEdits, but some 
> users (including me) sometimes feel an wish of a different GUI. Maybe 
> a split into interface/implementation panes, or navigation from a 
> project or unit explorer, with edits restricted to a single selected 
> procedure or method. A tighter coupling of the logical caret position 
> to a navigation map or tree (code explorer...) sometimes were very nice.
Splitting the space inside a single tab/page (with one of those 
splitters on the top end of the scrollbar) came up a few times as 
suggestions, and I agree, it would be a nice extension. (and isn't 
related to docking, since docking wouldn't combine tabs).

As for coupling edits to a single procedure. I haven't thought about any 
of this yet. I know how it works, and I know some people may like it. 
but it's a different thing. Implementation wise it's not very related to 
the multi-view stuff.

>
> I think that now, when the views have been separated from the source 
> files, it should be easy to implement such additional (maybe user 
> specific) components or effects.
Well the main part of it, would to write a wrapper around the (shared) 
text buffer, which limits SynEdits View to the selected range of lines. 
=> quite do-able

The thing that needs sorting out, is the relationship between 
sourceEditor and Project. All the open tabs, and what is displayed in 
them (topline, caret, or in the above case selected procedure) need to 
be stored in the project. That neds to be syncronized...
And I don't quite like how it's currently done (or rather where it is 
done) => Main is abused as the connector, because main is the only thing 
that knows all the parts involved.

Martin