bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes


From: Eli Zaretskii
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Tue, 09 Jan 2024 05:28:32 +0200

> Date: Mon, 8 Jan 2024 22:06:56 +0200
> Cc: monnier@iro.umontreal.ca, 68246@debbugs.gnu.org, casouri@gmail.com,
>  joaotavora@gmail.com
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 08/01/2024 21:55, Eli Zaretskii wrote:
> >> Date: Mon, 8 Jan 2024 20:57:13 +0200
> >> Cc:68246@debbugs.gnu.org,casouri@gmail.com,joaotavora@gmail.com
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> Even if we call non-file-visiting buffers' contents "languages", I don't
> >> think anyone will have a heart attack or something.
> > "No heart attack" is a poor criterion for good parameterization and
> > consistent terminology.  Confusing terms will spread confusion and
> > bugs.  There's no reason for us to settle for sub-optimal terminology.
> > 
> >> E.g., for example, we have message-mode, but if we wanted to support
> >> alternatives, we could call the base "email-message". Or for different
> >> major modes to edit VC commit messages, we could call the language
> >> "vc-log-message".
> > Those are not "languages", so let's not call them that.
> 
> I'm not married to the term (have there been alternatives suggested?), 
> but I do believe that having a notion distinct from "major modes" would 
> bring more clarity in this area.

If we can come up with some sane terminology, let's do that.  But
adopting incorrect one just because we need some name is not TRT.





reply via email to

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