Dear org-mode-maintainers,
first I want to thank you for your awesome work on that awesome mode. Today I
want to come to you with an proposal that you may like and may only require a
(comparatively) small code-change. Let me first start with two observations
around the same issue: When I deal with org-mode documents that contain
code-blocks I note that it does not map language-identifiers to major-modes as
I would expect.
1. Let’s define a code-block like `src_rust[]{fn hello(){println!("Hello
World!")}}` in an emacs-instance with default-configs. It does not recognize
that mode because per default emacs ships with rust-ts-mode. The
documentation<https://orgmode.org/org.html#index-org_002dsrc_002dlang_002dmodes>
says “If an Emacs major-mode named <LANG>-mode exists, where <LANG> is the
language identifier from code block’s header line, then the edit buffer uses
that major mode. Use this variable to arbitrarily map language identifiers to
major modes.“ So I propose that org considers as well `<LANG>-ts-mode ` in
addition to `<LANG>-mode `.
2. There is the variable `major-mode-remap-alist` that let’s the user
control which major-modes get mapped to which others. (As far as I understand,
this variable has been introduced for that very purpose to deal with those
`-ts-mode`s.) However, the example from the first observation even fails if
that alist contains `(rust-mode . rust-ts-mode)` as an entry.
Of course, the documentation mentions a workaround with `org-src-lang-modes`
that could serve as an alternative to that `major-mode-remap-alist` but it
nevertheless feels a bit strange to me that org-mode ignores how user want to
select their major-modes as defined e.g. in `major-mode-remap-alist`. So, I
would propose to respect that as well – unless of course there is a dedicated
entry in `org-src-lang-modes` which should have the topmost priority if
existing.
Again thank you for your awesome work and kind regards!
Jörg
