GNU bug report logs - #68246
30.0.50; Add non-TS mode as extra parent of TS modes

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 68246 <at> debbugs.gnu.org, casouri <at> gmail.com, monnier <at> iro.umontreal.ca, joaotavora <at> gmail.com
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 <at> iro.umontreal.ca, 68246 <at> debbugs.gnu.org, casouri <at> gmail.com,
>  joaotavora <at> gmail.com
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 08/01/2024 21:55, Eli Zaretskii wrote:
> >> Date: Mon, 8 Jan 2024 20:57:13 +0200
> >> Cc:68246 <at> debbugs.gnu.org,casouri <at> gmail.com,joaotavora <at> gmail.com
> >> From: Dmitry Gutov<dmitry <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.