Closed fiddlerwoaroof closed 6 years ago
I have considered it. I worry about conflicts. I know there are editors out there that actually care about the file-local value of Package
-- whatever Edi Weitz uses -- but I think they use uppercase to avoid conflict with Emacs.
Are you suggesting mode:
or package:
to designate the language?
I was thinking of using mode:
On Sep 16, 2018, 1:09 PM -0700, Paul M. Rodriguez notifications@github.com, wrote:
I have considered it. I worry about conflicts. I know there are editors out there that actually care about the file-local value of Package -- whatever Edi Weitz uses -- but I think they use uppercase to avoid conflict with Emacs. Are you suggesting mode: or package: to designate the language? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread. !DSPAM:5b9eb860190831573652274!
That way, if I have an emacs mode for my language, I’ll get the right emacs editing experience. This would make emacs work a bit like DrRacket does.
So if you have a mode line like
;; -*- mode: my-language-mode; package: foo.bar -*-
It would be equivalent to
#lang my-language
It sounds reasonable. I actually wrote a file local variable parser a while ago for something else. I'll poke around and see if I still have the code.
I’ve committed a parser for file locals (it’s not complicated, but there are some corner cases if you want to be compatible with Emacs). But I haven’t decided yet what the precedence of the mode should be, relative to other ways of designating a language, and whether it should be used as-is or there should be a translation mechanism (so that e.g. sql-mode would be handled by cl-yesql).
Would it be possible to support the hello-emacs lines as an alternative way to specify the language used to interpret the file? e.g.
;; -*- mode: my-language; package: foo.bar -*-
Since a lot of Common Lisp development occurs in emacs anyways, this would allow for a more integrated development experience.