| Click after last character [message #1844740] |
Thu, 23 September 2021 16:03  |
 Lucio Menci
Messages: 7
Registered: June 2017 |
Junior Member |
|
|
Hi,
I'd like that Eclipse should permit to click after the last character. It should not seems a very usefull tool, but it is very annoiyng when you write without respect margins (me and my team write code in this way, and should be usefull) and you have to select a long sentence.
If the nearest rows (the first one after and the first one before) are smaller than the ones you are dragging the mouse, the display area will always show the latest selection point, ie the horizontal scroll bar always scroll to the leftmost position.
If would be able to the selection to be in a free area (like the area selection mode does), you are free to select text from the middle of a long sentence to the middle of a long sentence having short sentences in the middle.
No, the area selection mode is not an alternative, in cases like the one mentioned.
Well, if you simply click in a free area and have the cursor where there are no characters, when you write something with the keyboard you can choolse if Eclipse have to fill the space with spaces or shift the insertion point just after the last character in the same row.
Could it be implemented? Or is it already implemented and I didn't see an option to permit it?
Thank you
Lucio Menci
|
|
|
|
| Re: Click after last character [message #1844760 is a reply to message #1844752] |
Fri, 24 September 2021 07:51  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
Hi Lucio
This is a very sensible suggestion that runs counter to the philosophy of most/all modern editors.
30 years ago when I was programming an editor in PDP 11 assembler, I had the opportunity to attend a presentation on the mathematics of editors. I was very sceptical that there was any useful mathematics, but actually it was one of the best presentations I have attended; I still remember it.
The bottom line is that each editing keystroke/action is a mathematical operator that should be predictable and deterministic so that combinations are equally predictable and deterministic allowing a one finger typist to look at the keyboard without needing to verify state on the screen for side effects.
Certain combinations such as Cursor-Right then Cursor-Left are self-evidently and always no-ops in a predictable editor.
What about Cursor-Right then Cursor-Down then Cursor-Left then Cursor-Up? When put so simply it is obviously a no-op. But no, Cursor-Down has a column side effect if the new line is too short; pretty much the basis of your suggestion.
If Cursor-Down is re-implemented without a column side-effect, we get to your suggestion. But how is Type-Character following a beyond end of line Cursor-Down implemented? Is the gap filled with spaces or tabs? Ok there is a preference for that.
But consider Cursor-Right then Cursor-Right then Cursor-Left then Cursor-Left , when the characters immediately following the cursor are space then tab, does the column advance by two or up to the modulo 8 column? Do the Cursor-Lefts then go back one or by the previous advance, if there was one?
Bottom line, the editor design can choose to operate using persisted characters or visible columns as the horizontal increment. The former is easier to implement and is superficially friendlier, but actually unpredictable and so less friendly since it is impossible to implement a macro recording facility in which a precise sequence of keystrokes can be recorded and repeatedly executed in a predictable fashion. Sadly modern editors are inferior in many ways to the mathematically sound editor I programmed 30 years ago.
(In a predictable editor the Tab-Right/Tab-Left action is advance/retreat to module 8 column positioning command, rather than Type-Tab-Character/Shorten Line; actual tabs only occur once some padding is necessary to support non-control characters beyond the end of line.)
Regards
Ed Willink
|
|
|
Powered by
FUDForum. Page generated in 0.03852 seconds
] 
Search
Help
Register
Login
Home
