emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Extending define-derived-mode


From: Eli Zaretskii
Subject: Re: Extending define-derived-mode
Date: Fri, 02 Jun 2023 14:51:17 +0300

> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 2 Jun 2023 00:45:31 -0700
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  emacs-devel@gnu.org,
>  mickey@masteringemacs.org,
>  theo@thornhill.no,
>  dgutov@yandex.ru
> 
> >> I don’t entirely understand the example. Say I have a xxx-base-mode, and I 
> >> want to setup menu-bar menus in it to be shared by xxx-mode and 
> >> xxx-ts-mode. What is the problem that I’m gonna run into? Couldn’t you 
> >> just use the base-mode’s keymap?
> > 
> > A base mode usually doesn't have a map, only the actually used derived
> > modes do.
> 
> We can create a map for the base mode, and the child mode’s map will inherit 
> from it.

We can, but it won't solve the basic problem.

This sub-thread comes from me explaining why this presents a problem
for, e.g., defining menu-bar items, remember?  So, if we examine the
issue in that context, you will see that creating a map for the base
mode has the following downsides:

 . It can only have bindings for the commands that are identical in
   all child modes, something that normally isn't the case.  For
   example "C-c C-q" is bound in both c-mode and c-ts-mode, but to
   different commands.
 . The menu items you can define in the base mode can therefore only
   reference commands bound in the base mode's map, which once again
   means only identical commands.  For example, compare the menu items
   in the "C/C++" menu-bar menu of c-ts-mode with those in the "C"
   menu of c-mode, and you will see what I mean.

This is why it makes sense to define the bindings and menus in the
child modes, not in the common base mode: in many cases the same key
sequences and menu items will be bound to different commands.

Likewise with buffer-local variables: in many cases they will have
different values for different modes, and sometimes even different
names, although their functions and effects could be very similar or
identical.

Bottom line: based on our experience to this point, it sounds like at
least in some cases the differences between the non-TS mode and TS
mode supporting the same language is significant enough to make the
idea of inheriting from a common base mode problematic if not
impractical.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]