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.devel Subject: RE: Modernize frame-title-format: "%b - GNU Emacs" Date: Tue, 1 Sep 2020 07:54:31 -0700 (PDT) Message-ID: References: <> <> <<83y2lux5hm.fsf@gnu.org>> 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="4077"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Stefan Kangas , emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 01 17:14:58 2020 Return-path: Envelope-to: ged-emacs-devel@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 1kD7zs-0000tV-Oc for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Sep 2020 17:14:56 +0200 Original-Received: from localhost ([::1]:58142 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kD7zr-0002eo-Pa for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Sep 2020 11:14:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39742) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kD7gH-0005ay-3s for emacs-devel@gnu.org; Tue, 01 Sep 2020 10:54:41 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:56190) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kD7gE-0001cS-37; Tue, 01 Sep 2020 10:54:40 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 081EnZEs099756; Tue, 1 Sep 2020 14:54:35 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=PBh2O2GYwCvZRx6xdt0ctE0WZUiUqtQPW8kHKmHScY4=; b=rmisr2uxfYBUg/fd7Gkexwn7xP2Ee9umn2vj61TMPhkcplvDWWiKBjqgCCChs3MkCSmg dT7/RuCKBOjUIgMzV1BhfmHhVjrbO6G4KpZkTHv5U4sqdHP8mGjpOjQElHOV6fJGqtUu 4JSdqSqkL3Yc6l8p7/tKfj4tRy4crjBR/cretKdMsWuaWBEgY3hS04gu6MkI8A/Vu5yg rRsXrYdTJdgT4wUgHJnFYGHjGoYrZrcTgjIaB8Nvjg1tiSkqIdAuK6tm40QkKK1aDyKo otBMkRlOUoQUxYjSO4NpKxNLRpqlszdnrzOHbN4zBbhxBzMXyO2cA9ZmJicRm8OPzjEz 1w== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 339dmmu9jg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 01 Sep 2020 14:54:35 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 081EpBHL193323; Tue, 1 Sep 2020 14:54:35 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 3380knawf1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 01 Sep 2020 14:54:34 +0000 Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 081EsXgn009719; Tue, 1 Sep 2020 14:54:33 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5044.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9730 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 adultscore=0 mlxscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009010125 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9730 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 phishscore=0 mlxlogscore=999 adultscore=0 impostorscore=0 mlxscore=0 suspectscore=0 spamscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009010125 Received-SPF: pass client-ip=156.151.31.85; envelope-from=drew.adams@oracle.com; helo=userp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/01 10:54:36 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254472 Archived-At: > >> In Visual Studio and XCode, the path of the file is displayed just > >> above the "buffer". In Eclipse, it is displayed in the title bar. > >> And that information is displayed in its "natural" order, with the > >> current filename on the right. > > > > Is that a good argument for the default Emacs > > behavior? What's a good argument for this order, > > without recourse to whether others use it? >=20 > If many (if not all) of the most popular code editors do something, and > Emacs wants to do (or in this case, to continue to do) something else, th= e > onus of the proof is on Emacs to justify that its own default behavior is > better. (The bias of that sentence is that Emacs is primarily a code > editor, which is true for me, but not necessarily for everyone.) There's no need for Emacs to justify its behavior wrt other editors or any other programs, to anyone. Emacs users and developers can decide what Emacs behavior should be, including default behavior. Again: What's a good argument on its own merits, without recourse to an argument from authority? ("Everybody else does it!") Everyone in Texas might have 42 guns and attend church twice every Sunday. That's not a reason why everyone in Switzerland should act the same. > The current default behavior (using only the file name for %b, and in cas= e > of conflict uniquifying the names with uniquify-buffer-name-style set to > post-forward-angle-brackets) was introduced in Emacs 24.4. It's already > much better than the previous default behavior (uniquify-buffer-name-styl= e > set to nil, with which buffer names are uniquified with numbers), but IMO > still far from optimal. "Optimal" is perhaps in the eye of the beholder. And it might not necessarily apply to _default_ behavior. And popularity outside Emacs does not "optimal" make. You'll need a real argument, not just popularity, as to why you think the behavior is not "optimal" or, more appropriately, is not a good default. > (This discussion has now diverged from the original purpose of this > thread, which was to "modernize frame-title-format".) I don't think it has. Except that now we're talking about "optimal" behavior and comparing Emacs with other code editors. Yes, those things diverge from the question of what to use for the `frame-title-format' default. I agree that that's an unproductive route. > >> (Likewise, it is almost standard to display the current working > >> directory in full in shell prompts.) > > > > I don't see how that's relevant here. >=20 > The equivalent of the Emacs current default behavior would be to print, i= n > the prompt, only the basename of the current working directory instead of > the current working directory in full. Such a prompt is not a frame title. That's the irrelevance. Unless, as I mentioned, it's a frame whose selected window has a `*shell*' buffer, or similar. There is likely no single `frame-title-format' that is "optimal" for all uses of a frame. The question is about the default format. I don't think that most Emacs frames, for most users most of the time, are like CLI windows. Do you? > > Isn't that what we'd want for default behavior: minimal text that > > distinguishes and identifies the current set of frames? >=20 > You apparently assume that "minimal" is better, presumably because > "minimal" means "less to read" and therefore "less mental charge". Minimal for distinguishing. And actually, I suggested that we could reasonably include a lot _more_ in the default frame title. > I do not think this is the case. Understanding a uniquified buffer name = with > only a part of the directory placed after the file name between angle > brackets requires (at least for me) much more effort than understanding > `buffer-file-truename'. The former is, BTW, much less predictable, as it > changes when you open and close files/buffers. Yes, it can change when the editing context changes, including the set of buffers you're using. Whether that's a feature or a problem is arguable. IMO, it's good, not bad, default behavior. > The fact that most code > editors chose to use the latter is, at least for me, > an indication that it is in general easier to understand, > and it is indeed, at least for me, easier to understand. Fortunately, you can easily change `frame-title-format' to fit your preferences. As can I. > Say, you open /home/drew/.emacs and /home/drew/foo/bar/.emacs. When you > open the first one you have a buffer ".emacs". When you open the second > one you now have a buffer ".emacs" and another one ".emacs". > If you now close the first one you have again a buffer ".emacs", but it's > not the same one as the ".emacs" you initially opened! See above. You're repeating, out of order, what you said earlier. Whether the confusion you point to is generally (i.e., for default behavior) worth the benefit of not repeating the same long dirs in multiple frames (which is the much more typical case - see my previous mail), is an open question. Clearly we disagree about the answer. > Likewise when you open /home/drew/.emacs, then /ssh:drew@...:.emacs, then > close the first one. You have a buffer ".emacs", then two buffers > ".emacs<>" and ".emacs" (what's this ".emacs<>"?), then > again single a buffer ".emacs" (the remote one!). >=20 > And so forth. Same point. See above.