bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: bug#33007: 27.0.50; Proposal for function to edit and return string
Date: Tue, 16 Oct 2018 16:05:22 -0700 (PDT)

> > * 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 via email to

[Prev in Thread] Current Thread [Next in Thread]