GNOME Bugzilla – Bug 789947
Pos1: Always scroll the view completely to the left
Last modified: 2017-11-22 22:37:55 UTC
I have code with several pretty long lines (which has of course different parts indented by several levels). Currently, when I’m inside a longer line (i.e. the view is horizontally scrolled somewhat to the right) and press <Pos1> for setting the cursor to the “intelligent” beginning of that line, the view gets aligned just to the new cursor position – so the first few “columns” are not visible. Since source code is always left-aligned, this doesn’t make sense, because the view then hides the first 4/8/12 columns due to the indentation of that current level. Afterwards you then always have to manually scroll the view completely to the left edge, for making the first few columns visible. Could the view therefore be always scrolled completely to the left, when <Pos1> is pressed – independently of Pos1 being “intelligent” or „unintelligent”. (Pressing <End> should of course not be modified.)
Created attachment 363264 [details] [review] movements: scroll full left for first char movements If we are trying to go to the semantic beginning of a line, we should try harder to ensure that we make the first real column visible.
Thanks for reporting! Attachment 363264 [details] pushed as 4a9f99c - movements: scroll full left for first char movements
Many thanks for implementing!
Should this be included in 3.27.2? Because I couldn’t recognize it yet…?
Should be. Maybe the keybinding you're using doesn't match the movements fixed in this commit. What is the key name you are pressing? You can use `xev` to get the key name that is pressed. Just run xev, then type the key you're using, and read the name from the output. state 0x0, keycode 110 (keysym 0xff50, Home), same_screen YES, In the case above, they key name is "Home".
I use Neo2 layout, so I have a “soft link” to home via: ``` KeyPress event, serial 34, synthetic NO, window 0x3600001, root 0x273, subw 0x0, time 58982764, (157,-27), root:(363,1265), state 0x0, keycode 94 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 37, synthetic NO, window 0x3600001, root 0x273, subw 0x0, time 58982870, (157,-27), root:(363,1265), state 0x20, keycode 38 (keysym 0xff50, Home), same_screen YES, XKeysymToKeycode returns keycode: 110 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False ``` The home key of my keyboard is Fn + Left-Arrow: ``` KeyPress event, serial 34, synthetic NO, window 0x3600001, root 0x273, subw 0x0, time 59484411, (1479,1162), root:(2536,1280), state 0x0, keycode 110 (keysym 0xff50, Home), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False ```
Created attachment 364015 [details] video demoing the fix This demos what I thought the issue was, and the fix. First is Home, which moves to position 0. The second is ^ which moves to the first non-whitespace and ensures that the view scrolls enough to try to see position 0 at the same time.
Yes, this was precisely what I liked it to be, but somehow this doesn’t work here…
The only thing I can think of, is that for some reason our keybindings aren't matching the keycode/state that we're receiving from your keyboard.
I assumed, that this is a hook into the “intelligent Pos1” function…? This works as expected.
Unfortunately, keybindings have to be fairly specific in the keycode matching. For example, we have to duplicate our entries for PageUp KP_PageUp (for the keypad). So it's probably a matter of a missing entry.
Oh ok, how can I help here then?
We need to figure out what the keybinding accel name would be, and then duplicate these two lines, replacing "asciicircum" with that accel name. https://git.gnome.org/browse/gnome-builder/tree/src/libide/keybindings/vim.css?id=cf289165ba29a920946052b220f489935c6b9623#n413
Can you reference Christian Stadelmann [1]? I don’t know what to do here, but I assume he does, as he uses the same keyboard layout. [1] https://bugzilla.gnome.org/page.cgi?id=describeuser.html&login=gnome%40genodeftest.de
(In reply to Frank from comment #0) > I have code with several pretty long lines (which has of course different > parts indented by several levels). > > Currently, when I’m inside a longer line (i.e. the view is horizontally > scrolled somewhat to the right) and press <Pos1> for setting the cursor to > the “intelligent” beginning of that line, the view gets aligned just to the > new cursor position – so the first few “columns” are not visible. > > Since source code is always left-aligned, this doesn’t make sense, because > the view then hides the first 4/8/12 columns due to the indentation of that > current level. Afterwards you then always have to manually scroll the view > completely to the left edge, for making the first few columns visible. > > Could the view therefore be always scrolled completely to the left, when > <Pos1> is pressed – independently of Pos1 being “intelligent” or > „unintelligent”. (Pressing <End> should of course not be modified.) I can reproduce this on builder 3.24.2 (Gtk 3.22.21, Fedora 26). It does not matter which Pos1 key I use (whether it is on the basic layer or on Neo2's level 4). My xev output looks the same as in comment #6. (In reply to Christian Hergert from comment #13) > We need to figure out what the keybinding accel name would be, and then > duplicate these two lines, replacing "asciicircum" with that accel name. > > https://git.gnome.org/browse/gnome-builder/tree/src/libide/keybindings/vim. > css?id=cf289165ba29a920946052b220f489935c6b9623#n413 How can one do that? Anyway, the Neo2 layout produces a "keysym 0xff50, Home" event, so the keyboard layout should not matter at all as far as I understand. Have you seen https://bugzilla.gnome.org/show_bug.cgi?id=789300 ? I doubt it is related, but I'm not 100% sure.
When I switch to the standard German layout and press "Home" (which is "Fn + Arrow-Left" of my Dell in both cases), it also doesn’t work.
xev will be testing Xwayland, if you're running a Wayland session, so that could be different than what is happening under Wayland. Can you try under a regular Xorg session if you're not already and let me know? As for 3.22/3.24, those didn't have the fix, only our Nightly flatpak has the fix.
Same issue, KeyPress events are a little bit different: ``` KeyPress event, serial 37, synthetic NO, window 0x3600001, root 0x176, subw 0x0, time 2216029, (1558,815), root:(1730,993), state 0x0, keycode 94 (keysym 0xfe11, ISO_Level5_Shift), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 37, synthetic NO, window 0x3600001, root 0x176, subw 0x0, time 2216349, (1558,815), root:(1730,993), state 0x20, keycode 38 (keysym 0xff50, Home), same_screen YES, XKeysymToKeycode returns keycode: 110 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False ``` ``` KeyPress event, serial 37, synthetic NO, window 0x3800001, root 0x176, subw 0x0, time 2266133, (2088,1251), root:(2310,1479), state 0x0, keycode 110 (keysym 0xff50, Home), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False ```
(Running Fedora 27)
Okay, I figured out why this is the case. For some reason, based on the initial report, I miss-assumed you were using the vim keybindings, and it occurs to me now that is not the case. The "Smart Home/End" feature of GtkSourceView is what is providing this experience in the default keybindings. (You can press Home multiple times to jump between position 0 and the first non-whitespace character).
Yes exactly, this answers why you mentioned “^” and “0”. ^^
Created attachment 364156 [details] [review] sourceview: use IdeSourceViewMovement for smart-home This allows us to override the behavior of smart-home from GtkSourceView so we have more control over the scrolling within Builder and it's viewport.
This should take care of things for the default keybindings. Had to duplicate the work we were doing in GtkSourceView, which is rather non-ideal, but it fits into our movements design well. Attachment 364156 [details] pushed as 2d89719 - sourceview: use IdeSourceViewMovement for smart-home
Hell yeah, it works! Many thanks!