Re: Re: self_insert_cmd + TAB problem

[Guenter Milde <G.Milde@xxxxxxxxxxxxxxxxxxxx>]

On Mon, 18 Mar 2002 14:02:16 -0500 wrote "John E. Davis" <davis@xxxxxxxxxxxxx>:

> Guenter Milde <G.Milde@xxxxxxxxxxxxxxxxxxxx> wrote:
> > Besides the possibility of a new "tab" buffer-hook, there is a chance 
> > to use
> 
> It is not clear to me that this will solve the problem because modes
> will define a tab hook to do something other than inserting a tab.
> Instead, with a couple of lines of code added to site.sl, I created a
> new variable called Tab_Always_Inserts_Tab that the user can set.
> I belive that this solves the problem in a simple and clean way.

How would mode_cmd solve the problem:

The default binding of the TAB key (set in the emulation mode) would be
   setkey("TAB_cmd", "^I");
   
TAB_cmd will call a moded dependend TAB_hook:
   define TAB_cmd()
   {
        run_cmd_hook("TAB_hook");
   } 
   
and the language-modes define this hook, e.g.

   define slang_TAB_hook() {insert_region_or_line();}
or
   define text_TAB_hook() {text_indent_relative;}

there is also provision for a default, e.g.
   define default_TAB_hook() {insert("\t");}

Now, if a user decides not to use an "intelligent" TAB key but have it
insert "\t" all the time, he/she will simply do what is normal for all keys:

   setkey("self_insert_cmd", "^I");

and this will work for all modes.


IMHO, this has some major advantages:

1. Consistency: The new user can use the common action for key (re)bindings.
   (and will not be puzzled by some "hidden actions" of the modes) 
   
   -> No need to learn about a global_mode_hook or a special customization
   variable.

2. Extensibility: The scheme is extensible to more actions

   E.g.:
   I use it to bind Alt-Return to an "execute_cmd"
   which evaluates the buffer or region by calling
   MODENAME_execute_hook together with
      define python_execute_hook(){py_exec();}
      define slang_execute_hook (){evalbuffer ();}
      define slangcalc_execute_hook(){calc_make_calculation();}
      define latex_execute_hook(){latex_compose (0);}


   Another example would be markup, where a command "bold_cmd" or
   "italic_cmd" would call the apropriate functions in html or latex 
   modes.
   
3. Less keybinding clashes as the language modes don't need to bind keys to
   actions that have a MODENAME_*_hook. Keybinding is done by the emulation
   modes.
   
4. Subsidiarity:

   Once a mode_cmd is defined, language mode authors can make use of it
   without interference to existing code.
   
   E.g.: Guidos function_help (help_for_word_at_point in my naming scheme)
   uses a case statement to define different actions for slang and c modes.
   If a new mode (say python) comes up with help function as well, one needs
   to modify help.sl to get the new function incorporated. My implemenation
   "decentralizes" the task:
   
   In my help.sl, the function help_for_word_at_point extracts the word at
   the editing point and calls help_for_word_cmd, which itself calls the
   MODENAME_help_for_word_hook with the word as argument:

   define help_for_word_at_point ()
   {
      variable word_at_point = bget_word(Slang_word);  %from bufutils.sl
      if (word_at_point == "")
        error("don't know what to give help for");
      help_for_word_cmd(word_at_point);
   }  
   
   Now the modes can define a hook to participate in the context help,
   e.g.
   
   define slang_help_for_word_hook(word){help_for_object (word);}
   define c_help_for_word_hook(word){unix_man ("3 " + word);}
   define python_help_for_word_hook(word){do_shell_cmd("pydoc " + word);}
   
   and the emulation binds it to a key
   
   setkey ("help_for_word_at_point", Key_Shift_F1);


(And all this with less lines of code than this letter has lines of
explanation.)
   
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>.