[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-text-dev] Patch proposal
|
> -----Original Message-----
> From: Knut Radloff [mailto:knut_radloff@xxxxxxxxxx]
> Sent: Tuesday, January 28, 2003 12:43 PM
> To: platform-text-dev@xxxxxxxxxxx
> Subject: Re: [platform-text-dev] Patch proposal
>
>
> I'm resending this message since it didn't get posted initially.
> In addition to the comments below, if you are going to
> provide a new key
> binding for Ctrl+Up/Down I personally prefer the second
> option you mention
> (scroll the text, don't move the caret).
It is not a new key binding, the functionality (and key binding) already
exists. I want to modify the current behavior.
> However, it is more difficult to
> implement. You have to worry about things like what should
> happen if there
> is no text underneath the caret once the text has been
> scrolled. I.e., the
> caret was on a long line and now hovers over a short line.
Having done some development in the text editor arena, I fully realize how
difficult it can be. (And just to prove what a masochist I can be, I'm also
considering taking on the split file editor enhancement #8009. :-) )
As for how to handle the caret moving across a short line, I think you have
two options: 1) temporarily move the caret to the end of the short line, or
2) allow what VS calls "virtual spaces", allowing the caret to be placed
anywhere in the visible space of the editor. #1 would be easier to
implement and more consistent with how the editors work now (i.e. exactly
the same as just using the up/down arrows in that situation). #2 would
require adding the "virtual spaces" functionality to the editor (which would
be a nice thing to have anyway).
> The idea of the Ctrl+Up/Down action is to be able to view
> text without
> moving the caret so that you can easily go back to the old caret/edit
> location. Changing this to move the caret in certain cases
> defeats this purpose.
I disagree. The idea of Ctrl+Up/Down is to scroll text into view without
moving the caret position. That's it. It doesn't have anything to do with
being able to "get back" to wherever the caret started. Here is the basic
idea: the caret should always be visible when navigating with the keyboard
(typing, arrow/hot keys, etc.), but doesn't have to stay visible when
navigating with the mouse (scrollbars, mouse wheel, etc).
> That said, I don't even use this feature so I may be the only one who
> thinks this is the way it should work.
Developers are very picky about their text editors. No matter how we do it,
there will be people that won't like it. I mean, there are people in the
newsgroup lobbying for a vi mode, for Pete's sake! (What's the world coming
to???) I think the answer is to add a rich set of options to the editor,
then add preferences that allow everybody to customize the set of features
they want to turn on.
> Note that the default behavior of this action is defined in
> the SWT text
> widget. org.eclipse.ui.text could certainly override it.
>
> Knut
>
>
> Ron Baldwin <ron.baldwin@xxxxxxxxxxxxxxx>
> Sent by: platform-text-dev-admin@xxxxxxxxxxx
> 01/27/2003 04:24 PM
> Please respond to platform-text-dev
>
>
> To: "'platform-text-dev@xxxxxxxxxxx'"
> <platform-text-dev@xxxxxxxxxxx>
> cc:
> Subject: [platform-text-dev] Patch proposal
>
>
>
> I would like to submit a patch for something I consider a
> bug, but want to
> run it by the list before I spend any time on it.
>
> In an editor, you can Ctrl+Arrow Up/Down to scroll the window without
> moving
> the caret position. The problem comes in when the caret scrolls off
> screen
> and then you hit an arrow key (without Ctrl) and the window
> jumps back to
> where the caret is.
>
> What I think should happen is once the caret hits the first or last
> visible
> line (depending on which way you are scrolling) it should not go any
> further. Instead the caret should bump one line at a time as
> necessary to
> keep it visible.
>
> Thoughts? Comments? Green Light?
>
> Ron
>
> _______________________________________________
> platform-text-dev mailing list
> platform-text-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-text-dev
>
>
>
>
> _______________________________________________
> platform-text-dev mailing list
> platform-text-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-text-dev
>
