GNOME Bugzilla – Bug 737230
Suggestion to use Ctrl+Up/Down for beginning/end of paragraph
Last modified: 2018-05-02 16:15:53 UTC
----------- Background: ----------- It has been a recurring feature request over many years to use Ctrl+PageUp/PageDown for tab switching in gEdit (so much so that it's in the gEdit FAQ), however that binding is grabbed by GtkTextView for moving to the beginning/end of the paragraph. I figured I'd ask again to see if opinions have changed, along with proposing an alternative to the current behavior. There are often two or three different ways to switch tabs on a platform, but in almost every application with a tabbed interface on every major platform, Ctrl+PageUp/PageDown long ago became the de facto standard, or the common and expected way to switch between tabs. gEdit is the one main application on the Linux desktop that does not support switching with these shortcuts, because of its dependence on GtkTextView. If this shortcut were not caught by GtkTextView, gEdit would implement the expected behavior, because GtkNotebook supports tab switching via Ctrl+PageUp/PageDown if the views it wraps do not capture those shortcuts. --------------------- Proposed alternative: --------------------- Currently Alt+Home/End does not seem bound to anything in GtkTextView. I propose using Alt+Home/End to move to the beginning/end of the paragraph, and releasing the Ctrl+PageUp/PageDown key bindings so that GtkNotebook can "do the right thing" and implement the expected tab switching behavior on Ctrl+PageUp/PageDown. ---------- Reasoning: ---------- (1) Alt+Home/End is a more mnemonic shortcut combination for "beginning/end of paragraph" than Ctrl+PageUp/PageDown, because the desired behavior of navigating to the beginning or end of the paragraph has nothing to do with paging, but everything to do with going to the beginning/end of something, which is what the Home and End keys are understood to do. (2) Changing these keybindings would make a lot of gEdit users happy.
We don't use Alt as a modifier in edit bindings; it is reserved for mnemonics (underlined characters in labels)
Hmm -- well what about Ctrl+Up/Down for beginning/end of paragraph? Right now they seem to be bound to "go to the beginning of the *previous* paragraph" and "go to the end of the *following* paragraph", which seem like strange actions to want to perform anyway, because unless you're already at the beginning or end of a paragraph, the jump is, on average, 1.5 paragraphs the first time you hit the combination. Maybe the right behavior is that the first time you hit Ctrl+Up/Down, it moves to the beginning/end of the *current* paragraph (duplicating the current behavior of Ctrl+PgUp/PgDown), and once you're there, subsequently hitting the same shortcut again moves to the beginning/end of the previous/following paragraph respectively? If that change were made, then the first press of Ctrl+Up/Down would be exactly duplicated by the first press of Ctrl+PgUp/PgDown (and subsquent repeat presses of Ctrl+PgUp/PgDown don't do anything anyway, once you're already at the beginning/end of the paragraph), so that would free up the Ctrl+PgUp/PgDown binding for use with tab switching in GtkNotebook.
It seems a good idea to me (in Comment #2). What do you think, Paolo?
Created attachment 299112 [details] [review] textview: better paragraph movements gtk_text_iter_forward_to_line_end() moves to the next line if the iter is already at the end of the line (in case of an empty line here). So a check is needed. And the behavior is now consistent between forward and backward movements: the first movement is to move to the beginning/end of the paragraph, if not already done. If the cursor was in the middle of a paragraph, jumping 1.5 paragraph was a bit strange and not really useful.
Created attachment 299113 [details] [review] textview: remove Ctrl+PageUp and Ctrl+PageDown bindings They are now equivalent to the first movement of Ctrl+Up and Ctrl+Down. Moreover Ctrl+PageUp and Ctrl+PageDown are usually used to switch between tabs in a GtkNotebook. Unfortunately GtkScrolledWindow also uses Ctrl+PageUp/PageDown (for horizontal scrolling), and a GtkTextView is generally included in a scrolled window. But at least this commit moves us closer to the goal.
+1 for this, please. Re comment #2: Implementing an internal state which remembers whether it's the first or second time in a row that you press this key sounds dangerous to me and might easily be misleading for the user. Instead, how about achieving the same goal by looking at the cursor position only? I.e. if the cursor is at the very beginning of a paragraph then Ctrl+Up takes you to the beginning of the previous paragraph, otherwise to the beginning of the current one (and of course similarly for Ctrl+Down)?
Review of attachment 299113 [details] [review]: I agree with this patch. Can we get it in?
Pinging on this bug, since it has not been updated in >6 months, even though there's a reviewed patch attached. What can be done to fix the issue with GtkScrolledWindow using Ctrl+PageUp/PageDown, referred to in Comment #5?
Pinging again. More than a year has gone by since the last comment.
Ping! It would be great to get this in.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
I don't have the option of reopening this bug, but years later, it still needs fixing. Can this bug please be moved to GitLab?
Reopened.
(In reply to Luke Hutchison from comment #8) > What can be done to fix the issue with GtkScrolledWindow using > Ctrl+PageUp/PageDown, referred to in Comment #5? Right now, I guess users who want an enclosing Notebook to get those accelerators instead of the inner ScrolledWindow would have to unbind them from the SW in CSS. More broadly, whether that can/should be done by default seems like a UI design question.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/509.