From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#33007: 27.0.50; Proposal for function to edit and return string Date: Mon, 15 Oct 2018 15:07:18 -0700 (PDT) Message-ID: <6a27b968-1307-44f2-b335-cde4ef51159b@default> References: <86pnwh4je8.fsf@protected.rcdrun.com>> <83bm81xl84.fsf@gnu.org> <20181011063321.GD27672@protected.rcdrun.com>> <87lg74zk2k.fsf@web.de>> <834ldsy31m.fsf@gnu.org>> <87efcrazrs.fsf@mail.linkov.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1539641168 24742 195.159.176.226 (15 Oct 2018 22:06:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Oct 2018 22:06:08 +0000 (UTC) Cc: Michael Heerdegen , bugs@gnu.support, 33007@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 16 00:06:03 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCAzz-0006JX-LY for geb-bug-gnu-emacs@m.gmane.org; Tue, 16 Oct 2018 00:06:03 +0200 Original-Received: from localhost ([::1]:55057 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCB26-00045l-2P for geb-bug-gnu-emacs@m.gmane.org; Mon, 15 Oct 2018 18:08:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43026) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gCB1z-00045U-Kt for bug-gnu-emacs@gnu.org; Mon, 15 Oct 2018 18:08:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gCB1w-0002sP-EA for bug-gnu-emacs@gnu.org; Mon, 15 Oct 2018 18:08:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47310) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gCB1u-0002ri-RA for bug-gnu-emacs@gnu.org; Mon, 15 Oct 2018 18:08:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gCB1u-00064S-HI for bug-gnu-emacs@gnu.org; Mon, 15 Oct 2018 18:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 15 Oct 2018 22:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 33007 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 33007-submit@debbugs.gnu.org id=B33007.153964125423302 (code B ref 33007); Mon, 15 Oct 2018 22:08:02 +0000 Original-Received: (at 33007) by debbugs.gnu.org; 15 Oct 2018 22:07:34 +0000 Original-Received: from localhost ([127.0.0.1]:51568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCB1S-00063k-GU for submit@debbugs.gnu.org; Mon, 15 Oct 2018 18:07:34 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:51508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gCB1R-00063Y-IF for 33007@debbugs.gnu.org; Mon, 15 Oct 2018 18:07:34 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9FM4qVR186794; Mon, 15 Oct 2018 22:07:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=j0VyK4QxIHWQn1FS7gVbVDc+/jze177SOoSrxEJ3EiM=; b=3M9jRIx4+dUgSVNtUiKOubJBczSWo25AoTy+HpEN4RmB80Cm27vl7hxjDezw+PWj1Tr3 r39dFpIEPiACtlmNNGkWWzK7EkoeZKhyASw0Yam7aUyriNNRBbbd4BWNXRr6rleLVL++ Uli6yzn8V8siY6/POmaknra0fOF1Q4wT9196sQ202XA9BzUZ25MhxXpAmcW3c9HpBaC5 u9Qm+ohD3jAfFLKwEISf8Lk3ZhYilTtEGlMCBb/qjrX2sWnubWWXNxQbnPJJLsg/ERpa 4I+vJLwgUH5VcYCqShwzgLKPRS4rKN59B5rORYajESbiLYMuFi/cfiGFlXAUbn22TWki /g== Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2120.oracle.com with ESMTP id 2n39br50q1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 15 Oct 2018 22:07:27 +0000 Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9FM7K3j030182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 15 Oct 2018 22:07:20 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9FM7J1F000902; Mon, 15 Oct 2018 22:07:19 GMT In-Reply-To: <87efcrazrs.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4735.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9047 signatures=668706 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810150190 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:151292 Archived-At: > > 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. >=20 > 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).