[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-text-dev] Patch proposal
|
Ron,
Depends on how your submission looks like. The original functionality is
implemented in AbstractTextEditor.ScrollLinesAction. If you can keep it
there, it would make it easier for us to look at it.
Thanks for you help.
Kai
At 11:03 PM 1/29/2003 -0600, you wrote:
Is it realistic to attempt to get this in before M5 and the code freeze, or
should I just sit tight until after 2.1 ships?
> -----Original Message-----
> From: Knut Radloff [mailto:knut_radloff@xxxxxxxxxx]
> Sent: Tuesday, January 28, 2003 6:07 PM
> To: platform-text-dev@xxxxxxxxxxx
> Cc: Lynne Kues
> Subject: RE: [platform-text-dev] Patch proposal
>
>
> Good point about keeping the caret visible when doing
> keyboard navigation.
> This action is a bit of a black sheep.
> Instead of providing a new binding you could also enter a bug report
> against SWT saying that the default key behavior should keep
> the caret on
> the screen. I say "new binding" because you're binding the key to a
> different action or rather you would remove the default key binding.
>
> Knut
>
>
>
>
> Ron Baldwin <ron.baldwin@xxxxxxxxxxxxxxx>
> Sent by: platform-text-dev-admin@xxxxxxxxxxx
> 01/28/2003 06:13 PM
> Please respond to platform-text-dev
>
>
> To: "'platform-text-dev@xxxxxxxxxxx'"
> <platform-text-dev@xxxxxxxxxxx>
> cc:
> Subject: 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
> >
> _______________________________________________
> 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
>
_______________________________________________
platform-text-dev mailing list
platform-text-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-text-dev
