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: Tue, 16 Oct 2018 16:05:22 -0700 (PDT)	[thread overview]
Message-ID: <eb035ac5-5eac-4071-82c6-1361dda892ec@default> (raw)
In-Reply-To: <87pnw992hn.fsf@mail.linkov.net>

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





  reply	other threads:[~2018-10-16 23:05 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
2018-10-16 22:12               ` Juri Linkov
2018-10-16 23:05                 ` Drew Adams [this message]
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=eb035ac5-5eac-4071-82c6-1361dda892ec@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.