[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FAQ.html and MANUAL.html, was Re: fwd: Re: Re: Please review changed man-file of w3m



markus.hiereth@freenet.de wrote:
>> Okay, revised FAQ.html attached.  I also have a revised and
>> re-HTMLified MANUAL.html, but it still has a few points I'm not sure
>> about.  Going through the original in rendered form:
> 
> I wonder whether I am able to support You. I suppose the technical
> questions were answered when we had been working on the manual
> page. And I am not the one to judge English language and
> style.

Well, I'm posting to d-l-e on the grounds that theoretically somebody
else might help (and to make sure that if I'm hit by a metaphorical
bus tomorroe then my efforts will still be publicly accessible).
 
> Though, I am able to indicate phrases where the documentation fails to
> explain something. One of the foremost motivations for revising at
> least the selected three files in the doc-directory was all the
> redundancy. E.g. in MANUAL.html, "visual startup mode" as explanation
> for option -v survived.
> 
> >>From my point of view, by the use of links and references, whole
> sections of MANUAL.html could be dropped. I am just afraid that
> changes of this depth are as well beyond the business of a language
> team as the are not within the scope of Debian and Tatsuya as package
> maintainer.

The trouble is, upstream are more likely to see MANUAL.html as the
primary repository of all knowledge about w3m; after all, unlike the
man page it's there on the project home page.  In an ideal world we'd
be able to unify the two manuals to simplify maintenance.

[...]
> I would prefer a reference to manual page than providing the
> explanantions to w3m's option a second time.

I'll need to at least go through the whole file again looking for
phrasings that can be imported from the man page.  I might also try to
fix some of the structural problems.

[...]

Meanwhile, to carry on in "mumbling to myself about things that still
need fixing" mode:

>>> Lynx-like key binding
[...]
>>> C-g              Show current page position
>> 
>> As above, with the addition of hyphenation for "(direction)-arrow".
>> And wait, that last one: is "Show current page position" the same
>> thing as "Show current line number" (non-Lynx-like "C-g")?

I should have just looked this up in the example keymap files.  Yes,
they're both "C-g LINE_INFO", and it does more than just show the line
number (which makes it sound like a "toggle -n mode" button).

And we really might as well abbreviate all the ESC-foo codes as M-foo,
since apparently that always works.

I've gone through keymap.default ticking off the ones that are
explained in MANUAL.html; there are a couple of dozen left over.  For
a start the docs fail to mention that there are good sensible bindings
for things like HOME, PGUP etc - it mentions the alternate Lynxlike
arrow-key bindings, but not the default ones.

Undocumented default keymappings, most of which could go in a new
"Tabbed Browsing" section:

 keymap	C-q	CLOSE_TAB
 keymap	C-t	TAB_LINK
 keymap	(	UNDO
 keymap	)	REDO
 keymap	";"	MARK_WORD
 keymap	D	DOWNLOAD_LIST
 keymap	L	LIST
 keymap	T	NEW_TAB
 keymap	m	MOUSE_TOGGLE
 keymap	r	VERSION
 keymap	{	PREV_TAB
 keymap	|	PIPE_BUF
 keymap	}	NEXT_TAB
 keymap	M-W	DICT_WORD_AT
 keymap	M-c	COMMAND
 keymap	M-k	DEFINE_KEY
 keymap	M-l	LIST_MENU
 keymap	M-m	MOVE_LIST_MENU
 keymap	M-o	SET_OPTION
 keymap	M-t	TAB_MENU
 keymap	M-u	GOTO_RELATIVE
 keymap	M-v	PREV_PAGE
 keymap	M-w	DICT_WORD
 keymap	M-[2~	MENU

That last one is INS; but then there are four more mapped to keys that
don't seem to exist on my system:

 keymap	M-[28~	MENU		# meant to be F5?
 keymap	M-[E	MENU		# meant to be F5?
 keymap	M-[L	MENU		# conceivably ditto?
 keymap	M-[Z	PREV_LINK	# mythical BACKTAB/shift-TAB

b = PREV_PAGE, B = BACK ("Back to the previous buffer"); what _is_ the
difference exactly?

Yes, / and ? are SEARCH and SEARCH_BACK, but C-s and C-r aren't the
same, they're ISEARCH and ISEARCH_BACK.

C-c isn't actually defined as a keymapping; presumably w3m just
catches the SIGINT.  So it may in fact not be possible to redefine it.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: