all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>,
	Michael Heerdegen <michael_heerdegen@web.de>
Cc: bugs@gnu.support, 33007@debbugs.gnu.org
Subject: bug#33007: 27.0.50; Proposal for function to edit and return string
Date: Thu, 11 Oct 2018 14:41:12 +0000 (UTC)	[thread overview]
Message-ID: <ff9d53f8-857a-4e95-af38-65c4fdc1ecde@default> (raw)
In-Reply-To: <<834ldsy31m.fsf@gnu.org>>

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





  parent reply	other threads:[~2018-10-11 14:41 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 [this message]
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
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=ff9d53f8-857a-4e95-af38-65c4fdc1ecde@default \
    --to=drew.adams@oracle.com \
    --cc=33007@debbugs.gnu.org \
    --cc=bugs@gnu.support \
    --cc=eliz@gnu.org \
    --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.