Keybinding configuration about astroid HOT 19 CLOSED

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

from astroid.

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

from astroid.

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.

from astroid.

from astroid.

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

from astroid.

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

from astroid.

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

from astroid.

How can I use the Tab key?

from astroid.

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.

from astroid.

Short answer: Not implemented yet for custom keybindings.

from astroid.

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

from astroid.

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.

from astroid.

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.

from astroid.

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

from astroid.

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

from astroid.

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

from astroid.

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 [email protected]
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.

from astroid.

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.

from astroid.

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.

from astroid.