From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#42210: Add -other-window variants of project-prefix-map commands Date: Sun, 5 Jul 2020 17:00:10 -0700 (PDT) Message-ID: References: <87blkw5cd3.fsf@iris.silentflame.com> <87tuymh4k9.fsf@iris.silentflame.com> <875zb1hfpy.fsf@iris.silentflame.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21320"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dgutov@yandex.ru, juri@linkov.net To: Sean Whitton , 42210@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 06 02:02:00 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jsEa8-0005Sb-5R for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Jul 2020 02:02:00 +0200 Original-Received: from localhost ([::1]:45340 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jsEa7-0006iv-6W for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jul 2020 20:01:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53982) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jsEZC-0006YF-4Y for bug-gnu-emacs@gnu.org; Sun, 05 Jul 2020 20:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:49806) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jsEZB-000544-Pl for bug-gnu-emacs@gnu.org; Sun, 05 Jul 2020 20:01:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jsEZB-0001D2-Os for bug-gnu-emacs@gnu.org; Sun, 05 Jul 2020 20:01:01 -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, 06 Jul 2020 00:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42210 X-GNU-PR-Package: emacs Original-Received: via spool by 42210-submit@debbugs.gnu.org id=B42210.15939936254597 (code B ref 42210); Mon, 06 Jul 2020 00:01:01 +0000 Original-Received: (at 42210) by debbugs.gnu.org; 6 Jul 2020 00:00:25 +0000 Original-Received: from localhost ([127.0.0.1]:33119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jsEYb-0001C4-Ew for submit@debbugs.gnu.org; Sun, 05 Jul 2020 20:00:25 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:36024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jsEYZ-0001Bp-9V for 42210@debbugs.gnu.org; Sun, 05 Jul 2020 20:00:24 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 065NqwRn027906; Mon, 6 Jul 2020 00:00:17 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-2020-01-29; bh=7+X2AfKkuzUwA9de5lVTboFeOlLfLWfW3azckyrZnS0=; b=mN/8nBNBpMzq1eSjv4byhLIppVgUzKs8mb2E3zIXTqt0rAzvvS08XEY34G8LJ8LuGO5L pZhzO0zjSciMY6DGI35HuwErsxYc+s93fVGnqLrcVKjNISifcejnUKkjMvmHpIXAUjk0 wmNfwq+GQXy+Et7/cqugBNAa5ImelnKTbdUZ3pF0cSgIqS6JlqShhnAIyGeAxBq7qCRf t5al97myMK28C2elC1A4wdz6xd6LaluQBXOd95xsuuThX7tQKrXLvtCgmwnKylvudssW pNYOColuFdO6RJGlfyZ27oc4dpuRqqdHfMKFksu5qg8IG8gradk6CZvgKl1cMER14xLO rA== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2120.oracle.com with ESMTP id 322kv63eqe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 06 Jul 2020 00:00:17 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 065Ns52S073676; Mon, 6 Jul 2020 00:00:16 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3030.oracle.com with ESMTP id 3233pue922-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 06 Jul 2020 00:00:16 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 06600B6e007781; Mon, 6 Jul 2020 00:00:11 GMT In-Reply-To: <875zb1hfpy.fsf@iris.silentflame.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5017.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9673 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007050186 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9673 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 phishscore=0 spamscore=0 priorityscore=1501 clxscore=1015 impostorscore=0 mlxscore=0 adultscore=0 cotscore=-2147483648 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007050186 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:182758 Archived-At: > > 1. I disagree with calling the macro `define-other-window-command'. > > > > My disagreement is this: Defining an other-window command > > should do just that. It should not define a command that > > only "prefers" to display in another window. It should > > define a command that actually displays in another window. > > > > And your doc string in fact says the latter, though the > > behavior is, I guess, only the former. Please consider > > renaming the macro and fixing the doc string, to make clear > > that it's NOT other-window but only maybe-other-window. >=20 > Hmm, but doesn't pop-to-buffer-other-window also only prefer to use > another window, and ultimately defers to the display-buffer-alist > machinery? 1. (There is no `pop-to-buffer-other-window', is there?) The doc of `pop-to-buffer' goes out of its way to tell about its relation with `display-buffer' - because it passes its arg to it. =20 The doc of `switch-to-buffer-other-window' just says directly that it selects the buffer in another window. Only at its very end does it mention the possibility that `display-buffer' can alter behavior: This uses the function `display-buffer' as a subroutine; see its documentation for additional customization information. What's not so good is to (a) not say what THIS function is for: other-window and (b) not mention `display-buffer', while suggesting some other behavior than other-window. 2. I suppose `display-buffer(-alist)' can override anything now. If that's all that's meant then I think it shouldn't be put that way. It's OK (but might not be needed or appropriate) to add some mention of it at the end. But I don't think the behavior of the command should be described that way. The point of the resulting function is (presumably) to use another window. The point of any additional `display-buffer*' shenanigans - or other Lisp code that might have an effect on things - could be just about anything. This doc should be about what the resulting function intends to do, not whatever some other code might make it do instead. If you want to go the other route, then make the relation explicit, as does the doc of `pop-to-buffer' and `switch-to-buffer-other-window'. > > 2. Why "resultant buffer". What does the buffer result > > from? It's about whatever FUNCTION displays, no? >=20 > Please feel free to suggest alternative phrasing that will be short > enough to fit in one line, which I understand to be required. Define an other-window version of FUNCTION. or Define a function like FUNCTION that outputs to another window. or Define a function like FUNCTION but that outputs to another window. > > 3. Presumably FUNCTION must be a _command_. If so, > > the arg should be called COMMAND, and the doc adjusted > > accordingly. >=20 > No, it can just be a function too. You're right; I was wrong about that. However, isn't the real purpose of this macro to define commands, which you can bind to keys to get other-window behavior? Is there really some other expected use case? Would anyone use it for a non-interactive function? If you want to be exact then yes, FUNCTION. But in that case I think the doc should say that FUNCTION is typically a command, i.e., give the use case that's the raison d'etre for the macro. BTW, this part of your patch doesn't seem right: (called-interactively-p). Argument KIND is optional (should it really be?), but the behavior of calling the function without KIND is not documented, and it always just returns nil. (I filed bug #42222 about KIND being optional etc.)