Thread View: gmane.emacs.devel
6 messages
6 total messages
Started by JD Smith
Sat, 26 Aug 2023 12:47
On treesit preference for "consumer" modes
Author: JD Smith
Date: Sat, 26 Aug 2023 12:47
Date: Sat, 26 Aug 2023 12:47
48 lines
2243 bytes
2243 bytes
The current LANG-mode and LANG-ts-mode separation leaves some ambiguities. One in particular: some modes are “consumers” of other majors modes. That is, they have a different focus, but use LANG modes as subordinate helpers for some aspect of their feature set. Examples: org-mode SRC block highlighting, or a shell mode which wants to highlight and indent code written at the shell prompt. In the pre-treesit era, such a “consumer mode” simply reached for, e.g., LANG-mode for this, directly making use of all the customizations users have applied. In the new era of LANG-mode and LANG-ts-mode duality, how should the consumer mode decide which one to use? 1. Obviously you can check `(treesit-available-p)', but this tells you nothing about whether the user prefers and has configured treesit support in their LANG buffers. 2. You can be more specific with `(treesit-ready-p LANG)', but again that only says whether treesit with LANG is possible, not whether it is desired or configured. 3. You could check `major-mode-remap-alist' for a LANG entry, which does indicate affirmative user desire for treesit, but a) this is not required to configure LANG-ts-mode for use in LANG buffers, and b) it’s not clear this variable or its active usage will persist for the long term, in particular if LANG-mode is eventually deprecated in favor of LANG-ts-mode. 4. You could force the user to opt-in, with a custom setting like `some-consumer-mode-support-treesit', but that requires users to spot this option, and will quite reasonably confuse users who have already configured treesit support in their LANG buffers. Why should they have to repeat themselves like that? 5. You could combine #3 with checking `auto-mode-alist', but you’d have to interpret file extension regexes, which is likely error pone, and leaves out dir-local variables, etc. Is there some long-term durable, central setting or function which consumer modes can consult to determine whether to use LANG-mode or LANG-ts-mode? I guess I’m looking for something like `(treesit-preferred LANG)’ or `(default-major-mode LANG)’.
Re: On treesit preference for "consumer" modes
Author: JD Smith
Date: Sat, 26 Aug 2023 13:17
Date: Sat, 26 Aug 2023 13:17
96 lines
4714 bytes
4714 bytes
--Apple-Mail=_E547E704-B8D9-4FAE-AF28-68ED5F0B6680 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 26, 2023, at 1:04 PM, Eli Zaretskii <eliz@gnu.org> wrote: >> I guess I’m looking for something like `(treesit-preferred LANG)’ or `(default-major-mode LANG)’. > > There's no such thing, and probably won't be, at least not soon enough > for you to rely on it. We are still learning how to deal with this > new situation. Got it, thanks. There has always been some ambiguity when there are several modes competing, but usually there is a “dominant strain” consumer modes can adopt as the default. > As for your suggestions: treesit-preferred is problematic, because no > one says the user will always prefer ts modes for all of the > languages, nor do we want to force them. As for default-major-mode, I > don't understand how could we implement that, except by deferring to > user options again. This would be a top-level user option, but it would be “one stop shopping” for the user. I.e. they would not need to configure this and `major-mode-remap-alist’. One (likely too) simple idea: a function to ask emacs “What mode would you enable if I opened /path/to/file.EXT”, without actually having to open it. Consumer modes could check that for relevant paths and extensions, and opt to use that mode (if everything else checks out). > . if a ts mode is already loaded (featurep test) The consumer-mode may be the first to use it. > . if auto-mode-alist defines a ts mode for the relevant files I mentioned that in my #5. I suppose that’s a cousin of my (too) simple idea above, except for dir-locals etc. --Apple-Mail=_E547E704-B8D9-4FAE-AF28-68ED5F0B6680 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br><div><br><blockquote type="cite"><div>On Aug 26, 2023, at 1:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:</div></blockquote><blockquote type="cite"><div><div><blockquote type="cite">I guess I’m looking for something like `(treesit-preferred LANG)’ or `(default-major-mode LANG)’.<br></blockquote><br>There's no such thing, and probably won't be, at least not soon enough<br>for you to rely on it.  We are still learning how to deal with this<br>new situation.<br></div></div></blockquote><div><br></div><div>Got it, thanks.  There has always been some ambiguity when there are several modes competing, but usually there is a “dominant strain” consumer modes can adopt as the default.</div><br><blockquote type="cite"><div><div>As for your suggestions: treesit-preferred is problematic, because no<br>one says the user will always prefer ts modes for all of the<br>languages, nor do we want to force them.  As for default-major-mode, I<br>don't understand how could we implement that, except by deferring to<br>user options again.<br></div></div></blockquote></div><div><br></div><div>This would be a top-level user option, but it would be “one stop shopping” for the user.  I.e. they would not need to configure this and `<font color="#000000"><span style="caret-color: rgb(0, 0, 0);">major-mode-remap-alist’.</span></font></div><br><div>One (likely too) simple idea: a function to ask emacs “What mode would you enable if I opened /path/to/file.EXT”, without actually having to open it.  Consumer modes could check that for relevant paths and extensions, and opt to use that mode (if everything else checks out).</div><div><br></div><div><blockquote type="cite"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> . if a ts mode is already loaded (featurep test)</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"></blockquote><div><br></div><div>The consumer-mode may be the first to use it.</div><br><blockquote type="cite"><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"> . if auto-mode-alist defines a ts mode for the relevant files</span><br style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"></blockquote><br></div><div>I mentioned that in my #5. I suppose that’s a cousin of my (too) simple idea above, except for dir-locals etc. </div></body></html> --Apple-Mail=_E547E704-B8D9-4FAE-AF28-68ED5F0B6680--
Re: On treesit preference for "consumer" modes
Author: Eshel Yaron
Date: Sat, 26 Aug 2023 19:58
Date: Sat, 26 Aug 2023 19:58
37 lines
1621 bytes
1621 bytes
Hi, JD Smith <jdtsmith@gmail.com> writes: > ...some modes are “consumers” of other majors modes. That is, they > have a different focus, but use LANG modes as subordinate helpers for > some aspect of their feature set. Examples: org-mode SRC block > highlighting, or a shell mode which wants to highlight and indent code > written at the shell prompt. In the pre-treesit era, such a “consumer > mode” simply reached for, e.g., LANG-mode for this, directly making > use of all the customizations users have applied. I think the last sentence is a slight over simplification: even before `foo-ts-mode`s, Emacs didn't have a clean abstraction for a (programming language) AFAICT, only major modes. And "competing" major modes for the same language are not a new problem. So these "consumer modes" would have to be more clever and, hopefully, already have the right methods in place to deal with the existence of multiple major modes per language. (Admittedly, `foo-ts-mode`s make this challenge much more pronounced.) Looking at the specific examples you mentioned: Org mode handles this well with `org-src-lang-modes`, which is quite more sophisticated than just reaching out for `LANG-mode`. (BTW in `sweeprolog.el` there's a similar mechanism for highlighting quasi-quoted content that leverages similar user option `sweeprolog-qq-mode-alist`.) The shell input example is more interesting since currently, IIUC, `shell-mode` really is naive in the sense that it always uses `sh-mode` without having a user option for specifying e.g. `bash-ts-mode` instead. Best, Eshel
Re: On treesit preference for "consumer" modes
Author: Eli Zaretskii
Date: Sat, 26 Aug 2023 20:04
Date: Sat, 26 Aug 2023 20:04
21 lines
1374 bytes
1374 bytes
> From: JD Smith <jdtsmith@gmail.com> > Date: Sat, 26 Aug 2023 12:47:18 -0400 > > The current LANG-mode and LANG-ts-mode separation leaves some ambiguities. One in particular: some modes are “consumers” of other majors modes. That is, they have a different focus, but use LANG modes as subordinate helpers for some aspect of their feature set. Examples: org-mode SRC block highlighting, or a shell mode which wants to highlight and indent code written at the shell prompt. In the pre-treesit era, such a “consumer mode” simply reached for, e.g., LANG-mode for this, directly making use of all the customizations users have applied. > > In the new era of LANG-mode and LANG-ts-mode duality, how should the consumer mode decide which one to use? A user option, I think. There's no other reliable way ATM. > I guess I’m looking for something like `(treesit-preferred LANG)’ or `(default-major-mode LANG)’. There's no such thing, and probably won't be, at least not soon enough for you to rely on it. We are still learning how to deal with this new situation. As for your suggestions: treesit-preferred is problematic, because no one says the user will always prefer ts modes for all of the languages, nor do we want to force them. As for default-major-mode, I don't understand how could we implement that, except by deferring to user options again.
Re: On treesit preference for "consumer" modes
Author: Eli Zaretskii
Date: Sat, 26 Aug 2023 20:14
Date: Sat, 26 Aug 2023 20:14
20 lines
743 bytes
743 bytes
> Date: Sat, 26 Aug 2023 20:04:10 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: emacs-devel@gnu.org > > > From: JD Smith <jdtsmith@gmail.com> > > Date: Sat, 26 Aug 2023 12:47:18 -0400 > > > > In the new era of LANG-mode and LANG-ts-mode duality, how should the consumer mode decide which one to use? > > A user option, I think. There's no other reliable way ATM. You could also use telltale signs, if they exist: . if a ts mode is already loaded (featurep test) . if auto-mode-alist defines a ts mode for the relevant files But these cannot be relied upon 100%, because the user might prefer a ts mode, but has not yet loaded it or used it in this session. So a fallback is needed, and that can only be a user option, I think.
Re: On treesit preference for "consumer" modes
Author: Eli Zaretskii
Date: Sat, 26 Aug 2023 20:31
Date: Sat, 26 Aug 2023 20:31
10 lines
427 bytes
427 bytes
> From: JD Smith <jdtsmith@gmail.com> > Date: Sat, 26 Aug 2023 13:17:54 -0400 > Cc: emacs-devel@gnu.org > > One (likely too) simple idea: a function to ask emacs “What mode would you enable if I opened > /path/to/file.EXT”, without actually having to open it. Consumer modes could check that for relevant > paths and extensions, and opt to use that mode (if everything else checks out). See set-auto-mode--apply-alist.
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads