[Geany] revisiting default keyboard shortcuts: a proposed solution

[John Gabriele]

On 9/5/07, Nick Treleaven <nick.treleaven at btinternet.com> wrote:
> On 09/04/2007 05:27:32 PM, John Gabriele wrote:
>
> > For example, after thinking about this discussion, I'd probably
> > change F7 --> Shift-Alt-F ("incremental *f*ind"), and maybe
> > F2 --> Shift-Alt-E ("back to *e*ditor").
>
> Fair enough, personally I prefer F-keys though (I guess my fingers are
> used to finding the bumps on the F and J keys, so it's easy to move
> back to the 'home' position).
>
> Just to mention that sometime I/we will probably add incremental find
> backwards, which would be nice to do by adding shift to the incremental
> find binding.

Really looking forward to that feature! :) Maybe a checkbox connected
with that search field widget (indicating search direction), where the
key combo would check the checkbox before making the field active?

I can see how it's now getting into a gray area between using
Shift-Alt vs. Ctrl-Alt, since even though you're still manipulating
GUI elements, they're acting an awful lot like regular editing
commands. I guess this is one of those cases where you need to think
about what the user is using the command for, and choose the key combo
based on that (keeping things consistent for the user), rather than
strictly deciding key combos based on the editor feature
implementation. So, that said, here's an updated and summed-up (and
supplemented) list of some key combos that I think are worth mulling
over:

* Ctrl-Alt-T -- insert date ("*t*oday", or "*t*ime") (Ctrl-Alt-D would
be a collision with a Gnome binding)
* Ctrl-Alt-U -- toggle case of selected text (though I think Enrico
likes Ctrl-U for this one -- maybe he changes case a lot. :) ). Or, if
you like having two separate key combos for changing case (as is the
current setup), you could use:

    * Ctrl-Alt-U -- make selection uppercase
    * Ctrl-Alt-L -- make selection lowercase (though, this collides
with a Gnome key combo)

* Ctrl-Alt-N -- down-by-paragraph (possibly in addition to Ctrl-], for
users of non-english keyboards)
* Ctrl-Alt-P -- up-by-paragraph (possibly in addition to Ctrl-[, for
users of non-english keyboards)

* Shift-Alt-V -- scroll to current line ("center *v*iew") (instead of
Shift-Ctrl-L).
* Shift-Alt-B -- select text between innermost matching brackets
(**who snuck this in here? ;)**). It does seem to go rather well with
Shift-Alt-{W,L,P} though...

* Alt-{Up,Down,Left,Right} -- scroll window view by line/character.
* Alt-{PgUp,PgDn} -- scroll back and forward through editor tabs
(seems to follow nicely with the other Alt key commands, right?).
* Alt-{Home,End} -- Go to first tab (like Alt-1), and last tab
(Alt-0)? Just an idea here, but these two combos seem to just flow
nicely from the rest of the Alt keys dealing with the GUI. Also,
Enrico, you noted that someone once mentioned that numbers keys aren't
always easy to hit on some keyboards, so maybe Alt-{Home,End} would be
easier than Alt-{1,0} for some users?

Finally, getting back to the main point of this reply, noting the
(future) reverse incremental search feature:

* Ctrl-Alt-F -- incremental search forward (just a possible
alternative to an F-key)
* Ctrl-Alt-R -- incremental search reverse (just a possible
alternative to an F-key)
* Ctrl-Alt-E -- bring focus back to editor window (just a possible
alternative to an F-key)

Most of those above are new Ctrl-Alt combos, which was Nick's (and
later, Enrico's) original concern (since some folks find the Shift-Alt
combo cumbersome to hit). Add to that, using Alt for
scrolling/tabbing, and Shift-Alt for selecting (and some GUI
manipulation) seems nicely self-consistent and easier to remember than
the current keys -- for example, my fingers expect the Ctrl-movement
keys to move the cursor (like Ctrl-{Right,Left} do), and so both
Ctrl-{PgUp,PgDn} and Ctrl-{Up,Down} *still* seem to me to behave in an
unexpected way.

Hope that was useful.
---John