Xiki still stomping global keymap after removing default keys

[Donavan-Ross]

Hi,

Firstly, what an amazing piece of software!

....But after removing the default theme and keys I still have issues with commands being interpreted as prefix keys, e.g. C-e and C-d. I can't find the keys in the mode-map help which is usually how I deal with such issues.

Where are these keys bound? Do I need to install from source and edit before compiling?

Thanks!
Donavan

[Craig Muth]

> Firstly, what an amazing piece of software!

Thanks! :)

> ....But after removing the default theme and keys I still have issues with
> commands being interpreted as prefix keys

Do you mean removing these lines?

~/.el4r/init.rb
| KeyBindings.keys
| Themes.use "Default"

> e.g. C-e and C-d

Is it only C-e and C-d, or also C-a, C-o, C-t, C-l?

> . I can't find
> the keys in the mode-map help which is usually how I deal with such issues.

If they're mapped, they should be in it (global-map, I believe). It's
just delegating to the elisp (define-key) method behind the scenes
(via the el4r bridge)...

/projects/xiki/lib/xiki/keys.rb
| $el.define_key map, keys, &block

> Where are these keys bound?

Here's the execution tree. It means KeyBindings.keys calls .as_keys,
which calls .AA, which calls Keys.method_missing ... which ends up
calling (define-key) through the el4r bridge:

~/.el4r/init.rb
| KeyBindings.keys
/projects/xiki/lib/xiki/
- key_bindings.rb
| def self.keys
| def self.as_keys # C-a C-... keys
| Keys.AA { Line.to_left } # Set C-a C-a to normal emacs C-a
- keys.rb
| def self.method_missing
| self.define_key
| $el.define_key

> Do I need to install from source and edit before compiling?

There's no compiling involved, it's all interpreted. If you comment
out the KeyBindings.keys line and restart emacs it should stop mapping
them.

--Craig

[Donavan-Ross]

On Saturday, March 9, 2013 11:31:56 PM UTC+2, Craig wrote:

> Firstly, what an amazing piece of software!

Thanks! :)

> ....But after removing the default theme and keys I still have issues with
> commands being interpreted as prefix keys

Do you mean removing these lines?

~/.el4r/init.rb
  | KeyBindings.keys
  | Themes.use "Default"

Yes, replaced those lines with: Keys.set("M-.") { Launcher.launch_or_hide(:blink=>true) }
 

> e.g. C-e and C-d
 

Is it only C-e and C-d, or also C-a, C-o, C-t, C-l?

It's only C-e and C-d, the others work fine. And if I press, for example, C-e C-e I get 'is undefined'. 

> . I can't find
> the keys in the mode-map help which is usually how I deal with such issues.

If they're mapped, they should be in it (global-map, I believe).  It's
just delegating to the elisp (define-key) method behind the scenes
(via the el4r bridge)...

Yes you're right, my mistake, was looking at mode map not  key bindings.

/projects/xiki/lib/xiki/keys.rb
  |     $el.define_key map, keys, &block

> Where are these keys bound?

Here's the execution tree.  It means KeyBindings.keys calls .as_keys,
which calls .AA, which calls Keys.method_missing ... which ends up
calling (define-key) through the el4r bridge:

~/.el4r/init.rb
  | KeyBindings.keys
/projects/xiki/lib/xiki/
  - key_bindings.rb
    | def self.keys
      | def self.as_keys   # C-a C-... keys
        | Keys.AA { Line.to_left }   # Set C-a C-a to normal emacs C-a
  - keys.rb
    | def self.method_missing
      | self.define_key
        | $el.define_key

Ok awesome, I'll take a look at this in the morning. Fixing my emacs keybindings and getting to grips with xiki will be a nice Sunday project. :)

> Do I need to install from source and edit before compiling?

There's no compiling involved, it's all interpreted.  If you comment
out the KeyBindings.keys line and restart emacs it should stop mapping
them.

This is what you get for installing software after 12pm, I seem to have confused gems with binaries. 

--Craig

Thanks Craig

Cheers,
Donavan

[Donavan-Ross]

Hi Craig,

A quick question if I may, how do I tap into the Ruby error logs.

el4r is returning nil and raising a generic error. And that's about it I see in the only log I can find related to el4r. I looked in ruby folder too, in rvm, including the xiki folder.

2013-03-11 16:22:32 +0200:[DEBUG] (3) Waiting for Ruby expression
2013-03-11 16:22:32 +0200:[DEBUG] (3) Received Ruby expression: nil
2013-03-11 16:22:32 +0200:[DEBUG] (2) Sending callback interrupt.
2013-03-11 16:22:32 +0200:[DEBUG] (3) Sending Lisp expression: (buffer-file-name (el4r-lisp-object-from-id 339))
2013-03-11 16:22:32 +0200:[DEBUG] (3) Waiting for Ruby expression
2013-03-11 16:22:32 +0200:[DEBUG] (3) Received Ruby expression: nil
2013-03-11 16:22:32 +0200:[DEBUG] (2) Sending callback interrupt.
2013-03-11 16:22:32 +0200:[DEBUG] (3) Sending Lisp expression: (buffer-file-name (el4r-lisp-object-from-id 340))
2013-03-11 16:22:32 +0200:[DEBUG] (3) Waiting for Ruby expression

[Craig Muth]

Usually the ruby errors show up in /tmp/el4r-foo.XXXXX.log, which it
appears is where you pasted that output from.

Notice that el4r makes a new log with a different XXXXX number each
time it's reloaded, so be sure you're looking at the one in /tmp/ with
the newest update date. It's possible the error is in there and you
were looking at an older log.

The Option-e (or Meta-e) shortcut defined in Xiki opens the most
recent el4r log and jumps to the error.

--Craig

> --
> You received this message because you are subscribed to the Google Groups
> "Xiki" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to xiki+uns...@googlegroups.com.
> To post to this group, send email to xi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/xiki?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>