From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Daniel Pfeiffer Newsgroups: gmane.emacs.devel Subject: Re: buff-menu.el changes Date: Tue, 17 Dec 2002 00:00:15 +0100 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20021217000015.50ec6208.occitan@esperanto.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1040079760 16877 80.91.224.249 (16 Dec 2002 23:02:40 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 16 Dec 2002 23:02:40 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18O4Fw-0004Nn-00 for ; Tue, 17 Dec 2002 00:02:36 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18O4Tc-0007dA-00 for ; Tue, 17 Dec 2002 00:16:44 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18O4EU-0000uM-00 for emacs-devel@quimby.gnus.org; Mon, 16 Dec 2002 18:01:06 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18O4E5-0000u5-00 for emacs-devel@gnu.org; Mon, 16 Dec 2002 18:00:41 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18O4E3-0000tf-00 for emacs-devel@gnu.org; Mon, 16 Dec 2002 18:00:41 -0500 Original-Received: from mailout03.sul.t-online.com ([194.25.134.81]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18O4E2-0000tB-00 for emacs-devel@gnu.org; Mon, 16 Dec 2002 18:00:39 -0500 Original-Received: from fwd09.sul.t-online.de by mailout03.sul.t-online.com with smtp id 18O4Dz-000612-09; Tue, 17 Dec 2002 00:00:35 +0100 Original-Received: from pfdabpc.inhouse.start.de (520007185214-0001@[80.128.217.168]) by fmrl09.sul.t-online.com with smtp id 18O4Dy-0Equn2C; Tue, 17 Dec 2002 00:00:34 +0100 Original-To: bob@rattlesnake.com In-Reply-To: X-Mailer: Sylpheed version 0.8.1claws (GTK+ 1.2.10; ) X-Operating-System: GNU/Linux of course X-Face: #O4jYYB1q_#GM@+5bpI17zYh*qp]@lt"%.HQGbezyU>Cm@cp>rdE97{c:@). kR3O3H&LeNb(Q\/E^f{g|i~#u\4!\lJ"jR; Cx&[\,\xjKcLei-_1\d&TAm\E3&(c|>cQIoik]V8Vdf Qs)St&=rh'+N6/WxXf.VfUnD[<; 9{#[ZWC>]FP$xVRgTLssqs)7nQ'sH@l[9b5oo1@llkNJPx;&H(^ o~/ X-Sender: 520007185214-0001@t-dialin.net Original-cc: Juanma Barranquero X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:10183 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:10183 "Robert J. Chassell" skribis: > Today's CVS snapshot, Mon, 2002 Dec 16 18:58 UTC > GNU Emacs 21.3.50.23 (i686-pc-linux-gnu, X toolkit) > > Changes were made in lisp/buff-menu.el > > * First, when Buffer-menu-use-header-line is nil it is impossible to > move to the next line using the next-line (C-n) command when point > is on the `C' of CRM, which is the first character of the first > line of a buffer. next-line (C-n) works for me, even with 21.2 -q. It simply skips the intangible line. > Instead, you must use forward-char (C-f) to go to the next line. Being able to move over intangible text charwise but not linewise sounds counterintuitive and would seem a 21.3 bug. Also a bug is being able to go before the C. I even tried (in 21.2) to add another intangible space before the C and to narrow it away. Even then I could go before the C, i.e. between two chars with the same ingtangible value. > Obviously, the intent is that no one go to that first character in > the buffer. However, for whatever reason, I find myself there > frequently, so this decreases the value of the user interface. > > The problem can be solved by commenting out the line > > (put-text-property 1 (point) 'intangible t) > > in the function definition for list-buffers-noselect > > Please either remove that line or, if you think that some people > will like the feature, make it a variable that leaves the user > free to move by default using the standard command. Actually I made the two styles of header optional because Info does it that way. But I can't see who would not want to use the much neater new format. It would make the code simpler to use only the new-style fixed header. > * Second, the addition of the `C' to the existing `RM' is consistent > logically, since it must mean `current', but it is not needed and > makes the headline look `heavy'. > > Th new heading format with the `C' is hard coded into > list-buffers-noselect. I don't like columns with stuff in them but without a header, but feel free to make it optional. > Please either revert the hard coding > or make the format of a header line be a variable, such as > > Buffer-menu-header-line-format > > In any event, please place the second line of the header, the > underlines, close to the value for the first line of the header. > As written, the first line of the header is in the let statement, > but the second line of the header is in the body of the defun. > This separation of the two header lines not only makes the defun > hard to maintain, but is ugly. That's because of the two different kinds of header line as I mentioned above. If I insert it, I left it at the beginning, where it used to be done. But when I set it in the new variable, it must be done at the end, because local variables get cleared. > Please define the second line of the header as the second line of > the Buffer-menu-header-line-format variable. I don't like columns with stuff in them but without a header, but feel free to make it optional. > * Third, the default width for Buffer-menu-buffer+size-width is 21, > but I find that 24 makes a better default. > > Similarly, the default width for Buffer-menu-buffer+size-width is > 11, but I find that 16 makes a better default. I stuck to the old widths designed for 80 columns. Of course I added the clipping because everything was so cluttered and columns so irregular as to make the whole thing useless. The change is trivial, feel free to do it. > * Fourth, when Buffer-menu-use-header-line is t, the `CRM' > characters in the header line do not line up above their > respective `Current', `Read-only', and `Modified' columns. > > In a plain vanilla GNU Emacs, started with `-q', the `M' is over > the . that indicates the current buffer. > > Please fix this, since this makes a plain vanilla instance of > Emacs look ugly and ill designed. My columns were designed to align nicely. Do different Emacsen have different widths of the gray continuation-line indicator columns? Mine are 1 space wide, even with -q. Please correct it, as I don't know how this works. coralament / best Grötens / liebe Grüße / best regards / elkorajn salutojn Daniel Pfeiffer -- GPL 3: take the wind out of Palladium's sails! -- ------ -- My other stuff here too, sawfish, make.pl...: -- ------ -- http://dapfy.bei.t-online.de/ --