Community
Participate
Working Groups
I am typing line by line in the maximized java editor. Soon the code grows beyond one page, so the editor scrolls upward automatically. The problem is that my caret (i.e. the blinking prompt) is always at the *bottom* of the editor. There is no margin at the bottom so I'm forced to look down to the edge of the editor, and I cannot see the things under the line I'm tying (e.g. brackets, finally clauses, etc.). So I thing a configurable margin at the bottom can really help improve the user experience, as the users - the programmers - are always typing.
Typing at the very bottom of the editor can be annoying (at least for me). If it is the last line in the file I always insert few blank lines at the end of the file and then scroll so that I am not typing at the very bottom of the editor (of course I also have to remove these blank lines). A margin or even a transparent scrollbar at the bottom may be interesting. Just thinking out loud :)
Or, we could do a couple of things - Allow the last line in the file to be scrolled up a little, rather than always showing it at the very bottom of the editor - While typing at the very bottom of the editor press Enter to insert a new line => the editor auto scrolls by 1 line. Maybe we can also auto scroll when Enter is pressed on the bottom few lines.
When starting with a new document there's no text to scroll upwards yet. Automatically inserting blank lines seems wrong too. If there are already enough lines, a "Lock Line" command could make sure that we always stay on the current line (text would be shifted downwards). Moving to SWT for comment whether this would fit into StyledText.
I don't think "margin" is the right term here. The StyledText already supports margins, but these are just white areas around the actual content area. I see two potential problems: a) You're editing text at the end of the last page of a document. In this case, you can't move the "current" line (where the text caret is) upwards, and you're forced to do all the editing in the bottom part of the editor. This could be solved with a mode where a StyledText has virtual lines after the real lines that make up the content. These virtual lines are not part of the document (i.e. not saved and not editable), but they increase the height of the text area by 1 page, such that you can always work at the top of the editor. This also affects the vertical scroll bar (and for text editors, also the rulers). I remember MS Word documents once worked like this (don't know how it is today). b) Your document is long enough, but the annoyance is that the caret moves downwards in the visible area whenever you add a new line, so you soon end up at the bottom of the editor. This could be solved with the "Lock Line" mode Dani suggested, or with a mode where the Enter key would automatically make the editor scroll up 1 line if the caret is in the bottom part of the editor (e.g. in the last 10 visible lines).
(In reply to comment #4) > a) You're editing text at the end of the last page of a document. In this case, > you can't move the "current" line (where the text caret is) upwards, and you're > forced to do all the editing in the bottom part of the editor. > > This could be solved with a mode where a StyledText has virtual lines after the > real lines that make up the content. These virtual lines are not part of the > document (i.e. not saved and not editable), but they increase the height of the > text area by 1 page, such that you can always work at the top of the editor. > This also affects the vertical scroll bar (and for text editors, also the > rulers). I remember MS Word documents once worked like this (don't know how it > is today). +1. 'Virtual lines' is the right term and this is what I had in mind. > b) Your document is long enough, but the annoyance is that the caret moves > downwards in the visible area whenever you add a new line, so you soon end up > at the bottom of the editor. This could be solved with the "Lock Line" mode > Dani suggested, -1 for the 'Lock line' mode, as in this mode the editor would always scroll up on pressing Enter which could be distracting. > or with a mode where the Enter key would automatically make the > editor scroll up 1 line if the caret is in the bottom part of the editor (e.g. > in the last 10 visible lines). +1. Though I would enable this for the last 3-5 lines.
My two cents: 1. There is a bottom line that the caret can never go below. Once the caret touches the line, it scrolls up. 2. The bottom line should larger than one line, maybe 3-10 lines, or smartly computed based on the current size of the editor and the font height. 3. It doesn't have to scroll one line at a time. Scrolling several lines can avoid causing distractions. Exactly how many lines could be configurable or smartly computed.
And maybe we can call this "smart scroll" or alike.
> > b) Your document is long enough, but the annoyance is that the caret moves > > downwards in the visible area whenever you add a new line, so you soon end up > > at the bottom of the editor. This could be solved with the "Lock Line" mode > > Dani suggested, > -1 for the 'Lock line' mode, as in this mode the editor would always scroll up > on pressing Enter which could be distracting. Currently it does this "distracting" thing already when you're at the bottom ;-). I would see "Line Lock" as a manual/user action and Markus's proposal as an auto-lock.
(In reply to comment #8) > I would see "Line Lock" as a manual/user action and Markus's proposal as > an auto-lock. That's another thing, I would rather NOT add another action that a user needs to keep in mind and remember to use. I prefer if things 'just work' automatically without any user intervention. (Though I do not care if the 'Line lock' action is added *in addition* to Markus's proposal)
(In reply to comment #9) > (In reply to comment #8) > > I would see "Line Lock" as a manual/user action and Markus's proposal as > > an auto-lock. > That's another thing, I would rather NOT add another action that a user needs > to keep in mind and remember to use. I prefer if things 'just work' > automatically without any user intervention. (Though I do not care if the 'Line > lock' action is added *in addition* to Markus's proposal) Well, your "just work" might not be how other want to interact with the editor. They might want the current and known behavior.
The maximum value in the vertical scrollbar is always set to the height of the content (basically lineCount * lineHeight, provided StyledText is in fixed line height mode). That means that the user can scroll the content down till the bottom edge of the last line aligns with the bottom edge of the client area, then scrolling stop (as maximum vertical scrolling was reached). That is our design in StyledText, many other editor use this same design. What you are suggesting, from what I understood, is to change the maximum value in the vertical scrollbar to contentHeight + clientAreaHeight - lineHeight. That code would allow the user to scroll the content as much as moving the top edge of the last line to align to the top edge of the client area. I've seem this behavior in some editor (VisualStudio comes to mind, but I'm not 100% sure). is that the behaviour that you are asking ?
(In reply to comment #11) > The maximum value in the vertical scrollbar is always set to the height of the > content (basically lineCount * lineHeight, provided StyledText is in fixed line > height mode). > > That means that the user can scroll the content down till the bottom edge of > the last line aligns with the bottom edge of the client area, then scrolling > stop (as maximum vertical scrolling was reached). > > That is our design in StyledText, many other editor use this same design. > > What you are suggesting, from what I understood, is to change the maximum > value in the vertical scrollbar to contentHeight + clientAreaHeight - > lineHeight. > That code would allow the user to scroll the content as much as moving the top > edge of the last line to align to the top edge of the client area. > > I've seem this behavior in some editor (VisualStudio comes to mind, but I'm not > 100% sure). > > is that the behaviour that you are asking ? Yes, this corresponds to 'problem a' from comment 4. And yes, this behavior is available in other editors e.g. Microsoft Word.
I think 'problem b' from comment 4 should go on a different problem report (if you think that is important). From the SWT standpoint 'problem b' is not important, as it can be easily on top of the widget. Besides, the way it was proposed it seems wrong to me. Changing the way 'enter key' works based on the current line index (plus a flag) does not sounds right to me. I think the behavior you want already exists in emacs (not sure if Eclipse implements), it is called 'open-line'. You can try in most natives apps in the mac using control+o, see http://www.danrodney.com/mac/ (look for Emacs Key Bindings). Do you think an 'open-line' command in Eclipse would help ?
> I think the behavior you want already exists in emacs (not sure if Eclipse > implements), it is called 'open-line'. You can try in most natives apps in the > mac using control+o, see http://www.danrodney.com/mac/ (look for Emacs Key > Bindings). > > Do you think an 'open-line' command in Eclipse would help ? This already works in Eclipse when you're on a new line: Ctrl+Shift+Enter.
Stack-Overflow Question on this issue: https://stackoverflow.com/questions/2197218/how-can-i-get-eclipse-to-scroll-past-the-bottom-of-the-document
