I think I have come up with a solution to the issues that folks are bringing up with regard to Geany's default keyboard shortcuts. Nick had good points, and I hope to address them below.
The issues:
* Using Ctrl-Alt vs. Shift-Alt * Shift-Ctrl-U and unicode * Possible clashes with desktop manager key combos * Ctrl-Up/Down and window scrolling * Being able to operate Geany easily without a mouse
Points about Geany, as Nick as noted:
* It's a *programmer's* editor * Symmetry and consistency is good * Multi-part key combos are not really preferred, but they're there if you need them.
Some observations:
* The Alt keys are used for dealing with menus and menu items. * Shift gets used a lot to select text (holding it down while moving). * Having many different keyboard shortcut modifiers (prefixes) can *possibly* be confusing.
Here's my proposed solution then:
Geany is a powerful GUI programmer's editor. As such, we should be taking advantage of the key bindings available. This means using Ctrl-Alt ... as well as Shift-Alt.
Having lots of keyboard shortcut modifiers can lead to a complex interface though. To combat that complexity, you can clearly specify what type of action the given modifiers are meant for. Geany is already using Ctrl-foo and Shift-Ctrl-foo keys -- where Shift-Ctrl-foo often means an extended or opposite version of Ctrl-foo. Ok. In fact, Nick's ideas for combos for extending cut/copy to lines seem to fit pretty well here:
* Shift-Ctrl-X -- cut the current line (was Shift-Ctrl-K) * Shift-Ctrl-C -- copy the current line (was Shift-Alt-K)
(He's right -- those do look pretty easy to remember.)
Now, Geany is also using Alt keys to deal with gui elements (including the Alt-1 and Alt-0 combos), and the Shift key to deal with selecting text (holding it down while navigating). I propose then, that Shift-Alt be specifically used for commands that either have to do with the GUI, or else with selecting text. That is, continue to use Shift-Alt-{W,L,P} to select word, line, and paragraph, and add to this list:
* Shift-Alt-J to vertically center ("jump") the window view on the current line (was Shift-Ctrl-L) * Shift-Alt-{Up,Down} to scroll the window up- and down-by-line.
For now, Ctrl-{Up,Down} can be left as is, until such time that someone wants to take the time to change that to up-/down-by-paragraph. Until then, users will probably be fine with using Ctrl-[ and Ctrl-].
Currently, the F-keys are used the way I'm proposing Shift-Alt be used. This is fine, and some users who really want certain F-key commands really at their fingertips may want to re-assign them to unused Shift-Alt key combos. :)
Finally then, this leaves us with the Ctrl-Alt modifier. I propose this be used for how Shift-Alt has previously been used: for special, possibly-less-used or advanced features. This would include:
* Ctrl-Alt-D to insert the date
And possibly these, having to do with changing case:
* Ctrl-Alt-U (think "all *U*pper or lowercase") to toggle selection between all upper and lowercase. * Ctrl-Alt-C ('c' for "capitalize") to make the current word start with a capital letter and then move the cursor to the end of that word * Ctrl-Alt-L ('l' for "lowercase") to make the current word start with a lowercase letter and then move the cursor to the end of that word
One last problem is possible key combo collisions with desktop managers. Geany cannot possibly sidestep collisions with all desktops. Since Geany (conveniently) uses Ctrl-Alt combos for lesser-used or advanced features, it can probably be best left to the user what they want to do. I know, for example, that I never use the Gnome Ctrl-Alt-{L,D} combos, and so will simply unmap them so Geany sees them. If someone else uses them, then they'll probably want to change Geany's defaults anyway.
---John
On 09/04/2007 12:57:45 AM, John Gabriele wrote:
[...] Geany is a powerful GUI programmer's editor. As such, we should be taking advantage of the key bindings available. This means using Ctrl-Alt ... as well as Shift-Alt.
I agree. I think you summed up everything well, thanks John.
[...] Now, Geany is also using Alt keys to deal with gui elements (including the Alt-1 and Alt-0 combos), and the Shift key to deal with selecting text (holding it down while navigating). I propose then, that Shift-Alt be specifically used for commands that either have to do with the GUI, or else with selecting text. That is, continue to use Shift-Alt-{W,L,P} to select word, line, and paragraph, and add to this list:
- Shift-Alt-J to vertically center ("jump") the window view on the
current line (was Shift-Ctrl-L)
Or maybe Shift-Alt-V for View current line?
- Shift-Alt-{Up,Down} to scroll the window up- and down-by-line.
I think we can use Alt-{Up,Down} for this. We can use both Alt-[^a-z] and Alt-Shift-{x} for GUI-related commands.
[...] Currently, the F-keys are used the way I'm proposing Shift-Alt be used. This is fine, and some users who really want certain F-key commands really at their fingertips may want to re-assign them to unused Shift-Alt key combos. :)
Yes, I think we'll keep the F-keys.
Finally then, this leaves us with the Ctrl-Alt modifier. I propose this be used for how Shift-Alt has previously been used: for special, possibly-less-used or advanced features. This would include:
- Ctrl-Alt-D to insert the date
I guess that's less common, so maybe we could use that even though it won't work by default on Gnome.
And possibly these, having to do with changing case:
- Ctrl-Alt-U (think "all *U*pper or lowercase") to toggle selection
between all upper and lowercase.
Not sure about that. It might be best to use ctrl-u for toggle case, unless there's something better to use ctrl-u for.
- Ctrl-Alt-C ('c' for "capitalize") to make the current word start
with a capital letter and then move the cursor to the end of that word
- Ctrl-Alt-L ('l' for "lowercase") to make the current word start
with a lowercase letter and then move the cursor to the end of that word
Maybe - but can you explain what situations would you use that?
One last problem is possible key combo collisions with desktop managers. Geany cannot possibly sidestep collisions with all desktops.
I think it's worth trying (in theory), especially for the most common desktops. E.g. we don't use Alt-F-key combos to avoid window manager conflicts. But it's probably OK for less common bindings.
<grumble> It'd be nice if Gnome used the super (a.k.a 'Windows' key) for things like show/lock desktop, but maybe they don't want to due to portability reasons. </grumble>
Regards, Nick
On 9/4/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 09/04/2007 12:57:45 AM, John Gabriele wrote:
[...] Geany is a powerful GUI programmer's editor. As such, we should be taking advantage of the key bindings available. This means using Ctrl-Alt ... as well as Shift-Alt.
I agree. I think you summed up everything well, thanks John.
:)
[...] Now, Geany is also using Alt keys to deal with gui elements (including the Alt-1 and Alt-0 combos), and the Shift key to deal with selecting text (holding it down while navigating). I propose then, that Shift-Alt be specifically used for commands that either have to do with the GUI, or else with selecting text. That is, continue to use Shift-Alt-{W,L,P} to select word, line, and paragraph, and add to this list:
- Shift-Alt-J to vertically center ("jump") the window view on the
current line (was Shift-Ctrl-L)
Or maybe Shift-Alt-V for View current line?
Yeah, that sounds good too. Either way.
- Shift-Alt-{Up,Down} to scroll the window up- and down-by-line.
I think we can use Alt-{Up,Down} for this. We can use both Alt-[^a-z] and Alt-Shift-{x} for GUI-related commands.
Oh, right you are.
[...]
Finally then, this leaves us with the Ctrl-Alt modifier. I propose
this be used for how Shift-Alt has previously been used: for special, possibly-less-used or advanced features. This would include:
- Ctrl-Alt-D to insert the date
I guess that's less common, so maybe we could use that even though it won't work by default on Gnome.
And possibly these, having to do with changing case:
- Ctrl-Alt-U (think "all *U*pper or lowercase") to toggle selection
between all upper and lowercase.
Not sure about that. It might be best to use ctrl-u for toggle case, unless there's something better to use ctrl-u for.
- Ctrl-Alt-C ('c' for "capitalize") to make the current word start
with a capital letter and then move the cursor to the end of that word
- Ctrl-Alt-L ('l' for "lowercase") to make the current word start
with a lowercase letter and then move the cursor to the end of that word
Maybe - but can you explain what situations would you use that?
I've used these occasionally while re-writing plain text ... breaking long sentences in two, or gluing short ones together, or just editing something that's not capitalized correctly. It's not used all that often, but once in a while. Emacs has similar bindings: Alt-C, Alt-L, and Alt-U, where Alt-L makes the whole remainder of the word (noting cursor position) lowercase, then moves the cursor to the end of the word. Alt-U does likewise, but uppercase. Alt-C capitalizes the letter below the cursor, even mid-word (or in front of the cursor, if on whitespace). I haven't yet needed these commands when dealing with code though.
I hesitate to suggest using Ctrl-U, just because changing case does not seem like something that's needed terribly often, and also because Ctrl-Alt-U could possibly be used along with the Ctrl-Alt-{C,L}, keeping things more consistent (that is, all key combos dealing with case would be Ctrl-Alt keys).
Also, those Ctrl-foo keys are pretty valuable keyboard real estate. :) I keep feeling like you're going to find something really useful and common that you're going to want to use them for. For example, after loading a tags file, personally, I'd expect to use Ctrl-< to go to tag definition, and use Ctrl-> to go back to where I previously was, but seeing as how Enrico seems to often prefer using letters, I could see him wanting to use Ctrl-J to *j*ump to tag definition, and possibly Ctrl-U to go back *u*p the tag stack ...
One last problem is possible key combo collisions with desktop managers. Geany cannot possibly sidestep collisions with all desktops.
I think it's worth trying (in theory), especially for the most common desktops. E.g. we don't use Alt-F-key combos to avoid window manager conflicts. But it's probably OK for less common bindings.
<grumble> It'd be nice if Gnome used the super (a.k.a 'Windows' key) for things like show/lock desktop, but maybe they don't want to due to portability reasons. </grumble>
Seems like the Gnome keyboard shortcuts are a bit of a hodge podge of mostly Ctrl-Alt-foo and Alt-F_keys, with some Shift-Ctrl-Alt-keys sprinkled in for finger calisthenics. ;)
---John
On Tue, 4 Sep 2007 09:41:13 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 9/4/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 09/04/2007 12:57:45 AM, John Gabriele wrote:
[...] Geany is a powerful GUI programmer's editor. As such, we should be taking advantage of the key bindings available. This means using Ctrl-Alt ... as well as Shift-Alt.
I agree. I think you summed up everything well, thanks John.
+1.
Finally then, this leaves us with the Ctrl-Alt modifier. I propose
this be used for how Shift-Alt has previously been used: for special, possibly-less-used or advanced features. This would include:
- Ctrl-Alt-D to insert the date
I guess that's less common, so maybe we could use that even though it won't work by default on Gnome.
Hmm, I don't like this. We set a keybinding while knowing it won't work on Gnome? Not that I'm a Gnome fan but I guess there are several people using Geany on Gnome(GTK2...). So, I would agree with John and change it to Ctrl-Alt-D.
And possibly these, having to do with changing case:
- Ctrl-Alt-U (think "all *U*pper or lowercase") to toggle
selection between all upper and lowercase.
I would prefer toggling as suggested by Nick and using Ctrl-U.
- Ctrl-Alt-C ('c' for "capitalize") to make the current word start
with a capital letter and then move the cursor to the end of that word
- Ctrl-Alt-L ('l' for "lowercase") to make the current word start
with a lowercase letter and then move the cursor to the end of that word
Maybe - but can you explain what situations would you use that?
I've used these occasionally while re-writing plain text ... breaking long sentences in two, or gluing short ones together, or just editing something that's not capitalized correctly. It's not used all that
This is somewhat I would expect to be used very rarely and so I don't think we really need this. When ever keybindings work together with plugins someone could just write a plugin to add it.
I hesitate to suggest using Ctrl-U, just because changing case does not seem like something that's needed terribly often, and also because
Maybe not used very often by you. I don't use it that often too, but sometimes I'm really happy this feature exists. I don't know how often other users use it.
Also, those Ctrl-foo keys are pretty valuable keyboard real estate. :) I keep feeling like you're going to find something really useful and common that you're going to want to use them for. For example, after loading a tags file, personally, I'd expect to use Ctrl-< to go to tag definition, and use Ctrl-> to go back to where I previously was, but seeing as how Enrico seems to often prefer using letters, I could see
There is even a reason why I do this ;-). For example, take Ctrl+{[,]}: on a German keyboard you have to press Ctrl-Alt GR-{8,9}. And as one mentioned in the first keybindings thread on some keyboard it is even necessary to use a modifier to just type numbers. The letters a-z should be on most keyboards accessable without any other action and so IMO we should prefer these letters whenever possible.
Regards, Enrico
On 9/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 4 Sep 2007 09:41:13 -0400, "John Gabriele" jmg3000@gmail.com wrote:
Finally then, this leaves us with the Ctrl-Alt modifier. I propose
this be used for how Shift-Alt has previously been used: for special, possibly-less-used or advanced features. This would include:
- Ctrl-Alt-D to insert the date
I guess that's less common, so maybe we could use that even though it won't work by default on Gnome.
Hmm, I don't like this. We set a keybinding while knowing it won't work on Gnome? Not that I'm a Gnome fan but I guess there are several people using Geany on Gnome(GTK2...). So, I would agree with John and change it to Ctrl-Alt-D.
Just to be clear, Gnome already uses Ctrl-Alt-D for something. I was proposing that Geany go ahead and use that combo anyway, letting users decide what to do with it. I think Nick had agreed with me, possibly figuring that that key combo isn't used too often on Gnome anyway.
Geany's insert-date doesn't *have* to be Ctrl-Alt-D. You could always use something else, like Ctrl-Alt-T (for "Today" or "Time"). Unless someone can think of an opposite or extension of duplicate-line, I suppose you could use Shift-Ctrl-D to insert the date, if that's a feature you use a lot. My hunch is that there's probably some other future Geany feature lurking around that you'll want to use Shift-Ctrl-D for, but I'm not sure what that would be yet... ;)
[snip]
Also, those Ctrl-foo keys are pretty valuable keyboard real estate. :) I keep feeling like you're going to find something really useful and common that you're going to want to use them for. For example, after loading a tags file, personally, I'd expect to use Ctrl-< to go to tag definition, and use Ctrl-> to go back to where I previously was, but seeing as how Enrico seems to often prefer using letters, I could see
There is even a reason why I do this ;-).
Yup, you've explained why in the past.
For example, take Ctrl+{[,]}: on a German keyboard you have to press Ctrl-Alt GR-{8,9}.
All the more reason to change up-/down-by-paragraph to Ctrl-{Up,Down}. :) Is there any way to override the built-in GTK default of scrolling the view with those keys?
If that's not possible, in the interim, maybe you could use Ctrl-Alt-N ("next") and Ctrl-Alt-P ("previous")?
And as one mentioned in the first keybindings thread on some keyboard it is even necessary to use a modifier to just type numbers. The letters a-z should be on most keyboards accessable without any other action and so IMO we should prefer these letters whenever possible.
Check.
---John
On Tue, 4 Sep 2007 12:53:58 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 9/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 4 Sep 2007 09:41:13 -0400, "John Gabriele" jmg3000@gmail.com wrote:
Finally then, this leaves us with the Ctrl-Alt modifier. I propose
this be used for how Shift-Alt has previously been used: for special, possibly-less-used or advanced features. This would include:
- Ctrl-Alt-D to insert the date
I guess that's less common, so maybe we could use that even though it won't work by default on Gnome.
Hmm, I don't like this. We set a keybinding while knowing it won't work on Gnome? Not that I'm a Gnome fan but I guess there are several people using Geany on Gnome(GTK2...). So, I would agree with John and change it to Ctrl-Alt-D.
Just to be clear, Gnome already uses Ctrl-Alt-D for something. I was proposing that Geany go ahead and use that combo anyway, letting users
Oops. Sorry, I should read what I've written before sending to the world ;-). Again, I don't like the idea to set a keybinding which can't be used by a certain amount of users(read Gnome users). I don't care about the keyboard shortcut actually used, maybe Ctrl-Alt-T or even undefined, I just don't like to set something which we know to not work on several systems.
For example, take Ctrl+{[,]}: on a German keyboard you have to press Ctrl-Alt GR-{8,9}.
All the more reason to change up-/down-by-paragraph to Ctrl-{Up,Down}. :) Is there any way to override the built-in GTK default of scrolling the view with those keys?
It is not a GTK built-in default but a Scintilla one and it can be disabled/changed.
Regards, Enrico
On Tue, 04 Sep 2007 12:17:07 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
[...] Currently, the F-keys are used the way I'm proposing Shift-Alt be used. This is fine, and some users who really want certain F-key commands really at their fingertips may want to re-assign them to
I can't understand why you have such a big antipathy against the F-keys ;-). Seriously, I don't believe I'm the only one who likes to use the F-keys. One reason should be that many(or even most [besides Emacs ;-)]) apps use the F-keys by default.
Regards, Enrico
On 9/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 04 Sep 2007 12:17:07 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
[...] Currently, the F-keys are used the way I'm proposing Shift-Alt be used. This is fine, and some users who really want certain F-key commands really at their fingertips may want to re-assign them to
I can't understand why you have such a big antipathy against the F-keys ;-). Seriously, I don't believe I'm the only one who likes to use the F-keys. One reason should be that many(or even most [besides Emacs ;-)]) apps use the F-keys by default.
I probably use my editor more than all the other apps on my system combined. And most of that time, my fingers on on the home row. I can hit Ctrl, Shift-Ctrl, Alt, Shift-Alt, and Ctrl-Alt just fine and zoom around the editor and text files with those keys without removing my hands from the home row. Having to resort to using an F-key throws a monkeywrench into the works and I've got to remove my hands *and* look down to find those F-keys.
I'm not saying don't use F-keys, I'm just saying that users who are using Geany as a programmer's editor may want to remap certain commands from F-keys to Shift-Alt keys, to make them easier to reach while working. So it's good to have that option available (which Geany provides). Using Shift-Alt (or Alt) specifically for dealing with GUI-related elements not only makes it easier to memorize the Geany key combos (since we can group them mentally a little better, ie: "Shift-Alt has to do either with selecting text or dealing with a GUI feature"), but it also means that there's probably going to be a fair number of Shift-Alt combos available (with no default mapping), so that gives users a place to move some of those F-key mappings to, if they wish.
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").
---John
On Tue, 4 Sep 2007 12:27:32 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 9/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 04 Sep 2007 12:17:07 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
[...] Currently, the F-keys are used the way I'm proposing Shift-Alt be used. This is fine, and some users who really want certain F-key commands really at their fingertips may want to re-assign them to
I can't understand why you have such a big antipathy against the F-keys ;-). Seriously, I don't believe I'm the only one who likes to use the F-keys. One reason should be that many(or even most [besides Emacs ;-)]) apps use the F-keys by default.
I probably use my editor more than all the other apps on my system combined. And most of that time, my fingers on on the home row. I can hit Ctrl, Shift-Ctrl, Alt, Shift-Alt, and Ctrl-Alt just fine and zoom around the editor and text files with those keys without removing my hands from the home row. Having to resort to using an F-key throws a monkeywrench into the works and I've got to remove my hands *and* look down to find those F-keys.
Hehe, I have more problems to press Shift-Alt than pressing blindly any F key. And for pressing any F key I need only one finger, for pressing any key together with Shift-Alt I need in most cases even both hands. All what I want to say is that not all people dislike the F keys.
Regards, Enrico
On 9/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 4 Sep 2007 12:27:32 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 9/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 04 Sep 2007 12:17:07 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
[...] Currently, the F-keys are used the way I'm proposing Shift-Alt be used. This is fine, and some users who really want certain F-key commands really at their fingertips may want to re-assign them to
I can't understand why you have such a big antipathy against the F-keys ;-). Seriously, I don't believe I'm the only one who likes to use the F-keys. One reason should be that many(or even most [besides Emacs ;-)]) apps use the F-keys by default.
I probably use my editor more than all the other apps on my system combined. And most of that time, my fingers on on the home row. I can hit Ctrl, Shift-Ctrl, Alt, Shift-Alt, and Ctrl-Alt just fine and zoom around the editor and text files with those keys without removing my hands from the home row. Having to resort to using an F-key throws a monkeywrench into the works and I've got to remove my hands *and* look down to find those F-keys.
Hehe, I have more problems to press Shift-Alt than pressing blindly any F key. And for pressing any F key I need only one finger, for pressing any key together with Shift-Alt I need in most cases even both hands. All what I want to say is that not all people dislike the F keys.
Cool. Then some users will keep and continue to use the F-key defaults, and others will have the Shift-Alt modifier available if they want to remap.
My argument here is simply that, for a variety of reasons previously mentioned, it seems right (IMO) to use Shift-Alt primarily for selecting text and for dealing with GUI elements. The F-keys also happen to be used for dealing with GUI elements (often (but not always) in the sense of switching between gui panes like the search bar, vte, scribble, editor window, etc.). This is merely a happy coincidence, and if users want to remap some F-keys in their own keybindings.conf, it's nice that they've got a nice set of roped-off key combos they can stake out for that purpose: namely, the Shift-Alt prefixed keys.
The biggest factor, IMO, is that when you consistently section off key combos into groups, for example:
* Ctrl- is for common and well-known editor features * Shift-Ctrl- is most often either an extension of, or opposite version of, Ctrl- * Alt- is (as usual) for menus and other GUI elements * Shift- is (as usual) most often for selecting text while you move the cursor via the keyboard * Shift-Alt- is for selecting text and manipulating gui elements * Ctrl-Alt- is for lesser-used or else advanced editor features * Shift-Ctrl-Alt is strictly for easter eggs ;)
they become easier to remember (and easier for your fingers to remember). I think Geany could use the extra key combos you get when using *both* Shift-Alt and Ctrl-Alt, but if key combos just get randomly assigned with both prefixes, I think it will make things very difficult to remember.
---John
On 09/04/2007 05:27:32 PM, John Gabriele wrote:
On 9/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 04 Sep 2007 12:17:07 +0100, Nick Treleaven nick.treleaven@btinternet.com 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.
Also, I think I mentioned before that Escape will focus the editor when the search bar or goto line field is focussed.
Regards, Nick
On 9/5/07, Nick Treleaven nick.treleaven@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
On 09/06/2007 08:36:56 AM, John Gabriele wrote:
On 9/5/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
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?
Maybe, not sure yet.
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
At the moment I'm undecided about what to group under Alt-Shift and Ctrl-Alt. Personally I think I need to meditate on this for a while until everything feels right, so maybe decide after the 0.12 release.
- 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...
I'm thinking of adding something like 'select scope' which uses the current fold level. Or did you mean () brackets for selecting e.g. an argument list for a function?
- Alt-{PgUp,PgDn} -- scroll back and forward through editor tabs
(seems to follow nicely with the other Alt key commands, right?).
I don't like that. Users are used to Ctrl-{PgUp,PgDn} e.g. in browsers.
- 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?
I'm thinking of adding something like that, that's easier to type than the number keys.
Regards, Nick
On Thu, 06 Sep 2007 13:22:52 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 09/06/2007 08:36:56 AM, John Gabriele wrote:
On 9/5/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
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?
Maybe, not sure yet.
I would suggest to use a separate search button. One button for usual forward and one for backward search. Maybe the buttons could be put horizontal splitted. But we shouldn't talk about minor GUI stuff until the feature isn't implemented at all ;-).
- Alt-{PgUp,PgDn} -- scroll back and forward through editor tabs
(seems to follow nicely with the other Alt key commands, right?).
I don't like that. Users are used to Ctrl-{PgUp,PgDn} e.g. in browsers.
I agree.
- 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?
I'm thinking of adding something like that, that's easier to type than the number keys.
Yes sounds good. Alt-{Home,End} are currently used by Scintilla for "Go to start/end of display line." but I guess we could drop this binding without replacement(IMO).
Regards, Enrico
On 09/06/2007 05:16:13 PM, Enrico Tröger wrote:
On Thu, 06 Sep 2007 13:22:52 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 09/06/2007 08:36:56 AM, John Gabriele wrote:
- 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?
I'm thinking of adding something like that, that's easier to type than the number keys.
Yes sounds good. Alt-{Home,End} are currently used by Scintilla for "Go to start/end of display line." but I guess we could drop this binding without replacement(IMO).
I think we could use Ctrl-Shift-{PgDn, PgUp} for this. Then it's just a Shift extension of switching notebook pages normally.
Also, I'm thinking of adding Alt-{PgDn, PgUp} to move the current tab, with wraparound.
Regards, Nick
On Thu, 6 Sep 2007 03:36:56 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- Ctrl-Alt-T -- insert date ("*t*oday", or "*t*ime") (Ctrl-Alt-D would
be a collision with a Gnome binding)
Yes.
- 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
He does ;-). But I can have my own keybindings.conf where the default of Ctrl-Alt-U is changed to Ctrl-U ;-). We don't need to take care of any of my personal preferences even though it's a nice idea...
Regards, Enrico
On Mon, 3 Sep 2007 19:57:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- The Alt keys are used for dealing with menus and menu items.
Just to clarify this because it sounds (for me) like this behaviour is something specific to Geany. But menu item mnemonics(the underlined letters in the menu item title) are very common on almost all graphical user interfaces I ever seen(including Motif, Qt, GTK and Windows). Accessing a desired submenu or menu item with Alt-{underlined letter} is common in the same way. So, this isn't anything specific to Geany neither did we choose to use it. And even if we would not use the accelerators in the menu items we couldn't remove them all because some are set by GTK itself and so not using them would be again inconsistent and uncommon with other GUI apps.
Regards, Enrico