Keybinding configuration

[hugoroy]

The README isn't exactly explicit regarding what and how to configure astroid.
https://github.com/gauteh/astroid/blob/master/README.md#configuration

For instance, how can the user modify the keybindings (e.g. Tab and Shift-Tab instead of b and B)? How can the user change the order of messages in the Thread Index List View (e.g. from older on top to newer on bottom)?

Some guidance would be nice :-)

Thanks

[gauteh]

At the moment they are not configurable, although this is high on the list! I was thinking to keep this out of the config file and maybe in a keybindings file?

The README should not be too complicated, but perhaps it could link to the wiki or something on how to configure keys (once that is implemented).

[hugoroy]

Ok. I also prefer to configure keybindings in a file of its own. The wiki should be the right place for this indeed (provided it's linked to from the README#configure section)

Thanks for replying fast and keep up the good work :-)

[gauteh]

Yeah.. I was thinking something along the lines of:

.config/astroid/keybindings:

thread_index.down=j
thread_index.up=k
thread_index.page_down=J
# thread_index.reply=r
# thread_index.forward=f

anything with # is ignored, and the default will be used. A fresh keybindings file will contain only a bunch of # statements to no effect.

[gauteh]

Hi, I pushed a bunch of changes that allows keybindings to be configured in ~/.config/astroid/keybindings the format is as discussed: ``` thread_index.next_thread=j ... ``` it is possible to set up several aliases for the same target, by listing it several times. All original bindings and aliases for the target are removed when it is manually configured. Some special keys are still missing (for the user bindings), let me know if you are missing something. You can figure out all the target names by looking for `register_key (...)` in the code or observe the debug output when you press a key.

[hugoroy]

I'm going to test this as soon as I'm able to build it again :-) see https://aur.archlinux.org/packages/astroid/#news

Then I'll edit the wiki to start a bit of documentation on that.

Thanks

[gauteh]

ok, thanks for testing. please use github for issues. what compiler are
you using?

Hugo Roy writes on December 31, 2015 18:15:

I'm going to test this as soon as I'm able to build it again :-) see https://aur.archlinux.org/packages/astroid/#news

Then I'll edit the wiki to start a bit of documentation on that.

Thanks

---

Reply to this email directly or view it on GitHub:
https://github.com/gauteh/astroid/issues/21#issuecomment-168224585

[gauteh]

fstream ambigiuty should be fixed! happy new year :)

Gaute Hope writes on December 31, 2015 18:46:

ok, thanks for testing. please use github for issues. what compiler are
you using?

Hugo Roy writes on December 31, 2015 18:15:

I'm going to test this as soon as I'm able to build it again :-) see https://aur.archlinux.org/packages/astroid/#news

Then I'll edit the wiki to start a bit of documentation on that.

Thanks

---

Reply to this email directly or view it on GitHub:
https://github.com/gauteh/astroid/issues/21#issuecomment-168224585

[hugoroy]

How can I use the Tab key?

[gauteh]

Hugo Roy writes on January 2, 2016 21:42:

How can I use the Tab key?

I was planning to support Tab and friends (like Down) in keybindings.cc,
which matches the map (keynames at
https://github.com/gauteh/astroid/blob/master/src/modes/keybindings.cc#L20).
The parser is located at keybindings.cc at:
https://github.com/gauteh/astroid/blob/master/src/modes/keybindings.cc#L302.

[gauteh]

Short answer: Not implemented yet for custom keybindings.

[hugoroy]

I'm having a hard time to set my own keybindings right now. It doesn't seem possible to override the defaults (i.e. if a key is already set to something then it can't be defined by the user for something else?)

For instance, this doesn't work:

thread_view.next_message=j

[debug] (12:28:38): key: registering key: thread_view.next_message: n
[ERROR] (12:28:38): key: j already exists in map.

(astroid:25755): glibmm-ERROR **: 
unhandled exception (type std::exception) in signal handler:
what: key: j already exists

[1]    25755 trace trap (core dumped)  astroid

Also, why can't a key be more than once, if the context is different. For instance consider:

main_window.close_page=C-w thread_index.close_pane=C-w

Output:

[debug] (12:27:22): key: registering key: main_window.close_page: x
[debug] (12:27:22): key: alias: C-w(119)
[ERROR] (12:27:22): key alias: C-w already exists in map.
terminate called after throwing an instance of 'Astroid::duplicatekey_error'
  what():  key: C-w already exists
[1]    25695 abort (core dumped)  astroid

[gauteh]

Hugo Roy writes on January 3, 2016 12:29:

I'm having a hard time to set my own keybindings right now. It doesn't seem possible to override the defaults (i.e. if a key is already set to something then it can't be defined by the user for something else?)

For instance, this doesn't work:

#thread_view.next_message=j

[debug] (12:28:38): key: registering key: thread_view.next_message: n
[ERROR] (12:28:38): key: j already exists in map.

First; I updated the error so that it is possible to know which key it
is conflicting with.

In this case it is conflicting with thread_view.down.

Secondly, this is a choice, since the other key-target would be
unreachable. The current behavior is to not allow targets to be
unreachable, and you would have to also define thread_view.down in
your custom keybindings. I guess, the other way is more logical? To just
delete the original one (if it is not user-defined)?

Also, why can't a key be more than once, if the context is different. For instance consider:

main_window.close_page=C-w thread_index.close_pane=C-w

There was a bug in how I scanned for user-aliases, this should be fixed.

[gauteh]

Gaute Hope writes on January 3, 2016 20:17:

Hugo Roy writes on January 3, 2016 12:29:

I'm having a hard time to set my own keybindings right now. It doesn't seem possible to override the defaults (i.e. if a key is already set to something then it can't be defined by the user for something else?)

For instance, this doesn't work:

#thread_view.next_message=j

[debug] (12:28:38): key: registering key: thread_view.next_message: n
[ERROR] (12:28:38): key: j already exists in map.

First; I updated the error so that it is possible to know which key it
is conflicting with.

In this case it is conflicting with thread_view.down.

Secondly, this is a choice, since the other key-target would be
unreachable. The current behavior is to not allow targets to be
unreachable, and you would have to also define thread_view.down in
your custom keybindings. I guess, the other way is more logical? To just
delete the original one (if it is not user-defined)?

I pushed a change which now allows this behavior, existing (non
user-defined) keys will be overwritten with a warning. I guess this will
make it easier to test out new keys.

[hugoroy]

Secondly, this is a choice, since the other key-target would be unreachable. The current behavior is to not allow targets to be unreachable, and you would have to also define thread_view.down in your custom keybindings. I guess, the other way is more logical? To just delete the original one (if it is not user-defined)?

I pushed a change which now allows this behavior, existing (non user-defined) keys will be overwritten with a warning. I guess this will make it easier to test out new keys.

Yes, I think this is the most useful :-)

Thanks

[gauteh]

I just pushed f19b6f2 and 5b00aaa which allow Unbound keys, this means that there are now four new targets which are not reachable by default, but can be accessed through the keybindings file.

These are forward_inline and forward_attached, which is usually
configured through the config file, but you can reach them directly by
setting keybindings like this:

# thread view
thread_view.forward_inline=f
thread_view.forward_attached=M-f

# thread index
thread_index.forward_inline=f
thread_index.forward_attached=M-f

(if you overwrite the existing keybinding for forward, the config option
will have no effect).

[hugoroy]

Arf, now I can't launch astroid any longer:

[info ] (13:10:16): date: init.
[info ] (13:10:16): keybindings: loading user bindings from: /home/hugo/.config/astroid/keybindings
[debug] (13:10:16): ky: parsing line: main_window.close_page=C-w #default: x
[ERROR] (13:10:16): key spec invalid: C-w #default: x
terminate called after throwing an instance of 'Astroid::keyspec_error'
  what():  invalid length of spec
[1]    28208 abort (core dumped)  astroid

Removing the #comment works, but this is unfortunate :)

[gauteh]

Err, yeah. Should split on # too, move the comment to a new line untill we
get to fix it.

Den lørdag 23. januar 2016 skrev Hugo Roy notifications@github.com
følgende:

Arf, now I can't launch astroid any longer:

info : date: init.
info : keybindings: loading user bindings from: /home/hugo/.config/astroid/keybindings
debug: ky: parsing line: main_window.close_page=C-w #default: x
ERROR: key spec invalid: C-w #default: x
terminate called after throwing an instance of 'Astroid::keyspec_error'
what(): invalid length of spec
[1] 28208 abort (core dumped) astroid

—
Reply to this email directly or view it on GitHub
https://github.com/gauteh/astroid/issues/21#issuecomment-174179305.

[gauteh]

Gaute Hope writes on January 23, 2016 16:38:

Err, yeah. Should split on # too, move the comment to a new line untill we
get to fix it.

Should be fixed now in: c357871.

[gauteh]

There is a new get_keys.py script which gathers all the keybindings and
creates a template. Printing keys to debug output is now gone. We might
consider adding a keybindings files to examples/ dir, but we'd have to
keep it up-to-date - and I haven't figured out how to do that without
running the script after every build.

The wiki has been updated.