>> The problem now is that removing support for 'elisp' would break too >> much. > > What I suggest for this particular issue is this: first be liberal > while staying consistent (thus allowing "elisp" as Troy suggest), > then be strict when a major release is issued (thus removing aliases > that are problematic, not just "elisp" but others.) > > WDYT? Troy, would you be able to prepare a patch for this?
My 2¢ from the peanut gallery.
Generally speaking, I’m in favor of consistency. A couple of months ago,
I stumbled over the fact that ‘elisp’ seemed to do syntax highlighting
correctly but didn’t tangle. I didn’t, at the time, work out the cause
of the problem, I just learned to use ‘emacs-lisp’ as the language name.
Looking at this thread, it seems like there are a bunch of exceptions to
the rule that the language is be the name of the mode without ‘-mode’.
Just off the top of my head, I can think of several languages supported
by multiple modes. If the rule is that the language is the mode name,
then if I use ‘extra-special-language-mode’ to edit ‘language’, do I
have to use ‘extra-special-language’ as the language name? Is that going
to seem natural? What burden does that put on the developer of
‘extra-special-language-mode’ to make tangle and other Org-mode features
work like they would for ‘language-mode’?
I wonder if it makes more sense to invent a mechanism for assigning
language synonyms that can be used throughout Org?
Be seeing you,
norm
P.S. Just to prove I can play devil’s advocate, I’m very conscious of
the fact that a few days ago, I invented an ‘xproc-mode’ as a vacuous
extension to ‘xml-mode’ precisely *because* I wanted to define different
org-babel-execute behavior.
--
Norman Tovey-Walsh <n...@nwalsh.com> | Some disguised deceits
https://nwalsh.com/ | counterfeit truth so perfectly
| that not to be taken in by them
| would be an error of
| judgment.--La Rochefoucauld
signature.asc
Description: PGP signature
