unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Kévin Le Gouguec" <kevin.legouguec@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: casouri@gmail.com,  luangruo@yahoo.com,  stefankangas@gmail.com,
	emacs-devel@gnu.org
Subject: Re: emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324)
Date: Tue, 24 Sep 2024 09:10:49 +0200	[thread overview]
Message-ID: <871q19zfuu.fsf@gmail.com> (raw)
In-Reply-To: <864j66fct2.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 23 Sep 2024 21:24:41 +0300")

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



  reply	other threads:[~2024-09-24  7:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <172663360099.23732.9998257239822693024@vcs2.savannah.gnu.org>
     [not found] ` <20240918042641.56C7BC410E2@vcs2.savannah.gnu.org>
2024-09-18  6:31   ` emacs-30 f0daa2f2153: Conservative heuristic for tree-sitter parser ranges (bug#73324) Po Lu
2024-09-20  4:53     ` Yuan Fu
2024-09-20  6:32       ` Eli Zaretskii
2024-09-20  6:44         ` Eli Zaretskii
2024-09-21  3:10           ` Yuan Fu
2024-09-22  0:59     ` Stefan Kangas
2024-09-22  5:18       ` Eli Zaretskii
2024-09-22  5:43       ` Po Lu
2024-09-22  6:44         ` Yuan Fu
2024-09-22 21:23           ` Kévin Le Gouguec
2024-09-23  8:27             ` Robert Pluim
2024-09-23 11:49             ` Eli Zaretskii
2024-09-23 17:24               ` Kévin Le Gouguec
2024-09-23 18:24                 ` Eli Zaretskii
2024-09-24  7:10                   ` Kévin Le Gouguec [this message]
2024-09-26  7:28                     ` Yuan Fu

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=871q19zfuu.fsf@gmail.com \
    --to=kevin.legouguec@gmail.com \
    --cc=casouri@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    --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).