[Geany] tuning Geany key combos

[John Gabriele]

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

[Enrico Tröger]

On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele" <***@gmail.com>
wrote:

Hi all,

Post by John Gabriele
[...]
So, given all that, to even more finely tune Geany's editing
A. Get rid of using Shift to make a key combo do the opposite
* 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.

Post by John Gabriele
* 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?

Post by John Gabriele
* 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

Post by John Gabriele
* 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.

Post by John Gabriele
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,
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.

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.

Post by John Gabriele
Finally, some new key combos to possibly add that would probably
1. Select line. Use Alt-L
2. Select paragraph. Use Alt-P (switch Project menu to Alt-R)

Above two sound nice. Could be implemented.

Post by John Gabriele
3. 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").

Post by John Gabriele
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

[John Gabriele]

[snip]

Post by John Gabriele
* 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?

Post by John Gabriele
* 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.

Post by John Gabriele
[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,
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.

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.

Post by John Gabriele
Finally, some new key combos to possibly add that would probably
1. Select line. Use Alt-L
2. Select paragraph. Use Alt-P (switch Project menu to Alt-R)

Above two sound nice. Could be implemented.

Post by John Gabriele
3. 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.

Post by John Gabriele
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

[Enrico Tröger]

Post by John Gabriele

Post by Enrico Tröger
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele"
[snip]

Post by John Gabriele
* 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?

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?

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.

Post by John Gabriele

Post by Enrico Tröger

Post by John Gabriele
* 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 ;-)).

Post by John Gabriele
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.
* 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.

Post by John Gabriele

Post by Enrico Tröger
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 ;-).

Post by John Gabriele

Post by Enrico Tröger
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?

Post by John Gabriele
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.

Post by John Gabriele
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.

Post by John Gabriele

Post by Enrico Tröger

Post by John Gabriele
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

[John Gabriele]

Post by Enrico Tröger

Post by John Gabriele

Post by Enrico Tröger
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele"
[snip]

Post by John Gabriele
* 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?

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?

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.

Post by Enrico Tröger
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.

Post by Enrico Tröger
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,

Post by Enrico Tröger

Post by John Gabriele
* 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. :)

Post by Enrico Tröger

Post by John Gabriele

Post by Enrico Tröger

Post by John Gabriele
* 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.

T

[Jeff Pohlmeyer]

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

[Enrico Tröger]

On Tue, 26 Jun 2007 13:21:02 -0500, "Jeff Pohlmeyer"

Post by Jeff Pohlmeyer
Hello friends, interesting discussion you are having here...
This might be slightly off topic, but here are a couple of things
1)
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?

Post by Jeff Pohlmeyer
2)
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

[John Gabriele]

Post by Enrico Tröger
On Tue, 26 Jun 2007 13:21:02 -0500, "Jeff Pohlmeyer"

[snip]
1)
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.

[John Gabriele]

[snip]
So, due to that first one, even you Geany provides a secret ninja key

Whoops. Typo:

even you Geany --> even if Geany

[snip]
1. Provide a "Document --> Allow tab characters" menu time that

Gah. Another one:

menu time --> menu item

---John

[Jeff Pohlmeyer]

Post by John Gabriele

Post by Enrico Tröger
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
1. 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 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

[Enrico Tröger]

On Wed, 27 Jun 2007 15:47:02 -0500, "Jeff Pohlmeyer"

Post by Jeff Pohlmeyer

Post by John Gabriele

Post by Enrico Tröger
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
1. 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 ;-).

Post by Jeff Pohlmeyer
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
[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

[Jeff Pohlmeyer]

Post by Enrico Tröger
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

[John Gabriele]

Post by Jeff Pohlmeyer

Post by Enrico Tröger
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

[Jeff Pohlmeyer]

Post by John Gabriele
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

[Enrico Tröger]

Post by John Gabriele

Post by Enrico Tröger
On Tue, 26 Jun 2007 13:21:02 -0500, "Jeff Pohlmeyer"

[snip]
1)
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
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.
1. 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.

Post by John Gabriele
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-: .

Ok, should be no big deal to add a key binding but I think it will be
emtpy by default.

Regards,
Enrico

[Enrico Tröger]

Post by John Gabriele

On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele"

[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.

Post by John Gabriele
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.

Post by John Gabriele

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

[Enrico Tröger]

On Tue, 26 Jun 2007 16:29:27 +0200, Enrico Tröger
<***@uvena.de> wrote:

Hi,

Post by Enrico Tröger

Post by John Gabriele
* 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

[John Gabriele]

On Tue, 26 Jun 2007 16:29:27 +0200, Enrico Tröger
Hi,

Post by Enrico Tröger

Post by John Gabriele
* 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 selec

[Enrico Tröger]

Post by John Gabriele

Post by Enrico Tröger
On Tue, 26 Jun 2007 16:29:27 +0200, Enrico Tröger
Hi,

Post by Enrico Tröger

Post by John Gabriele
* 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.

Post by John Gabriele
Also, when I unindent by one space, Geany often extends the selection
'''
,---.
| 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

[John Gabriele]

Post by Enrico Tröger

{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.

:)

Post by Enrico Tröger

{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,
-

[Enrico Tröger]

Post by John Gabriele
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
'''
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

[Enrico Tröger]

On Tue, 26 Jun 2007 16:29:27 +0200, Enrico Tröger
<***@uvena.de> wrote:

Hi,

Post by Enrico Tröger
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

[Nick Treleaven]

Post by John Gabriele

On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele"

Post by John Gabriele

Post by Enrico Tröger
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele"

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.

[...]

Post by John Gabriele
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,

Post by John Gabriele
* 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

Post by John Gabriele
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
* Ctrl-G to comment
* Ctrl-B to uncomment (go *b*ack :) )

I use the toggle comment the most (but I reassigned it to ctrl-').

Post by John Gabriele
Another possibility is using non-alphanumeric keys for this. Say,
* Ctrl-# (Shift-Ctrl-3) to comment
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.

Post by John Gabriele

Post by John Gabriele

Post by Enrico Tröger

Post by John Gabriele
* 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).

Post by John Gabriele

Post by John Gabriele

Post by Enrico Tröger
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,

Post by John Gabriele
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).

Post by John Gabriele

[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

[Enrico Tröger]

On Thu, 28 Jun 2007 13:57:49 +0100, Nick Treleaven

Post by Nick Treleaven
[...]

Post by John Gabriele
Anyhow, not a big deal at all. The current way just seems
inconsistent to me. What's more important, IMO, is the Ctrl-G

Post by Enrico Tröger

Post by John Gabriele
* 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
//~ 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

[John Gabriele]

Post by Nick Treleaven

On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele"

Post by John Gabriele
* 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

[Jeff Pohlmeyer]

Post by Nick Treleaven

Post by John Gabriele
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

[John Gabriele]

Post by Jeff Pohlmeyer

Post by Nick Treleaven

Post by John Gabriele
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

[Maxime Sadrieh (iKs)]

Post by Jeff Pohlmeyer

Post by Nick Treleaven

Post by John Gabriele
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.

[François Cami]

On Thu, 28 Jun 2007 13:57:49 +0100

Post by Nick Treleaven

Post by John Gabriele

On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele"

Post by Enrico Tröger
On Tue, 26 Jun 2007 00:41:07 -0400, "John Gabriele"

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

[Nick Treleaven]

Post by Maxime Sadrieh (iKs)

Post by Jeff Pohlmeyer

Post by Nick Treleaven

Post by John Gabriele
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.

Post by Maxime Sadrieh (iKs)

Post by Jeff Pohlmeyer
[...]
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.

Post by Maxime Sadrieh (iKs)
About those Ctrl+9/Ctrl+0 and Ctrl+( Ctrl+) that you talked about,
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.

Post by Maxime Sadrieh (iKs)
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.

Post by Maxime Sadrieh (iKs)
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

[Enrico Tröger]

On Fri, 29 Jun 2007 13:07:03 +0100, Nick Treleaven

Post by Nick Treleaven

Post by Jeff Pohlmeyer

Post by Nick Treleaven

Post by John Gabriele
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.

Post by Jeff Pohlmeyer
[...]
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

[Jeff Pohlmeyer]

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-shortcuts

- Jeff

[Nick Treleaven]

Post by John Gabriele

Post by John Gabriele

On Tue, 26 Jun 2007 11:43:27 -0400, "John Gabriele"

Post by John Gabriele
* Tab, Shift-Tab --> use Ctrl-9 & Ctrl-0 to

indent/de-indent

Post by John Gabriele
by one space, and Ctrl-) & Ctrl-( to indent/de-indent

by

Post by John Gabriele
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).

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.

Post by John Gabriele
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.

Post by John Gabriele
* 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).

Post by John Gabriele
Applying this to Geany's current key bindings, F3/Shift-F3 is good.
Shift-Alt-D even makes sense this way. :)
* 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.

Post by John Gabriele
* 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.

Post by John Gabriele
* 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

[Enrico Tröger]

On Fri, 29 Jun 2007 13:24:00 +0100, Nick Treleaven

Post by Nick Treleaven

Post by John Gabriele
Applying this to Geany's current key bindings, F3/Shift-F3 is good.
Shift-Alt-D even makes sense this way. :)
* 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.

Post by Nick Treleaven

Post by John Gabriele
* 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.

Post by Nick Treleaven

Post by John Gabriele
* 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

[John Gabriele]

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

[Enrico Tröger]

Post by John Gabriele
Nick,

Nice, a little summary is really a good idea ;-).

Post by John Gabriele
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.

Post by John Gabriele
* 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).

Post by John Gabriele
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.

Post by John Gabriele
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

[Michael Comperchio]

Post by Enrico Tröger

Post by John Gabriele
Nick,

Nice, a little summary is really a good idea ;-).

Post by John Gabriele
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.

Post by John Gabriele
* 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 ;-).
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).

Post by John Gabriele
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.

Post by John Gabriele
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
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

[John Gabriele]

Post by Enrico Tröger

Post by John Gabriele
* 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.

Post by Enrico Tröger
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.

Post by Enrico Tröger

Post by John Gabriele
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 G

[Enrico Tröger]

Post by John Gabriele

On Fri, 29 Jun 2007 11:08:49 -0400, "John Gabriele"

Post by John Gabriele
* 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 ;-).

Post by John Gabriele

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
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)?

Post by John Gabriele

Post by John Gabriele
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

[Nick Treleaven]

Post by Michael Comperchio
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
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

[Harold Aling]

Post by Nick Treleaven
I agree. I think Geany basically conforms with that table where
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-

[Enrico Tröger]

Post by Harold Aling

Post by Nick Treleaven
I agree. I think Geany basically conforms with that table where
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

[Michael Comperchio]

Post by Nick Treleaven

Post by Michael Comperchio
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
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
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
http://uvena.de/cgi-bin/mailman/listinfo/geany

Funny you should mention that....I change my keybindings to that.... ^H

Michael

[Jeff Pohlmeyer]

Post by Nick Treleaven
I agree. I think Geany basically conforms with that table where
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

[Enrico Tröger]

On Tue, 3 Jul 2007 17:16:31 -0500, "Jeff Pohlmeyer"

Post by Jeff Pohlmeyer

Post by Nick Treleaven
I agree. I think Geany basically conforms with that table where
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

[Nick Treleaven]

On Fri, 29 Jun 2007 14:12:53 -0400, "John Gabriele"

Post by John Gabriele

On Fri, 29 Jun 2007 11:08:49 -0400, "John Gabriele"

Post by John Gabriele
* doesn't seem crazy about the toggle (at least for changing

case

Post by John Gabriele

Post by John Gabriele
of a selection), but then mentions that Ctrl-B could still

toggle

Post by John Gabriele

Post by John Gabriele
line commenting.

Well, I don't really care. As long as I can redefine the keys to

my

Post by John Gabriele

own preferences I'm happy ;-).

Right. :) But, of course, for features that are currently

implemented

Post by John Gabriele
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

[Enrico Tröger]

On Wed, 04 Jul 2007 16:17:25 +0100, Nick Treleaven

Post by Nick Treleaven

Post by Enrico Tröger
[...]
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

[Nick Treleaven]

Post by Enrico Tröger
On Wed, 04 Jul 2007 16:17:25 +0100, Nick Treleaven

Post by Nick Treleaven

Post by Enrico Tröger
[...]
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

Post by Nick Treleaven

Post by Enrico Tröger
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

[John Gabriele]

Post by Enrico Tröger
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 ma

[Enrico Tröger]

Post by John Gabriele

Post by Enrico Tröger
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.

Post by John Gabriele
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.

Post by John Gabriele
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 ;-).

Post by John Gabriele
* Shift-Alt-W to select word

Will be done (only need to add the default keybinding).

Post by John Gabriele
* 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.

Post by John Gabriele
* 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?

Post by John Gabriele
* Shift-Alt-M to select all text between matching brackets.

Hmm, nice idea.


Regards,
Enrico

[John Gabriele]

Post by Enrico Tröger

Post by John Gabriele
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. :)

Post by Enrico Tröger
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.

Post by Enrico Tröger

Post by John Gabriele
[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?

Post by Enrico Tröger

Post by John Gabriele
* 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

[John Gabriele]

Post by Enrico Tröger

Post by John Gabriele
* 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 st

[Enrico Tröger]

Post by John Gabriele

On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele"

Post by John Gabriele
* 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
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.

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

[Enrico Tröger]

On Thu, 5 Jul 2007 21:00:51 +0200, Enrico Tröger

Post by Enrico Tröger

Post by John Gabriele

On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele"

Post by John Gabriele
* 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
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.

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

[John Gabriele]

On Thu, 5 Jul 2007 21:00:51 +0200, Enrico Tröger

Post by Enrico Tröger

Post by John Gabriele

On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele"

Post by John Gabriele
* 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
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.

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,
---Joh

[Enrico Tröger]

Post by John Gabriele

Post by Enrico Tröger
On Thu, 5 Jul 2007 21:00:51 +0200, Enrico Tröger

On Thu, 5 Jul 2007 12:57:04 -0400, "John Gabriele"

Post by John Gabriele

On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele"

Post by John Gabriele
* 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
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.

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.

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.

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

[John Gabriele]

Post by Enrico Tröger

Post by John Gabriele
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! :)

Post by Enrico Tröger

Post by John Gabriele

Post by John Gabriele
Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).

Ok, I'll do it tomorrow if nobody complains ;-).

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!
---

[Enrico Tröger]

Post by John Gabriele

Post by Enrico Tröger

Post by Enrico Tröger

Post by John Gabriele
Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).

Ok, I'll do it tomorrow if nobody complains ;-).

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.

Post by John Gabriele
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

[Enrico Tröger]

Post by John Gabriele

Post by Enrico Tröger
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.

Post by Enrico Tröger

[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.

Post by John Gabriele
(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?

Post by John Gabriele
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

[John Gabriele]

Post by Enrico Tröger

Post by John Gabriele

Post by Enrico Tröger

[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.

Post by John Gabriele
(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``.

Post by Enrico Tröger
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).

Post by Enrico Tröger

Post by John Gabriele
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 Prefer

[Enrico Tröger]

Post by John Gabriele

On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele"

Post by John Gabriele

Post by Enrico Tröger

[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.

Post by John Gabriele
(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.

Post by John Gabriele

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?

Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).

Ok, I'll do it tomorrow if nobody complains ;-).

Post by John Gabriele

Post by John Gabriele
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.

Post by John Gabriele
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

[Michael Comperchio]

Post by Enrico Tröger

Post by John Gabriele

On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele"

Post by John Gabriele

Post by Enrico Tröger

[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.

Post by John Gabriele
(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.

Post by John Gabriele

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?

Ctrl-K, cut line: Shift-Ctrl-K, go to line: Ctrl-L).

Ok, I'll do it tomorrow if nobody complains ;-).

Post by John Gabriele

Post by John Gabriele
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.

Post by John Gabriele
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
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

[Enrico Tröger]

On Thu, 05 Jul 2007 15:58:05 -0400, Michael Comperchio

[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

[Enrico Tröger]

On Thu, 5 Jul 2007 21:15:20 +0200, Enrico Tröger
<***@uvena.de> wrote:

Hi,

Post by Enrico Tröger

Post by John Gabriele

Post by Enrico Tröger
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?

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

[Jeff Pohlmeyer]

Post by Enrico Tröger
...
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

[Enrico Tröger]

On Thu, 5 Jul 2007 18:04:56 +0200, Enrico Tröger

Post by Enrico Tröger

Post by John Gabriele

Post by Enrico Tröger
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

[Enrico Tröger]

On Thu, 5 Jul 2007 20:26:42 +0200, Enrico Tröger

Post by Enrico Tröger
On Thu, 5 Jul 2007 18:04:56 +0200, Enrico Tröger

On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele"

Post by John Gabriele

Post by Enrico Tröger
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

[John Gabriele]

[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,
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.
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

[Nick Treleaven]

Post by Enrico Tröger

Post by John Gabriele
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

Post by John Gabriele
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.

Post by Enrico Tröger

Post by John Gabriele
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,

Post by John Gabriele
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

[Enrico Tröger]

On Fri, 06 Jul 2007 11:54:15 +0100, Nick Treleaven

Post by Nick Treleaven

On Wed, 4 Jul 2007 20:20:45 -0400, "John Gabriele"

Post by John Gabriele
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

Post by John Gabriele
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.

Post by Nick Treleaven

Post by John Gabriele
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,

Post by John Gabriele
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

[Nick Treleaven]

Post by Enrico Tröger

Post by John Gabriele

On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele"
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?

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

[John Gabriele]

Post by Nick Treleaven

Post by Enrico Tröger

Post by John Gabriele

On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele"
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?

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
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?

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 pre

[Enrico Tröger]

Post by John Gabriele

Post by Nick Treleaven

On Thu, 5 Jul 2007 15:09:58 -0400, "John Gabriele"

Post by John Gabriele

On Thu, 5 Jul 2007 12:47:30 -0400, "John Gabriele"
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?

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
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?

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).

Post by John Gabriele
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