After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 305167 - CTRL+LEFT ARROW not working correctly at start of line
CTRL+LEFT ARROW not working correctly at start of line
Status: RESOLVED DUPLICATE of bug 727972
Product: gtk+
Classification: Platform
Component: Widget: GtkTextView
2.6.x
Other All
: Normal minor
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-05-23 03:45 UTC by Neo
Modified: 2014-04-10 15:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Neo 2005-05-23 03:45:38 UTC 
Problem:

1. Open a C++ source file.
2. Place the cursor at the start of a line (not the first or second line).
3. Now press CTRL+LEFT ARROW.
4. Instead of going to the end of previous line, the cursor jumps to the line
above previous line.


Other information:
Comment 1 Paolo Borelli 2005-05-23 07:14:37 UTC 
(not that at 99% this is not a gedit bug, but a gtk+ bug, try to see if that
happen with any other gtk application which uses GtkTextView).

However I cannot reproduce here... If I have

foo bar
baz

and the cursor is before baz and I hit ctrl+left, the cursor is moved before
bar. Obviosly if the line contains just one word, the cursor is moved to the
start of the line.
Comment 2 Neo 2005-05-23 09:08:28 UTC 
I think it's a problem by concept.

Consider the following example:

if(true)
{
  do_it();
}

I put cursor just before do_it(), and press CTRL+LEFT. I wish the cursor would
go to the end (or start) of { on the previous line. However, the cursor jumps to
the start of 'true'.
Comment 3 Paolo Borelli 2005-05-23 09:17:11 UTC 
Ok that makes sense... I guess that the current idea is that the cursor jumps to
the previous word start as defined by pango word breaking algorithm.

I'm reassigning to gtk+ and let them decide if this case can be taken into
account for the cursor movement.
Comment 4 Paolo Borelli 2005-06-15 08:55:16 UTC 
Just for reference I took a look at what others do:

- emacs behaves like the current GtkTextView
- vi behaves like you request
- mozilla text entry behaves like you request
Comment 5 Sébastien Wilmet 2014-04-10 15:32:39 UTC 
The root of the problem is bug #727972.

*** This bug has been marked as a duplicate of bug 727972 ***