jed-users mailing list

[2002 Date Index] [2002 Thread Index] [Other years]
[Thread Prev] [Thread Next]      [Date Prev] [Date Next]

Re: Re: jed limits


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

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

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.  The pop_keymap
function would be where most of the work would occur.  Instead of just
going directly back to the previous keymap, you would have to
reconstruct that keymap because it would nolonger exist.  The list of
keymaps attached to the buffer would be used to do this.

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.

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.

Let me know if you need more details.
Thanks,
--John

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


[2002 date index] [2002 thread index]
[Thread Prev] [Thread Next]      [Date Prev] [Date Next]