From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Modernize frame-title-format: "%b - GNU Emacs" Date: Tue, 01 Sep 2020 16:31:06 -0400 Message-ID: References: > > <83y2lux5hm.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31996"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Gregory Heytings , Eli Zaretskii , Stefan Kangas , Drew Adams To: Gregory Heytings via "Emacs development discussions." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 01 22:32:07 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 1kDCwo-0008Cx-00 for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Sep 2020 22:32:06 +0200 Original-Received: from localhost ([::1]:35398 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kDCwn-0002CE-0l for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Sep 2020 16:32:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44560) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDCw2-0001kp-1X for emacs-devel@gnu.org; Tue, 01 Sep 2020 16:31:18 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19186) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kDCvy-0005It-Dn; Tue, 01 Sep 2020 16:31:17 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CF596806F7; Tue, 1 Sep 2020 16:31:11 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C9C198066B; Tue, 1 Sep 2020 16:31:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1598992268; bh=kqHBM5TxKCGYIe4RfP18qkYKmZuraxLeIcxYzhCzRi0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=FFkL6Gb3adx6edBDGkQ2tEXR4ogXcDEMpdMvd0sNJpn+67bfi4gCdEfEIm/NKEM+E JGgSn94gwAiIiq5M6ThfKX2leki1ooqDgrebCju8xnHlxLUhmfFZy/J9vF1Gakwth2 hXWxAtycy4hhTpEnOQNFyH57Mocp4JaJaGA5GrLOfFMcKat8Mzx6QjQGLKHGBajomT MEcVWsWhV2zfkGmqAybow/ZQWRTdhVaePy2dC712Fy1s4p+ifGR3pgtHSQZDueStJQ raR0VR2VG6J+2DnZcOilETPscKf4kZVUgdDCyf7LDtaViX3CA3GUzms3xXL+07a5st ZoBt7lkyEqBFA== Original-Received: from alfajor (unknown [45.72.232.131]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 319441206E3; Tue, 1 Sep 2020 16:31:08 -0400 (EDT) In-Reply-To: (Gregory Heytings via's message of "Tue, 1 Sep 2020 19:00:45 +0200 (CEST)") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/01 16:31:12 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:254477 Archived-At: > The current default behavior of Emacs (using only the filename as its buffer > names) dates from a time when users did not have many files, or at least > much less files than what we have today. So having a buffer named > "interp.lsp" or "comp.pas" was clear enough. Nowadays it is often not. That can be controlled by the uniquify-* variables, tho. I understand that you prefer something like `buffer-file-truename` over `file-name-nondirectory`, but what is less clear is whether this opinion only applies to frame titles or also to buffer names. If it also applies to buffer names, then frame titles can just use "%b" and you/we just have to change the naming scheme for buffer names (and if the existing uniquify-* vars aren't good enough for that, we can fix it). Stefan