all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: Michael Heerdegen <michael_heerdegen@web.de>,
	bugs@gnu.support, 33007@debbugs.gnu.org
Subject: bug#33007: 27.0.50; Proposal for function to edit and return string
Date: Mon, 15 Oct 2018 15:07:18 -0700 (PDT)	[thread overview]
Message-ID: <6a27b968-1307-44f2-b335-cde4ef51159b@default> (raw)
In-Reply-To: <87efcrazrs.fsf@mail.linkov.net>

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





  reply	other threads:[~2018-10-15 22:07 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-10 20:49 bug#33007: 27.0.50; Proposal for function to edit and return string Jean Louis
2018-10-11  2:36 ` Eli Zaretskii
2018-10-11  6:33   ` Jean Louis
2018-10-11 13:31     ` Michael Heerdegen
2018-10-11 13:40       ` Jean Louis
2018-10-11 14:24       ` Eli Zaretskii
2018-10-11 20:20         ` Michael Heerdegen
2018-10-11 21:23           ` Drew Adams
2018-10-12  4:26           ` Eli Zaretskii
2018-10-12 11:26             ` Michael Heerdegen
2018-10-12 12:41               ` Eli Zaretskii
2022-04-24 13:15       ` Lars Ingebrigtsen
2022-04-25  3:00         ` Michael Heerdegen
2022-04-25  7:50           ` Lars Ingebrigtsen
2022-04-25 15:42             ` Juri Linkov
2022-04-25 22:26               ` Michael Heerdegen
2022-04-26  7:23                 ` Juri Linkov
2022-04-26  9:56                 ` Lars Ingebrigtsen
2022-04-26 15:36                   ` Juri Linkov
2022-04-27 12:09                     ` Lars Ingebrigtsen
2022-04-26  9:55               ` Lars Ingebrigtsen
2022-04-26 15:39                 ` Juri Linkov
2022-04-27 12:10                   ` Lars Ingebrigtsen
2022-04-27 16:44                     ` Juri Linkov
2022-04-27 17:05                       ` Lars Ingebrigtsen
2022-04-28  7:32                       ` Juri Linkov
2022-04-28 10:19                         ` Lars Ingebrigtsen
2022-05-08 18:22                           ` Juri Linkov
2022-05-09  9:49                             ` Lars Ingebrigtsen
2022-05-09 18:52                               ` Juri Linkov
2022-05-10  1:53                                 ` Lars Ingebrigtsen
2022-04-25 22:46         ` Michael Heerdegen
2022-04-26  9:58           ` Lars Ingebrigtsen
2018-10-11 13:55     ` Eli Zaretskii
2018-10-11 14:01       ` Michael Heerdegen
2018-10-11 14:08       ` Jean Louis
2018-10-11 14:16         ` Michael Heerdegen
2018-10-11 14:27         ` Eli Zaretskii
2018-10-11 14:36           ` Jean Louis
     [not found]     ` <<87lg74zk2k.fsf@web.de>
     [not found]       ` <<834ldsy31m.fsf@gnu.org>
2018-10-11 14:41         ` Drew Adams
2018-10-11 16:40           ` Eric Abrahamsen
2018-10-15 20:34           ` Juri Linkov
2018-10-15 22:07             ` Drew Adams [this message]
2018-10-16 22:12               ` Juri Linkov
2018-10-16 23:05                 ` Drew Adams
2018-10-17 15:39                   ` Michael Heerdegen
     [not found] <<86pnwh4je8.fsf@protected.rcdrun.com>

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6a27b968-1307-44f2-b335-cde4ef51159b@default \
    --to=drew.adams@oracle.com \
    --cc=33007@debbugs.gnu.org \
    --cc=bugs@gnu.support \
    --cc=juri@linkov.net \
    --cc=michael_heerdegen@web.de \
    /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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.