Hi,
I'd like to see Geany's default key combo choices be as optimized and clean as possible. This is a long post -- I hope it's useful. The seeds of this post were planted in a post I made here back on May 8.
In my experience, some editors' key-combos are easier than others for brain and fingers to remember. I think a large part has to do with choices regarding key-combinations. Aside from some common Gnome/GTK+ keys combinations such as:
* Ctrl-o to open a file, * Ctrl-s to save, * Ctrl-f to find, * Ctrl-arrow_key to move by-word or by-paragraph, * Ctrl-BackSpace to delete back, * and so on,
I see 9 major ways text editors use keys to activate commands. Those 9 ways are noted below, along with examples of Geany using most of them. The purpose of this longish post is to help tune Geany's editing component for maximum ease of use, memorability, uniformity, and editing speed (that is, sans mouse).
It seems to me that some ways of handling key combos are easier to use and remember than others. Also, an editor that sticks to some minimum number of those patterns seems to be easier to use. Here's the patterns I notice, along with example Geany commands:
1. Hit a key to toggle something.
* Ctrl-B (comment/uncomment line) * Ctrl-M (set/unset marker) * F11 * Ctrl-T (transpose lines)
2. Hit a key to do something, then Shift-key to reverse it.
* Ctrl-I, Shift-Ctrl-I * Ctrl-G, Shift-Ctrl-G * Ctrl-U, Shift-Ctrl-U * Tab, Shift-Tab
3. Hit a Ctrl-key to do something, then Shift-Ctrl-key to do even more, or maybe a similar thing but with a twist.
* Ctrl-F, Shift-Ctrl-F * Ctrl-O, Shift-Ctrl-O * Ctrl-S, Shift-Ctrl-S * Ctrl-W, Shift-Ctrl-W * Ctrl-R, Shift-Ctrl-R
4. Ctrl-key to do an action, Alt-key to do something similar, but with a twist.
5. A key to do one thing, and a separate key to do its opposite.
* Ctrl-+, Ctrl-- * Ctrl-., Ctrl-, * Ctrl-[, Ctrl-]
6. Ones that use the fancy named keys.
* Ctrl-PgUp, Ctrl-PgDn * etc... (a lot of the #3 and #4 style, above)
7. Alt-key, and Shift-Alt-key to do a variation on Alt-key.
8. Using the F_keys (at the top of the keyboard). Shift-F_key just like Shift-Ctrl-key and Shift-Alt-key.
* F3, Shift-F3 * F9, Shift-F9, Shift-Ctrl-F9
9. Ctrl-Alt-key, Alt-F_key, Shift-Ctrl-F_key .... yikes.
Here's what I've found regarding using those various key- combination patterns:
* Item 1. Toggling is fast and intuitive if the feature that it activates makes sense to toggle. Also nice is that it only uses up one key combo.
* Item 2. Using Shift to reverse an action doesn't feel right. I think brain and fingers tend to associate a key with an action, and shifting it should do something similar in some way, not opposite.
* Item 3. Using Shift to "extend" an action seems quite intuitive. Using Shift to also deal with selecting text (with arrow keys) does not seem to cause any confusion here.
* Item 4. This can feel intuitive once you get used to it, but will likely be confusing if using Shift like in item 3 above.
* Item 5. Intuitive, and works fine you've got Ctrl-key combos to burn.
* Item 6. Pretty much the default for GUI apps. Like 'em or not, we've got 'em.
* Item 7. Using Alt-key/Shift-Alt-key is analagous to item 3 above and works very well. Good for either less often used functions, or maybe specialized or fancier ones. Although some Alt-key's get used to activate menus, there's plenty left over for other uses.
* Item 8. These are awful for heavy use (they're a mile away from the home row!) and, IMO, should only be used for seldom-used commands (ex. window-related functions, build commands). There's no way one can successfully hit them during serious editing without having to look down at the keyboard and take a hand off the home row.
* Item 9. Here be dragons (that is, these are the ones that are tougher to remember, or that risk interefering with the window manager).
So, given all that, to even more finely tune Geany's editing environment, here's my suggestions:
A. Get rid of using Shift to make a key combo do the opposite (item 2 above). This includes:
* Ctrl-I, Shift-Ctrl-I --> Not needed. See below. * Ctrl-G, Shift-Ctrl-G --> Use Ctrl-G to toggle. * Ctrl-U, Shift-Ctrl-U --> Use Ctrl-U to toggle. Then use Shift-Ctrl-U to toggle first-letter capitalization. Yes. :) * Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
B. Fix an oddball case:
* Shift-Alt-D for insert date. This one's not too bad, but falls outside of the uniformity of having Shift-Alt-key be a fancy version of Alt-key. Maybe use Alt-I (for "insert")?
C. The mortal sin: Incremental search. Geany's Achilles' heel. One of an editors' most-useful features, it should be be effortless to do forward and backward incremental searches. As implemented, if I want to incrementally search forward, I need to hit F7, tap F3 to get to the one I want, then F2 to get back to the editor. So, I've basically got to spend the entire search looking at my hands instead of the text. It's even worse to search backward incrementally -- not sure I can even do this. Here's my proposed solution. Buckle seatbelts, and please observe the no-smoking signs:
1. Steal Ctrl-T. Use it for forward incremental search (think of it as "to" or "incremen*t*al"). Same as today's F7. Move "transpose lines" to Shift-Ctrl-L. 2. Shift-Ctrl-T gets you find next (like F3). 3. Use Alt-T to start a reverse incremental search (Use Alt-O to get the Tools menu). 4. Shift-Alt-T gets you find previous. Nice consistency here, I think. 5. Hitting Ctrl-LeftArrow or Ctrl-RightArrow should snap you out of the incremental search and back to the main editor window (instead of today's F2). After an incremental search, you often either want to go to the beginning or end of the word you found anyway.
When you're in an incremental search, regardless of direction, you should be able to tap either Shift-Ctrl-T to find next, or Shift-Alt-T to find previous.
Finally, some new key combos to possibly add that would probably be pretty useful, and don't stomp too much on anything else:
1. Select line. Use Alt-L 2. Select paragraph. Use Alt-P (switch Project menu to Alt-R) 3. Select word. Use Alt-W
Please let me know what you think.
By the way, I know that I can just change many of the above- mentioned key-bindings myself. But the point is, I think Geany might benefit from some discussion on optimizing some of its defaults.
Incidentally, can someone please point me to the docs on creating my own ~/.geany/keybindings.conf? I looked in the "Keybindings" and "Configuration files" chapters of the manual, but didn't see any info.
Thanks, ---John
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele" jmg3000@gmail.com wrote:
Hi all,
[...] So, given all that, to even more finely tune Geany's editing environment, here's my suggestions:
A. Get rid of using Shift to make a key combo do the opposite (item 2 above). This includes:
- Ctrl-G, Shift-Ctrl-G --> Use Ctrl-G to toggle.
No. Then you can't double comment a line. Ok, uses should be not that much but e.g. when commenting a block of code including some commented lines this would uncomment these particular lines which is mostly unintended. Maybe we could change Ctrl+B to Alt+G but it would be just a change of the default binding.
- Ctrl-U, Shift-Ctrl-U --> Use Ctrl-U to toggle. Then use Shift-Ctrl-U to toggle first-letter capitalization. Yes. :)
What about this string "aBcD" -> toggle to lower or upper case?
- Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
Who needs indentation by one space? I want to keep the Tab/Shift-Tab behaviour because I think it is very commonly. But because of talking about indentation: I plan to add a feature to auto indent current line by pressing a key. This means, the current line will be indented according to the previous line independent of the current indentation(maybe too less or too much indentation). My suggestion: Alt+I to be similar to Ctrl+I / Ctrl+Shift+I
B. Fix an oddball case:
- Shift-Alt-D for insert date. This one's not too bad, but falls outside of the uniformity of having Shift-Alt-key be a fancy version of Alt-key. Maybe use Alt-I (for "insert")?
Hmm, not sure whether it is better to change the binding for uniformity which maybe breaks users habits. On the other hand, Insert Custom Date is maybe not an every day used binding.
C. The mortal sin: Incremental search. Geany's Achilles' heel. One of an editors' most-useful features, it should be be effortless to do forward and backward incremental searches. As implemented, if I want to incrementally search forward, I need to hit F7, tap F3 to get to the one I want, then F2 to get back to the editor. So, I've basically got to spend the entire search looking at my hands instead of the text. It's even worse to search backward incrementally -- not sure I can even do this. Here's my proposed solution. Buckle seatbelts, and please observe the no-smoking signs:
- Steal Ctrl-T. Use it for forward incremental search (think of it as "to" or "incremen*t*al"). Same as today's F7. Move "transpose lines" to Shift-Ctrl-L.
- Shift-Ctrl-T gets you find next (like F3).
- Use Alt-T to start a reverse incremental search (Use Alt-O to get the Tools menu).
- Shift-Alt-T gets you find previous. Nice consistency here, I think.
- Hitting Ctrl-LeftArrow or Ctrl-RightArrow should snap you out of the incremental search and back to the main editor window (instead of today's F2). After an incremental search, you often either want to go to the beginning or end of the word you found anyway.
When you're in an incremental search, regardless of direction, you should be able to tap either Shift-Ctrl-T to find next, or Shift-Alt-T to find previous.
Basically good idea, anyway I prefer to keep F3 and Shift+F3 for searching forwards and backwards just because of its common usage (remember Geany != Emacs ;-)). And IMO the F-keys are not that far away from the main keys (or my fingers are just a bit longer ;-)). But we can surely improve the current behaviour of incremental search.
Finally, some new key combos to possibly add that would probably be pretty useful, and don't stomp too much on anything else:
- Select line. Use Alt-L
- Select paragraph. Use Alt-P (switch Project menu to Alt-R)
Above two sound nice. Could be implemented.
- Select word. Use Alt-W
Already present. Look for the binding "Select current word".
In general, Alt+letter key bindings are not very good for GUI apps. Because Alt+letter opens a file menu item where letter is used as a mnemonic(the underlined letter in the file menu item). And remember, the file menu items are translatable. I.e. you can't know which Alt +letter keybinding is used in any translation for any file menu item (I only speak of the first level menu items, File, Edit, View, ...). An example: Alt+T opens the Tools file menu item in Geany without any translation. To open this menu in Geany with a German translation you need Alt+W (German translation is "Werkzeuge").
Incidentally, can someone please point me to the docs on creating my own ~/.geany/keybindings.conf? I looked in the
No docs so far. Just open the preferences dialog, keybindings tab and change what you like to. After that, the file ~/.geany/keybindings.conf is created with your changed settings.
Regards, Enrico
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele" jmg3000@gmail.com wrote:
[snip]
- Ctrl-U, Shift-Ctrl-U --> Use Ctrl-U to toggle. Then use Shift-Ctrl-U to toggle first-letter capitalization. Yes. :)
What about this string "aBcD" -> toggle to lower or upper case?
I've found that the only times I need to mess with capitalization are:
1. When I've got a capitalized word that starts a sentence, but I add a word in front of it, so need to make the capitalized word lowercase. Likewise if I delete some words at the beginning of a sentence and want the next one to start the sentence, I need to capitalize it. Also sometimes when hopping through a sentence word-by-word and need to capitalize some proper names. Not *too* common, but sometimes handy.
2. To either make something all caps, or to make something all lowercase if someone was yelling at me. :)
I've never had to swap case as you describe. What situation would one need to do that?
- Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
Who needs indentation by one space?
When you select some text (say, you're cleaning up some poorly-indented code), and you need to shift it around but aren't exactly sure what column you need it at. You "tap right a few times, left, ah -- got it".
Also sometimes if you're putting ascii-art things in your comments (like primitive diagrams with boxes and arrows) and you're trying to make them line up right.
Also if you're writing out a list:
* one * two * two point five * two point seven five plus epsilon * two point eight * two point nine * whoops -- indented these last lines wrong.
and need to move those last lines out by 2 spaces.
I want to keep the Tab/Shift-Tab behaviour because I think it is very commonly.
Yeah, it is pretty common.
But because of talking about indentation: I plan to add a feature to auto indent current line by pressing a key. This means, the current line will be indented according to the previous line independent of the current indentation(maybe too less or too much indentation).
Heh. That sounds exactly like what Emacs does. :)
My suggestion: Alt+I to be similar to Ctrl+I / Ctrl+Shift+I
Yeah, those fit together well.
[snip]
C. The mortal sin: Incremental search. Geany's Achilles' heel. One of an editors' most-useful features, it should be be effortless to do forward and backward incremental searches. As implemented, if I want to incrementally search forward, I need to hit F7, tap F3 to get to the one I want, then F2 to get back to the editor. So, I've basically got to spend the entire search looking at my hands instead of the text. It's even worse to search backward incrementally -- not sure I can even do this. Here's my proposed solution. Buckle seatbelts, and please observe the no-smoking signs:
- Steal Ctrl-T. Use it for forward incremental search (think of it as "to" or "incremen*t*al"). Same as today's F7. Move "transpose lines" to Shift-Ctrl-L.
- Shift-Ctrl-T gets you find next (like F3).
- Use Alt-T to start a reverse incremental search (Use Alt-O to get the Tools menu).
- Shift-Alt-T gets you find previous. Nice consistency here, I think.
- Hitting Ctrl-LeftArrow or Ctrl-RightArrow should snap you out of the incremental search and back to the main editor window (instead of today's F2). After an incremental search, you often either want to go to the beginning or end of the word you found anyway.
When you're in an incremental search, regardless of direction, you should be able to tap either Shift-Ctrl-T to find next, or Shift-Alt-T to find previous.
Basically good idea, anyway I prefer to keep F3 and Shift+F3 for searching forwards and backwards just because of its common usage (remember Geany != Emacs ;-)). And IMO the F-keys are not that far away from the main keys (or my fingers are just a bit longer ;-)). But we can surely improve the current behaviour of incremental search.
Well, if there's a command like F7 but which starts the search going the opposite way, then it looks like users can customize the behaviour to get the above, if they want it. Can we get a Shift-F7 ("reverse searchbar search") so I can remap it to Alt-T? :)
Without having Ctrl-arrow_key to get out of the incremental search box, for now, it's easy enough to remap F2 to somewhere else I suppose.
Finally, some new key combos to possibly add that would probably be pretty useful, and don't stomp too much on anything else:
- Select line. Use Alt-L
- Select paragraph. Use Alt-P (switch Project menu to Alt-R)
Above two sound nice. Could be implemented.
- Select word. Use Alt-W
Already present. Look for the binding "Select current word".
Nice! Didn't see that in there. :) Thanks.
In general, Alt+letter key bindings are not very good for GUI apps. Because Alt+letter opens a file menu item where letter is used as a mnemonic(the underlined letter in the file menu item). And remember, the file menu items are translatable. I.e. you can't know which Alt +letter keybinding is used in any translation for any file menu item (I only speak of the first level menu items, File, Edit, View, ...). An example: Alt+T opens the Tools file menu item in Geany without any translation. To open this menu in Geany with a German translation you need Alt+W (German translation is "Werkzeuge").
Oh my. Hm. Didn't realize they changed for different languages.
Ok, well, I see that the Preferences --> Keybindings tab does not provide a way to change the keybindings for activating menus. If I assign a command to a key binding that's already used for a menu, the function I assigned it to seems to get precedence.
So, currently, if I use an Alt key that's already being used for a menu, then I lose the ability to activate that menu via the keyboard. If you're committed to using those menu name first letters along with changing them for various translations, then users will just have to live with stealing Alt key bindings sometimes.
Personally, the only time I've ever used the Alt keys to activate menus was once a long time ago when my mouse got unplugged somehow while using a GUI and I needed to save and shutdown the computer. :) But maybe other folks use them regularly.
Incidentally, can someone please point me to the docs on creating my own ~/.geany/keybindings.conf? I looked in the
No docs so far. Just open the preferences dialog, keybindings tab and change what you like to. After that, the file ~/.geany/keybindings.conf is created with your changed settings.
Ah. Sweet. I see: change one, and they all show up in the keybindings.conf file. Nice.
---John
On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele" jmg3000@gmail.com wrote:
[snip]
- Ctrl-U, Shift-Ctrl-U --> Use Ctrl-U to toggle. Then use Shift-Ctrl-U to toggle first-letter capitalization. Yes. :)
What about this string "aBcD" -> toggle to lower or upper case?
I've found that the only times I need to mess with capitalization are:
- When I've got a capitalized word that starts a sentence, but I add
a word in front of it, so need to make the capitalized word lowercase. Likewise if I delete some words at the beginning of a sentence and want the next one to start the sentence, I need to capitalize it. Also sometimes when hopping through a sentence word-by-word and need to capitalize some proper names. Not *too* common, but sometimes handy.
- To either make something all caps, or to make something all
lowercase if someone was yelling at me. :)
I've never had to swap case as you describe. What situation would one need to do that?
I came across this situation several times when copying text from somehwere or when writing code and copying some descriptive text("Show XYZ") as a variable name("show_xyz"). Then I lower down the string. I could also just rewrite it but why? I'm lazy and Geany can lower down the string. But when only toggle is available Geany would have to dice to choose whether I want the string in lower or upper case.
Is it really a problem to have two key bindings for that? AFAIK I always seen two bindings resp. two actions for lowering or uppering the case in other apps.
- Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
Who needs indentation by one space?
When you select some text (say, you're cleaning up some poorly-indented code), and you need to shift it around but aren't exactly sure what column you need it at. You "tap right a few times, left, ah -- got it".
Hmm, usually I do this by removing all indentation(Ctrl+Shift+I several times) and then re-indent the code as I like. Not necessarily faster but safer especially when the code was indented with spaces and you want to indent by tabs(my preference as you know ;-)).
Also sometimes if you're putting ascii-art things in your comments (like primitive diagrams with boxes and arrows) and you're trying to make them line up right.
Also if you're writing out a list:
- one
- two
- two point five
- two point seven
five plus epsilon
- two point eight
- two point nine
- whoops -- indented these last lines wrong.
and need to move those last lines out by 2 spaces.
Ok, but is it too hard to just use the space key in combination with the cursor keys for navigation? Yes this needs more work, more keystrokes but IMO it is a quite seldom use case.
But because of talking about indentation: I plan to add a feature to auto indent current line by pressing a key. This means, the current line will be indented according to the previous line independent of the current indentation(maybe too less or too much indentation).
Heh. That sounds exactly like what Emacs does. :)
Yes, it was suggested by a new Geany user who switched from Emacs ;-).
In general, Alt+letter key bindings are not very good for GUI apps. Because Alt+letter opens a file menu item where letter is used as a mnemonic(the underlined letter in the file menu item). And remember, the file menu items are translatable. I.e. you can't know which Alt +letter keybinding is used in any translation for any file menu item (I only speak of the first level menu items, File, Edit, View, ...). An example: Alt+T opens the Tools file menu item in Geany without any translation. To open this menu in Geany with a German translation you need Alt+W (German translation is "Werkzeuge").
Oh my. Hm. Didn't realize they changed for different languages.
They have to change. To keep the above example: "Werkzeuge" is the German translation(better: one of the possible translations) and it contains no 't', so how should the mnemonic keep?
Ok, well, I see that the Preferences --> Keybindings tab does not provide a way to change the keybindings for activating menus. If I
Because they can't be changed AFAIK and they shouldn't. They are defined by the translation.
So, currently, if I use an Alt key that's already being used for a menu, then I lose the ability to activate that menu via the keyboard. If you're committed to using those menu name first letters along with changing them for various translations, then users will just have to live with stealing Alt key bindings sometimes.
Personally, the only time I've ever used the Alt keys to activate menus was once a long time ago when my mouse got unplugged somehow while using a GUI and I needed to save and shutdown the computer. :) But maybe other folks use them regularly.
Personally, I don't use the keyboard to activate the file menu, too. But I guess there are many people who uses the mnemonics because it is a very common way of accessing the menus. So, IMO removing or overriding these mnemonics by default is no option.
Incidentally, can someone please point me to the docs on creating my own ~/.geany/keybindings.conf? I looked in the
No docs so far. Just open the preferences dialog, keybindings tab and change what you like to. After that, the file ~/.geany/keybindings.conf is created with your changed settings.
Ah. Sweet. I see: change one, and they all show up in the keybindings.conf file. Nice.
Yes, this file is created once you changed any of the default keybindings and in general there should be no need to manually edit the file because every available and configurable keybinding can be changed in the preferences dialog.
Regards, Enrico
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele" jmg3000@gmail.com wrote:
[snip]
- Ctrl-U, Shift-Ctrl-U --> Use Ctrl-U to toggle. Then use Shift-Ctrl-U to toggle first-letter capitalization. Yes. :)
What about this string "aBcD" -> toggle to lower or upper case?
I've found that the only times I need to mess with capitalization are:
- When I've got a capitalized word that starts a sentence, but I add
a word in front of it, so need to make the capitalized word lowercase. Likewise if I delete some words at the beginning of a sentence and want the next one to start the sentence, I need to capitalize it. Also sometimes when hopping through a sentence word-by-word and need to capitalize some proper names. Not *too* common, but sometimes handy.
- To either make something all caps, or to make something all
lowercase if someone was yelling at me. :)
I've never had to swap case as you describe. What situation would one need to do that?
I came across this situation several times when copying text from somehwere or when writing code and copying some descriptive text("Show XYZ") as a variable name("show_xyz"). Then I lower down the string. I could also just rewrite it but why? I'm lazy and Geany can lower down the string.
I'm sorry -- I should've been more clear and written "I've never had to swap *mixed* case as you describe." (emphasis added). I actually misread what you wrote and thought you were talking about having to turn "aBcD" into "AbCd". This operation seems like an oddball sort of transformation that probably shouldn't take up a key-combo.
So, yeah, my idea is that if you had "Show XYZ", you'd just add the underscore, use Alt-W (whoops -- already mapped that to "select current word" :) ), then hit Ctrl-U to get "show_xyz". If you accidentally tap Ctrl-U twice, you'll end up with "SHOW_XYZ" and you'll need to tap it one more time to get what you want.
But when only toggle is available Geany would have to dice to choose whether I want the string in lower or upper case.
I'd go with the more common operation -- go all lowercase first. Besides, you're already holding down the Ctrl key and you want uppercase, you just tap 'U' again.
Is it really a problem to have two key bindings for that? AFAIK I always seen two bindings resp. two actions for lowering or uppering the case in other apps.
No. The only problem is that using the Shift key to do the opposite of the un-Shifted command feels backwards, and IMO is more difficult for users to remember. Whenever I need to use Shift to do an opposite operation, my brain has to stop short and go, "oh, right. yes, I know Shift usually enhances the command in some way, but for this special case it makes it do the opposite".
If I were assigning two different keys for case transformation, one might be tempted to try and use:
* Ctrl-U for uppercase. Alt-U for just capitalize first letter. * Ctrl-L for lowercase. Alt-L for just lowercase first letter.
but that takes up way too many valuable key combos for just twiddling case. :)
Anyhow, not a big deal at all. The current way just seems inconsistent to me. What's more important, IMO, is the Ctrl-G Shift-Ctrl-G issue, where we wrote:
- Ctrl-G, Shift-Ctrl-G --> Use Ctrl-G to toggle.
No. Then you can't double comment a line. Ok, uses should be not that much but e.g. when commenting a block of code including some commented lines this would uncomment these particular lines which is mostly unintended. Maybe we could change Ctrl+B to Alt+G but it would be just a change of the default binding.
This one is probably a fairly heavily-used feature, and using Shift to make Ctrl-G do the opposite doesn't feel right. On the bright side, since Ctrl-G isn't really mnemonic for commenting (well, I don't think it is in english anyway), it seems like you could pretty easily find a 2nd key for uncommenting. Do many users use Ctrl-B? If not, then maybe:
* Ctrl-G to comment * Ctrl-B to uncomment (go *b*ack :) )
Another possibility is using non-alphanumeric keys for this. Say,
* Ctrl-# (Shift-Ctrl-3) to comment * Ctrl-@ (Shift-Ctrl-2) to uncomment
since the keys are right next to eachother, and a number of languages use '#' as the commenting character. This could also be nice because it frees up Ctrl-G, in case you needed that nice juicy key-combo for something else. :)
- Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
Who needs indentation by one space?
When you select some text (say, you're cleaning up some poorly-indented code), and you need to shift it around but aren't exactly sure what column you need it at. You "tap right a few times, left, ah -- got it".
Hmm, usually I do this by removing all indentation(Ctrl+Shift+I several times) and then re-indent the code as I like. Not necessarily faster but safer especially when the code was indented with spaces and you want to indent by tabs(my preference as you know ;-)).
[snip] Ok, but is it too hard to just use the space key in combination with the cursor keys for navigation? Yes this needs more work, more keystrokes but IMO it is a quite seldom use case.
I use the feature every so often. When you need it, it's very nice.
It might be something to mull over for users who use all spaces and who write lots of code comments. :) Again -- this one's not a big deal, it just falls nicely out of using '9' and '0', '(' and ')', and using Shift to extend Ctrl keys. If you thought it would improve Geany, you could always provide it as an available function without a default key-combo assigned to it, leaving users the choice of the map it somewhere if they wanted to.
Judging by the way this discussion is unfolding, I bet that there will always be a group of Geany users who remap Alt key combos to suit themselves, living with the fact that they'll sometimes be overriding the Alt menu commands. I think this is fine.
Thanks, ---John
Hello friends, interesting discussion you are having here...
This might be slightly off topic, but here are a couple of things I would like to see:
1) The ability to "force" a tab character, even when using spaces to indent:
Most of the C code I work with uses spaces for indentation, but what if I have a bunch of C files open and then I want to tweak the Makefile a bit? I have to go into preferences, enable "use tabs" , insert the tab char, and then go back into preferences and turn tabs off again. I would prefer that Ctrl+I and Ctrl+Shift+I could be used for normal indentation, and that the tab key would *always* insert a tab char, regardless of the preferences.
( Nedit actually uses Ctrl+Tab for this, but I suppose Geany's multi-paned environment needs to reserve Ctrl+Tab for window navigation. )
2) Completely disable editor hot keys when the editor doesn't have the focus:
For instance, what do most users expect if they press Ctrl+Z in the scribble window? I would expect it to either perform an undo on the scribble text, or at least have nothing happen at all. Instead, geany performs the undo in the main editor window, even though it doesn't have the focus, which seems like a real good chance to screw up a document without even realizing it.
Another reason for this is that Ctrl+L should clear the screen in VTE, but instead it brings up the "Go to line" dialog. This is really annoying to me, since I am so accustomed to using Ctrl+L in xterm, and I expect geany's term to behave in the same way.
One other comment, as far as the Alt key combos, I also seldom use the menu accelerators, but for some commands, they are the only alternative to mousing, for example, Alt+D->I to remove error markers. So I agree that Alt+ or Ctrl+Alt+ should *never* be used as defaults for any other bindings...
- Jeff
On Tue, 26 Jun 2007 13:21:02 -0500, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
Hello friends, interesting discussion you are having here...
This might be slightly off topic, but here are a couple of things I would like to see:
The ability to "force" a tab character, even when using spaces to indent:
Most of the C code I work with uses spaces for indentation, but what if I have a bunch of C files open and then I want to tweak the Makefile a bit? I have to go into preferences, enable "use tabs" , insert the tab char, and then go back into preferences and turn tabs off again. I would prefer that Ctrl+I and Ctrl+Shift+I could be used for normal indentation, and that the tab key would *always* insert a tab char, regardless of the preferences.
Yes, we need a solution for this. The easiest way would be to always indent by tab in Makefiles. But it won't help if you are editing any other file and currently need a "real" tab. Any ideas on best way to solve?
Completely disable editor hot keys when the editor doesn't have the focus:
For instance, what do most users expect if they press Ctrl+Z in the scribble window? I would expect it to either perform an undo on the scribble text, or at least have nothing happen at all. Instead, geany performs the undo in the main editor window, even though it doesn't have the focus, which seems like a real good chance to screw up a document without even realizing it.
It is nothing else than a bug :-(. Will be fixed soon.
Regards, Enrico
On 6/27/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 13:21:02 -0500, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
[snip]
The ability to "force" a tab character, even when using spaces to indent:
Most of the C code I work with uses spaces for indentation, but what if I have a bunch of C files open and then I want to tweak the Makefile a bit? I have to go into preferences, enable "use tabs" , insert the tab char, and then go back into preferences and turn tabs off again. I would prefer that Ctrl+I and Ctrl+Shift+I could be used for normal indentation, and that the tab key would *always* insert a tab char, regardless of the preferences.
Yes, we need a solution for this. The easiest way would be to always indent by tab in Makefiles. But it won't help if you are editing any other file and currently need a "real" tab. Any ideas on best way to solve?
My understanding is that, for users like me who use only spaces (no tabs) all the time, we've got the following settings set:
1. Prefs --> Files tab --> Saving Files --> "replace tabs by space" checked 2. Prefs --> Editor tab --> Features --> "use tabs when inserting whitespace" un-checked.
So, due to that first one, even you Geany provides a secret ninja key combo to insert an actual tab character, as soon as I save the file, it'll be converted to *n* spaces (where I've got *n* set to 4).
My impression is that the Document menu is supposed to have document-specific (as opposed to app-specific) settings that you can set for just this document (the one who's tab is selected). It makes sense that any settings you adjust here should override more general settings made in the Preferences dialog.
So, I think you need 2 things to remedy the situation:
1. Provide a "Document --> Allow tab characters" menu time that overrides the "replace tabs by space" behaviour just for this document.
2. Provide a key combo to insert an actual tab character. I'd probably use a punctuation mark for this, since it doesn't get used very often anyway. Probably Ctrl-_ , Ctrl-% , or Ctrl-: .
---John
On 6/27/07, John Gabriele jmg3000@gmail.com wrote:
[snip] So, due to that first one, even you Geany provides a secret ninja key
Whoops. Typo:
even you Geany --> even if Geany
[snip]
- Provide a "Document --> Allow tab characters" menu time that
Gah. Another one:
menu time --> menu item
---John
On 6/27/07, John Gabriele jmg3000@gmail.com wrote:
On 6/27/07, Enrico Tröger enrico.troeger@uvena.de wrote:
Yes, we need a solution for this. The easiest way would be to always indent by tab in Makefiles. But it won't help if you are editing any other file and currently need a "real" tab. Any ideas on best way to solve?
My understanding is that, for users like me who use only spaces (no tabs) all the time, we've got the following settings set:
- Prefs --> Files tab --> Saving Files --> "replace tabs by space" checked
- Prefs --> Editor tab --> Features --> "use tabs when inserting
whitespace" un-checked.
For personal projects that I am in complete control over, I will always prefer spaces over tabs. But sometimes I want to fiddle with a project belonging to someone else who prefers tabs, so the safest bet for me is to always leave the Saving Files --> "replace tabs by space" turned OFF.
It really isn't 100% dependent on the language mode or file type either, although some programs (like gnu make) insist on tabs, and some language's coding conventions (like Pascal) generally frown on tabs. But for C code, the tabs-vs-spaces war will probably rage on forever.
My suggestion would be to add another checkbox to the prefs dialog, instead of "Use tabulators when inserting whitespace" there would be a sub-option, something like:
[X] Use spaces for indentation. -> [X] Tab key still inserts tab char.
So...
With both boxes OFF, both [Tab] and Ctr+I will use tab chars.
With the first box ON, and the second OFF, both [Tab] and Ctr+I use spaces.
With both boxes checked, Ctr+I inserts spaces, and [Tab] inserts a tab char.
- Jeff
On Wed, 27 Jun 2007 15:47:02 -0500, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
On 6/27/07, John Gabriele jmg3000@gmail.com wrote:
On 6/27/07, Enrico Tröger enrico.troeger@uvena.de wrote:
Yes, we need a solution for this. The easiest way would be to always indent by tab in Makefiles. But it won't help if you are editing any other file and currently need a "real" tab. Any ideas on best way to solve?
My understanding is that, for users like me who use only spaces (no tabs) all the time, we've got the following settings set:
- Prefs --> Files tab --> Saving Files --> "replace tabs by space"
checked 2. Prefs --> Editor tab --> Features --> "use tabs when inserting whitespace" un-checked.
For personal projects that I am in complete control over, I will always prefer spaces over tabs. But sometimes I want to fiddle with a project belonging to someone else who prefers tabs, so the safest bet
Like Geany ;-).
It really isn't 100% dependent on the language mode or file type either, although some programs (like gnu make) insist on tabs, and some language's coding conventions (like Pascal) generally frown on tabs. But for C code, the tabs-vs-spaces war will probably rage on forever.
My suggestion would be to add another checkbox to the prefs dialog, instead of "Use tabulators when inserting whitespace" there would be a sub-option, something like:
[X] Use spaces for indentation. -> [X] Tab key still inserts tab char.
Nice idea but the problem is that it is still a global option and you need the preferences dialog if you just change it for one file. So I think John's suggestion is better (see previous mail and my answer on it).
Regards, Enrico
Nice idea but the problem is that it is still a global option and you need the preferences dialog if you just change it for one file. So I think John's suggestion is better.
To me, this just seems like a waste of a key binding. I almost never use the tab key to "indent by spaces" because I already have Ctrl+I for that.
So I would prefer that [Tab] literally means "Tab" and Ctrl+I (or whatever) means "indent", instead of using two key bindings to basically perform the same task. In other words, a tab is a tab, and an indent is an indent, in my mind they are simply not the same thing.
But as long as we end up with some way to insert tabs in Makefiles, I'll be happy...
- Jeff
On 6/28/07, Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
Nice idea but the problem is that it is still a global option and you need the preferences dialog if you just change it for one file. So I think John's suggestion is better.
To me, this just seems like a waste of a key binding. I almost never use the tab key to "indent by spaces" because I already have Ctrl+I for that.
So I would prefer that [Tab] literally means "Tab" and Ctrl+I (or whatever) means "indent", instead of using two key bindings to basically perform the same task. In other words, a tab is a tab, and an indent is an indent, in my mind they are simply not the same thing.
But as long as we end up with some way to insert tabs in Makefiles, I'll be happy...
I think it's like this:
You get the indent/de-indent feature using Ctrl-I/Shift-Ctrl-I. Also, Ctrl-I/Shift-Ctrl-I works for a single line the way you'd expect, regardless of where the cursor is.
While text editing, to indent forward by inserting stuff (tab or spaces), you hit the handy Tab key. To "indent back", you just hit BackSpace. This is the way everyone expects it to be, and probably won't change.
As an added bit of extra magic, after you've selected text, Geany seems to allow you to use Tab and Shift-Tab as aliases for Ctrl-I and Shift-Ctrl-I. Personally, I'm not crazy about this behaviour because:
1. If I select some text and hit the Tab key, I'd expect the selection to be replaced by a tab (or, for my configuration, 4 spaces). And,
2. Seems more consistent and uniform to have just one usual way to do a given editor function.
---John
While text editing, to indent forward by inserting stuff (tab or spaces), you hit the handy Tab key. To "indent back", you just hit BackSpace. This is the way everyone expects it to be, and probably won't change.
Which is why I suggested it should be an added preference, I'm not saying that it should be the default.
- Jeff
On Wed, 27 Jun 2007 15:53:01 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 6/27/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 13:21:02 -0500, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
[snip]
The ability to "force" a tab character, even when using spaces to indent:
Most of the C code I work with uses spaces for indentation, but what if I have a bunch of C files open and then I want to tweak the Makefile a bit? I have to go into preferences, enable "use tabs" , insert the tab char, and then go back into preferences and turn tabs off again. I would prefer that Ctrl+I and Ctrl+Shift +I could be used for normal indentation, and that the tab key would *always* insert a tab char, regardless of the preferences.
Yes, we need a solution for this. The easiest way would be to always indent by tab in Makefiles. But it won't help if you are editing any other file and currently need a "real" tab. Any ideas on best way to solve?
My understanding is that, for users like me who use only spaces (no tabs) all the time, we've got the following settings set:
- Prefs --> Files tab --> Saving Files --> "replace tabs by space"
checked 2. Prefs --> Editor tab --> Features --> "use tabs when inserting whitespace" un-checked.
So, due to that first one, even you Geany provides a secret ninja key combo to insert an actual tab character, as soon as I save the file, it'll be converted to *n* spaces (where I've got *n* set to 4).
My impression is that the Document menu is supposed to have document-specific (as opposed to app-specific) settings that you can set for just this document (the one who's tab is selected). It makes sense that any settings you adjust here should override more general settings made in the Preferences dialog.
So, I think you need 2 things to remedy the situation:
- Provide a "Document --> Allow tab characters" menu time that
overrides the "replace tabs by space" behaviour just for this document.
Yes, I think I'll implement this. And the menu item is activated by default for Makefiles(just for comfort) and can be activated for any file if needed.
- Provide a key combo to insert an actual tab character. I'd probably
use a punctuation mark for this, since it doesn't get used very often anyway. Probably Ctrl-_ , Ctrl-% , or Ctrl-: .
Ok, should be no big deal to add a key binding but I think it will be emtpy by default.
Regards, Enrico
On 06/26/2007 07:03:48 PM, John Gabriele wrote:
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele" jmg3000@gmail.com wrote:
I'd go with the more common operation -- go all lowercase first. Besides, you're already holding down the Ctrl key and you want uppercase, you just tap 'U' again.
Is it really a problem to have two key bindings for that? AFAIK I always seen two bindings resp. two actions for lowering or uppering the case in other apps.
No. The only problem is that using the Shift key to do the opposite of the un-Shifted command feels backwards, and IMO is more difficult for users to remember. Whenever I need to use Shift to do an opposite operation, my brain has to stop short and go, "oh, right. yes, I know Shift usually enhances the command in some way, but for this special case it makes it do the opposite".
Well there is Shift-F3 for search backwards too. Personally I find it easier to remember with shift for things like that, and it frees up more keys for other keybindings. But for indenting maybe ctrl-0 and ctrl-9 are better. I think that's because it's easier to associate with left and right.
[...]
Anyhow, not a big deal at all. The current way just seems inconsistent to me. What's more important, IMO, is the Ctrl-G Shift-Ctrl-G issue, where we wrote:
- Ctrl-G, Shift-Ctrl-G --> Use Ctrl-G to toggle.
No. Then you can't double comment a line. Ok, uses should be not that much but e.g. when commenting a block of code including some commented lines this would uncomment these particular lines which is mostly unintended. Maybe we could change Ctrl+B to Alt+G but it would be just a change of the default binding.
I like the way SciTE does it - by using '//~' so no comments are lost when toggling commenting (it uses ctrl-Q, but that's normally quit for GTK-apps):
//~ line //~ //commented line
This one is probably a fairly heavily-used feature, and using Shift to make Ctrl-G do the opposite doesn't feel right. On the bright side, since Ctrl-G isn't really mnemonic for commenting (well, I don't think it is in english anyway), it seems like you could pretty easily find a 2nd key for uncommenting. Do many users use Ctrl-B? If not, then maybe:
- Ctrl-G to comment
- Ctrl-B to uncomment (go *b*ack :) )
I use the toggle comment the most (but I reassigned it to ctrl-').
Another possibility is using non-alphanumeric keys for this. Say,
- Ctrl-# (Shift-Ctrl-3) to comment
- Ctrl-@ (Shift-Ctrl-2) to uncomment
since the keys are right next to eachother, and a number of languages use '#' as the commenting character. This could also be nice because it frees up Ctrl-G, in case you needed that nice juicy key-combo for something else. :)
The problem with non-alphanumeric keys by default is that different keyboard layouts require shift differently, and sometimes other modifier keys instead.
- Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
I like this, but maybe it should be the other way around - on most layouts ctrl-number is easier for common tab width indenting, and holding shift for the less common case makes sense (for me anyway).
Who needs indentation by one space?
When you select some text (say, you're cleaning up some poorly-indented code), and you need to shift it around but aren't exactly sure what column you need it at. You "tap right a few
times,
left, ah -- got it".
Hmm, usually I do this by removing all indentation(Ctrl+Shift+I several times) and then re-indent the code as I like. Not necessarily faster but safer especially when the code was indented with spaces and you want to indent by tabs(my preference as you know ;-)).
I do it like this too (as I prefer tabs).
[snip] Ok, but is it too hard to just use the space key in combination with the cursor keys for navigation? Yes this needs more work, more keystrokes but IMO it is a quite seldom use case.
I use the feature every so often. When you need it, it's very nice.
When I need to do this I use the rectangular selection to delete or copy & paste, which is quicker than manually. Or even a regex replace, but I tend to use it not for indenting.
Not using spaces, I don't know how often this is needed, but other editors have it and it could be useful.
Regards, Nick
On Thu, 28 Jun 2007 13:57:49 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
[...]
Anyhow, not a big deal at all. The current way just seems inconsistent to me. What's more important, IMO, is the Ctrl-G Shift-Ctrl-G issue, where we wrote:
- Ctrl-G, Shift-Ctrl-G --> Use Ctrl-G to toggle.
No. Then you can't double comment a line. Ok, uses should be not that much but e.g. when commenting a block of code including some commented lines this would uncomment these particular lines which is mostly unintended. Maybe we could change Ctrl+B to Alt+G but it would be just a change of the default binding.
I like the way SciTE does it - by using '//~' so no comments are lost when toggling commenting (it uses ctrl-Q, but that's normally quit for GTK-apps):
//~ line //~ //commented line
Hmm, looks nice. So we could use Ctrl+G or whatever for comment toggling and leave the bindings for usual commenting/uncommenting undefined.
Regards, Enrico
On 6/28/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 06/26/2007 07:03:48 PM, John Gabriele wrote:
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
I like this, but maybe it should be the other way around - on most layouts ctrl-number is easier for common tab width indenting, and holding shift for the less common case makes sense (for me anyway).
Guess it depends on which philosophy you want Geany to go with:
A. Most common usage without the Shift key B. Less common requires Shift
or
A. Basic feature without Shift B. Extended with Shift
But just a moment...
After fiddling with key combos a bit, I'm starting to see things Enrico's way. Not only are the Alt keys used for activating menus, but they're also used extensively to control GUI dialog elements. If a given dialog is not modal, there could be confusion (ex. "will Alt-P find previous, or will it select paragraph?"). It's actually possibly (probably?) more consistent to only use Ctrl-key, Shift-Ctrl-key, and Shift-Alt-key to control editing functions, and leave Alt-key for dealing with the GUI elements.
I'm still not sure about using Shift to make a key do the opposite, but I see that it's not all that uncommon (ex, in Firefox, using Ctrl-G to find next, and Shift-Ctrl-G to find previous). Maybe using Shift in this way isn't a bad thing, and I just need to take more time to get used to it.
If that's the case, then maybe optimum key combos are:
* when a Ctrl-key combo has an obvious opposite, add Shift to it to get that opposite. * When it doesn't have an obvious opposite, use Shift-Ctrl-key to get some kind of extended behaviour. * Use Shift-Alt-key for other specialized functions. If these functions have an opposite, you'll just have to work to find a Shift-Alt-another_key to provide that function (or else just use a menu item to get it).
Applying this to Geany's current key bindings, F3/Shift-F3 is good. Shift-Alt-D even makes sense this way. :)
The inconsistent keys now become:
* undo, redo: Ctrl-Z, Ctrl-Y. Maybe should be Ctrl-Z, Shift-Ctrl-Z? * toggle line comment: Ctrl-B. Maybe should be Ctrl-B to comment, Shift-Ctrl-B to uncomment? (That way it would be similar to how Ctrl-G works.) * toggle marker: Ctrl-M. Maybe Ctrl-M to mark, Shift-Ctrl-M to unmark.
And this opens up those Shift-Alt-keys for ones such as:
* Shift-Alt-W to select current word * Shift-Alt-L to select current line * Shift-Alt-P to select current paragraph
without anything being inconsistent. :)
Getting back to indent then, it looks like Ctrl-I to indent and Shift-Ctrl-I to de-indent is good. And maybe Shift-Alt-I could be for inserting that elusive raw tab character. :)
---John
On 06/28/2007 08:40:16 PM, John Gabriele wrote:
On 6/28/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 06/26/2007 07:03:48 PM, John Gabriele wrote:
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele" jmg3000@gmail.com wrote:
> * Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to
indent/de-indent
> by one space, and Ctrl-) & Ctrl-( to indent/de-indent
by
> one tab width.
I like this, but maybe it should be the other way around - on most layouts ctrl-number is easier for common tab width indenting, and holding shift for the less common case makes sense (for me anyway).
Guess it depends on which philosophy you want Geany to go with:
A. Most common usage without the Shift key B. Less common requires Shift
or
A. Basic feature without Shift B. Extended with Shift
Well, personally because we're limited by keys if we want to have universal keybindings I don't mind having both of the above. But it is harder to hold shift as well so I'd tend to go with the first one.
But just a moment...
After fiddling with key combos a bit, I'm starting to see things Enrico's way. Not only are the Alt keys used for activating menus, but they're also used extensively to control GUI dialog elements. If a given dialog is not modal, there could be confusion (ex. "will Alt-P find previous, or will it select paragraph?"). It's actually possibly
Well I'm not sure about you're example, but the answer IMO is it depends what's focussed. We've made some of the keybindings only active when the editor window has focus, but there may be more that need this check.
- when a Ctrl-key combo has an obvious opposite, add Shift to it to
get that opposite.
- When it doesn't have an obvious opposite, use Shift-Ctrl-key to get
some kind of extended behaviour.
- Use Shift-Alt-key for other specialized functions. If these
functions have an opposite, you'll just have to work to find a Shift-Alt-another_key to provide that function (or else just use a menu item to get it).
This seems OK in general, but personally I don't mind exceptions to the rule, so long as there's a reason for it. E.g. for indenting (see my other mail).
Applying this to Geany's current key bindings, F3/Shift-F3 is good. Shift-Alt-D even makes sense this way. :)
The inconsistent keys now become:
- undo, redo: Ctrl-Z, Ctrl-Y. Maybe should be Ctrl-Z, Shift-Ctrl-Z?
Well, I prefer it. I don't like holding shift for things that get pressed a lot, and I use undo/redo quite a lot. I realise some people might say the same for find previous, but I think there are more alternatives in that situation - e.g. find all/find usage. Undo/redo is important to be able to do easily because it can be stressful finding the right point without losing code.
- toggle line comment: Ctrl-B. Maybe should be Ctrl-B to comment,
Shift-Ctrl-B to uncomment? (That way it would be similar to how Ctrl-G works.)
- toggle marker: Ctrl-M. Maybe Ctrl-M to mark, Shift-Ctrl-M to unmark.
No, I think toggling is fine in that case. Also if we do end up using the '//~' trick from scite, toggling works there as well.
And this opens up those Shift-Alt-keys for ones such as:
- Shift-Alt-W to select current word
- Shift-Alt-L to select current line
- Shift-Alt-P to select current paragraph
Seems OK ;-)
Regards, Nick
On Fri, 29 Jun 2007 13:24:00 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
Applying this to Geany's current key bindings, F3/Shift-F3 is good. Shift-Alt-D even makes sense this way. :)
The inconsistent keys now become:
- undo, redo: Ctrl-Z, Ctrl-Y. Maybe should be Ctrl-Z, Shift-Ctrl-Z?
No. Ctrl-z, Ctrl-Y is very common for undo/redo. Firefox and Audacity are the only apps I just found on my system which are using Ctrl-Z/Ctrl-Shift-Z, all other tested apps(like Scite, Mousepad, Gimp, OopenOffice, Sylpheed, Opera) use the Ctrl-Y for redo. I really don't want to change this. Also because of the reason Nick mentioned, Ctrl-Y is much more easier to reach than Ctrl-Shift-Z for the often used Redo function.
- toggle line comment: Ctrl-B. Maybe should be Ctrl-B to comment,
Shift-Ctrl-B to uncomment? (That way it would be similar to how Ctrl-G works.)
Where is the difference? It would be just a change of the default bindings from Ctrl-(Shift)-G to Ctrl-(Shift)-B.
- toggle marker: Ctrl-M. Maybe Ctrl-M to mark, Shift-Ctrl-M to
unmark.
No, I think toggling is fine in that case. Also if we do end up using the '//~' trick from scite, toggling works there as well.
Yes, I think we really could use this '//~' trick.
Regards, Enrico
Nick,
Just to sum up what you wrote:
* Toggle keys are ok for things that make sense to toggle. * Prefer alphabetic keys. * Prefer Ctrl-key and Ctrl-other_key for most commonly needed editor functions. If they're adjacent keys, that's sometimes nice. But F3/Shift-F3 is ok too. * Ctrl-key/Shift-Ctrl-key also ok, but slightly harder to activate, so use for less commonly-needed editor features. * [I'm not sure what you think of using Alt keys] * Shift-Ctrl-key is ok for opposite of Ctrl-key. But exceptions to the rule are ok if there's a reason for them. * Shift-Alt-key is ok.
Also, Enrico
* likes Tab/Shift-Tab * suggested using Alt-I for some special indentation behaviour he has in mind. * likes F3/Shift-F3. Doesn't mind the Fkeys so much. * notes that using Alt-key isn't very good given it's used for manipulating GUI elements, and the letters for them can change for different languages. * doesn't seem crazy about the toggle (at least for changing case of a selection), but then mentions that Ctrl-B could still toggle line commenting. * likes Ctrl-Z/Ctrl-Y for Undo/Redo. Likes commonly-used keys to be easy to reach without the Shift key.
I originally posted because I'm concerned about having too many key-combo usage schemes making it more difficult to learn and use them. The phrase I was searching for when I posted was "context shift". You're fingers get used to "Shift-Ctrl-key does the opposite of Ctrl-key", then it's a context shift to go to "Shift-Ctrl-key does some extended behaviour of Ctrl-key", which makes the editor harder to use. IMO, it's the kind of thing you don't usually notice directly, but more of have a feeling that, "this editor feels more clumsy to use than editor X".
It sounds like what you're saying is that you don't see that as much of a concern (maybe it isn't -- it just seems so to me :) ).
Looking at the key bindings for terminal-based editors, I can see how they were limited by not having certain keys available to them (like not always having the named key (PgUp, PgDn, Delete, etc., or not always being able to use Shift with other modifier keys), so maybe they couldn't always be as consistent as they wanted.
I can see it's a pain to move default keys around, since users get used to certain keys. Maybe I'm just chasing foolish consistency too much here. :)
---John
On Fri, 29 Jun 2007 11:08:49 -0400, "John Gabriele" jmg3000@gmail.com wrote:
Nick,
Just to sum up what you wrote:
Nice, a little summary is really a good idea ;-).
Also, Enrico
- suggested using Alt-I for some special indentation behaviour he has
in mind.
No. Alt-I was just an idea but as we noticed Alt should be avoided to not conflict with GUI elements. So, maybe Alt-Shift-I could be used or something else.
- doesn't seem crazy about the toggle (at least for changing case of a
selection), but then mentions that Ctrl-B could still toggle line commenting.
Well, I don't really care. As long as I can redefine the keys to my own preferences I'm happy ;-). My actual point is: I would like to leave Ctrl-U/Ctrl-Shift-U for changing case like it is. About the comment/uncomment/comment toggling functions I don't really care. We could remove the default bindings for comment/uncomment and only set comment toggling to whatever seems well (ok, Scite's Ctrl-Q obviously isn't a good choice).
It sounds like what you're saying is that you don't see that as much of a concern (maybe it isn't -- it just seems so to me :) ).
At least not until this thread ;-). Anyway, it is good to talk about it and to improve Geany by this.
Looking at the key bindings for terminal-based editors, I can see how they were limited by not having certain keys available to them (like not always having the named key (PgUp, PgDn, Delete, etc., or not always being able to use Shift with other modifier keys), so maybe they couldn't always be as consistent as they wanted.
I think being consistent with a terminal-based editor is too difficult for a GUI editor. Only think of the Alt key, which is AFAIK completely available in non-graphical environments but almost can't be used in GUI apps. Small example: the Midnight Commander uses Alt-Tab for shell-like tab completion. Nice feature but completely unusable if you use mc in a terminal window under X because there Alt-Tab is used for cycling between open windows. Ok, obviously mc wasn't written for graphical environments but it shows this consistency would be very hard. IMO we should be consistent with other GUI apps and maybe Emacs as far as it is possible (hopefully nobody comes up who likes vi ;-)).
Regards, Enrico
Enrico Tröger wrote:
On Fri, 29 Jun 2007 11:08:49 -0400, "John Gabriele" jmg3000@gmail.com wrote:
Nick,
Just to sum up what you wrote:
Nice, a little summary is really a good idea ;-).
Also, Enrico
- suggested using Alt-I for some special indentation behaviour he has
in mind.
No. Alt-I was just an idea but as we noticed Alt should be avoided to not conflict with GUI elements. So, maybe Alt-Shift-I could be used or something else.
- doesn't seem crazy about the toggle (at least for changing case of a
selection), but then mentions that Ctrl-B could still toggle line commenting.
Well, I don't really care. As long as I can redefine the keys to my own preferences I'm happy ;-). My actual point is: I would like to leave Ctrl-U/Ctrl-Shift-U for changing case like it is. About the comment/uncomment/comment toggling functions I don't really care. We could remove the default bindings for comment/uncomment and only set comment toggling to whatever seems well (ok, Scite's Ctrl-Q obviously isn't a good choice).
It sounds like what you're saying is that you don't see that as much of a concern (maybe it isn't -- it just seems so to me :) ).
At least not until this thread ;-). Anyway, it is good to talk about it and to improve Geany by this.
Looking at the key bindings for terminal-based editors, I can see how they were limited by not having certain keys available to them (like not always having the named key (PgUp, PgDn, Delete, etc., or not always being able to use Shift with other modifier keys), so maybe they couldn't always be as consistent as they wanted.
I think being consistent with a terminal-based editor is too difficult for a GUI editor. Only think of the Alt key, which is AFAIK completely available in non-graphical environments but almost can't be used in GUI apps. Small example: the Midnight Commander uses Alt-Tab for shell-like tab completion. Nice feature but completely unusable if you use mc in a terminal window under X because there Alt-Tab is used for cycling between open windows. Ok, obviously mc wasn't written for graphical environments but it shows this consistency would be very hard. IMO we should be consistent with other GUI apps and maybe Emacs as far as it is possible (hopefully nobody comes up who likes vi ;-)).
Regards, Enrico
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
I like geany and use it on both windows and Linux for pretty much all my miscellaneous editting. I've been following this thread and here's my two cents. Many years ago when I first started writing GUI code (OS/2...late 80's) we were required to adhere to CUA standards. These have since become pretty much de-facto among GUI applications. My fingers just seem to do them. Seaching on WikiPedia gave me this list of keystrokes :
http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
Everyone has their own favorites, or wants, but it makes sense in the bigger picture to have default values that conform, new users are likely to try a program with non-standard keys, and discard it as having too steep a learning curve otherwise.
My Two Cents...
Michael
On 06/29/2007 04:48:21 PM, Michael Comperchio wrote:
I like geany and use it on both windows and Linux for pretty much all my miscellaneous editting. I've been following this thread and here's my two cents. Many years ago when I first started writing GUI code (OS/2...late 80's) we were required to adhere to CUA standards. These have since become pretty much de-facto among GUI applications. My fingers just seem to do them. Seaching on WikiPedia gave me this list of keystrokes :
http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
Everyone has their own favorites, or wants, but it makes sense in the bigger picture to have default values that conform, new users are likely to try a program with non-standard keys, and discard it as having too steep a learning curve otherwise.
I agree. I think Geany basically conforms with that table where possible, except: help is ctrl-h instead of f1 rEplace is ctrl-e instead of ctrl-h
I don't mind changing these if most people prefer them.
Regards, Nick
I agree. I think Geany basically conforms with that table where possible, except: help is ctrl-h instead of f1 rEplace is ctrl-e instead of ctrl-h
I don't mind changing these if most people prefer them.
Please do! I keep making the same mistake over and over again on each new installation of Geany... (that is, until I reassign CTRL-E)
-H-
On Tue, 03 Jul 2007 19:21:24 +0200, Harold Aling h.aling@home.nl wrote:
I agree. I think Geany basically conforms with that table where possible, except: help is ctrl-h instead of f1 rEplace is ctrl-e instead of ctrl-h
I don't mind changing these if most people prefer them.
Please do! I keep making the same mistake over and over again on each new installation of Geany... (that is, until I reassign CTRL-E)
Ok, Replace will be Ctrl+H and Help will be F1.
Regards, Enrico
Nick Treleaven wrote:
On 06/29/2007 04:48:21 PM, Michael Comperchio wrote:
I like geany and use it on both windows and Linux for pretty much all my miscellaneous editting. I've been following this thread and here's my two cents. Many years ago when I first started writing GUI code (OS/2...late 80's) we were required to adhere to CUA standards. These have since become pretty much de-facto among GUI applications. My fingers just seem to do them. Seaching on WikiPedia gave me this list of keystrokes :
http://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts
Everyone has their own favorites, or wants, but it makes sense in the bigger picture to have default values that conform, new users are likely to try a program with non-standard keys, and discard it as having too steep a learning curve otherwise.
I agree. I think Geany basically conforms with that table where possible, except: help is ctrl-h instead of f1 rEplace is ctrl-e instead of ctrl-h
I don't mind changing these if most people prefer them.
Regards, Nick _______________________________________________ Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Funny you should mention that....I change my keybindings to that.... ^H
Michael
I agree. I think Geany basically conforms with that table where possible, except: help is ctrl-h instead of f1 rEplace is ctrl-e instead of ctrl-h
I would certainly agree with re-mapping Help to F1, but I think Ctrl+R is a more logical choice for replace, at least in English.
- Jeff
On Tue, 3 Jul 2007 17:16:31 -0500, "Jeff Pohlmeyer" yetanothergeek@gmail.com wrote:
I agree. I think Geany basically conforms with that table where possible, except: help is ctrl-h instead of f1 rEplace is ctrl-e instead of ctrl-h
I would certainly agree with re-mapping Help to F1, but I think Ctrl+R is a more logical choice for replace, at least in English.
Ctrl-R is used for File Reload. Replace will be Ctrl-H.
Regards, Enrico
On 6/29/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 29 Jun 2007 11:08:49 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- doesn't seem crazy about the toggle (at least for changing case of a
selection), but then mentions that Ctrl-B could still toggle line commenting.
Well, I don't really care. As long as I can redefine the keys to my own preferences I'm happy ;-).
Right. :) But, of course, for features that are currently implemented as a toggle (comment/uncomment line, mark/unmark line, and transpose lines (besides the ones that toggle the subwindows and fullscreen)), users cannot currently redefine them to work like Ctrl-key/Shift-Ctrl-key. They can only pick a different key that causes the toggle to happen.
Not a big deal. Works fine as is. Though, it does seem sorta' odd that Geany provide two separate ways of commenting lines.
My actual point is: I would like to leave Ctrl-U/Ctrl-Shift-U for changing case like it is. About the comment/uncomment/comment toggling functions I don't really care. We could remove the default bindings for comment/uncomment and only set comment toggling to whatever seems well (ok, Scite's Ctrl-Q obviously isn't a good choice).
It's interesting to note what other editors use for the key combo to comment text. Emacs uses Alt-; (semicolon, since that's the comment character in lisp). I proposed Ctrl-@ (uncomment) and Ctrl-# (comment) since most scripting languages use '#' for the comment character. Not sure what NEdit uses. Don't think Gedit has the comment/uncomment feature.
Looking at the key bindings for terminal-based editors, I can see how they were limited by not having certain keys available to them (like not always having the named key (PgUp, PgDn, Delete, etc., or not always being able to use Shift with other modifier keys), so maybe they couldn't always be as consistent as they wanted.
I think being consistent with a terminal-based editor is too difficult for a GUI editor.
Sorry for not being clear: I meant that it's difficult for text-mode editors to be self-consistent, but easier for GUI editors like Geany to be so.
---John
On Fri, 29 Jun 2007 14:12:53 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 6/29/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 29 Jun 2007 11:08:49 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- doesn't seem crazy about the toggle (at least for changing case
of a selection), but then mentions that Ctrl-B could still toggle line commenting.
Well, I don't really care. As long as I can redefine the keys to my own preferences I'm happy ;-).
Right. :) But, of course, for features that are currently implemented as a toggle (comment/uncomment line, mark/unmark line, and transpose lines (besides the ones that toggle the subwindows and fullscreen)), users cannot currently redefine them to work like Ctrl-key/Shift-Ctrl-key. They can only pick a different key that causes the toggle to happen.
Is this necessary? Don't get me wrong but do we have to provide every single possibility? I don't think we need the possibility also to change the behaviour of certain keybindings. Geany is not Emacs ;-).
My actual point is: I would like to leave Ctrl-U/Ctrl-Shift-U for changing case like it is. About the comment/uncomment/comment toggling functions I don't really care. We could remove the default bindings for comment/uncomment and only set comment toggling to whatever seems well (ok, Scite's Ctrl-Q obviously isn't a good choice).
It's interesting to note what other editors use for the key combo to comment text. Emacs uses Alt-; (semicolon, since that's the comment character in lisp). I proposed Ctrl-@ (uncomment) and Ctrl-# (comment) since most scripting languages use '#' for the comment character. Not sure what NEdit uses. Don't think Gedit has the comment/uncomment feature.
Ctrl-@ is bad for at least QWERTZ keyboard layouts (need to press Ctrl-Alt GR-Q, Alt GR is right of the space key where US keyboards only have a second ALT key). IMO this is quite uncomfortable. Ctrl-# would be fine for me but I guess there are keyboard layouts where it isn't as easy to press as it is on QWERTZ or QWERTY. What about my suggestion to only use a keybinding (by default) for comment toggling, e.g. Ctrl-G or Ctrl-B (these ones are not yet used for anything else and are available on all keyboard layouts in the same way)?
Looking at the key bindings for terminal-based editors, I can see how they were limited by not having certain keys available to them (like not always having the named key (PgUp, PgDn, Delete, etc., or not always being able to use Shift with other modifier keys), so maybe they couldn't always be as consistent as they wanted.
I think being consistent with a terminal-based editor is too difficult for a GUI editor.
Sorry for not being clear: I meant that it's difficult for text-mode
You were, I didn't read carefully enough ;-).
Regards, Enrico
On 07/04/2007 04:03:27 PM, Enrico Tröger wrote:
On Fri, 29 Jun 2007 14:12:53 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 6/29/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 29 Jun 2007 11:08:49 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- doesn't seem crazy about the toggle (at least for changing
case
of a selection), but then mentions that Ctrl-B could still
toggle
line commenting.
Well, I don't really care. As long as I can redefine the keys to
my
own preferences I'm happy ;-).
Right. :) But, of course, for features that are currently
implemented
as a toggle (comment/uncomment line, mark/unmark line, and transpose lines (besides the ones that toggle the subwindows and fullscreen)), users cannot currently redefine them to work like Ctrl-key/Shift-Ctrl-key. They can only pick a different key that causes the toggle to happen.
Is this necessary? Don't get me wrong but do we have to provide every single possibility? I don't think we need the possibility also to change the behaviour of certain keybindings. Geany is not Emacs ;-).
I also don't think we should do that. I think there's no need for two separate keybindings if one toggle binding can do it.
For me I prefer having the default keybindings as useful as possible, rather than as consistent as possible. As long as there's a good reason to go against consistency I think that's fine.
[...] What about my suggestion to only use a keybinding (by default) for comment toggling, e.g. Ctrl-G or Ctrl-B (these ones are not yet used for anything else and are available on all keyboard layouts in the same way)?
Maybe we could use Ctrl-E now that Replace will be changed to Ctrl-H, because commEnt has an E in it I'd find that easier to remember than ctrl-b or ctrl-g, and ctrl-e can be done with one hand ;-)
Regards, Nick
On Wed, 04 Jul 2007 16:17:25 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
[...] What about my suggestion to only use a keybinding (by default) for comment toggling, e.g. Ctrl-G or Ctrl-B (these ones are not yet used for anything else and are available on all keyboard layouts in the same way)?
Maybe we could use Ctrl-E now that Replace will be changed to Ctrl-H, because commEnt has an E in it I'd find that easier to remember than ctrl-b or ctrl-g, and ctrl-e can be done with one hand ;-)
Sounds good. So, we remove the default keybindings for comment/uncomment and let them undefined and we assign Ctrl-E to toggle comment. OK?
Regards, Enrico
On 07/04/2007 04:31:26 PM, Enrico Tröger wrote:
On Wed, 04 Jul 2007 16:17:25 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
[...] What about my suggestion to only use a keybinding (by default) for comment toggling, e.g. Ctrl-G or Ctrl-B (these ones are not yet
used
for anything else and are available on all keyboard layouts in the same way)?
Maybe we could use Ctrl-E now that Replace will be changed to Ctrl-H, because commEnt has an E in it I'd find that easier to remember than ctrl-b or ctrl-g, and ctrl-e can be done with one hand ;-)
Sounds good. So, we remove the default keybindings for comment/uncomment and let them undefined and we assign Ctrl-E to toggle comment. OK?
Yes, once the toggle comment behaviour is updated to preserve existing comments, this should be fine.
Regards, Nick
On 7/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
Sounds good. So, we remove the default keybindings for comment/uncomment and let them undefined and we assign Ctrl-E to toggle comment. OK?
Sounds good to me. I'm interested to see how the new toggle comment behaviour ('//~' and '#~') works out in practice.
Also, since now Ctrl-G would be freed up, even though I know you prefer F3 for "find again" (and Shift-F3 for "find previous"), it's pretty standard to use Ctrl-G and Shift-Ctrl-G for that (Mac OS X, KDE, and Gnome). MS Windows is the only one who uses F3 for it. And Ctrl-G really is easier to hit than an F_key without looking away from the keyboard. Shift-F3 is even harder to hit. :) {ducks}
As long as we're looking at the Gnome HIG and the CUA standards, it looks like most apps use Ctrl-D instead of Ctrl-M to deal with bookmarks. I think Ctrl-M is usually reserved for hopping between *m*atching bracket characters (parentheses, brackets, braces, angle brackets). If you went with that, you could possibly switch "Duplicate" to Shift-Alt-C (for *c*opy). This seems reasonable to me, since it's probably much more common to toggle bookmarks and toggle between matching brackets than duplicating selected text.
By the way, I'm still rooting for seeing:
* Shift-Alt-W to select word * Shift-Alt-L to select line * Shift-Alt-P to select paragraph
oooh, and maybe one more, given the previous paragraph:
* Shift-Alt-M to select all text between matching brackets.
:)
---John
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
Sounds good. So, we remove the default keybindings for comment/uncomment and let them undefined and we assign Ctrl-E to toggle comment. OK?
Sounds good to me. I'm interested to see how the new toggle comment behaviour ('//~' and '#~') works out in practice.
Me too ;-). I'm going to start implementing it.
Also, since now Ctrl-G would be freed up, even though I know you prefer F3 for "find again" (and Shift-F3 for "find previous"), it's pretty standard to use Ctrl-G and Shift-Ctrl-G for that (Mac OS X, KDE, and Gnome). MS Windows is the only one who uses F3 for it. And Ctrl-G really is easier to hit than an F_key without looking away from the keyboard. Shift-F3 is even harder to hit. :) {ducks}
Hmm, it really seems to be more default to have Ctrl-(Shift-)G for Find Next/Previous. I didn't know that and until now only saw F3/Shift-F3. We could change it if Nick will agree.
As long as we're looking at the Gnome HIG and the CUA standards, it looks like most apps use Ctrl-D instead of Ctrl-M to deal with bookmarks. I think Ctrl-M is usually reserved for hopping between *m*atching bracket characters (parentheses, brackets, braces, angle brackets). If you went with that, you could possibly switch "Duplicate" to Shift-Alt-C (for *c*opy). This seems reasonable to me, since it's probably much more common to toggle bookmarks and toggle between matching brackets than duplicating selected text.
Oh please not. Switching between matching braces is nice but at least I use it very rare. But I use duplicating lines/selection very very often and I assume I get pain in my fingers if we change Duplicate to Shift-Alt-C ;-).
By the way, I'm still rooting for seeing:
- Shift-Alt-W to select word
Will be done (only need to add the default keybinding).
- Shift-Alt-L to select line
Shift-Alt-L is currently used a "Line Delete" by Scintilla, but I suggest to remove the Line Delete feature (because of probably rare usage) and use Shift-Alt-L for select line.
- Shift-Alt-P to select paragraph
No problem, just needs to be implemented. Could paragraph defined in some way? To avoid further discussions (;-)) we should use a common way of defining a paragraph(start and end). Do you know what I mean?
oooh, and maybe one more, given the previous paragraph:
- Shift-Alt-M to select all text between matching brackets.
Hmm, nice idea.
Regards, Enrico
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
As long as we're looking at the Gnome HIG and the CUA standards, it looks like most apps use Ctrl-D instead of Ctrl-M to deal with bookmarks. I think Ctrl-M is usually reserved for hopping between *m*atching bracket characters (parentheses, brackets, braces, angle brackets). If you went with that, you could possibly switch "Duplicate" to Shift-Alt-C (for *c*opy). This seems reasonable to me, since it's probably much more common to toggle bookmarks and toggle between matching brackets than duplicating selected text.
Oh please not.
Hehe. :)
Switching between matching braces is nice but at least I use it very rare. But I use duplicating lines/selection very very often and I assume I get pain in my fingers if we change Duplicate to Shift-Alt-C ;-).
Yes, I'm finding Duplicate quite helpful also, and maybe hitting Shift-Alt on my ergonomic keyboard is easier than on other more commonly-used keyboards.
By the way, I'm still rooting for seeing:
[snip]
- Shift-Alt-L to select line
Shift-Alt-L is currently used a "Line Delete" by Scintilla, but I suggest to remove the Line Delete feature (because of probably rare usage) and use Shift-Alt-L for select line.
Actually, that's Shift-Ctrl-L to delete current line, not Shift-Alt-L (and Ctrl-L cuts the line). Deleting (or else cutting) the current line is very handy, IMO. Though I'm used to both GNU Emacs and GNU nano using Ctrl-K for it. Ctrl-L seems more like it should be "go to line number" (what Ctrl-J is currently being used for). And I think I've seen Ctrl-J used for "join lines" (that is, "replace the newline at the end of this current line with a single space").
Incidentally, I don't see "delete current line" (or "cut current line") listed in Help --> Keyboard shortcuts, or in Edit --> Preferences --> Keybindings. I guess those 2 places are only for Geany-specific (outside of Scintilla defaults) bindings?
- Shift-Alt-P to select paragraph
No problem, just needs to be implemented. Could paragraph defined in some way? To avoid further discussions (;-)) we should use a common way of defining a paragraph(start and end). Do you know what I mean?
I think paragraphs are separated by blank lines (space is allowed).
---John
On 7/5/07, John Gabriele jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- Shift-Alt-P to select paragraph
No problem, just needs to be implemented. Could paragraph defined in some way? To avoid further discussions (;-)) we should use a common way of defining a paragraph(start and end). Do you know what I mean?
I think paragraphs are separated by blank lines (space is allowed).
Actually, since Ctrl-] and Ctrl-[ already move the cursor by-paragraph, all "select paragraph" needs to do is:
1. Ctrl-] (go to end of current paragraph). 2. Mark this as the end of the selection. 3. Ctrl-[ (go to beginning of paragraph). 4. Mark this as the start of the selection.
---John
On Thu, 5 Jul 2007 12:57:04 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/5/07, John Gabriele jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- Shift-Alt-P to select paragraph
No problem, just needs to be implemented. Could paragraph defined in some way? To avoid further discussions (;-)) we should use a common way of defining a paragraph(start and end). Do you know what I mean?
I think paragraphs are separated by blank lines (space is allowed).
Actually, since Ctrl-] and Ctrl-[ already move the cursor by-paragraph, all "select paragraph" needs to do is:
- Ctrl-] (go to end of current paragraph).
- Mark this as the end of the selection.
- Ctrl-[ (go to beginning of paragraph).
- Mark this as the start of the selection.
Not exactly because Ctrl-] jumps to the next paragraph not the end of the current one. But it doesn't matter. I'll implement it by going to the beginning of the current paragraph and then going down until an empty line(completely empty or a line with only whitespace) is found and then spawn a selection between these two points.
Regards, Enrico
On Thu, 5 Jul 2007 21:00:51 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 12:57:04 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/5/07, John Gabriele jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- Shift-Alt-P to select paragraph
No problem, just needs to be implemented. Could paragraph defined in some way? To avoid further discussions (;-)) we should use a common way of defining a paragraph(start and end). Do you know what I mean?
I think paragraphs are separated by blank lines (space is allowed).
Actually, since Ctrl-] and Ctrl-[ already move the cursor by-paragraph, all "select paragraph" needs to do is:
- Ctrl-] (go to end of current paragraph).
- Mark this as the end of the selection.
- Ctrl-[ (go to beginning of paragraph).
- Mark this as the start of the selection.
Not exactly because Ctrl-] jumps to the next paragraph not the end of the current one. But it doesn't matter. I'll implement it by going to the beginning of the current paragraph and then going down until an empty line(completely empty or a line with only whitespace) is found and then spawn a selection between these two points.
Done in SVN r1669. Please test it. I also set Shift-Alt-W for select current word.
Regards, Enrico
On 7/6/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 21:00:51 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 12:57:04 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/5/07, John Gabriele jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
- Shift-Alt-P to select paragraph
No problem, just needs to be implemented. Could paragraph defined in some way? To avoid further discussions (;-)) we should use a common way of defining a paragraph(start and end). Do you know what I mean?
I think paragraphs are separated by blank lines (space is allowed).
Actually, since Ctrl-] and Ctrl-[ already move the cursor by-paragraph, all "select paragraph" needs to do is:
- Ctrl-] (go to end of current paragraph).
- Mark this as the end of the selection.
- Ctrl-[ (go to beginning of paragraph).
- Mark this as the start of the selection.
Not exactly because Ctrl-] jumps to the next paragraph not the end of the current one. But it doesn't matter. I'll implement it by going to the beginning of the current paragraph and then going down until an empty line(completely empty or a line with only whitespace) is found and then spawn a selection between these two points.
Done in SVN r1669. Please test it.
Very nice! Thanks! A couple quick issues I noted:
1. When I select a paragraph and hit Ctrl-D to duplicate it, it doesn't behave like when duplicating lines. It pastes the copy of the paragraph directly onto the end of the selected paragraph, which makes that first line begin right where the paragraph ends, instead of on the next line.
2. If the last line of the paragraph is very long, the window scrolls right to show me the end of that line. This is a bit jarring. It would be nicer, IMO, if the window view stayed scrolled left, regardless of line length.
As a solution to both of those, it seems like select-paragraph should select the paragraph, *including* the last newline at the end of it.
I also set Shift-Alt-W for select current word.
Ah... need to remove that from the list of things I change/add on a fresh Geany install. :)
Thanks, ---John
On Fri, 6 Jul 2007 11:27:39 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/6/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 21:00:51 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 12:57:04 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/5/07, John Gabriele jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
> * Shift-Alt-P to select paragraph
No problem, just needs to be implemented. Could paragraph defined in some way? To avoid further discussions (;-)) we should use a common way of defining a paragraph(start and end). Do you know what I mean?
I think paragraphs are separated by blank lines (space is allowed).
Actually, since Ctrl-] and Ctrl-[ already move the cursor by-paragraph, all "select paragraph" needs to do is:
- Ctrl-] (go to end of current paragraph).
- Mark this as the end of the selection.
- Ctrl-[ (go to beginning of paragraph).
- Mark this as the start of the selection.
Not exactly because Ctrl-] jumps to the next paragraph not the end of the current one. But it doesn't matter. I'll implement it by going to the beginning of the current paragraph and then going down until an empty line(completely empty or a line with only whitespace) is found and then spawn a selection between these two points.
Done in SVN r1669. Please test it.
Very nice! Thanks! A couple quick issues I noted:
- When I select a paragraph and hit Ctrl-D to duplicate it, it
doesn't behave like when duplicating lines. It pastes the copy of the paragraph directly onto the end of the selected paragraph, which makes that first line begin right where the paragraph ends, instead of on the next line.
- If the last line of the paragraph is very long, the window scrolls
right to show me the end of that line. This is a bit jarring. It would be nicer, IMO, if the window view stayed scrolled left, regardless of line length.
As a solution to both of those, it seems like select-paragraph should select the paragraph, *including* the last newline at the end of it.
Yes, this is exactly the problem. I wasn't sure about the selection boundaries and decided to not include the new line character(s). Obviously it is better when it is included. So, fixed it in SVN r1673. Thanks.
Regards, Enrico
On 7/7/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Fri, 6 Jul 2007 11:27:39 -0400, "John Gabriele" jmg3000@gmail.com wrote:
As a solution to both of those, it seems like select-paragraph should select the paragraph, *including* the last newline at the end of it.
Yes, this is exactly the problem. I wasn't sure about the selection boundaries and decided to not include the new line character(s). Obviously it is better when it is included. So, fixed it in SVN r1673. Thanks.
Nice! :)
That sounds preferable and easy to remember to me (delete line: Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).
Ok, I'll do it tomorrow if nobody complains ;-).
Changes in SVN r1674: Ctrl-K - delete line Ctrl-Shift-K - cut line Shift-Alt-K - copy line Ctrl-T - transpose line (now changeable) Shift-Alt-L - select line Ctrl-L - goto line dialog
Excellent. Now I don't feel so bad using up Ctrl-T for getting the incremental search. :)
Incidentally, I notice that, by default, you've accidentally got "Uncomment line(s)" set to just a Ctrl character by itself.
Thanks! ---John
On Mon, 9 Jul 2007 11:08:08 -0400, "John Gabriele" jmg3000@gmail.com wrote:
That sounds preferable and easy to remember to me (delete line: Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).
Ok, I'll do it tomorrow if nobody complains ;-).
Changes in SVN r1674: Ctrl-K - delete line Ctrl-Shift-K - cut line Shift-Alt-K - copy line Ctrl-T - transpose line (now changeable) Shift-Alt-L - select line Ctrl-L - goto line dialog
Excellent. Now I don't feel so bad using up Ctrl-T for getting the incremental search. :)
Hehe.
Incidentally, I notice that, by default, you've accidentally got "Uncomment line(s)" set to just a Ctrl character by itself.
Oops, the Control mask just was left over while deleting the previous default value. Thank you!
Regards, Enrico
On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele" jmg3000@gmail.com wrote:
Switching between matching braces is nice but at least I use it very rare. But I use duplicating lines/selection very very often and I assume I get pain in my fingers if we change Duplicate to Shift-Alt-C ;-).
Yes, I'm finding Duplicate quite helpful also, and maybe hitting Shift-Alt on my ergonomic keyboard is easier than on other more commonly-used keyboards.
By the way, I'm still rooting for seeing:
[snip]
- Shift-Alt-L to select line
Shift-Alt-L is currently used a "Line Delete" by Scintilla, but I suggest to remove the Line Delete feature (because of probably rare usage) and use Shift-Alt-L for select line.
Actually, that's Shift-Ctrl-L to delete current line, not Shift-Alt-L
Oops, sorry.
(and Ctrl-L cuts the line). Deleting (or else cutting) the current line is very handy, IMO. Though I'm used to both GNU Emacs and GNU nano using Ctrl-K for it. Ctrl-L seems more like it should be "go to
The Gnome HIG says in Table 10.4 "Emacs-style navigation keys for widgets" Ctrl-U for delete current line. It really seems there is no sane way to provide defaults to make all happy. Sigh. But we could bind Delete line or Cut line to Ctrl-K (and the other one to Ctrl-Shift-K or Ctrl-Alt-K, I don't care) and bind Go to line to Ctrl -L. What do you think?
Incidentally, I don't see "delete current line" (or "cut current line") listed in Help --> Keyboard shortcuts, or in Edit --> Preferences --> Keybindings. I guess those 2 places are only for Geany-specific (outside of Scintilla defaults) bindings?
Yes. Ctrl-L is a Scintilla binding but could be rebind by Geany (as we have already done for example for Ctrl-A).
Regards, Enrico
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele" jmg3000@gmail.com wrote:
[snip]
- Shift-Alt-L to select line
Shift-Alt-L is currently used a "Line Delete" by Scintilla, but I suggest to remove the Line Delete feature (because of probably rare usage) and use Shift-Alt-L for select line.
Actually, that's Shift-Ctrl-L to delete current line, not Shift-Alt-L
Oops, sorry.
(and Ctrl-L cuts the line). Deleting (or else cutting) the current line is very handy, IMO. Though I'm used to both GNU Emacs and GNU nano using Ctrl-K for it. Ctrl-L seems more like it should be "go to
The Gnome HIG says in Table 10.4 "Emacs-style navigation keys for widgets" Ctrl-U for delete current line.
That's odd. Might be an error. In Emacs, Ctrl-U is a prefix key -- you usually use it to tell Emacs to do the next command <n> times: ``Ctrl-U <n> some_command``.
It really seems there is no sane way to provide defaults to make all happy. Sigh. But we could bind Delete line or Cut line to Ctrl-K (and the other one to Ctrl-Shift-K or Ctrl-Alt-K, I don't care) and bind Go to line to Ctrl -L. What do you think?
That sounds preferable and easy to remember to me (delete line: Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).
Incidentally, I don't see "delete current line" (or "cut current line") listed in Help --> Keyboard shortcuts, or in Edit --> Preferences --> Keybindings. I guess those 2 places are only for Geany-specific (outside of Scintilla defaults) bindings?
Yes. Ctrl-L is a Scintilla binding but could be rebind by Geany (as we have already done for example for Ctrl-A).
I see that you can steal a key-binding from Scintilla, and have Geany override it. But, can you re-bind some other key to a Scintilla-specific command, such as "delete line" or "cut line"? I don't see either of those listed in Preferences --> Keybindings.
---John
On Thu, 5 Jul 2007 15:09:58 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele" jmg3000@gmail.com wrote:
[snip]
- Shift-Alt-L to select line
Shift-Alt-L is currently used a "Line Delete" by Scintilla, but I suggest to remove the Line Delete feature (because of probably rare usage) and use Shift-Alt-L for select line.
Actually, that's Shift-Ctrl-L to delete current line, not Shift-Alt-L
Oops, sorry.
(and Ctrl-L cuts the line). Deleting (or else cutting) the current line is very handy, IMO. Though I'm used to both GNU Emacs and GNU nano using Ctrl-K for it. Ctrl-L seems more like it should be "go to
The Gnome HIG says in Table 10.4 "Emacs-style navigation keys for widgets" Ctrl-U for delete current line.
That's odd. Might be an error. In Emacs, Ctrl-U is a prefix key -- you
Probably, just wanted to mention it.
It really seems there is no sane way to provide defaults to make all happy. Sigh. But we could bind Delete line or Cut line to Ctrl-K (and the other one to Ctrl-Shift-K or Ctrl-Alt-K, I don't care) and bind Go to line to Ctrl -L. What do you think?
That sounds preferable and easy to remember to me (delete line: Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).
Ok, I'll do it tomorrow if nobody complains ;-).
Incidentally, I don't see "delete current line" (or "cut current line") listed in Help --> Keyboard shortcuts, or in Edit --> Preferences --> Keybindings. I guess those 2 places are only for Geany-specific (outside of Scintilla defaults) bindings?
Yes. Ctrl-L is a Scintilla binding but could be rebind by Geany (as we have already done for example for Ctrl-A).
I see that you can steal a key-binding from Scintilla, and have Geany override it. But, can you re-bind some other key to a Scintilla-specific command, such as "delete line" or "cut line"? I
Yes, no problem.
don't see either of those listed in Preferences --> Keybindings.
Not yet ;-). I'll add them tomorrow together with the Line transpose feature which is currently bound to Ctrl-T (by Scintilla). I think we keep this default but make it changeable through Geany.
Regards, Enrico
Enrico Tröger wrote:
On Thu, 5 Jul 2007 15:09:58 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele" jmg3000@gmail.com wrote:
[snip]
- Shift-Alt-L to select line
Shift-Alt-L is currently used a "Line Delete" by Scintilla, but I suggest to remove the Line Delete feature (because of probably rare usage) and use Shift-Alt-L for select line.
Actually, that's Shift-Ctrl-L to delete current line, not Shift-Alt-L
Oops, sorry.
(and Ctrl-L cuts the line). Deleting (or else cutting) the current line is very handy, IMO. Though I'm used to both GNU Emacs and GNU nano using Ctrl-K for it. Ctrl-L seems more like it should be "go to
The Gnome HIG says in Table 10.4 "Emacs-style navigation keys for widgets" Ctrl-U for delete current line.
That's odd. Might be an error. In Emacs, Ctrl-U is a prefix key -- you
Probably, just wanted to mention it.
It really seems there is no sane way to provide defaults to make all happy. Sigh. But we could bind Delete line or Cut line to Ctrl-K (and the other one to Ctrl-Shift-K or Ctrl-Alt-K, I don't care) and bind Go to line to Ctrl -L. What do you think?
That sounds preferable and easy to remember to me (delete line: Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).
Ok, I'll do it tomorrow if nobody complains ;-).
Incidentally, I don't see "delete current line" (or "cut current line") listed in Help --> Keyboard shortcuts, or in Edit --> Preferences --> Keybindings. I guess those 2 places are only for Geany-specific (outside of Scintilla defaults) bindings?
Yes. Ctrl-L is a Scintilla binding but could be rebind by Geany (as we have already done for example for Ctrl-A).
I see that you can steal a key-binding from Scintilla, and have Geany override it. But, can you re-bind some other key to a Scintilla-specific command, such as "delete line" or "cut line"? I
Yes, no problem.
don't see either of those listed in Preferences --> Keybindings.
Not yet ;-). I'll add them tomorrow together with the Line transpose feature which is currently bound to Ctrl-T (by Scintilla). I think we keep this default but make it changeable through Geany.
Regards, Enrico
Geany mailing list Geany@uvena.de http://uvena.de/cgi-bin/mailman/listinfo/geany
Well if we're really wishing.... I'd love to have the old BRIEF keybindings.... Alt-d - delete line Alk-k - Delete to end of line
:)
Michael
On Thu, 05 Jul 2007 15:58:05 -0400, Michael Comperchio mcmprch@gmail.com wrote:
[snip many many text] Well if we're really wishing.... I'd love to have the old BRIEF keybindings.... Alt-d - delete line Alk-k - Delete to end of line
I'm sorry but we pointed already out that using Alt-letter isn't a good idea because of menu accelerators. Anyway, feel free to reassign the keybindings you like while loosing the menu accelerators.
Regards, Enrico
On Thu, 5 Jul 2007 21:15:20 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
It really seems there is no sane way to provide defaults to make all happy. Sigh. But we could bind Delete line or Cut line to Ctrl-K (and the other one to Ctrl-Shift-K or Ctrl-Alt-K, I don't care) and bind Go to line to Ctrl -L. What do you think?
That sounds preferable and easy to remember to me (delete line: Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).
Ok, I'll do it tomorrow if nobody complains ;-).
Changes in SVN r1674: Ctrl-K - delete line Ctrl-Shift-K - cut line Shift-Alt-K - copy line Ctrl-T - transpose line (now changeable) Shift-Alt-L - select line Ctrl-L - goto line dialog
Regards, Enrico
On 7/7/07, Enrico Tröger enrico.troeger@uvena.de wrote:
Changes in SVN r1674: ... Ctrl-L - goto line dialog
Cool ! I re-mapped go-to-line to Ctrl+G, and now my "clear screen" hotkey works in VTE!
Thanks!
- Jeff
On 07/05/2007 08:15:20 PM, Enrico Tröger wrote:
On Thu, 5 Jul 2007 15:09:58 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele" jmg3000@gmail.com wrote: But we could bind Delete line or Cut line to Ctrl-K (and the other one to Ctrl-Shift-K or Ctrl-Alt-K, I don't care) and bind Go to line to Ctrl -L. What do you think?
That sounds preferable and easy to remember to me (delete line: Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).
Ok, I'll do it tomorrow if nobody complains ;-).
I've been thinking it might be better to swap the default ctrl-k actions: 1. Delete Line is more destructive than Cut Line, so having to press shift as well makes it harder to do by accident - occasionally I don't hold down the shift key enough when doing the ctrl-shift keycombos. 2. Ctrl-k for 'K'ut line seems easier to remember.
Anyone else agree?
Also I've made pressing Escape focus the editor when using the incremental search bar or goto line toolbar control.
Regards, Nick
On 7/24/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/05/2007 08:15:20 PM, Enrico Tröger wrote:
On Thu, 5 Jul 2007 15:09:58 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele" jmg3000@gmail.com wrote: But we could bind Delete line or Cut line to Ctrl-K (and the other one to Ctrl-Shift-K or Ctrl-Alt-K, I don't care) and bind Go to line to Ctrl -L. What do you think?
That sounds preferable and easy to remember to me (delete line: Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).
Ok, I'll do it tomorrow if nobody complains ;-).
I've been thinking it might be better to swap the default ctrl-k actions:
- Delete Line is more destructive than Cut Line, so having to press
shift as well makes it harder to do by accident - occasionally I don't hold down the shift key enough when doing the ctrl-shift keycombos. 2. Ctrl-k for 'K'ut line seems easier to remember.
Anyone else agree?
Most often, I use Ctrl-K to gobble up some lines that I don't need. One case where this shows up is: I cut or copy something to the clipboard, navigate to where I want it, but first hit Ctrl-K or Enter a few times to tidy up a bit before hitting Ctrl-V to paste. If Ctrl-K was was cutting, I'd lose my previous selection.
---John
On Tue, 24 Jul 2007 12:46:24 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/24/07, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/05/2007 08:15:20 PM, Enrico Tröger wrote:
On Thu, 5 Jul 2007 15:09:58 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/5/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele" jmg3000@gmail.com wrote: But we could bind Delete line or Cut line to Ctrl-K (and the other one to Ctrl-Shift-K or Ctrl-Alt-K, I don't care) and bind Go to line to Ctrl -L. What do you think?
That sounds preferable and easy to remember to me (delete line: Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).
Ok, I'll do it tomorrow if nobody complains ;-).
I've been thinking it might be better to swap the default ctrl-k actions:
- Delete Line is more destructive than Cut Line, so having to press
shift as well makes it harder to do by accident - occasionally I don't hold down the shift key enough when doing the ctrl-shift keycombos. 2. Ctrl-k for 'K'ut line seems easier to remember.
Anyone else agree?
Yes, personally I don't really care because I use these features very very seldom (I'm used to delete or cut lines by marking them and Ctrl-X or DEL). Anyway, the point about the destructiveness of Delete line make sense to me and in most cases it should be better to cut the line instead of real deleting it (ok, there is Undo but there is also a clipboard manager on most systems).
Most often, I use Ctrl-K to gobble up some lines that I don't need. One case where this shows up is: I cut or copy something to the clipboard, navigate to where I want it, but first hit Ctrl-K or Enter a few times to tidy up a bit before hitting Ctrl-V to paste. If Ctrl-K was was cutting, I'd lose my previous selection.
In any case you still can reassign the keys.
Regards, Enrico
On Thu, 5 Jul 2007 18:04:56 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
Sounds good. So, we remove the default keybindings for comment/uncomment and let them undefined and we assign Ctrl-E to toggle comment. OK?
Sounds good to me. I'm interested to see how the new toggle comment behaviour ('//~' and '#~') works out in practice.
Me too ;-). I'm going to start implementing it.
Done in SVN r1668 (also fixed some selection issues).
The comment toggling feature seems to work but of course I probably put some bugs in the code ;-). Anyway, it is a bit different from Scite's behaviour because I wanted to keep the current comment/uncomment (without toggling) functionality. Scite only use comment toggling and so they use just //~ as the comment characters. We still use only // and add the ~ only when comment toggling. So, ordinary uncomment will work although the ~ will remain. The char '~' is hardcoded at the moment, could be changed at compile time in src/geany.h (GEANY_TOGGLE_MARK). Should it be configurable for each filetype? Is there any need for this or is there any language which uses '~' as a single comment character (which would obviously break the comment toggling)?
Regards, Enrico
On Thu, 5 Jul 2007 20:26:42 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
On Thu, 5 Jul 2007 18:04:56 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/4/07, Enrico Tröger enrico.troeger@uvena.de wrote:
Sounds good. So, we remove the default keybindings for comment/uncomment and let them undefined and we assign Ctrl-E to toggle comment. OK?
Sounds good to me. I'm interested to see how the new toggle comment behaviour ('//~' and '#~') works out in practice.
Me too ;-). I'm going to start implementing it.
Done in SVN r1668 (also fixed some selection issues).
Forgot to mention: Keyboard shortcut for comment toggling was changed to: Ctrl-E. Shortcuts for comment/uncomment are now undefined.
Regards, Enrico
On 07/05/2007 05:04:56 PM, Enrico Tröger wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com
Also, since now Ctrl-G would be freed up, even though I know you prefer F3 for "find again" (and Shift-F3 for "find previous"), it's pretty standard to use Ctrl-G and Shift-Ctrl-G for that (Mac OS X, KDE, and Gnome). MS Windows is the only one who uses F3 for it. And Ctrl-G really is easier to hit than an F_key without looking away
from
the keyboard. Shift-F3 is even harder to hit. :) {ducks}
Hmm, it really seems to be more default to have Ctrl-(Shift-)G for Find Next/Previous. I didn't know that and until now only saw F3/Shift-F3. We could change it if Nick will agree.
Well I prefer F3, but if ctrl-g is more widely known among *nix users, I don't mind if it's changed.
As long as we're looking at the Gnome HIG and the CUA standards, it looks like most apps use Ctrl-D instead of Ctrl-M to deal with bookmarks. I think Ctrl-M is usually reserved for hopping between *m*atching bracket characters (parentheses, brackets, braces, angle brackets). If you went with that, you could possibly switch "Duplicate" to Shift-Alt-C (for *c*opy). This seems reasonable to
me,
since it's probably much more common to toggle bookmarks and toggle between matching brackets than duplicating selected text.
Oh please not. Switching between matching braces is nice but at least I use it very rare. But I use duplicating lines/selection very very often and I assume I get pain in my fingers if we change Duplicate to Shift-Alt-C ;-).
I tend to use duplicate about the same as the other commands mentioned, and I prefer Ctrl-D. I would argue that markers are different from browser-like bookmarks, but maybe I'm being pedantic.
Regards, Nick
On Fri, 06 Jul 2007 11:54:15 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 07/05/2007 05:04:56 PM, Enrico Tröger wrote:
On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele" jmg3000@gmail.com
Also, since now Ctrl-G would be freed up, even though I know you prefer F3 for "find again" (and Shift-F3 for "find previous"), it's pretty standard to use Ctrl-G and Shift-Ctrl-G for that (Mac OS X, KDE, and Gnome). MS Windows is the only one who uses F3 for it. And Ctrl-G really is easier to hit than an F_key without looking away
from
the keyboard. Shift-F3 is even harder to hit. :) {ducks}
Hmm, it really seems to be more default to have Ctrl-(Shift-)G for Find Next/Previous. I didn't know that and until now only saw F3/Shift-F3. We could change it if Nick will agree.
Well I prefer F3, but if ctrl-g is more widely known among *nix users, I don't mind if it's changed.
I prefer F3 too but I think in this case we should change it.
As long as we're looking at the Gnome HIG and the CUA standards, it looks like most apps use Ctrl-D instead of Ctrl-M to deal with bookmarks. I think Ctrl-M is usually reserved for hopping between *m*atching bracket characters (parentheses, brackets, braces, angle brackets). If you went with that, you could possibly switch "Duplicate" to Shift-Alt-C (for *c*opy). This seems reasonable to
me,
since it's probably much more common to toggle bookmarks and toggle between matching brackets than duplicating selected text.
Oh please not. Switching between matching braces is nice but at least I use it very rare. But I use duplicating lines/selection very very often and I assume I get pain in my fingers if we change Duplicate to Shift-Alt-C ;-).
I tend to use duplicate about the same as the other commands mentioned, and I prefer Ctrl-D. I would argue that markers are different from browser-like bookmarks, but maybe I'm being pedantic.
I agree. Keep Ctrl-D for Duplicate and Ctrl-M for toggling markers.
Regards, Enrico
Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
I like this, but maybe it should be the other way around - on most layouts ctrl-number is easier for common tab width indenting, and holding shift for the less common case makes sense (for me anyway).
For what it's worth, NEdit uses Ctrl+9 for single-space indent, and Ctrl+( for tab-width indent, so I would be inclined to vote for that.
But if I remember correctly, Borland's editors use Ctrl+I and Ctrl+U for indent/unindent, so I guess it's impossible to not confuse somebody :-)
- Jeff
On 6/28/07, Jeff Pohlmeyer yetanothergeek@gmail.com wrote:
Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
I like this, but maybe it should be the other way around - on most layouts ctrl-number is easier for common tab width indenting, and holding shift for the less common case makes sense (for me anyway).
For what it's worth, NEdit uses Ctrl+9 for single-space indent, and Ctrl+( for tab-width indent, so I would be inclined to vote for that.
But if I remember correctly, Borland's editors use Ctrl+I and Ctrl+U for indent/unindent, so I guess it's impossible to not confuse somebody :-)
Probably most important is to just pick a design and stay consistent with it. If you're going to use Shift to make an editor function with an obvious opposite do its opposite, then you should use that throughout to keep the keybindings consistent.
Reminds me of an Emacs feature that always bugged me: Emacs often uses Alt-key to mean something just more or extended than Ctrl-key (ex. Ctrl-F to go forward-by-character, Alt-F to go forward-by-word). That's fine, and you can get used to it pretty easily. But then they go and set Ctrl-V be page-down, and Alt-V page up, which feels totally wrong given you're already used to those modifier keys meaning something else.
---John
Jeff Pohlmeyer wrote:
Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
I like this, but maybe it should be the other way around - on most layouts ctrl-number is easier for common tab width indenting, and holding shift for the less common case makes sense (for me anyway).
For what it's worth, NEdit uses Ctrl+9 for single-space indent, and Ctrl+( for tab-width indent, so I would be inclined to vote for that.
But if I remember correctly, Borland's editors use Ctrl+I and Ctrl+U for indent/unindent, so I guess it's impossible to not confuse somebody :-)
- Jeff
About those Ctrl+9/Ctrl+0 and Ctrl+( Ctrl+) that you talked about, remember everyone doesn't use qwery keybords :
Fore example on my french "azerty" keyboard, to pres Ctrl+9 you have to press "Ctrl", "Shift" and the "9 button" (which is "ç" if you don't press Shift) and for Ctrl+0, "Ctrl" + "Shift" + the "0 button" (which is à if you don't press Shift). That's not a big deal but keep it in mind.
Also, I don't know about qwerty keybords but ) and ( are not close to each other here (they are 6 characters far from each other) and are not next to 9 and 0 at all. That's a bit more of a problem if you choose to keep those combination to indent/deindent.
So like somebody said, try to stay on alphanumeric characters elsewhat the different keybord layouts will make it almost impossible for some people to use your combinations efficiently ;)
iKs.
On 06/29/2007 12:29:10 AM, Maxime Sadrieh (iKs) wrote:
Jeff Pohlmeyer wrote:
Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
I like this, but maybe it should be the other way around - on most layouts ctrl-number is easier for common tab width indenting, and holding shift for the less common case makes sense (for me anyway).
Oops, I didn't want to remove tab/shift-tab, I meant replace ctrl-[shift]-I to be changed.
[...] But if I remember correctly, Borland's editors use Ctrl+I and Ctrl+U for indent/unindent, so I guess it's impossible to not confuse somebody :-)
I'd vote for this - I prefer having two adjacent keys for indent/unindent, and it's easy to remember. It wouldn't use up keybindings if we implemented indent by one space when holding shift - otherwise there are no universal adjacent keys that can do this. It would mean Ctrl-U for convert case would have to be changed, but IMO this is a less common command.
About those Ctrl+9/Ctrl+0 and Ctrl+( Ctrl+) that you talked about, remember everyone doesn't use qwery keybords :
Fore example on my french "azerty" keyboard, to pres Ctrl+9 you have to press "Ctrl", "Shift" and the "9 button" (which is "ç" if you don't press Shift) and for Ctrl+0, "Ctrl" + "Shift" + the "0 button" (which is à if you don't press Shift).
Yikes, I thought that was pretty much standard. I've just looked through the Wikipedia page and it seems only AZERTY that does this.
http://en.wikipedia.org/wiki/Keyboard_layout
I agree for common commands, but for less common ones (not indenting) I think Ctrl-number is mostly OK (e.g. custom commands). We're running out of keybindings(!) Also they are configurable.
Also, I don't know about qwerty keybords but ) and ( are not close to each other here (they are 6 characters far from each other) and are not next to 9 and 0 at all. That's a bit more of a problem if you choose to keep those combination to indent/deindent.
Yes, I guess those aren't a good choice.
So like somebody said, try to stay on alphanumeric characters elsewhat the different keybord layouts will make it almost impossible for some people to use your combinations efficiently ;)
Ironically, it was me that said that ;-)
Regards, Nick
On Fri, 29 Jun 2007 13:07:03 +0100, Nick Treleaven nick.treleaven@btinternet.com wrote:
On 06/29/2007 12:29:10 AM, Maxime Sadrieh (iKs) wrote:
Jeff Pohlmeyer wrote:
Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
I like this, but maybe it should be the other way around - on most layouts ctrl-number is easier for common tab width indenting, and holding shift for the less common case makes sense (for me anyway).
Oops, I didn't want to remove tab/shift-tab, I meant replace ctrl-[shift]-I to be changed.
[...] But if I remember correctly, Borland's editors use Ctrl+I and Ctrl+U for indent/unindent, so I guess it's impossible to not confuse somebody :-)
I'd vote for this - I prefer having two adjacent keys for indent/unindent, and it's easy to remember. It wouldn't use up keybindings if we implemented indent by one space when holding shift
Why don't we just implement the feature, add key bindings for it but leave them undefined so everyone who wants to use it can bind the feature to any keys he likes.
As we know in the meantime, we are low on available keybindings, especially on adjacent ones and we will get more actions. So IMO for less common commands it's better to leave the default keybindings undefined and let the user the choice of defining it.
Regards, Enrico
Probably worth mentioning that the Gnome HIG provides guidelines for at least some of the bindings in question. I don't necessarily agree with everything they say, and I doubt anyone else here will either, but it might be worth a look:
http://developer.gnome.org/projects/gup/hig/2.0/input-keyboard.html#standard...
- Jeff
On Thu, 28 Jun 2007 13:57:49 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On 06/26/2007 07:03:48 PM, John Gabriele wrote:
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele" jmg3000@gmail.com wrote:
I'd go with the more common operation -- go all lowercase first. Besides, you're already holding down the Ctrl key and you want uppercase, you just tap 'U' again.
Is it really a problem to have two key bindings for that? AFAIK I always seen two bindings resp. two actions for lowering or uppering the case in other apps.
No. The only problem is that using the Shift key to do the opposite of the un-Shifted command feels backwards, and IMO is more difficult for users to remember. Whenever I need to use Shift to do an opposite operation, my brain has to stop short and go, "oh, right. yes, I know Shift usually enhances the command in some way, but for this special case it makes it do the opposite".
Well there is Shift-F3 for search backwards too. Personally I find it easier to remember with shift for things like that, and it frees up more keys for other keybindings. But for indenting maybe ctrl-0 and ctrl-9 are better. I think that's because it's easier to associate with left and right.
Tab and Shift+Tab is easier to do, IMHO, especially for those of us with localized keyboards, since numbers are not reachable without Shift.
Cheers
François
On Tue, 26 Jun 2007 14:03:48 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 6/26/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele" jmg3000@gmail.com wrote:
[snip]
I came across this situation several times when copying text from somehwere or when writing code and copying some descriptive text ("Show XYZ") as a variable name("show_xyz"). Then I lower down the string. I could also just rewrite it but why? I'm lazy and Geany can lower down the string.
I'm sorry -- I should've been more clear and written "I've never had to swap *mixed* case as you describe." (emphasis added). I actually misread what you wrote and thought you were talking about having to turn "aBcD" into "AbCd". This operation seems like an oddball sort of transformation that probably shouldn't take up a key-combo.
I agree.
So, yeah, my idea is that if you had "Show XYZ", you'd just add the underscore, use Alt-W (whoops -- already mapped that to "select current word" :) ), then hit Ctrl-U to get "show_xyz". If you accidentally tap Ctrl-U twice, you'll end up with "SHOW_XYZ" and you'll need to tap it one more time to get what you want.
But when only toggle is available Geany would have to dice to choose whether I want the string in lower or upper case.
I'd go with the more common operation -- go all lowercase first. Besides, you're already holding down the Ctrl key and you want uppercase, you just tap 'U' again.
I don't like it. For the example you have to convert it twice if you want to convert the string into upper case. I prefer the current behaviour.
Is it really a problem to have two key bindings for that? AFAIK I always seen two bindings resp. two actions for lowering or uppering the case in other apps.
No. The only problem is that using the Shift key to do the opposite of the un-Shifted command feels backwards, and IMO is more difficult for users to remember. Whenever I need to use Shift to do an opposite operation, my brain has to stop short and go, "oh, right. yes, I know Shift usually enhances the command in some way, but for this special case it makes it do the opposite".
[snip] Anyhow, not a big deal at all. The current way just seems inconsistent
It is because we kept the default bindings from Scintilla/Scite where Ctrl+U is for lower case and Ctrl+Shift+U is for upper case.
Regards, Enrico
On Tue, 26 Jun 2007 16:29:27 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
But because of talking about indentation: I plan to add a feature to auto indent current line by pressing a key. This means, the current line will be indented according to the previous line independent of the current indentation(maybe too less or too much indentation). My
FYI: added in SVN r1705. No default keybinding (yet).
Regards, Enrico
On Tue, 26 Jun 2007 16:29:27 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
- Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
Who needs indentation by one space? I want to keep the Tab/Shift-Tab
FYI: indent/deindent by one space was added in SVN r1705. No default keybinding.
Regards, Enrico
On 7/16/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 16:29:27 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
- Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
Who needs indentation by one space? I want to keep the Tab/Shift-Tab
FYI: indent/deindent by one space was added in SVN r1705. No default keybinding.
Neat. :) I've been waiting to be able to map indent/unindent to Ctrl-0/9, and also indent-/unindent-by-single-space to Shift-Ctrl-)/(. Ahh... feels nice. :)
Incidentally, I notice that when I try to unindent (de-dent? de-indent? dent? ;) ) by one space, it actually pops me back to the nearest indent level (in my case, multiples of 4 spaces). This is probably connected with the nice and slick feature that allows me to hit backspace once and back up one indent level (which is a much-appreciated feature!). Is there any way to have it always just move one space in either direction, without any extra indentation magic?
Also, when I unindent by one space, Geany often extends the selection on me. For example, in a .py file:
'''
,---. | x | `---'
'''
If I select just the box in the middle, it indents-by-single-space fine, but unindenting-by-single-space extends the selection downward.
---John
On Mon, 16 Jul 2007 14:16:32 -0400, "John Gabriele" jmg3000@gmail.com wrote:
On 7/16/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 26 Jun 2007 16:29:27 +0200, Enrico Tröger enrico.troeger@uvena.de wrote:
Hi,
- Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to indent/de-indent by one space, and Ctrl-) & Ctrl-( to indent/de-indent by one tab width.
Who needs indentation by one space? I want to keep the Tab/Shift-Tab
FYI: indent/deindent by one space was added in SVN r1705. No default keybinding.
Neat. :) I've been waiting to be able to map indent/unindent to Ctrl-0/9, and also indent-/unindent-by-single-space to Shift-Ctrl-)/(. Ahh... feels nice. :)
Incidentally, I notice that when I try to unindent (de-dent? de-indent? dent? ;) ) by one space, it actually pops me back to the nearest indent level (in my case, multiples of 4 spaces). This is probably connected with the nice and slick feature that allows me to hit backspace once and back up one indent level (which is a much-appreciated feature!). Is there any way to have it always just move one space in either direction, without any extra indentation magic?
Thanks, this is some kind of usual "buggyness" I put in to keep us busy ;-). Fixed in SVN.
Also, when I unindent by one space, Geany often extends the selection on me. For example, in a .py file:
'''
,---. | x | `---'
'''
If I select just the box in the middle, it indents-by-single-space fine, but unindenting-by-single-space extends the selection downward.
I think it is fixed in SVN. Give it a try.
Regards, Enrico
On 7/17/07, Enrico Tröger enrico.troeger@uvena.de wrote:
On Mon, 16 Jul 2007 14:16:32 -0400, "John Gabriele" jmg3000@gmail.com wrote:
{snip} Is there any way to have it always just move one space in either direction, without any extra indentation magic?
Thanks, this is some kind of usual "buggyness" I put in to keep us busy ;-). Fixed in SVN.
:)
{snip} If I select just the box in the middle, it indents-by-single-space fine, but unindenting-by-single-space extends the selection downward.
I think it is fixed in SVN. Give it a try.
It now keeps its original selection for me, thanks. :)
One last thing I notice, which may or may not be a bug: If I select multiple lines, each having a different amount of whitespace before the text, for example:
''' foo bar baz '''
and I unindent-by-space, when that "foo" hits column 0, I expect the unindenting to not go any further. Instead, what happens is that "foo" stays where it is, but the next 2 lines keep unindenting. Same thing happens when bar hits column 0, and will continue until all lines are flush left. This behaviour seems wrong to me, but maybe you prefer it. The regular indent/unindent commands behave this way as well.
Thanks, ---John
On Tue, 17 Jul 2007 10:59:36 -0400, "John Gabriele" jmg3000@gmail.com wrote:
One last thing I notice, which may or may not be a bug: If I select multiple lines, each having a different amount of whitespace before the text, for example:
''' foo bar baz '''
and I unindent-by-space, when that "foo" hits column 0, I expect the unindenting to not go any further. Instead, what happens is that "foo" stays where it is, but the next 2 lines keep unindenting. Same thing happens when bar hits column 0, and will continue until all lines are flush left. This behaviour seems wrong to me, but maybe you prefer it. The regular indent/unindent commands behave this way as well.
Yes, this behaviour is intentionally in both cases(space and regular indentation). I never thought of anything else. Reason and/or examples to change it are welcome but I think to stop deindenting(or unindenting or however it is called ;-)) when any line within the selection reaches column 0, isn't the best choice. Then you have to reselect your text in case you want to deindent the other lines further. In your case, if you want to stop the deindenting when the first line reaches column 0 just stop pressing the keyboard shortcut. I think it's fair enough.
Regards, Enrico
On 6/26/07, John Gabriele jmg3000@gmail.com wrote:
[snip]
C. The mortal sin: Incremental search. Geany's Achilles' heel. One of an editors' most-useful features, it should be be effortless to do forward and backward incremental searches. As implemented, if I want to incrementally search forward, I need to hit F7, tap F3 to get to the one I want, then F2 to get back to the editor. So, I've basically got to spend the entire search looking at my hands instead of the text. It's even worse to search backward incrementally -- not sure I can even do this. Here's my proposed solution. Buckle seatbelts, and please observe the no-smoking signs:
- Steal Ctrl-T. Use it for forward incremental search (think of it as "to" or "incremen*t*al"). Same as today's F7. Move "transpose lines" to Shift-Ctrl-L.
- Shift-Ctrl-T gets you find next (like F3).
- Use Alt-T to start a reverse incremental search (Use Alt-O to get the Tools menu).
- Shift-Alt-T gets you find previous. Nice consistency here, I think.
- Hitting Ctrl-LeftArrow or Ctrl-RightArrow should snap you out of the incremental search and back to the main editor window (instead of today's F2). After an incremental search, you often either want to go to the beginning or end of the word you found anyway.
When you're in an incremental search, regardless of direction, you should be able to tap either Shift-Ctrl-T to find next, or Shift-Alt-T to find previous.
Then on 7/4/07, I wrote:
Also, since now Ctrl-G would be freed up, even though I know you prefer F3 for "find again" (and Shift-F3 for "find previous"), it's pretty standard to use Ctrl-G and Shift-Ctrl-G for that (Mac OS X, KDE, and Gnome). MS Windows is the only one who uses F3 for it. And Ctrl-G really is easier to hit than an F_key without looking away from the keyboard. Shift-F3 is even harder to hit. :) {ducks}
Well, with Ctrl-G and Shift-Ctrl-G set up to do find next/previous, to get incremental search working nicely, I just:
* changed "switch to toolbar search field" from F7 to Ctrl-T (incremen*t*al search) * changed "back to editor window" from F2 to Shift-Ctrl-T
and it seems to work quite nicely for me now. Thanks.
---John