Who uses "caret past EOL"? lazarus / 9-Editor ---------------------------------------------------------------------- Martin_fr · 2023-06-02 12:55 If you do, do you use it within the range of the "longest line" only? That is, currently caret-past-eol additionally allows you to scroll up to over 1000 columns, even if you don't have any line that long. Do you use that scroll range? ---------------------------------------------------------------------- eljo · 2023-06-02 13:02 No, usually the width of my screen is enough add an error margin of lets say 100 columns and you are safe with me. ---------------------------------------------------------------------- Martin_fr · 2023-06-02 13:26 Quote from: eljo on June 02, 2023, 03:02:22 pmNo, usually the width of my screen is enough add an error margin of lets say 100 columns and you are safe with me. In future, the "cursor right" key will not be restricted anymore (like in other editors / notepad++ with "virtual space"). The scroll bar will extend, if the key is hold or repeatedly pressed. But, if you want to use the mouse to place the caret (and maybe the scroll vertically on the scrollbar or with an tilt-able wheel) then you need some already available scroll range. - You may want to stay within the range of the longest line, eg all other text will be placed below/above the content of the longest line - You may just want to scroll "a bit" beyond that (100 chars is probably the amount that fits into the visible part of your editor?) - You may want to go really far? Git main branch already has options to chose from... ---------------------------------------------------------------------- eljo · 2023-06-02 14:30 Quote from: Martin_fr on June 02, 2023, 03:26:39 pmQuote from: eljo on June 02, 2023, 03:02:22 pmNo, usually the width of my screen is enough add an error margin of lets say 100 columns and you are safe with me. In future, the "cursor right" key will not be restricted anymore (like in other editors / notepad++ with "virtual space"). The scroll bar will extend, if the key is hold or repeatedly pressed. But, if you want to use the mouse to place the caret (and maybe the scroll vertically on the scrollbar or with an tilt-able wheel) then you need some already available scroll range. - You may want to stay within the range of the longest line, eg all other text will be placed below/above the content of the longest line - You may just want to scroll "a bit" beyond that (100 chars is probably the amount that fits into the visible part of your editor?) - You may want to go really far? Git main branch already has options to chose from... the visible part of my window is around 184 chars, or at least that's what the editor reports when I place the cursor there, and I have the visible right margin set to 120 chars. I do not need to mouse click on anything really farthest than 180 to 200 chars as my code is wrapped on the 120 chars limit and only the comments at the end of the line occupy space beyond that but I find my self clicking on the extremes to add those comments instead of moving around with the arrow keys most of the time. ---------------------------------------------------------------------- 440bx · 2023-06-02 15:32 I very commonly use the caret past EOL.  That said it is rare that I need to put the caret on column 1000 or even past 512.  To me personally, what is truly important is being able to scroll vertically from the current caret column position and have the caret _remain_ in that column regardless of where the line ends. I find editors like notepad where the cursor jumps from one end of line to another to be utterly useless and extremely aggravating to boot. ---------------------------------------------------------------------- Martin_fr · 2023-06-02 15:57 Quote from: 440bx on June 02, 2023, 05:32:56 pmTo me personally, what is truly important is being able to scroll vertically from the current caret column position and have the caret _remain_ in that column regardless of where the line ends. That will - in any case - remain a given for "caret past eol". The existing mode remains (either as default or option) with one minor change: 1024 wont be a hard cut off anymore. 1) In addition to what currently exists, if the cursor key is used to go right, it will not stop anymore at 1024 but got on. However (in 1024 mode) - the scrollbar will by default only cover 1024 (or the longest line, whichever is greater). - only if the caret is actually moved further out, then will the scrollbar increase its range (in the same way as it  would if you typed at the end of the longest line > 1024) 2) There will be an option (or new default) that the extra range of the scrollbar will be less than 1024 (longest line + one page). But the caret will still be able to move out, and increase the scrollbar. 2a) Option to have no added scrollbar, until the caret moves out (yet the scrollbar covers the longest line) You can already try all that with the main branch. Question is about what is the best default. => I.e. how many people would be annoyed if (in order to get/keep 1024) the need to change an option after upgrading to 2.4. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40282 ---------------------------------------------------------------------- 440bx · 2023-06-02 16:30 Now, after checking the github link, I understand the problem. Quote from: Martin_fr on June 02, 2023, 05:57:23 pm1) In addition to what currently exists, if the cursor key is used to go right, it will not stop anymore at 1024 but got on. However (in 1024 mode) - the scrollbar will by default only cover 1024 (or the longest line, whichever is greater). - only if the caret is actually moved further out, then will the scrollbar increase its range (in the same way as it  would if you typed at the end of the longest line > 1024) I like this solution.  I think it's very intuitive and easy to understand. ---------------------------------------------------------------------- Martin_fr · 2023-06-02 16:34 Quote from: 440bx on June 02, 2023, 06:30:11 pmNow, after checking the github link, I understand the problem. Quote from: Martin_fr on June 02, 2023, 05:57:23 pm1) In addition to what currently exists, if the cursor key is used to go right, it will not stop anymore at 1024 but got on. However (in 1024 mode) - the scrollbar will by default only cover 1024 (or the longest line, whichever is greater). - only if the caret is actually moved further out, then will the scrollbar increase its range (in the same way as it  would if you typed at the end of the longest line > 1024) I like this solution.  I think it's very intuitive and easy to understand. But the question is, should the default scrollbar be - Max(1024, LongestLine) - LongestLine + WindowWidthInChars (either default includes: extendable by cursor-right) Do you often need to use the mouse to place the caret into the 1024 space (further than the one-page would allow). ---------------------------------------------------------------------- 440bx · 2023-06-02 17:03 Quote from: Martin_fr on June 02, 2023, 06:34:39 pmBut the question is, should the default scrollbar be - Max(1024, LongestLine) - LongestLine + WindowWidthInChars (either default includes: extendable by cursor-right) Do you often need to use the mouse to place the caret into the 1024 space (further than the one-page would allow). I'd go for Max(1024, LongestLine) just because it's simpler and less likely to require updating (it is rare - at least for me - to need more than 1024 columns.) As far as using the mouse, it is quite rare for me to use the mouse when editing and cannot think of a case where I would use it to put the caret past some column.  Personally, to navigate code I find the cursor keys along with page up/down and home/end to be much more efficient than the mouse. On a related but somewhat different note, something I think would be "nice to have" is an indication of how long the longest line is, e.g, 23/96 where 23 is the current column number  where the caret is (already displayed along with the line number) followed by 96 (presuming the longest line in that file is 96 characters long.)  Since this feature would require scanning the entire file, which could occasionally be slow, it might be appropriate to have it menu- selectable per file.  It might be nice too to have the line extent used for the current horizontal scroll range, e.g, 23/96/1024 where 23 and 96 are as previously mentioned and 1024 (or whatever applies) is the number of characters used to set the horizontal scrollbar extent. When the longest line is greater than 1024 then it would show something along the lines of 23/1510/1560 where 1560 would be a horizontal extent chosen to be slightly wider than the widest line (50 characters in this example.) ---------------------------------------------------------------------- Martin_fr · 2023-06-02 17:28 If you don't use the mouse, you don't need the 1024. Since - in future - the keyboard can move the caret to MaxInt. The longest line is in any case already looked up. Since the scrollbar depends on it. And if - in future - you use "longest line + page" for the scrollbar (or even without the "plus page") then the scrollbar gives you an indication of the longest line. But if you insisted on 1024, would it be an issue, if you had to make a config change in 2.4? (just once) The 1024, you only need, if you scroll horizontally without moving the caret. => That is usually by mouse. Not sure it may be it can be mapped to keyboard, in which case the limit applies to that to (but only if caret does not move) ---------------------------------------------------------------------- 440bx · 2023-06-02 17:58 Quote from: Martin_fr on June 02, 2023, 07:28:12 pmBut if you insisted on 1024, would it be an issue, if you had to make a config change in 2.4? (just once) No, it wouldn't be. Just for the record, I don't insist on 1024.  From what you stated, I am under the impression that the editor already determines the longest line and, if that is the case then the horizontal extent can simply be based on that and nothing else. Quote from: Martin_fr on June 02, 2023, 07:28:12 pmThe 1024, you only need, if you scroll horizontally without moving the caret. => That is usually by mouse. Not sure it may be it can be mapped to keyboard, in which case the limit applies to that to (but only if caret does not move) It's not really mapped to the keyboard but the extent and horizontal page size determine the size of the tracking thumb which is _visually_ useful when using either the keyboard or the mouse.  The size of the tracking thumb is what I was thinking about when going along with 1024 but, if Lazarus already knows the longest line in all cases then it could use a extent value derived from it instead., e.g, MaxLineWidth + SomeMargin. ---------------------------------------------------------------------- Martin_fr · 2023-06-02 18:16 Quote from: 440bx on June 02, 2023, 07:58:58 pm if Lazarus already knows the longest line in all cases then it could use a extent value derived from it instead., e.g, MaxLineWidth + SomeMargin. That is the idea. I do think that no one will miss the old behaviour, or the number of those will be so low they can be ask to adjust their config. But I have made changes in the past, with that exact same presumption, only to stand corrected. Hence I posted. ---------------------------------------------------------------------- 440bx · 2023-06-02 18:44 Quote from: Martin_fr on June 02, 2023, 08:16:40 pmThat is the idea. I do think that no one will miss the old behaviour, or the number of those will be so low they can be ask to adjust their config. But I have made changes in the past, with that exact same presumption, only to stand corrected. Hence I posted. I think it is a perfectly reasonable idea that works well.  OTOH, so far only two users have given you feedback, hopefully more will follow. ---------------------------------------------------------------------- Bart · 2023-06-02 20:26 Quote from: Martin_fr on June 02, 2023, 02:55:58 pmIf you do, do you use it within the range of the "longest line" only? That is, currently caret-past-eol additionally allows you to scroll up to over 1000 columns, even if you don't have any line that long. Do you use that scroll range? I do use this option. And I don't really care the horizontal scrollbar allows me to scroll 1000 columns. It never bothered me. Bart ---------------------------------------------------------------------- Martin_fr · 2023-06-02 21:07 Quote from: Bart on June 02, 2023, 10:26:04 pmQuote from: Martin_fr on June 02, 2023, 02:55:58 pmIf you do, do you use it within the range of the "longest line" only? That is, currently caret-past-eol additionally allows you to scroll up to over 1000 columns, even if you don't have any line that long. Do you use that scroll range? I do use this option. And I don't really care the horizontal scrollbar allows me to scroll 1000 columns. It never bothered me. Bart Question is the other way round, would it bother you if the default was for it to only be around 100 extra? (with the option to switch back to the large one) ---------------------------------------------------------------------- Bart · 2023-06-02 21:31 Quote from: Martin_fr on June 02, 2023, 11:07:13 pmQuestion is the other way round, would it bother you if the default was for it to only be around 100 extra? (with the option to switch back to the large one) Probably not. Would it (the amount of extra colums) be configurable? Bart ---------------------------------------------------------------------- RayoGlauco · 2023-06-02 22:58 In my case, I very rarely get past column 150. ---------------------------------------------------------------------- dbannon · 2023-06-03 03:42 I would think a 100 char beyond the longest line would be more than adequate, I cannot imagine typing text beyond a large block of whitespace, it would be quite confusing. Sometimes I like to have comments line up and that means starting some small white space beyond existing code but never a 100 characters beyond. Davo ---------------------------------------------------------------------- 440bx · 2023-06-03 04:15 Quote from: dbannon on June 03, 2023, 05:42:20 amI would think a 100 char beyond the longest line would be more than adequate, I agree, I think that even 50 characters would probably be, at least, adequate. ---------------------------------------------------------------------- MathMan · 2023-06-03 10:01 I do use 'caret past EOL' regularly when editing text (of any form, not source code only). I'm with 440bx that the most important thing is the caret to stay coloumn-fixed when scrolling up/down - behaviour like in Notepad++ is giving me the creeps. Regarding sizing of scrollbar - I wouldn't size it to longest line or longest line+constant. Instead I would take a relative approach like constant*longest line. That in mind from an aesthetic prespective the golden ration springs to mind for the constant. Just my 2c, MathMan ---------------------------------------------------------------------- Martin_fr · 2023-06-03 10:23 Quote from: MathMan on June 03, 2023, 12:01:37 pmbehaviour like in Notepad++ is giving me the creeps. Off topic: Enable "Virtual Space" in editor options of NotePad++ ---------------------------------------------------------------------- MathMan · 2023-06-03 10:42 Quote from: Martin_fr on June 03, 2023, 12:23:24 pmQuote from: MathMan on June 03, 2023, 12:01:37 pmbehaviour like in Notepad++ is giving me the creeps. Off topic: Enable "Virtual Space" in editor options of NotePad++ Too sad - v7.8.6 installed (company policy), but above is "new to v8.4.3" - but thanks anyway. ---------------------------------------------------------------------- kupferstecher · 2023-06-03 14:26 Quote from: Martin_fr on June 02, 2023, 06:34:39 pmDo you often need to use the mouse to place the caret into the 1024 space (further than the one-page would allow). Me not. My code normally is within 80 characters and comments may be longer but starting within the screen width. I won't start anything on character 720 (and for that use the mouse). Quote from: Martin_fr on June 02, 2023, 06:34:39 pm- LongestLine + WindowWidthInChars Basically it should be alright also as default. But the considerations should be on (unexpected) side effects. E.g. using 'LongestLine' means the scrollbar is adjusted after each key pressed while being in the longest line. This could be unbeautiful. Perhaps having fixed steps could be a solution, e.g. using  Screenwidth + n * 128 steps. Then n is determined depending on LongestLine and WindowWidthInChars. On the other hand horizontal scrolling is more obvious, when there is less white space "reserved". Another question is, would large files influence the time of determening LongestLine while typing. ---------------------------------------------------------------------- Eugene Loza · 2023-06-03 15:09 Quote from: Martin_fr on June 02, 2023, 02:55:58 pmIf you do, do you use it within the range of the "longest line" only?I didn't even know if such possibility exists (just double-checked and couldn't find that in Options) and would very welcome this. My lines aren't usually long (except when I sometimes start writing a single-line comment but then get unexpectedly verbose), most often fit within 100 symbols and using only first tiny fraction of the scrollbar is not accurate enough, especially on touchpad. ---------------------------------------------------------------------- Martin_fr · 2023-06-03 16:34 Quote from: Eugene Loza on June 03, 2023, 05:09:44 pmQuote from: Martin_fr on June 02, 2023, 02:55:58 pmIf you do, do you use it within the range of the "longest line" only?I didn't even know if such possibility exists (just double-checked and couldn't find that in Options) and would very welcome this. The option will be in 2.4 (and is in git main). Only open point is, what will be the new default (within the default of caret-past-eol enabled)