GNU bug report logs -
#77834
[PATCH] Improve help-fns-edit-variable for Lisp editing
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 26 Apr 2025 14:55:46 +0300
with message-id <8634dvuofx.fsf <at> gnu.org>
and subject line Re: bug#77834: [PATCH] Improve help-fns-edit-variable for Lisp editing
has caused the debbugs.gnu.org bug report #77834,
regarding [PATCH] Improve help-fns-edit-variable for Lisp editing
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
77834: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=77834
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
[Message part 3 (text/plain, inline)]
Tags: patch
Before d50c82f3e98e ("Simplify
'help-enable-variable-value-editing' using 'string-edit'"),
help-fns-edit-variable would open a buffer in emacs-lisp-mode
and would not allow exiting that buffer with an invalid Lisp
expression. Restore that functionality by enhancing string-edit
to allow choosing a major mode and allow passing a function to
validate the buffer contents before returning.
In GNU Emacs 30.1.50 (build 8, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.12, Xaw scroll bars) of 2025-04-10 built on
igm-qws-u22796a
Repository revision: 128bc06bfcc56a35d6b5555cc546faaf0d964df0
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)
Configured using:
'configure --config-cache --with-x-toolkit=lucid --without-gpm
--without-gconf --without-selinux --without-imagemagick --with-modules
--with-gif=no --with-cairo --with-rsvg --without-compress-install
--with-tree-sitter --with-native-compilation=aot'
[0001-Improve-help-fns-edit-variable-for-Lisp-editing.patch (text/patch, attachment)]
[Message part 5 (message/rfc822, inline)]
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 77834 <at> debbugs.gnu.org, larsi <at> gnus.org, philipk <at> posteo.net,
> azeng <at> janestreet.com
> Date: Wed, 16 Apr 2025 13:31:39 -0400
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Cc: 77834 <at> debbugs.gnu.org, larsi <at> gnus.org, philipk <at> posteo.net,
> >> azeng <at> janestreet.com
> >> Date: Wed, 16 Apr 2025 12:29:26 -0400
> >>
> >> >> -(defun read-string-from-buffer (prompt string)
> >> >> +(cl-defun read-string-from-buffer (prompt string
> >> >> + &key major-mode
> >> >> + read)
> >> >
> >> > I don't see any reasons to make this a cl-defun, just to add 2 more
> >> > optional arguments.
> >>
> >> It's to match the existing cl-defun for string-edit. string-edit takes
> >> keyword arguments - read-string-from-buffer probably should match it.
> >
> > But read-string-from-buffer is a public function, so any incompatible
> > changes in it should be avoided.
> >
> >> Alternatively, I could just not change read-string-from-buffer and only
> >> change string-edit. Then help-fns-edit-variable could call string-edit
> >> directly. That would duplicate a bit more code though.
> >
> > I think this will be better. string-edit is already a cl-defun, so we
> > just adding new optional arguments to it.
>
> OK, reverted the changes to read-string-from-buffer and switched
> help-fns-edit-variable to call string-edit directly.
>
> > But we also need a default for the :read argument if it is omitted.
>
> Good catch, done.
>
> >> >> "Switch to a new buffer to edit STRING in a recursive edit.
> >> >> -The user finishes editing with \\<string-edit-mode-map>\\[string-edit-done], or aborts with \\<string-edit-mode-map>\\[string-edit-abort]).
> >> >> +
> >> >> +When the user finishes editing with `string-edit-done', this function
> >> >
> >> > Why did you remove the keymap and command markup? That loses useful
> >> > features.
> >> >
> >> >> +If the user aborts with `string-edit-abort', this function signals an
> >> >> +error.
> >> >
> >> > Same here.
> >>
> >> I removed these because neither of these are user-facing functions; the
> >> docstrings are only read by Lisp hackers writing new packages using
> >> these functions. And it seems to me that for a Lisp programmer it's
> >> more useful to know the name of the commands which the user uses to
> >> finish editing, rather than the bindings for those commands.
> >
> > The original text shows both the command name and its binding.
> >
> >> But this is not an important change, if you prefer it to have the keymap
> >> markup instead.
> >
> > I'd prefer not to lose the information, indeed.
>
> OK, reverted.
>
> Also updated the docstrings to not use passive voice.
Thanks, now installed on the master branch, and closing the bug.
This bug report was last modified 25 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.