From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#71971: 31.0.50; Add user option server-window-alist Date: Mon, 08 Jul 2024 19:41:16 +0200 Message-ID: <871q43vl1f.fsf@bernoul.li> References: <871q463hke.fsf@gmx.de> <86cynq4vfa.fsf@gnu.org> <87msmuvc5m.fsf@bernoul.li> <86wmly37c6.fsf@gnu.org> Reply-To: Jonas Bernoulli Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8106"; mail-complaints-to="usenet@ciao.gmane.io" Cc: michael.albinus@gmx.de, 71971@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 08 19:42:14 2024 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 1sQsNR-0001rj-Ii for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jul 2024 19:42:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQsND-0005AU-VF; Mon, 08 Jul 2024 13:41:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQsNB-000528-OQ for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2024 13:41:57 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sQsNB-0000pB-G8 for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2024 13:41:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sQsNG-00036U-7H for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2024 13:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jonas Bernoulli Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Jul 2024 17:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71971 X-GNU-PR-Package: emacs Original-Received: via spool by 71971-submit@debbugs.gnu.org id=B71971.172046049111892 (code B ref 71971); Mon, 08 Jul 2024 17:42:02 +0000 Original-Received: (at 71971) by debbugs.gnu.org; 8 Jul 2024 17:41:31 +0000 Original-Received: from localhost ([127.0.0.1]:51420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQsMk-00035k-Pm for submit@debbugs.gnu.org; Mon, 08 Jul 2024 13:41:31 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:53480) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQsMh-00035U-3l for 71971@debbugs.gnu.org; Mon, 08 Jul 2024 13:41:29 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id A4B2C164D4; Mon, 8 Jul 2024 19:41:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-type:content-type:mime-version:message-id:date:date :references:in-reply-to:subject:subject:from:from; s=sel2011a; t=1720460479; bh=t8onZXusdGQRnIocJTx289OpA/W6eS8m3wYoiTZR0VE=; b= TRG6u7h2kKVeO/ogzsEWWvVbyFtJMXBm4MNDKQNgou61OVZODCD3WJFNZ7mQAjBK XUAPt1QZiPJmybmlhHH95GEddDtd2WTxFz13sMCJu/8w6n3qnD2cIn6ITDXctQeV kFm1DWoIUKt4robuJt20RvubBYtG1dJV0DkaTE9eWKE= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id AXrGQqudFKHP; Mon, 8 Jul 2024 19:41:19 +0200 (CEST) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id ECA4616463; Mon, 8 Jul 2024 19:41:17 +0200 (CEST) In-Reply-To: <86wmly37c6.fsf@gnu.org> 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288603 Archived-At: Eli Zaretskii writes: >> From: Jonas Bernoulli >> Cc: 71971@debbugs.gnu.org >> Date: Sat, 06 Jul 2024 16:16:21 +0200 >> >> So in summary, it is possible for the same person to want the behavior >> to be different in different situations. The fact that "committing from >> Emacs using Magit" involves the use of emacsclient, just like "quickly >> edit a file from the terminal" does, is an implementation detail, and >> should not make it necessary for the user to decide which use-case >> should be optimized to their liking, at the cost of undesirable behavior >> in the other case. > > That sounds to me like the value of $EDITOR should be "emacsclient -c" > whereas the value of $GIT_EDITOR should be just "emacsclient"? Who would set those variables to those values? Where? --- I am beginning to think that at least for Magit's needs the new --create-frame is sufficient. It could just call EDITOR="emacsclient -c" git commit Unfortunately that's a fairly new argument, so with-editor will have to keep providing an alternative. But when it comes to the question of whether server-window-alist should be added to future Emacs releases, that isn't a concern. I understand your hesitancy to add such a variable. I am not sure it is necessary anymore either. > IOW, > what you describe involves workflows some of which want a new client > frame and some want to reuse the same frame. Yes. > But the server-window variable and the proposed server-window-alist > are about having certain _buffers_ display in certain _windows_. It > is not even possible to express the "give me a new frame" preference, > because the only frame you can mention in the value is an existing > frame, and I very much doubt that "normal" users will know how to > express even a specific frame there, with the sole exception of the > selected one. So, AFAICT, to support the two varieties you described, > users will almost always need to write a function and put it into the > alist elements' SERVER-WINDOW slots, is that right? Oh, I see, there's no switch-to-buffer-new-frame, just switch-to-buffer-other-frame. So I think what happened is that "committing from Magit" needed a way the override a universal user preference of "something other than the default of server-window=nil" to go back to "server-window=nil". And then implemented it in a way that could potentially be useful for other packages, without realizing that other pieces that would make that actually useful (such as the new-frame function) weren't actually available. As I said before, had --create-frame been available, I would probably have used that. That being said, maybe adding switch-to-buffer-new-frame wouldn't be such a bad idea. > And what will > they use for the REGEXP part? are they supposed to know by heart the > names of temporary files Git and other VCSes use for editing commit > messages? Well no, Magit takes care of that, and so could VC. Other packages could also add their package-specific defaults to the alist. Users could edit these elements. Users could also express their own preferences for specific files that they want to handle differently, and whose names they are well aware of. I don't know whether anyone would want that. I am not doing it. As I said, I might have over generalized it and added a feature nobody actually uses. > My conclusion is that if we want to support the above workflows, we > need a more user-friendly feature, using which users will be able to > easily control the server's frame-creation behavior depending on some > predictably-deterministic attribute of the connection or the client. Now that we have not only --tty and --reuse-frame but also --create-frame, I personally don't need anything more. But that of course doesn't mean that I cannot imagine that others (including future me) might not want more options. It's worth considering what else could be offered. > One possibility would be to add a new protocol command telling > server.el how to create/reuse frames, and then tell users to set > $EDITOR and similar variables to invoke that command via the > emacsclient command-line arguments. Other ideas are welcome. I'm not sure what you mean by "protocol". More arguments? You mention environment variables. If I remember correctly, I did experiment with that, but ran into the problem that while it was possible to pass along additional environment variables when using "emacsclient --tty", the same was not possible when using "emacsclient --create-frame".