On Tue, Apr 14, 2020 at 12:29 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: João Távora <joaotavora@gmail.com>
> > Date: Tue, 14 Apr 2020 09:48:43 +0100
> > Cc: Juri Linkov <juri@linkov.net>, 40573@debbugs.gnu.org,
> >       Stefan Monnier <monnier@iro.umontreal.ca>, Dmitry Gutov <
> dgutov@yandex.ru>
> >
> > > How would you propose to identify these files for turning on this
> > > special mode?  They don't seem to have a clear-cut set of extensions
> > > and/or file names.
> >
> > One thing I don't understand is why is this important at all.
>
> It is only important if we want this new mode to be turned on
> automatically in such files.  If we want these files to be visited in
> Fundamental mode, or some other random mode due to their extensions,
> then this is indeed not important.  But then .dir-locals.el, for
> example, will be visited in emacs-lisp-mode, something I thought we
> wanted to prevent?
>

Yes, we do.  And it's trivial to add an entry for .dir-locals.el
to auto-mode-alist for that, as was suggested often. In hindsight
choosing .el for that file wasn't great, but it's not very bad either.

For files under our control, we have more options, including
mode cookies and doing nothing.

> Examples such as recentf, tramp, and ido files had already been given.
> > Again please don't base any implementation on those "details": they are
> > just an example.  The universe of lisp data files is much greater than
> > that.
>
> We must have some body of common traits of these files to program a
> mode that is suitable for them.
>

That's easy: lisp forms that can be `read`.

But it's even easier to find that "suitable mode" if you think
about the problem differently, as a "differences to
emacs-lisp-mode" problem. Let me explain.

Basically we just need to split emacs-lisp-mode in two.
I'd say flymake and imenu and xref and eldoc stay in
emacs-lisp-mode, all the rest stays in lisp-data-mode.
After the inheritance is setup,  emacs-lisp-mode is
unaffected, but lisp-data-mode can be used independently.

But if we don't get the "split point" right the first time, it's
very easy to move things across the border to get a better
lisp-data-mode _without_ adversely affecting emacs-lisp-mode
in any way.

Stefan's approach that I linked to is a good first approach
to that split point.  Again, we can adjust it afterwards.

João Távora