From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Subversion of user chosen major mode by Emacs. [Was: My usage of imenu is broken.] Date: Wed, 29 May 2024 22:17:48 +0300 Message-ID: <86h6egsa03.fsf@gnu.org> References: <86r0dmtbk2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17642"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 29 21:18:40 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sCOop-0004Ns-U0 for ged-emacs-devel@m.gmane-mx.org; Wed, 29 May 2024 21:18:40 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sCOo6-0001Hy-BK; Wed, 29 May 2024 15:17:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sCOo3-0001HZ-Sh for emacs-devel@gnu.org; Wed, 29 May 2024 15:17:52 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sCOo2-0001CD-KB; Wed, 29 May 2024 15:17:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Xrzyt66c375gZkiuok8CcQWMzpVrNmZQA77eRSvQtzc=; b=on9JxkYeLDWwhHrH6Rvh HIG/KmdOl+CLjBaTjftyRZITGxIY0WfoEAfajXfs0kkPSIbYnwI54c46aMCb7WHc7SztvLo/yy009 Wz4m/R+6PKMUPKmvjveHsc9Kte7zG5F6ZmDghqzXPbQrfcWdYiLPWBRXNme7RaVBMFYZ+cbH6qHhi FeRPWllT71QEFCjeEnZJ4nB1mIU6zlMrUFX1D3Q8wuVYWOeog4DOIjAH3faMSHAiYohsX7HdNzisS +GadSmz69K+j0Mk0Gjx7Uc6t9rK+d4yIR+W1qu2aGrVzj4Cx+d0obYeg+WGP3nRdIv+uhiY0qh+3w uwtUfnY5e306+g==; In-Reply-To: (message from Alan Mackenzie on Wed, 29 May 2024 11:16:44 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:319704 Archived-At: > Date: Wed, 29 May 2024 11:16:44 +0000 > Cc: Eli Zaretskii , emacs-devel@gnu.org > From: Alan Mackenzie > > > In the past, `auto-mode-alist` way used for that, but that did not > > account for cases where the major mode is not specified via the file > > name, but instead via `-*- mode -*-`, or via `interpreter-mode-alist`, > > or via ... > > That's a case of going for 100% perfection at the expense of the normal > case. People don't put -*- c-mode -*- into files. Not as a general > rule. > > c-mode and c++-mode are registered trade marks of CC Mode, much as Emacs > means GNU Emacs, not any other editor with similar functionality. If > somebody has specified -*- c-mode -*-, then they mean CC Mode. Actually, this may or may not be true. There are cases where people put "-*- c++ -*-" etc. in files, but any mode supporting C++ will do. As one example, consider the libstdc++ headers such as 'algorithm' and others that have no file-name extension: it is clear that the mode cookie there does not necessarily mean these files should only be edited with c++-mode. As another example, consider the *.h files that are part of GDB sources: not every header file there will be identified by Emacs as C++ just by looking at the contents, so the GDB developers want to make sure Emacs turns on some C++ supporting mode when editing these files. As yet another example, consider our .dir-locals.el files: the mode-specific settings there don't care whether the user uses c-mode or c-ts-mode to edit our C sources. And there can be other examples. So sometimes the major mode symbol does in fact stand for the type of content and not for the specific mode it names. And Emacs should support these use cases, because users are rightfully annoyed when they need to duplicate the same boring settings. > or Emacs should provide something like -*- c-generic-mode -*-. That'd be swell, and we do provide these in some cases. But doing so is only possible if the maintainers of the related modes agree to cooperate to bring their modes closer. And you at the time were not very enthusiastic, to say the least, about any such involvement. So here we are. > > Also it encouraged `c-ts-mode.el` (and friends) duplicating > > the regexps used to specify "this is probably a C file", often doing it > > slightly differently from the other major mode. > > Surely a trivial problem, if a problem at all. Actually, our experience since introduction of the *-ts-modes indicates it is not a trivial problem at all. To wit: we don't yet have a good solution for it, and several naïve attempts proved to cause problems we needed to fix. It is surprising how a typical mode's simplest definitions are tightly coupled with the implementation of the basic features we need for major modes: font-lock, indentation, syntax analysis, etc. It turns out our abstractions in that department leak like hell. > > Instead, conceptually `auto-mode-alist` should now be used to specify > > the type of content (tho represented not as something like a MIME type > > but as a symbol that (usually) denotes a major mode), and then > > `major-mode-remap` is used to decide which major mode to use for that > > file type. > > Oh deity, no! auto-mode-alist specifies the MODE, not some abstract > "content type". See above: not necessarily true, at least not in all cases. And note that mode symbols are used not only in auto-mode-alist. A very frequent use is as an argument to the likes of derived-mode-p.