>> 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
Description: PGP signature