From: "João Távora" <joaotavora@gmail.com>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: 68246@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>,
casouri@gmail.com, Stefan Kangas <stefankangas@gmail.com>,
monnier@iro.umontreal.ca
Subject: bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes
Date: Tue, 16 Jan 2024 11:06:25 +0000 [thread overview]
Message-ID: <CALDnm51w6iay+eOgNdcM=b-e1qba6VCpROaQ=U4Zf4oOGRtggA@mail.gmail.com> (raw)
In-Reply-To: <d87d6c8c-3d2a-42fa-ac4e-0e2282d44423@gutov.dev>
On Tue, Jan 16, 2024 at 2:09 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
> > We could define them all in batch in a macro, that's not too bad. And
> > then let the existing fleshed out ones overwrite those definitions by
> > making sure to load them later.
>
> A keyword for define-derived-mode like (:base t)? That would work.
I think that would just clash with the existing PARENT one (when would
one of those bases _not_ be the parent). For base modes, I think
the current approach is mostly fine. There's something we can do
for the existing ones (and future ones) though, which is to explicitly
mark them abstract somehow.
> > The main advantages of the foo-base-mode approach is that:
> >
> > * it is easily grokkable by everybody, as it is very simply based on
> > simple inheritance, which everybody knows already.
> >
> > * there's already a fair number of such modes in the tree.
>
> Agree.
>
> I guess the part I don't quite like is adding a lot more new -base-
> modes (we'll have to add one for every prog mode, at least), most of
> which would stay unused, but unlike hook variables, clutter the function
> namespace.
Agree. And this is why I'm not crazy about the solution either. But as
to cluttering the function namespace we could say that (:abstract t) modes
do _not_ generate a function (or do not generate them in the public
namespace -- as I think the function still has to exist for any
concrete submodes down the line to call it).
> > But I do like your patch better, it seems pretty useful to introduce the
> > language concept, as it solves this and more problems more cleanly. So
> > let's see where that goes.
>
> Great.
>
> >> This choice is coupled with the corresponding logic in 'buffer-language'
> >> (whether to keep the replace-regexp-in-string branch).
> >
> > Yes. I think we should err on the side on convenience. What exactly are
> > the defects can we get? I can't see anything else but the tuareg-mode, and we
> > can plug that on our side. Maybe you can see more.
>
> For example, it would sometimes return ugly non-existent languages like
> :help-fns--edit-value, :org-lint--report or :xref--xref-buffer.
What if we filter by prog-mode? It would leave the ':ruby-base' and
':python-base' as false positives, I guess. But then we could reasonably
say that anything ending with '-base' is abstract (or use the
aforementioned explicit abstract prop).
It would also make ':lisp-data' a language. But that's not bad.
lisp-data-mode is actually a useful concrete prog-mode derivative,
so I think it's OK to have ':lisp-data' as a language.
We can then have exceptions for some notable cases. 'lisp-mode' is
as we know, for Common Lisp only.
> In most cases that would be harmless, but OTOH the callers would miss
> out on the opportunity to see that the language is nil and apply their
> own fallbacks right away. I don't have a real problem scenario in mind,
> though.
Neither do I, but I agree we should be as accurate as possible.
> Perhaps some commands that would act on the language of the current
> buffer might want to say "no language is associated", but could not with
> the "convenience" approach.
For sure.
> >> Are there specific uses for get-mode-for-language when there is no
> >> existing buffer?
> >
> > Yes, I'd say this markdown-mode use is exactly that. Markdown inserts
> > some text into a buffer and all it knows is the language it's supposed
> > to fontify it with. The major mode has that logic, so it must invoke
> > the correct (and preferred) major-mode function.
>
> Sorry, I meant get-language-for-mode (which is the one implemented as
> buffer-language currently).
>
> > Another use is allowing the user to choose major modes for languages,
> > say from a tutorial or wizard or at Emacs startup. Say, I prefer
> > ruby-ts-mode for Ruby, but c++-mode for C++. It'd be helpful to summarize
> > those preferences.
>
> This would require capabilities like "get all modes for a language" (not
> one of the set of functions mentioned so far, and it'll need a full scan
> of major-mode-remap-alist) and "get current mode for a language" (this
> one matches markdown-mode's function you posted).
Yes. I don't see the full scan of m-m-remap-alist as problematic
from a effiency perspective. If we decide it's the database, it's
the database. It's unfortunate that the "alist" implementation is
hardcoded in the name (which is why I would prefer a (:language "Foo")
kwarg to define-derived-mode) but we can abstract the alist aspect
away with accessors and do the usual "Do not change this variable
directly, use these accessors instead".
> BTW, get-current-mode-for-language could be implemented in terms of
> set-buffer-language.
What does get-current-mode-for-language do exactly?
> >> We could have both functions: buffer-language and get-language-for-mode
> >> ('get-mode-language'?). Or define one initially and add the other as needed.
> >
> > Yes. buffer-language isn't bad, it's a useful helper. But buffer-language
> > should be just
> >
> > (with-current-buffer buffer (get-language-for-mode major-mode))
> >
> > Right? Modulo some caching if it turns out to be very inneficient
> > (which I really doubt)
>
> Again: this won't work for files where no suitable major mode is
> available (e.g. not installed yet).
Right. So maybe
(or (with-current-buffer buffer (get-language-for-mode major-mode))
(let (kw)
(and buffer-file-name
(keywordp (setq kw (alist-get buffer-file-name auto-mode-alist)))
kw))
(consult-oracles)
(error "Don't know what language this is, sorry"))
?
next prev parent reply other threads:[~2024-01-16 11:06 UTC|newest]
Thread overview: 146+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-04 22:11 bug#68246: 30.0.50; Add non-TS mode as extra parent of TS modes Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 23:02 ` João Távora
2024-01-04 23:05 ` Dmitry Gutov
2024-01-04 23:41 ` João Távora
2024-01-04 23:18 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-04 23:48 ` João Távora
2024-01-04 23:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 0:35 ` João Távora
2024-01-05 0:43 ` Yuan Fu
2024-01-05 7:51 ` Eli Zaretskii
2024-01-05 11:27 ` João Távora
2024-01-05 13:26 ` Eli Zaretskii
2024-01-05 15:16 ` João Távora
2024-01-05 15:34 ` Eli Zaretskii
2024-01-05 18:02 ` João Távora
2024-01-05 18:56 ` Eli Zaretskii
2024-01-05 23:20 ` João Távora
2024-01-05 23:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 0:16 ` João Távora
2024-01-06 4:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 14:36 ` João Távora
2024-01-06 15:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-06 22:22 ` João Távora
2024-01-07 6:55 ` Eli Zaretskii
2024-01-08 0:12 ` João Távora
2024-01-08 3:34 ` Eli Zaretskii
2024-01-08 10:50 ` João Távora
2024-01-08 13:13 ` Eli Zaretskii
2024-01-08 14:45 ` João Távora
2024-01-08 17:15 ` Eli Zaretskii
2024-01-14 2:19 ` Yuan Fu
2024-01-14 3:10 ` João Távora
2024-01-14 4:00 ` Yuan Fu
2024-01-14 7:02 ` Eli Zaretskii
2024-01-14 23:40 ` João Távora
2024-01-15 12:38 ` Eli Zaretskii
2024-01-15 14:45 ` João Távora
2024-01-15 15:00 ` Eli Zaretskii
2024-01-15 15:09 ` João Távora
2024-01-15 2:10 ` Dmitry Gutov
2024-01-15 12:46 ` Eli Zaretskii
2024-01-15 18:32 ` Dmitry Gutov
2024-01-15 18:52 ` Eli Zaretskii
2024-01-15 20:17 ` Dmitry Gutov
2024-01-15 20:27 ` Eli Zaretskii
2024-01-15 15:27 ` João Távora
2024-01-15 20:51 ` Dmitry Gutov
2024-01-15 23:11 ` João Távora
2024-01-16 2:09 ` Dmitry Gutov
2024-01-16 11:06 ` João Távora [this message]
2024-01-17 2:41 ` Dmitry Gutov
2024-01-17 10:20 ` João Távora
2024-01-18 0:47 ` Dmitry Gutov
2024-01-17 17:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-18 5:05 ` Dmitry Gutov
2024-01-18 14:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-18 19:55 ` Dmitry Gutov
2024-01-18 21:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 1:28 ` Dmitry Gutov
2024-01-19 12:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 12:53 ` João Távora
2024-01-19 13:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 14:01 ` João Távora
2024-01-19 18:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-19 22:47 ` João Távora
2024-01-20 7:03 ` Eli Zaretskii
2024-01-20 10:16 ` João Távora
2024-01-21 0:32 ` Yuan Fu
2024-01-21 9:54 ` Eli Zaretskii
2024-01-24 6:20 ` Yuan Fu
[not found] ` <jwvfrxt5e75.fsf-monnier+emacs@gnu.org>
[not found] ` <86v86ovp6j.fsf@gnu.org>
2024-03-09 15:39 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-20 5:43 ` Dmitry Gutov
2024-01-14 6:33 ` Eli Zaretskii
2024-01-14 23:18 ` João Távora
2024-01-15 12:35 ` Eli Zaretskii
2024-01-15 14:49 ` João Távora
2024-01-08 4:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-08 11:11 ` João Távora
2024-01-08 12:45 ` Eli Zaretskii
2024-01-08 18:57 ` Dmitry Gutov
2024-01-08 19:55 ` Eli Zaretskii
2024-01-08 20:06 ` Dmitry Gutov
2024-01-08 22:12 ` João Távora
2024-01-09 3:28 ` Eli Zaretskii
2024-01-08 19:18 ` Stefan Kangas
2024-01-08 19:57 ` Eli Zaretskii
2024-01-08 20:05 ` Dmitry Gutov
2024-01-09 3:27 ` Eli Zaretskii
2024-01-16 2:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-16 23:29 ` João Távora
2024-01-17 0:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-17 0:49 ` João Távora
2024-01-17 3:45 ` Dmitry Gutov
2024-01-19 5:12 ` Yuan Fu
2024-01-20 5:47 ` Dmitry Gutov
2024-01-20 7:46 ` Eli Zaretskii
2024-01-21 0:32 ` Dmitry Gutov
2024-01-08 19:04 ` Dmitry Gutov
2024-01-09 0:10 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 0:39 ` João Távora
2024-01-09 0:52 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 1:05 ` João Távora
2024-01-09 1:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 1:11 ` João Távora
2024-01-09 3:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 10:52 ` João Távora
2024-01-10 1:18 ` Dmitry Gutov
2024-01-10 16:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-11 3:41 ` Dmitry Gutov
2024-01-09 4:49 ` Stefan Kangas
2024-01-09 7:24 ` Kévin Le Gouguec
2024-01-09 1:09 ` Dmitry Gutov
2024-01-09 1:31 ` João Távora
2024-01-09 3:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09 11:05 ` João Távora
2024-01-10 1:15 ` Dmitry Gutov
2024-01-10 1:59 ` João Távora
2024-01-10 16:04 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-10 17:02 ` Dmitry Gutov
2024-01-10 17:31 ` João Távora
2024-01-10 1:41 ` Dmitry Gutov
2024-01-10 6:24 ` Stefan Kangas
2024-01-10 15:51 ` João Távora
2024-01-11 3:49 ` Dmitry Gutov
2024-01-16 2:35 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-16 10:34 ` João Távora
2024-01-16 17:45 ` Dmitry Gutov
2024-01-16 22:00 ` João Távora
2024-01-17 2:05 ` Dmitry Gutov
2024-01-17 10:31 ` João Távora
2024-01-17 23:37 ` Dmitry Gutov
2024-01-06 8:12 ` Eli Zaretskii
2024-01-06 8:07 ` Eli Zaretskii
2024-01-06 13:52 ` João Távora
2024-01-05 19:03 ` Stefan Kangas
2024-01-05 23:37 ` João Távora
2024-01-06 8:09 ` Eli Zaretskii
2024-01-06 3:19 ` Yuan Fu
2024-01-06 3:36 ` Dmitry Gutov
2024-01-06 4:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-07 6:59 ` Yuan Fu
2024-01-06 14:54 ` João Távora
2024-01-08 18:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-05 7:40 ` Eli Zaretskii
2024-01-05 18:43 ` Stefan Kangas
2024-01-05 19:11 ` Stefan Kangas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALDnm51w6iay+eOgNdcM=b-e1qba6VCpROaQ=U4Zf4oOGRtggA@mail.gmail.com' \
--to=joaotavora@gmail.com \
--cc=68246@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=dmitry@gutov.dev \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).