On Tue, Apr 14, 2020 at 1:38 PM Eli Zaretskii wrote: > > > From: João Távora > > Date: Tue, 14 Apr 2020 12:48:55 +0100 > > Cc: Juri Linkov , 40573@debbugs.gnu.org, > > Stefan Monnier , Dmitry Gutov < dgutov@yandex.ru> > > > > 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. > > What I was getting at was that maybe there are other extensions that > we'd like to trigger this mode. Also, Emacs has means for > automatically turning modes on, other than the file-name extension and > the mode cookie. Maybe some of them could be used in this case. Do you mean magic-mode-alist? Do you think you'd be able to come up with something that won't yield a lot of false positives or a lot of false negatives? If so, don't let me stop you. But also don't let those ambitious stand in the way of the new mode: they're not a prerequisite. > > 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`. > > I meant traits that are relevant to what major modes do: > fontification, indentation, what is considered a defun, etc. Sure, and I meant it's easier to think of them as subtraction from the existing emacs-lisp-mode. Ask yourself the inverse question: what things _aren't_ relevant. The more things you can confidently subtract, the closer you are to something better than the current situation. You'll see it's much easier than the exercise you're trying to make. I'd subtract flymake, xref, eldoc and imenu, for starters. For font-lock I don't mind if for the time being we use the same font-lock keywords. Doesn't mean we can't tweak these things in the future, of course. But maybe you know of other low-hanging fruit that only makes sense for elisp code. Re. defun finding. In general, there are no things analogous to a defun in data files, there just aren't! Doesn't mean we can't, in the future, derive new modes from lisp-data-mode where such constructs make sense. But for now, I'd add it to "confidently subtract" list. João -- João Távora