From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: RE: Problem with new display in buffer-menu command Date: Mon, 04 Dec 2006 14:09:35 -0600 (CST) Message-ID: <7901483.11418981165262975741.JavaMail.root@vms073.mailsrvcs.net> NNTP-Posting-Host: dough.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1165263020 30790 80.91.229.10 (4 Dec 2006 20:10:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2006 20:10:20 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 21:10:17 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by dough.gmane.org with esmtp (Exim 4.50) id 1GrK8e-0004xG-O0 for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2006 21:10:09 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GrK8e-00087E-Ih for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2006 15:10:08 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GrK8N-0007zX-5q for emacs-devel@gnu.org; Mon, 04 Dec 2006 15:09:51 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GrK8M-0007yj-31 for emacs-devel@gnu.org; Mon, 04 Dec 2006 15:09:50 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GrK8L-0007yg-W2 for emacs-devel@gnu.org; Mon, 04 Dec 2006 15:09:50 -0500 Original-Received: from [206.46.252.46] (helo=vms046pub.verizon.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GrK8K-00027D-OW; Mon, 04 Dec 2006 15:09:49 -0500 Original-Received: from vms073.mailsrvcs.net ([192.168.1.2]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0J9R00AFEMNZRJX0@vms046.mailsrvcs.net>; Mon, 04 Dec 2006 14:09:35 -0600 (CST) Original-Received: from 130.76.96.18 ([130.76.96.18]) by vms073.mailsrvcs.net (Verizon Webmail) with HTTP; Mon, 04 Dec 2006 14:09:35 -0600 (CST) X-Originating-IP: [130.76.96.18] Original-To: Richard Stallman X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:63275 Archived-At: In the buffer-menu display, long file names are now truncated (indicated by a ":"). Since the display lines are not wrapped, as well, this can result in a display looking like this: . viper-keys-new-test-c: 6 C++/lah ~/usr/local/share/emacs/22.0.91/lisp/emulation/v viper-keys-new-test-c: 6 C++/lah ~/usr/local/share/emacs/22.0.91/lisp/emulation/v %* emulation 4097 Dired by name ~/usr/local/share/emacs/22.0.91/lisp/emulation/ % lisp 39305 Dired by name ~/usr/local/share/emacs/22.0.91/lisp/ In your message, the first two file names are indented much more than the following ones. Is that true in the menu too? If so, that seems like a bug, isn't it? No, they are all lined up in the menu. It was either a bad cut-and-paste, on my part, and/or the mailer messed it up. One of the two top files ends in .h file and the other ends in .cpp, but the user cannot tell which is which from this display without first visiting one. We could omit text from the middle of the name instead of from the end. Would that be better? No Two different files with the same extension might differ only by the middle characters in their base name, which would result in the same problem. Normally, one would expect the full filename to appear when moving the mouse over the truncated filename. But, instead, the message "mouse-1: select this buffer" is always displayed, instead, which isn't helpful in this situation. That seems like a good idea. I think that we have no ability to attach different help strings to parts of a menu item, but we could attach the full file name as the help string to the whole menu item. I just realized that the above suggestion ONLY works when Emacs is running in a window manager. So, for a complete solution, perhaps the following would be a better approach. Instead of having one default display width for the Buffer column, support having a default range (or small set) of widths to pick from. When the need to truncate (with the current default width) is first determined, change the current default width to a larger one (in the default range or from the default set of widths) which is capable of displaying the full file name. Then simply re-call the logic to re-generate the display with the new current default width. If a file name length exceeds the maximum width permitted (perhaps half of the current Emacs line width might be a good choice), then truncate using the current truncate logic using the maximum width. Another alternative is to have the first suggested behavior when running in a window manager and, when not running in a window manager, revert back to using Emacs 21 behavior.