[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [platform-text-dev] Patch proposal
|
StyledText is SWT.
TextEditor stuff is Platform Text. So if you are submitting a patch for
AbstractTextEditor this is the right place.
Knut
Ron Baldwin <ron.baldwin@xxxxxxxxxxxxxxx>
Sent by: platform-text-dev-admin@xxxxxxxxxxx
01/30/2003 03:54 PM
Please respond to platform-text-dev
To: "'platform-text-dev@xxxxxxxxxxx'" <platform-text-dev@xxxxxxxxxxx>
cc:
Subject: RE: [platform-text-dev] Patch proposal
OK, I'll see if I can put something together and submit a patch.
Also, I have submitted a patch against #19825, regarding right clicking
and
context menus. McQ had an objection, but I'm not sure what he means. I
would like to resolve the objection and get the change in before M5 if
possible. If it comes down to personal taste, what about adding a
preference?
BTW, who owns StyledText? The last time I posted to swt-dev regarding it,
Veronika told me I should be here.
Ron
> -----Original Message-----
> From: Knut Radloff [mailto:knut_radloff@xxxxxxxxxx]
> Sent: Thursday, January 30, 2003 12:41 PM
> To: platform-text-dev@xxxxxxxxxxx
> Cc: Lynne Kues
> Subject: RE: [platform-text-dev] Patch proposal
>
>
> Oops, ignore what I said. For some reason I thought
> StyledText defines
> that action. In this case we/SWT are off the hook.
>
> Knut
>
>
>
>
> Kai-Uwe Maetzel <kai-uwe_maetzel@xxxxxxx>
> Sent by: platform-text-dev-admin@xxxxxxxxxxx
> 01/30/2003 01:06 PM
> Please respond to platform-text-dev
>
>
> To: platform-text-dev@xxxxxxxxxxx
> cc:
> Subject: 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
>
> _______________________________________________
> 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
