bug#33007: 27.0.50; Proposal for function to edit and return string

bug#33007: 27.0.50; Proposal for function to edit and return string

[Jean Louis]

I would like to propose function for GNU Emacs so that there is
function to edit and return the string.

It would be equivalent to read-from-minibuffer only that we shall have
function to edit in the whole buffer, not just in one line in mini
buffer.

Sadly I don't know how to make it.

Here are my two attempts:

(defun rcd-edit-value (value)
      (let ((file (make-temp-file "rcd-db-" nil ".txt" value)))
        (find-file file)
        (string-from-file)))

(defun string-from-file (file)
  "Return file content."
  (with-temp-buffer
    (insert-file-contents file)
    (buffer-string)))

(setq got-it (rcd-edit-value "something"))

but this one is not working as (find-file file) does not wait, and I get
"something" back from file.

This below is my other attempt which looks more logical and could end
with C-c C-c but I am failing to get the value given back.

(defun buffer-out ()
  (interactive)
  (let ((buffer (current-buffer))
	(value (buffer-string)))
    (kill-buffer buffer)))

;; (defun buffer-string-out ()
;;   (interactive)
;;   (buffer-string))

(defun edit-string (string)
  (interactive)
  (let ((buffer "*edit-string*"))
    (get-buffer-create buffer)
    (switch-to-buffer buffer)
    (set-buffer buffer)
    (let ((inhibit-read-only nil))
      (insert string)
      (fundamental-mode)
      (local-set-key (kbd "C-c C-c") 'buffer-out))))

In my opinion such function shall exist in Emacs by standard, so that
user is able to quickly edit string in a temporary buffer or temporary
file or both, and that value of the buffer is returned back.

Several people asked me why I would do that. Some variables requires
editing, and variables could be as big as Org file, and they could come
from a database.

Then I could edit field values from PostgreSQL database and construct
other small helpful programs.

Jean

bug#33007: 27.0.50; Proposal for function to edit and return string

[Eli Zaretskii]

> From: Jean Louis <bugs@gnu.support>
> Date: Wed, 10 Oct 2018 22:49:19 +0200
> 
> 
> I would like to propose function for GNU Emacs so that there is
> function to edit and return the string.
> 
> It would be equivalent to read-from-minibuffer only that we shall have
> function to edit in the whole buffer, not just in one line in mini
> buffer.

We already have read-string, I think it does what you want.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Jean Louis]

On Thu, Oct 11, 2018 at 05:36:59AM +0300, Eli Zaretskii wrote:
> > From: Jean Louis <bugs@gnu.support>
> > Date: Wed, 10 Oct 2018 22:49:19 +0200
> > 
> > 
> > I would like to propose function for GNU Emacs so that there is
> > function to edit and return the string.
> > 
> > It would be equivalent to read-from-minibuffer only that we shall have
> > function to edit in the whole buffer, not just in one line in mini
> > buffer.
> 
> We already have read-string, I think it does what you want.

It reads from mini buffer, it does not open
standard buffer where one could change modes and
have editing capabilities, preview, insert from
other files, etc.

I have found solution for me. And I think
something like that shall be included in emacs.

Why?

We have read-from-minibuffer.

Logically there shall be read-from-buffer too.

Isn't it?

I am using this one below now but it would be nice
to have it as fully fledged with options
etc. professional built-in function.

I have website revision system written in LISP
that invokes Emacs to edit PostgreSQL variables,
including LISP variables. Such contain markup,
notes, description, bodies of text that cannot fit
into read-string function and where I need to
preview the file, work with it, until it is
published. Some page are even in Org mode, so I
would need to see how they look like before I let
it be fed into the database again.

At the moment I tried doing the same from within
Emacs, I have spent hours trying to find something
like read-from-buffer as I was convinced it exists
there.

That is why I am proposing standardized function
to read-from-buffer with nice options as built in
function.

And I will appreciate any improvements to the
below function.

Jean

Something like this below shall become read-from-buffer

;;; edited from https://raw.githubusercontent.com/deestan/emacs/master/emacs-goodies-el/miniedit.el
(defun edit-string (value)
  "Edits string and returns it"
  (let ((this-buffer (buffer-name))
	(new-value value)
	(buffy "*edit-string*"))
    (save-excursion
      (switch-to-buffer buffy)
      (set-buffer buffy)
      (text-mode)
      (local-set-key (kbd "C-c C-c") 'exit-recursive-edit)
      (if (stringp value) (insert value))
      (message "When you're done editing press C-c C-c or C-M-c to continue.")
      (unwind-protect
	  (recursive-edit)
	(if (get-buffer-window buffy)
	    (progn
	      (setq new-value (buffer-substring (point-min) (point-max)))
	      (kill-buffer buffy))))
      (switch-to-buffer this-buffer)
      new-value)))

bug#33007: 27.0.50; Proposal for function to edit and return string

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> Something like this below shall become read-from-buffer [...]

I agree that such an interface would be useful for Emacs.  I think it
already has been reinvented multiple times in Emacs itself.  I invented
it myself.

Some minor thoughts: The input buffer should be more controllable: modes
and keymap shouldn't be fixed.  Also, it should be possible to prefill
the buffer with a string describing what the user is expected to do, and
which is ignored after the user has finished.


Michael.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Jean Louis]

On Thu, Oct 11, 2018 at 03:31:15PM +0200, Michael Heerdegen wrote:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Something like this below shall become read-from-buffer [...]
> 
> I agree that such an interface would be useful for Emacs.  I think it
> already has been reinvented multiple times in Emacs itself.  I invented
> it myself.
> 
> Some minor thoughts: The input buffer should be more controllable: modes
> and keymap shouldn't be fixed.  Also, it should be possible to prefill
> the buffer with a string describing what the user is expected to do, and
> which is ignored after the user has finished.

Yes, please. With some immutable string maybe like
instructions, as option.

Jean

bug#33007: 27.0.50; Proposal for function to edit and return string

[Eli Zaretskii]

> Date: Thu, 11 Oct 2018 08:33:21 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 33007@debbugs.gnu.org
> 
> > We already have read-string, I think it does what you want.
> 
> It reads from mini buffer, it does not open
> standard buffer where one could change modes and
> have editing capabilities, preview, insert from
> other files, etc.

The minibuffer is a normal buffer, so you should be able to use all
the facilities you mention, perhaps by allowing recursive minibuffers.

That said, I don't object to an extended facility like the one you
implemented.

Thanks.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> The minibuffer is a normal buffer, so you should be able to use all
> the facilities you mention, perhaps by allowing recursive minibuffers.

My use case is typically to be able to enter/edit multi line text.  The
minibuffer is not really good for that, since bindings interfere with
editing (RET, Space etc), and the height of the minibuffer is limited.


Michael.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Jean Louis]

On Thu, Oct 11, 2018 at 04:55:52PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 11 Oct 2018 08:33:21 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 33007@debbugs.gnu.org
> > 
> > > We already have read-string, I think it does what you want.
> > 
> > It reads from mini buffer, it does not open
> > standard buffer where one could change modes and
> > have editing capabilities, preview, insert from
> > other files, etc.
> 
> The minibuffer is a normal buffer, so you should be able to use all
> the facilities you mention, perhaps by allowing
> recursive minibuffers.

I don't know how to use minibuffer as normal
buffer. For example I cannot enter M-x commands,
as there is error command attempted to use
minibuffer while in minibuffer.

> That said, I don't object to an extended facility like the one you
> implemented.

That would be nice.

Jean

bug#33007: 27.0.50; Proposal for function to edit and return string

[Michael Heerdegen]

Jean Louis <bugs@gnu.support> writes:

> I don't know how to use minibuffer as normal
> buffer. For example I cannot enter M-x commands,
> as there is error command attempted to use
> minibuffer while in minibuffer.

Just enable recursive minibuffers.

But there are other problems, like accidentally hitting C-g or a history
command let's you lose your input.


Michael.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Eli Zaretskii <eliz@gnu.org>,  33007@debbugs.gnu.org
> Date: Thu, 11 Oct 2018 15:31:15 +0200
> 
> Some minor thoughts: The input buffer should be more controllable: modes
> and keymap shouldn't be fixed.  Also, it should be possible to prefill
> the buffer with a string describing what the user is expected to do, and
> which is ignored after the user has finished.

Don't we already have something like that in Customize and/or in EWW,
where they allow the user to fill fields in a form?

bug#33007: 27.0.50; Proposal for function to edit and return string

[Eli Zaretskii]

> Date: Thu, 11 Oct 2018 16:08:45 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: 33007@debbugs.gnu.org
> 
> > The minibuffer is a normal buffer, so you should be able to use all
> > the facilities you mention, perhaps by allowing
> > recursive minibuffers.
> 
> I don't know how to use minibuffer as normal
> buffer. For example I cannot enter M-x commands,
> as there is error command attempted to use
> minibuffer while in minibuffer.

"M-x set-variable RET enable-recursive-minibuffers RET t RET"

bug#33007: 27.0.50; Proposal for function to edit and return string

[Jean Louis]

On Thu, Oct 11, 2018 at 05:27:02PM +0300, Eli Zaretskii wrote:
> > Date: Thu, 11 Oct 2018 16:08:45 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: 33007@debbugs.gnu.org
> > 
> > > The minibuffer is a normal buffer, so you should be able to use all
> > > the facilities you mention, perhaps by allowing
> > > recursive minibuffers.
> > 
> > I don't know how to use minibuffer as normal
> > buffer. For example I cannot enter M-x commands,
> > as there is error command attempted to use
> > minibuffer while in minibuffer.
> 
> "M-x set-variable RET enable-recursive-minibuffers RET t RET"

I understand. Thank you.

OK, that still cannot replace full window buffer.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Drew Adams]

> Don't we already have something like that in Customize
> and/or in EWW, where they allow the user to fill fields
> in a form?

As Michael said, " I think it already has been reinvented
multiple times in Emacs itself."

The buffer is usually exited with `C-c C-c'. If the buffer
contains Lisp code, that's typically read with `read'
when you use `C-c C-c'.

The mode should be configurable, maybe defaulting
to Emacs Lisp mode (?). A key (other than `q') should
let you cancel (burying or killing the buffer without
evaluating or otherwise processing it in any way).

The functions that (1) create and display the buffer
and (2) process it (e.g. a command bound to `C-c C-c',
by default) or cancel it should be usable in various
ways, for buffer content of various kinds and for
processing of various kinds.

This should be done as simply as possible, e.g. as
contrasted with something like what `view-mode'
does, which is complex. If we want to provide
different buffer-display behaviors that should be
done simply somehow.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Eric Abrahamsen]

Drew Adams <drew.adams@oracle.com> writes:

>> Don't we already have something like that in Customize
>> and/or in EWW, where they allow the user to fill fields
>> in a form?
>
> As Michael said, " I think it already has been reinvented
> multiple times in Emacs itself."
>
> The buffer is usually exited with `C-c C-c'. If the buffer
> contains Lisp code, that's typically read with `read'
> when you use `C-c C-c'.
>
> The mode should be configurable, maybe defaulting
> to Emacs Lisp mode (?). A key (other than `q') should
> let you cancel (burying or killing the buffer without
> evaluating or otherwise processing it in any way).
>
> The functions that (1) create and display the buffer
> and (2) process it (e.g. a command bound to `C-c C-c',
> by default) or cancel it should be usable in various
> ways, for buffer content of various kinds and for
> processing of various kinds.
>
> This should be done as simply as possible, e.g. as
> contrasted with something like what `view-mode'
> does, which is complex. If we want to provide
> different buffer-display behaviors that should be
> done simply somehow.

Gnus also invented this wheel a while ago, for editing Group parameters.
There's also a Customize interface to the same data, though, which is
arguably easier to use.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Don't we already have something like that in Customize and/or in EWW,
> where they allow the user to fill fields in a form?

The use cases I have in mind don't fit there.  If you for example want
an interface to be able to attach multi line text notes to articles in
Gnus, it makes no sense to use a Customize or EWW buffer for that.

`org-capture' is another (already implemented) example: It prompts you
for a new note or task using a pop-up buffer.  This time, this buffer is
in org mode.

Magit's buffer prompting for a commit message is yet another example.
In all these cases, you don't yet have a buffer that you could use for
input, unlike Customize or EWW, and the minibuffer is not good for the
task.


Michael.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Drew Adams]

> > Don't we already have something like that in Customize and/or in EWW,
> > where they allow the user to fill fields in a form?
> 
> The use cases I have in mind don't fit there.  If you for example want
> an interface to be able to attach multi line text notes to articles in
> Gnus, it makes no sense to use a Customize or EWW buffer for that.
> 
> `org-capture' is another (already implemented) example: It prompts you
> for a new note or task using a pop-up buffer.  This time, this buffer is
> in org mode.
> 
> Magit's buffer prompting for a commit message is yet another example.
> In all these cases, you don't yet have a buffer that you could use for
> input, unlike Customize or EWW, and the minibuffer is not good for the
> task.

Plus adding/editing a bookmark annotation, plus...

The need is a general one. And the appropriate modes for possible editing buffers are unlimited. And what-to-do-with-the-result-of-editing is also unlimited.

What's needed is a function that lets you specify such things: editing mode and a function (such as `read', for Lisp code) to apply to the buffer content after editing (i.e., as part of "sending" or returning it).

Also needed probably is some way to provide text to be inserted at the top of the buffer as instructions, suitably commented-out if needed.

(Alternatively, put such text in a separate pop-up buffer, like `M-x report-emacs-bug' does with (some of) its instructions/help.)

bug#33007: 27.0.50; Proposal for function to edit and return string

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: bugs@gnu.support,  33007@debbugs.gnu.org
> Date: Thu, 11 Oct 2018 22:20:47 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Don't we already have something like that in Customize and/or in EWW,
> > where they allow the user to fill fields in a form?
> 
> The use cases I have in mind don't fit there.  If you for example want
> an interface to be able to attach multi line text notes to articles in
> Gnus, it makes no sense to use a Customize or EWW buffer for that.

I meant the infrastructure they use.  Customize uses widgets, AFAIR.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> I meant the infrastructure they use.  Customize uses widgets, AFAIR.

But in Customize or EWW, you already have a buffer you can use for
input.  In the cases I described, you don't.  If you e.g. want to query
the user for a (possibly longer) note to attach to an article in Gnus,
or want to query for a new note to capture (org), there is just no
buffer at hand to place a widget.

But if you already must use a dedicated buffer for input, using a widget
is no real additional gain.


Michael.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: bugs@gnu.support,  33007@debbugs.gnu.org
> Date: Fri, 12 Oct 2018 13:26:34 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I meant the infrastructure they use.  Customize uses widgets, AFAIR.
> 
> But in Customize or EWW, you already have a buffer you can use for
> input.  In the cases I described, you don't.  If you e.g. want to query
> the user for a (possibly longer) note to attach to an article in Gnus,
> or want to query for a new note to capture (org), there is just no
> buffer at hand to place a widget.

I just wanted to point out places where we do something similar, in
case we could reuse or refactor what they do, instead of inventing
from scratch.  I'm not saying that, because we have all those places,
we don't need the proposed feature.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

> The functions that (1) create and display the buffer
> and (2) process it (e.g. a command bound to `C-c C-c',
> by default) or cancel it should be usable in various
> ways, for buffer content of various kinds and for
> processing of various kinds.

Or to add a new arg to the existing standard functions like read-string
that will force them to use the bottom side window for reading (like the
bottom window is used for *Completions*) instead of the minibuffer.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Drew Adams]

> > The functions that (1) create and display the buffer
> > and (2) process it (e.g. a command bound to `C-c C-c',
> > by default) or cancel it should be usable in various
> > ways, for buffer content of various kinds and for
> > processing of various kinds.
> 
> Or to add a new arg to the existing standard functions like read-string
> that will force them to use the bottom side window for reading (like the
> bottom window is used for *Completions*) instead of the minibuffer.

Perhaps I misunderstand you, but that sounds like the
opposite (well, an opposite) to what I suggested: "be
usable in various ways, for buffer content of various
kinds and for processing of various kinds."

Probably I didn't give a good idea what I meant by that.

In my view this is not necessarily about reading a string.
And it is not fundamentally about which window becomes
selected after the editing is finished (processed) or where
the window for editing is placed. But maybe those things
should be specifiable too.

Reading edited content in a Lisp buffer is quite different
from reading edited text as a string, for instance.

Example: In Bookmark+ you can edit a bookmark record,
which is Lisp code, and then hit `C-c C-c' when you are done,
to have the edited code take effect. In this case the
operative read operation is Lisp `read'. It's not about reading
a string at all in this case.

I think we should aim for something pretty general, which
pops up an editing buffer, lets you edit (whatever it is) there,
and then lets you hit a key (e.g. `C-c C-c' might be a good
default) to have the edited text processed in some way
(typically read in some way).

For that we need a pretty general function that accepts
parameters that let you specify the specific behavior you
need. Maybe parameters to specify things like these:

* what kind of popping up of the editing buffer
* what to name the editing buffer
* what kind of operation to process the edited text -
   a function (e.g. `read' in the case of editing a bookmark
   record, `read-string' in some other contexts, etc.).
   Maybe `read-string' by default?
* what to do with the editing buffer at the end.

Maybe other things are needed, to enable more uses.

Maybe you think we should have a parameter for how
(where) to display the pop-up editing buffer? And a
parameter for how to determine which window gets
selected after editing is finished? I don't have an
opinion about those possibilities, except that by
default probably you should be back in the window
and buffer you started in.

Possibly the last one I listed is not needed? In my
case I typically use a special-display buffer, which
puts the pop-up buffer in a separate frame.

So in my case it is enough to have option
`frame-auto-hide-function' take care of what to do
with the editing buffer at the end (I have
`delete-frame' as the value of that option).

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

> * what kind of popping up of the editing buffer
> * what to name the editing buffer
> * what kind of operation to process the edited text -
>    a function (e.g. `read' in the case of editing a bookmark
>    record, `read-string' in some other contexts, etc.).
>    Maybe `read-string' by default?

read-from-minibuffer has the following arguments.  Let's see which ones
should remain for the new function with a name like read-from-buffer
that will read from the editing buffer:

  PROMPT - probably necessary to insert some explanatory text, such as
  for example the text inserted at the top of the *Completions* buffer:
  "Click on a completion to select it.
   In this buffer, type RET to select the completion near point.
   Possible completions are:"

  INITIAL-CONTENTS - an obsolete alternative to DEFAULT-VALUE;

  KEYMAP - useful to provide a special keymap in the editing buffer;

  READ - interpret the result as a Lisp object and return that object;

  HIST - not sure, what functionality should be associated with the history
  in the editing buffer;

  DEFAULT-VALUE - necessary to specify the value to return after typing
  `C-c C-c' in the empty buffer;

  INHERIT-INPUT-METHOD - necessary as well

The new arguments should be the same as currently for the function
display-buffer:

  BUFFER-OR-NAME - the name of the editing buffer;

  ACTION - display action like display-buffer-below-selected or
  display-buffer-at-bottom.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Drew Adams]

> > * what kind of popping up of the editing buffer
> > * what to name the editing buffer
> > * what kind of operation to process the edited text -
> >    a function (e.g. `read' in the case of editing a bookmark
> >    record, `read-string' in some other contexts, etc.).
> >    Maybe `read-string' by default?
> 
> read-from-minibuffer has the following arguments.  Let's see which ones
> should remain for the new function with a name like read-from-buffer
> that will read from the editing buffer:
> 
>   PROMPT - probably necessary to insert some explanatory text, such as
>   for example the text inserted at the top of the *Completions* buffer:
>   "Click on a completion to select it.
>    In this buffer, type RET to select the completion near point.
>    Possible completions are:"
> 
>   INITIAL-CONTENTS - an obsolete alternative to DEFAULT-VALUE;
>   KEYMAP - useful to provide a special keymap in the editing buffer;
>   READ - interpret the result as a Lisp object and return that object;
>   HIST - not sure, what functionality should be associated with the history
>   in the editing buffer;
>   DEFAULT-VALUE - necessary to specify the value to return after typing
>   `C-c C-c' in the empty buffer;
>   INHERIT-INPUT-METHOD - necessary as well
> 
> The new arguments should be the same as currently for the function
> display-buffer:
> 
>   BUFFER-OR-NAME - the name of the editing buffer;
>   ACTION - display action like display-buffer-below-selected or
>   display-buffer-at-bottom.

I don't see it like that. I don't see it like `read-from-minibuffer'. I don't see
it as modal, requiring you to edit and return without doing other things
in between. To me, this is not about creating something similar to a
minibuffer interaction.

I instead see it like what `M-x report-emacs-bug' does, followed by `C-c C-c':

1. One operation to open a window with a buffer for editing something,
possibly putting some text there, some of which could be ignored
when the read or other action occurs (from `C-c C-c`). 

That buffer would, yes, have a mode (which already also means a
keymap, and possibly a read syntax (e.g. `emacs-lisp-mode' has Lisp
`read' syntax).

2. Another operation, bound to `C-c C-c' in that editing buffer, which
would do something to the edited text. Typically read it. Ignoring some
text perhaps (e.g. instructions shown there to begin with).

Think `report-emacs-bug' as the model, IMO. Or for a Lisp buffer, see, e.g.,
`bmkp-edit-bookmark-record' and `bmkp-edit-bookmark-record-send', in
file `bookmark+-1.el', here:

https://www.emacswiki.org/emacs/download/bookmark%2b-1.el

I mention that only because I have it ready-to-hand. But this is Jean-Louis's
bug. Maybe he has a different idea in mind. For me, what's needed is two
operations - nothing modal: make available a buffer for editing something,
and give you a way to send that something to some function that uses it.
I'm also guessing that this is what Michael had in mind when he said that
Emacs has invented this here and there, and he has too.

Those existing here-and-there's are the place to start. I offered one, above.
I expect there are many others that folks have come up with. Looking at
what they have in common should give us an idea of a minimum set and
possible optional behaviors etc.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > The new arguments should be the same as currently for the function
> > display-buffer:
> > 
> >   BUFFER-OR-NAME - the name of the editing buffer;
> >   ACTION - display action like display-buffer-below-selected or
> >   display-buffer-at-bottom.
>
> I don't see it like that. I don't see it like
> `read-from-minibuffer'. I don't see
> it as modal, requiring you to edit and return without doing other things
> in between. To me, this is not about creating something similar to a
> minibuffer interaction.
>
> I instead see it like what `M-x report-emacs-bug' does, followed by
> `C-c C-c': [...]

I would want it to cover both requirements.  It would be nice if
there would also be a front-end like `read-from-minibuffer'.  Code can
be shared between the two.

What may also make sense: Emacs is prompting for user input using the
minibuffer.  User can hit a key if he wants to give large input or may
want to use elisp mode or whatever - and a buffer appears accepting
input, replacing the minibuffer.  User hits C-c C-c when done.


Michael.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> Something like this below shall become read-from-buffer [...]
>
> I agree that such an interface would be useful for Emacs.  I think it
> already has been reinvented multiple times in Emacs itself.  I invented
> it myself.
>
> Some minor thoughts: The input buffer should be more controllable: modes
> and keymap shouldn't be fixed.  Also, it should be possible to prefill
> the buffer with a string describing what the user is expected to do, and
> which is ignored after the user has finished.

I've now added this to Emacs 29 (as well as a non-modal version with a
callback instead of a recursive edit).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now added this to Emacs 29 (as well as a non-modal version with a
> callback instead of a recursive edit).

Cool - thank you very much.  I tried it shortly, and it works for me.

One thing I found: at the end of `string-edit', you have

#+begin_src emacs-lisp
(message "%S" (substitute-command-keys
                 "Type `C-c C-c' when you've finished editing"))
#+end_src

That should be "%s" - we don't want a quoted, `read'able string
messaged.

Second: I find the name of `read-string-from-buffer' a bit misleading -
what about `edit-string-in-buffer'?  The emphasis should be on "edit",
because a string is already present, the function doesn't just prompt
for a (new) string.

Thanks,

Michael.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> One thing I found: at the end of `string-edit', you have
>
> #+begin_src emacs-lisp
> (message "%S" (substitute-command-keys
>                  "Type `C-c C-c' when you've finished editing"))
> #+end_src
>
> That should be "%s" - we don't want a quoted, `read'able string
> messaged.

Yup; fixed now (and I made it use the \[...] thing at the same time).

> Second: I find the name of `read-string-from-buffer' a bit misleading -
> what about `edit-string-in-buffer'?  The emphasis should be on "edit",
> because a string is already present, the function doesn't just prompt
> for a (new) string.

Yes, I was waffling between various names while I was typing the file,
and renamed the function to read-string-from-buffer while writing the
documentation.  :-)  I thought it might make sense from a discovery
point of view to have something that people who looked for `read-string'
would find easily (and could plug into existing functions easily).

But this function will probably mostly be used for editing strings, as
you point out, so `edit-string-in-buffer' sounds like a good idea to me.
Anybody have any further opinions before I rename?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

>> One thing I found: at the end of `string-edit', you have
>>
>> #+begin_src emacs-lisp
>> (message "%S" (substitute-command-keys
>>                  "Type `C-c C-c' when you've finished editing"))
>> #+end_src
>>
>> That should be "%s" - we don't want a quoted, `read'able string
>> messaged.
>
> Yup; fixed now (and I made it use the \[...] thing at the same time).

Another problem is that currently the message doesn't say how
to abort changes:

  Type C-c C-c when you’ve finished editing

whereas for example the message in Wdired is:

  Press C-c C-c when finished or C-c ESC to abort changes

>> Second: I find the name of `read-string-from-buffer' a bit misleading -
>> what about `edit-string-in-buffer'?  The emphasis should be on "edit",
>> because a string is already present, the function doesn't just prompt
>> for a (new) string.
>
> Yes, I was waffling between various names while I was typing the file,
> and renamed the function to read-string-from-buffer while writing the
> documentation.  :-)  I thought it might make sense from a discovery
> point of view to have something that people who looked for `read-string'
> would find easily (and could plug into existing functions easily).
>
> But this function will probably mostly be used for editing strings, as
> you point out, so `edit-string-in-buffer' sounds like a good idea to me.
> Anybody have any further opinions before I rename?

I think read-string-from-buffer is already a nice name,
and when its default is empty string, then it really reads
a new string from scratch.

Also it would be nicer to pop up its buffer under the current window
(need to play with display-buffer parameters), and a good example
is display-buffer-below-selected (e.g. as used in dired-mark-pop-up).

bug#33007: 27.0.50; Proposal for function to edit and return string

[Michael Heerdegen]

Juri Linkov <juri@linkov.net> writes:

> Another problem is that currently the message doesn't say how
> to abort changes:
>
>   Type C-c C-c when you’ve finished editing
>
> whereas for example the message in Wdired is:
>
>   Press C-c C-c when finished or C-c ESC to abort changes

Additionally: we have enough room to include such instructions in the
buffer itself.  There are many keybindings for aborting in use (also in
third party packages) like C-c ESC, C-c C-k, C-c C-a.  And when you need
to know which one it was the message is long gone.  We could use the
header-line, or the mode-line, or the buffer header used when using the
:help-text key.

Michael.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Michael Heerdegen]

Hello Lars,

do you think it would make sense to add a :setup-function key to
`string-edit'?  That arg could then be used to manipulate the key
bindings or toggle modes and such things.

Related question: Is it planned that this function will also be used to
implement reading Elisp expressions from a buffer, or other things
besides plain strings?

Thanks,

Michael.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

>> Another problem is that currently the message doesn't say how
>> to abort changes:
>>
>>   Type C-c C-c when you’ve finished editing
>>
>> whereas for example the message in Wdired is:
>>
>>   Press C-c C-c when finished or C-c ESC to abort changes
>
> Additionally: we have enough room to include such instructions in the
> buffer itself.  There are many keybindings for aborting in use (also in
> third party packages) like C-c ESC, C-c C-k, C-c C-a.  And when you need
> to know which one it was the message is long gone.  We could use the
> header-line, or the mode-line, or the buffer header used when using the
> :help-text key.

Indeed.  I perceive the new function as emulation of the minibuffer.
And since the minibuffer has read-only area with prompt at the beginning,
read-string-from-buffer could add a similar header as well,
like e.g. header lines in the Completions buffer.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Also it would be nicer to pop up its buffer under the current window
> (need to play with display-buffer parameters), and a good example
> is display-buffer-below-selected (e.g. as used in dired-mark-pop-up).

I see that that function has only a single usage in Emacs, and after
reading half the doc string, I can see why.

If we want to use something like that more in Emacs, somebody should
write a function with a simpler interface.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Additionally: we have enough room to include such instructions in the
> buffer itself.  There are many keybindings for aborting in use (also in
> third party packages) like C-c ESC, C-c C-k, C-c C-a.  And when you need
> to know which one it was the message is long gone.  We could use the
> header-line, or the mode-line, or the buffer header used when using the
> :help-text key.

Putting the instructions into a header line might be the nicest solution
here...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> do you think it would make sense to add a :setup-function key to
> `string-edit'?  That arg could then be used to manipulate the key
> bindings or toggle modes and such things.

Sure; go ahead and add that.

> Related question: Is it planned that this function will also be used to
> implement reading Elisp expressions from a buffer, or other things
> besides plain strings?

There's nothing planned, really.  :-)  Adding a variation to read a Lisp
form from a buffer would also be nice (which would signal an error if
the form isn't complete, much like `M-:' does these days).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

>> Additionally: we have enough room to include such instructions in the
>> buffer itself.  There are many keybindings for aborting in use (also in
>> third party packages) like C-c ESC, C-c C-k, C-c C-a.  And when you need
>> to know which one it was the message is long gone.  We could use the
>> header-line, or the mode-line, or the buffer header used when using the
>> :help-text key.
>
> Putting the instructions into a header line might be the nicest solution
> here...

This is exactly what org-src-mode does after invoking ‘C-c '’ (org-edit-special).
Its header-line-format is:

  "Edit, then exit with `\\[org-edit-src-exit]' or abort with `\\[org-edit-src-abort]'"

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

>> Also it would be nicer to pop up its buffer under the current window
>> (need to play with display-buffer parameters), and a good example
>> is display-buffer-below-selected (e.g. as used in dired-mark-pop-up).
>
> I see that that function has only a single usage in Emacs, and after
> reading half the doc string, I can see why.
>
> If we want to use something like that more in Emacs, somebody should
> write a function with a simpler interface.

The most important thing is that it should support customization
with display-buffer-alist: in Org mode it was impossible to
customize the location of Org popup windows because
display-buffer-alist was ignored in org-no-popups,
but now I see this limitation was removed recently.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> This is exactly what org-src-mode does after invoking ‘C-c '’
> (org-edit-special).
> Its header-line-format is:
>
>   "Edit, then exit with `\\[org-edit-src-exit]' or abort with
> `\\[org-edit-src-abort]'"

I've now added something like this to string-edit.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> The most important thing is that it should support customization
> with display-buffer-alist: in Org mode it was impossible to
> customize the location of Org popup windows because
> display-buffer-alist was ignored in org-no-popups,
> but now I see this limitation was removed recently.

pop-to-buffer-same-window does allow customization via
display-buffer-alist, but -below-selected would be a better default.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

> pop-to-buffer-same-window does allow customization via
> display-buffer-alist, but -below-selected would be a better default.

This is what could be used:

  (pop-to-buffer (generate-new-buffer "*edit string*")
                 '(display-buffer-below-selected
                   (window-min-height . 10)
                   (window-height . fit-window-to-buffer)))

but currently its window-min-height has no effect.
Maybe because of a bug?  The docstring of display-buffer-below-selected:

  If ALIST contains a `window-min-height' entry, this function
  ensures that the window used is or can become at least as high as
  specified by that entry's value.  Note that such an entry alone
  will not resize the window per se.  In order to do that, ALIST
  must also contain a `window-height' entry with the same value.

But still the window height is less than 10 lines.

BTW, maybe read-string-from-buffer should have ###autoload cookie?

Also any chance to make it argument-wise compatible with read-string?
Currently:

  (read-string PROMPT &optional INITIAL-INPUT
  (read-string-from-buffer STRING &optional HELP-TEXT

HELP-TEXT could be renamed to PROMPT, and STRING really is INITIAL-INPUT.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> BTW, maybe read-string-from-buffer should have ###autoload cookie?

Ah, yes.  Now added.

> Also any chance to make it argument-wise compatible with read-string?
> Currently:
>
>   (read-string PROMPT &optional INITIAL-INPUT
>   (read-string-from-buffer STRING &optional HELP-TEXT
>
> HELP-TEXT could be renamed to PROMPT, and STRING really is INITIAL-INPUT.

Yeah, that makes sense, I think?  I had initially thought that perhaps
callers wouldn't commonly have a HELP-TEXT, but perhaps all callers need
to say what the purpose of the string is.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

>> pop-to-buffer-same-window does allow customization via
>> display-buffer-alist, but -below-selected would be a better default.
>
> This is what could be used:
>
>   (pop-to-buffer (generate-new-buffer "*edit string*")
>                  '(display-buffer-below-selected
>                    (window-min-height . 10)
>                    (window-height . fit-window-to-buffer)))
>
> but currently its window-min-height has no effect.
> Maybe because of a bug?  The docstring of display-buffer-below-selected:
>
>   If ALIST contains a `window-min-height' entry, this function
>   ensures that the window used is or can become at least as high as
>   specified by that entry's value.  Note that such an entry alone
>   will not resize the window per se.  In order to do that, ALIST
>   must also contain a `window-height' entry with the same value.
>
> But still the window height is less than 10 lines.

Maybe a separate bug report is needed?  Because it seems that
the order of processing these parameters should be rather like this:

1. first set window-height with fit-window-to-buffer;
2. then check if the constraint of window-min-height is fulfilled,
   and shrink too high window.

Then 'string-edit' will insert the initial string, and
'fit-window-to-buffer' will fit the window.  If the window height
is less than 10 lines, it will enlarge to 10 lines.  But in case of
too many lines, the window height should not be more than
half of the original window.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> Maybe a separate bug report is needed?  Because it seems that
> the order of processing these parameters should be rather like this:
>
> 1. first set window-height with fit-window-to-buffer;
> 2. then check if the constraint of window-min-height is fulfilled,
>    and shrink too high window.
>
> Then 'string-edit' will insert the initial string, and
> 'fit-window-to-buffer' will fit the window.  If the window height
> is less than 10 lines, it will enlarge to 10 lines.  But in case of
> too many lines, the window height should not be more than
> half of the original window.

Yup; sounds like a separate bug report is warranted.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 727 bytes --]

>> Maybe a separate bug report is needed?  Because it seems that
>> the order of processing these parameters should be rather like this:
>>
>> 1. first set window-height with fit-window-to-buffer;
>> 2. then check if the constraint of window-min-height is fulfilled,
>>    and shrink too high window.
>>
>> Then 'string-edit' will insert the initial string, and
>> 'fit-window-to-buffer' will fit the window.  If the window height
>> is less than 10 lines, it will enlarge to 10 lines.  But in case of
>> too many lines, the window height should not be more than
>> half of the original window.
>
> Yup; sounds like a separate bug report is warranted.

As was found in bug#55169, this is already possible to do with a lambda:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: read-string-from-buffer.patch --]
[-- Type: text/x-diff, Size: 1285 bytes --]

diff --git a/lisp/textmodes/string-edit.el b/lisp/textmodes/string-edit.el
index ab0b3b3bd7..d3f614ca94 100644
--- a/lisp/textmodes/string-edit.el
+++ b/lisp/textmodes/string-edit.el
@@ -47,7 +47,10 @@ string-edit
 PROMPT will be inserted at the start of the buffer, but won't be
 included in the resulting string.  If PROMPT is nil, no help text
 will be inserted."
-  (pop-to-buffer-same-window (generate-new-buffer "*edit string*"))
+  (pop-to-buffer (generate-new-buffer "*edit string*")
+                 '(display-buffer-below-selected
+                   (window-height . (lambda (window)
+                                      (fit-window-to-buffer window nil 10)))))
   (when prompt
     (let ((inhibit-read-only t))
       (insert prompt)
@@ -113,14 +116,14 @@ string-edit-done
     (goto-char (prop-match-beginning match)))
   (let ((string (buffer-substring (point) (point-max)))
         (callback string-edit--success-callback))
-    (kill-buffer (current-buffer))
+    (quit-window 'kill)
     (funcall callback string)))
 
 (defun string-edit-abort ()
   "Abort editing the current string."
   (interactive)
   (let ((callback string-edit--abort-callback))
-    (kill-buffer (current-buffer))
+    (quit-window 'kill)
     (when callback
       (funcall callback))))
 

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> -  (pop-to-buffer-same-window (generate-new-buffer "*edit string*"))
> +  (pop-to-buffer (generate-new-buffer "*edit string*")
> +                 '(display-buffer-below-selected
> +                   (window-height . (lambda (window)
> +                                      (fit-window-to-buffer window nil 10)))))

Shouldn't it wait to do the fitting until it's prepared the buffer?
I.e., it should create the buffer first, insert all the stuff, and then
pop to it?

> -    (kill-buffer (current-buffer))
> +    (quit-window 'kill)

I think we really want to kill the buffer?  It'd be disturbing to leave
thees buffers lying around from a function call like
read-string-from-buffer.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#33007: 27.0.50; Proposal for function to edit and return string

[Juri Linkov]

>> -  (pop-to-buffer-same-window (generate-new-buffer "*edit string*"))
>> +  (pop-to-buffer (generate-new-buffer "*edit string*")
>> +                 '(display-buffer-below-selected
>> +                   (window-height . (lambda (window)
>> +                                      (fit-window-to-buffer window nil 10)))))
>
> Shouldn't it wait to do the fitting until it's prepared the buffer?
> I.e., it should create the buffer first, insert all the stuff, and then
> pop to it?

This is possible by moving `pop-to-buffer' to the end of the function.

>> -    (kill-buffer (current-buffer))
>> +    (quit-window 'kill)
>
> I think we really want to kill the buffer?  It'd be disturbing to leave
> thees buffers lying around from a function call like
> read-string-from-buffer.

The arg `kill' of `quit-window' actually kills the buffer.

bug#33007: 27.0.50; Proposal for function to edit and return string

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Shouldn't it wait to do the fitting until it's prepared the buffer?
>> I.e., it should create the buffer first, insert all the stuff, and then
>> pop to it?
>
> This is possible by moving `pop-to-buffer' to the end of the function.

Yeah, that's what I meant.

>>> -    (kill-buffer (current-buffer))
>>> +    (quit-window 'kill)
>>
>> I think we really want to kill the buffer?  It'd be disturbing to leave
>> thees buffers lying around from a function call like
>> read-string-from-buffer.
>
> The arg `kill' of `quit-window' actually kills the buffer.

I think I need new glasses or something.

Anyway, looks good to me, so go ahead and push.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no