[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser
From: |
Yuan Fu |
Subject: |
Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324) |
Date: |
Thu, 26 Sep 2024 00:28:39 -0700 |
> On Sep 24, 2024, at 12:10 AM, Kévin Le Gouguec <kevin.legouguec@gmail.com>
> wrote:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Kévin Le Gouguec <kevin.legouguec@gmail.com>
>>> Cc: casouri@gmail.com, luangruo@yahoo.com, stefankangas@gmail.com,
>>> emacs-devel@gnu.org
>>> Date: Mon, 23 Sep 2024 19:24:45 +0200
>>>
>>>> Isn't it a bug in magit that it doesn't do something like that
>>>> already? Fill column is just the tip of an iceberg, because a log
>>>> message is generally human-readable text, and so should benefit from
>>>> other features of Text mode and its descendants, like spell-checking
>>>> etc.
>>>
>>> It does try to do "something like that"; AFAIU the two main knobs are:
>>>
>>> * git-commit-major-mode lets users pick their preferred text-adjacent
>>> major mode (or it lets maintainers choose it, e.g. setting that variable
>>> in a checked-in .dir-locals.el; the default is text-mode),
>>>
>>> * git-commit-setup-hook lets users turn on useful log-editing features;
>>> the defcustom includes various opt-in functions. Robert mentioned
>>> magit-generate-changelog; there's also git-commit-turn-on-flyspell and
>>> bug-reference-mode.
>>>
>>> (There's also a mysterious git-commit-setup-changelog-support that
>>> checks for
>>>
>>> (fboundp 'log-indent-fill-entry) ; New in Emacs 27
>>>
>>> but I can't find any trace of log-indent-fill-entry in the tree so not
>>> sure what that's about)
>>
>> That sounds to me like a heap of patches when just having a full-blown
>> mode like VC does would have done the job cleanly and seamlessly.
>
> That's how it was 10 years ago: there was a single major mode,
> git-commit-mode, which "did it all" (setup emacsclient as git's EDITOR,
> setup font-lock, provide key bindings, etc). Then the decision was
> taken to move to configurable-major-mode-plus-hook.
>
> The commit log for that change¹ focuses on the technical details over
> the motivation, but looking at the current defcustom's selection of
> major modes, I guess the use-case is obvious - let people pick their
> preferred markup for authoring messages, and tuck all the "VC-specific
> extra features" under a dedicated minor mode & hook.
>
>>> So what's "missing" from Magit's git-commit.el is a knob dedicated to
>>> the fill-column for commit messages.
>>
>> I'm quite sure that soon enough someone will come with more "missing"
>> stuff. I still think they should use something very similar to
>> log-edit-mode there. It doesn't make much sense not to. E.g., the
>> .dir-locals settings would have been in effect for magit users as
>> well.
>
> Right. And in principle users should be able to opt-in to log-edit-mode
> (or vc-git-log-edit-mode?) by configuring git-commit-major-mode.
>
> I just don't expect that to be seamless - because (AFAIR; apologies for
> inaccuracies) log-edit-mode depends on callbacks set by vc-$BACKEND.el,
> which in turn depend on bookkeeping usually managed by vc.el commands;
> Magit steers mostly clear of that bookkeeping.
>
> tl;dr I don't disagree but I don't see log-edit-mode integration into
> Magit to be the path of least resistance.
>
> (That shouldn't stop anyone from trying though, or submit a feature
> request; this is all just my 2¢ as a {heavy Magit,occasional VC} user)
>
>
> ¹ 2014-03-18 "git-commit: allow use of arbitrary major mode" (feb58998)
>
> https://github.com/magit/magit/commit/feb58998fc128824728959695a9448e7752c2ca3.patch
I was hoping for some config that we can put in .dir-locals.el that works
automatically for magit. That should prevent a lot of future corrections on
fill column. That doesn’t seem trivial, so I guess I’ll just stick something
into my config and call it a day :-)
Yuan
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), (continued)
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Stefan Kangas, 2024/09/21
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Eli Zaretskii, 2024/09/22
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Po Lu, 2024/09/22
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Yuan Fu, 2024/09/22
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Kévin Le Gouguec, 2024/09/22
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Robert Pluim, 2024/09/23
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Eli Zaretskii, 2024/09/23
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Kévin Le Gouguec, 2024/09/23
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Eli Zaretskii, 2024/09/23
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324), Kévin Le Gouguec, 2024/09/24
- Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324),
Yuan Fu <=