Re: Re: Re: jed limits

[Guenter Milde <G.Milde@xxxxxxxxxxxxxxxxxxxx>]

On Tue, 12 Mar 2002 11:23:44 -0500 wrote "John E. Davis" <davis@xxxxxxxxxxxxx>:

> Guenter Milde <G.Milde@xxxxxxxxxxxxxxxxxxxx> wrote:
> >Thanks for your fast reply. I will not use 30 modes, but maybe 25 keymaps:
> 
> Perhaps I will remove the arbitrary limit on the number of keymaps
> from slang v2, but it will not happen until then because v1 must
> remain binary compatible.  I think an alternative solution requiring
> one additional keymap could be used as explained below.
> 
> [...]
> >Given the orthogonality of the modes, the keymaps are orthogonal as well,
> e.g.
> >
> >        global    global_mark      global_search     global_ishell  ...
> >        slang          slang_mark       slang_search      slang_ishell   ...
> >        python          python_mark      python_search     python_ishell  ...
> >        ...          ...                   ...                     ...
> >        
> >This way, with 8 modes and 4 features, I can quite easily reach the limit
> >(also, if e.g. search might be mode-independent)
> 
> In this scheme, wouldn't each buffer conceivably have a different
> minor-mode keymap?  For example, buffer a.sl would be using
> slang_search and b.sl would be using slang_mark.

Normally, a.sl and b.sl use "slang". 

When defining a region with Shift-Arrow keys in a.sl, it will use
"slang_mark", when I finished defining the region, it will use "slang"
again -> simple.

When, however during the definition of a region in a.sl I switch to b.sl,
and there start a isearch, buffer a.sl would be using "slang_mark" and b.sl
would be using "slang_search".
 
> In practice, how would keys be assigned to functions in these
> minor-mode keymaps given the various editor emulations?  For example,
> the _Reserved_Key_Prefix variable had to be introduced to allow the
> various emulation modes to use the various major-modes (e.g.,
> latex_mode).

The minor-mode-map is created by copying a language-mode-map, thus inheriting
the bindings from both, emulation and language mode. 

New bindings will either

 use rebind(old_fun, new_fun) to bind keys that are currently on old_fun to
 new_fun, (e.g. "self_insert_cmd" -> 
 "delete_region; pop_keymap; self_insert_cmd" in *_cuamark)
 
 bindings customizable with custom_variable (e.g. ISearch_Abort_key) or
 
 hardcoded bindings (e.g. Shift_Arrow keys in cuamark, as cuamark is in itself
 a kind of emulation-mode).


> Given the fact that only one keymap is active at a given time, perhaps
> only one additional keymap is necessary.  Let's call this spare keymap
> minor_mode_map.  To make use of it, you would create a stack or list
> of minor modes for each buffer as you would have to do anyway for
> push/pop_keymap functions.  Then push_keymap would save the name of
> the current keymap to the list and "create" another keymap by
> overwriting minor_mode_map with the desired key-definitions.  You
> would have to do this anyway with your scheme.  

However, I can no longer use copy_keymap, which would make the task
hard and lengthy. 

> As a concrete example, suppose a buffer uses the slang keymap.  Then
> the "pushes" to slang_mark and then to slang_search.   Then to pop
> back to slang_mark, the pop_keymap function would switch to the
> slang keymap and then "push" to the slang_mark keymap.
> 
> Now what about switching buffers or windows?  This is easy using 
> _jed_switch_active_buffer_hooks, which would "push" to the correct
> minor-mode map if necessary.

There is still a problem: consider switching from
a.sl to b.html when a is in search and b in a mark mode would mean:

  overwrite all bindings in minor_mode_map (slang+search) with the bindings
  from html_map
  
  bind all keys special to the mark feature mode

and vice versa.

> I hope the idea behind this scheme is clear.  I do not think that it
> requires too much coding to implement.  In fact I think it requires
> about 4 functions, e.g.,
> 
>      create_minor_mode_keymap
>         creates minor_mode_map if necessary and then copies the desired
>         keybindings to it.
> 
>      push_keymap
>         Saves the current keymap identifier to a list and calls
>         create_minor_mode_keymap.
>         
>      pop_keymap
>         Loops through the keymap list calling push_keymap.
>         
>      minor_mode_switch_active_buffer_hook
>         Calls a combination of the above functions to get to the
>         desired keymap.
>      
> I know that this solution may not be as elegant or simple as yours but
> it does have the advantage of requiring one additional keymap and will
> allow it to work with the current limitation on the number of keymaps.
> I also think it will be fast and will certainly use less memory.

I thought about not using minor_mode_keymaps at all but doing just
local_setkey()s while keeping track of the changes in a buffer-local
associative array. This still needs the unelegant workaround with
_jed_switch_active_buffer_hooks as well to ensure the changes in a.sl will
not affect b.sl, say, but would reduce the overhead when switching from a.sl
to c.html.

OTOH, I would like the elegant solution (of course). If there were a 
delete_keymap(map) function or if copy_keymap could overwrite an
existing keymap, the limit of 30 keymaps were no problem. 
(Feature Request :-)

Or I could try to stay below the limit by making mark_map and search_map
just copies of the Global map. (For marking or searching, mode-specific
functions might not be needed) The remaining ishell feature-mode
still needs *_ishell_maps to retain its main advantage of "edit a buffer
while an interactive program is attached" ("workbook-behaviour") but this
would just lower the limit to still acceptable 30/2 (or more, as
some keymaps will never be used with ishell-mode).

Guenter

--
G.Milde@xxxxxxxxxxxxxxxxxxxx


--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.