<<< Date Index >>>     <<< Thread Index >>>

Re: mutt/2185: In manual.xml, "screen" contents should not exceed



The following reply was made to PR mutt/2185; it has been noted by GNATS.

From: Vincent Lefevre <vincent@xxxxxxxxxx>
To: bug-any@xxxxxxxxxxxxx
Cc: 
Subject: Re: mutt/2185: In manual.xml, "screen" contents should not exceed
Date: Wed, 15 Feb 2006 22:41:01 +0100

 On 2006-02-15 17:35:02 +0100, Derek Martin wrote:
 >  More to the point, the bug is in lynx, not in mutt.  It is debatable
 >  whether the mutt developers should concern themselves with bugs in
 >  optional ancillary programs, especially if a fix is already available,
 >  whether or not there is an official release which contains the fix.
 
 Mutt is not just for developers, but also for users. Users shouldn't be
 affected by such a bug. And lynx is not optional to build the manual.
 
 If you do not care about lynx, why not using tables (which have been
 part of HTML since a long time) instead of <pre class=3D"screen"> (which
 is discouraged by the W3C to render tables) in the HTML version?
 
 >  FWIW, if an HTML browser is going to be what is used to format the
 >  manual text, then it might be better not to break the lines at all,
 >  and let the viewer format them appropriately, changing the formatting
 >  as necessary to compensate...  After all, not everyone runs their
 >  terminal at 80 columns, and (ideally) they should not be required to
 >  in order to get a readable manual.
 
 The problem is that .txt files can't easily be reformatted, in
 particular the parts that consist of lists of key bindings. The
 best way to get a reformatted manual is to choose the HTML format
 (or the man page format). The .txt format should probably be kept
 at 80 columns.
 
 >  HTML, and even man pages, have the advantage that they are (or at
 >  least can be) formatted to fit the user's screen, (mostly) without
 >  regard to how wide it is. For key mapping descriptions, this could
 >  be done (for example) with something like a dictionary list.
 
 Note that some of them have 3 columns, so I think that a table is the
 best solution IMHO. Otherwise your solution:
 
 >  The key binding goes in the term part, and the description goes in
 >  (fittingly enough) the description. The description would start
 >  with the name of the function bound to the key, followed by a dash
 >  or a colon, then the description of what it does. Or whatever. :)
 
 But would this be rendered in a compact form in practice?
 
 >  While I'm on the subject of the manual, I downloaded 1.5.11 the other
 >  day to run on a different machine (I didn't want to run CVS because of
 >  all the recent activity -- and bug reports -- involving the IMAP
 >  code), and I noticed that mutt seems to be looking for the manual text
 >  in /doc/mutt/manual.txt instead of the install prefix.  Presumably
 >  this was fixed in CVS since the version on my laptop works fine...
 >  But I thought I'd mention it anyway.
 
 Anyway I don't use this feature. Depending on function keys is a bad
 idea IMHO (depending on the context, they may be rebound, or may even
 be not present, like on the Zaurus PDA); but since this is just a
 matter of configuration here, this is OK.
 
 --=20
 Vincent Lef=E8vre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
 Work: CR INRIA - computer arithmetic / SPACES project at LORIA