Skip to main content

[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





Back to the top