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

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Jean Louis <[hidden email]>
> 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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> > 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)))



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
Jean Louis <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Jean Louis
> Date: Thu, 11 Oct 2018 08:33:21 +0200
> From: Jean Louis <[hidden email]>
> Cc: [hidden email]
>
> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Jean Louis
In reply to this post by Eli Zaretskii
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 <[hidden email]>
> > Cc: [hidden email]
> >
> > > 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



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
Jean Louis <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Michael Heerdegen
> From: Michael Heerdegen <[hidden email]>
> Cc: Eli Zaretskii <[hidden email]>,  [hidden email]
> 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?



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Jean Louis
> Date: Thu, 11 Oct 2018 16:08:45 +0200
> From: Jean Louis <[hidden email]>
> Cc: [hidden email]
>
> > 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"



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> > Cc: [hidden email]
> >
> > > 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.



Reply | Threaded
Open this post in threaded view
|

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

Eric Abrahamsen-2
In reply to this post by Jean Louis
Drew Adams <[hidden email]> 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.




Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
In reply to this post by Eli Zaretskii
Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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.)



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Michael Heerdegen
> From: Michael Heerdegen <[hidden email]>
> Cc: [hidden email],  [hidden email]
> Date: Thu, 11 Oct 2018 22:20:47 +0200
>
> Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Michael Heerdegen
Eli Zaretskii <[hidden email]> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Michael Heerdegen <[hidden email]>
> Cc: [hidden email],  [hidden email]
> Date: Fri, 12 Oct 2018 13:26:34 +0200
>
> Eli Zaretskii <[hidden email]> 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.