From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Robert J. Chassell" Newsgroups: gmane.emacs.devel Subject: Re: [jidanni@deadspam.com: modeline doesn't divulge buffer will go bye bye] Date: Thu, 20 Jun 2002 15:55:32 +0000 (UTC) Sender: emacs-devel-admin@gnu.org Message-ID: References: <200206201435.g5KEZLF18772@aztec.santafe.edu> Reply-To: bob@rattlesnake.com NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1024588831 29967 127.0.0.1 (20 Jun 2002 16:00:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 20 Jun 2002 16:00:31 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17L4MJ-0007nE-00 for ; Thu, 20 Jun 2002 18:00:31 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17L4o3-0001WW-00 for ; Thu, 20 Jun 2002 18:29:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17L4M7-0002SX-00; Thu, 20 Jun 2002 12:00:19 -0400 Original-Received: from megalith.rattlesnake.com ([140.186.114.245] helo=localhost) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17L4HW-0001wx-00 for ; Thu, 20 Jun 2002 11:55:35 -0400 Original-Received: by rattlesnake.com via sendmail from stdin id (Debian Smail3.2.0.114) Thu, 20 Jun 2002 15:55:32 +0000 (UTC) Original-To: emacs-devel@gnu.org In-Reply-To: <200206201435.g5KEZLF18772@aztec.santafe.edu> (message from Richard Stallman on Thu, 20 Jun 2002 08:35:21 -0600 (MDT)) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5018 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5018 What do you think of this idea? After using this ~20 years it dawns on me: The modeline of a buffer with an associated file and that with no associated file look the same. Bad. ... The most important thing, the fact that this buffer will go bye bye without a trace is not mentioned there! Interesting point! I am not sure that this information would be useful to me personally. However, it is clear that this information would be useful in general as a way of teaching people that buffers and the files are different. My impression is that many novices fail to make this distinction. Their mental model is wrong. Perhaps we could insert a dot in a space to the left of the `mode-line-frame-identification' segment of a mode line if the buffer is visiting a file, and replace that glyph with a blank space if the buffer is not associated with a file. I pick `dot' as the visible glyph since it is small, unobtrusive, and should not make the mode-line appear too cramped. Thus, in an X windowing environment, mode lines for an Emacs started with emacs -q --no-site-file --eval '(blink-cursor-mode 0)' would look like this: --:-- *scratch (Lisp Interaction) L1 All -J:--. .emacs (Emacs-Lisp) L1 Top --:-- *mail* (Mail) L1 All In a character-only terminal, the mode lines would look like this: --1-:-- -F2 *scratch (Lisp Interaction) L5 All --1J:--.-F2 .emacs (Emacs-Lisp) L1 Top --1-:-- -F1 *mail* (Mail) L1 All Currently, the default value of the `mode-line-frame-identification' is `" "' if you are using a window system which can show multiple frames, or `"-%F "' on an ordinary terminal which shows only one frame at a time. Perhaps the `-' in `-%F ' should be removed and replaced with a blank space if we put a dot or space in a column before. -- Robert J. Chassell bob@rattlesnake.com Rattlesnake Enterprises http://www.rattlesnake.com