[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [platform-text-dev] Patch proposal
|
If the changes are minor and you end up changing the default StyledText
behavior there's a possibility that we will be able to release it for M5.
You should enter a bug against SWT.
I suggest you try out both options, keeping the caret in the same location
and keeping it visible on the top/bottom visible line. The latter is what
Visual Studio does. It is the only app I found (that I have) that does
something special for Ctrl+Up/Down. Choose whatever feels best.
Since all you need to do is change the caret offset to keep the caret
visible, and there's already code that handles the short line/long line
problem it should be a fairly simple change.
Please post any other questions on the SWT mailing list.
Thanks,
Knut
Ron Baldwin <ron.baldwin@xxxxxxxxxxxxxxx>
Sent by: platform-text-dev-admin@xxxxxxxxxxx
01/30/2003 12:03 AM
Please respond to platform-text-dev
To: "'platform-text-dev@xxxxxxxxxxx'" <platform-text-dev@xxxxxxxxxxx>
cc:
Subject: RE: [platform-text-dev] Patch proposal
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