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