GNU bug report logs - #33007
27.0.50; Proposal for function to edit and return string

Previous Next

Full log

Message #65 received at 33007 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Eli Zaretskii <eliz <at> gnu.org>,
 33007 <at> debbugs.gnu.org, bugs <at> gnu.support
Subject: RE: bug#33007: 27.0.50; Proposal for function to edit and return
 string
Date: Mon, 15 Oct 2018 15:07:18 -0700 (PDT)

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.