[Lazarus] Issue 16987: Source Editor: Ctrl+A moves cursor to the end of file

[Martin]

On 22/07/2010 14:29, Alexander Klenin wrote:
> [Martin requested me to reply here instead of the bugtracker]
>    
>> Having the caret in the middle of the selection, after ctrl-a
>> would hinder other users from quickly selecting all, but the last n lines
>> (by deselecting a few lines after ctrl-a.)
>>      
> This is not a very compelling argument, since current implementation
> similarly prevents users from quickly selecting all but the _first_ lines.
>    
there is an option, to allow the caret skip the selection, which allows 
to move from one end to the other
But in general: yes, it's a question of what you want, expect, are used too.
(I admit it was a weak (almost silly) point of mine)

It is more a matter of consistency => all other ways of making a 
selection have the caret at the end of the selction.
If done it would require changes to line selection, and all other forms 
of selection too => including the selection created be "copy word on 
copy none", where you could be in the middle of a none selected word, 
and it becomes selected.
But which of those should change, and which should not, and what about 
users who wan the caret move to the begin of text (all, word, line 
(especially line?) ), and so on.

At least at the moment I don't fancy adding that an potential amount of 
options.

>> I leave this open as a feature request for (optional?) deferred scrolling, on select-all.
>>      
> I think this would be even worse than current behavior -- not only the
> caret position would be lost, but this fact would also be hidden from the user.
>    
Tried it notepad++? I thought it was nice, but I don't need it, so I am 
not going to do anything about it for now

>> I could also see a point of ctrl-a while all is selected, to deselect, and restore the caret
>>      
> While this would be a minor improvement, I think it is more important to fix
> history restoration, since the user expects that Ctrl+H would return
> him to the previous
> position, but does not expect that Ctrl+A would do it.
>
> If this is fixed, I would consider the issue resolved.
>    

Well that is easy and reasonable, and most of all done in rev 26782

I will close the bug then?

Martin