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

Re: Re: Please review changed man-file of w3m



Hello Justin,

Justin B Rye schrieb am 31. Oct 2014 um 23:12

> I'm re-merging some frayed threads here, skimming through and just
> answering the parts that still seem to be relevant.
> 
> >> (I've never quite understood how this is useful without -N; the only
> >> way I know of skipping between arguments is via the history function.
> >> Am I missing something?  Maybe it's an emacsism?)

> > I regard the stack of buffers as useful. It is an emacsism. You
> > get the buffers listed with s and select one with arrow-up or
> > arrow-down and return.l
 
> Is that when you run w3m out of Emacs?  Not being an Emacs user I'd
> never tried that.  But now I notice that the default w3m config lets
> you skip backwards in the bufferlist with "delete" - I'd reassigned
> that keymapping years ago when w3m acquired tabbed-browsing.


  
> >> And maybe *all* of these "user defined" options should say what the
> >> default is - or just say "see FILES".
 
> > I tend to mention files containing user data with the default
> > information, i.e. to mention ~/.w3m/bookmark.html here. In contrast,
> > the section FILES would only contain configuration files.
 
> The bookmarks file lives in the config directory, so I would say
> FILES is entitled to mention them.

w3m/bookmark.html is again listed within FILES

 
> >>>        -cols N
> >>>         combined  with -dump, HTML input is rendered to lines of N char-
> >>>         acters length
> >>
> >> This probably shouldn't say "input", and it's also true for output
> >> into a pipe even without -dump.
> >>
> >>    -cols N
> >>        for rendered HTML output to a pipe or via -dump, use line
> >>        widths of N characters
> > 
> > I used input because this means html code from all sources.
> 
> Yes, but the trouble is that "input" tends to mean only particular
> sources.
> 
> > As far as
> > I can see output into a pipe only works in combination with one of the
> > dump options.
> 
> I'm not sure I follow.  For me, "w3m $URL | head" looks different
> from "w3m -cols 5 $URL | head" even without a -dump option.
> 
> > My problem wie "HTML output": I regard it as plain text output.
> 
> True: it should say something like "rendered output".  In fact it even
> strips some of the rendering (colours, for instance).
> 
> > -cols
> > acts on the HTML block element <p>, it is part of the rendering.
> 
> It acts on any element for which the renderer needs to know the width
> of the terminal.
> 
> > -cols
> > combined with -dump_source has no effec.t
> 
> True - another reason for saying it affects "rendered output".

Explanation of option -cols has been modified

  
> >>    TMPDIR
> >>    WWW_HOME
> >>    etc
> >> I don't know if many of them are worth mentioning, but WWW_HOME makes
> >> a major difference to the program's usefulness.
 
> > Just mentioning these variable would be ok. But I fear the effort of
> > analysing their dependencies to other configuration approaches: Why
> > does w3m invoke mutt as mail user agent instead of mailx although
> > there is no trace of it in .w3m/config?
 
> In my case W3M doesn't seem to launch mutt for "mailto:"; links,
> which is okay since I don't want to send mail out of my web browser
> anyway.  I don't see any mention of mutt in the upstream or Debian
> sources...

I only saw w3m start mutt once. I was presumably due to an explicit
entry of mutt in the configuration panel. Presently, an mailto-URL
makes W3M use the internal mailer.


> [-------------------------------suture-------------------------------]
> 
> In the options table runthrough:
> 
[...]
> >> | -cols		int	no	yes	no	yes	no	no	no	---	yes
> >> 
> >> The one that's like setting $COLUMNS for rendered output to STDOUT.
> > 
> > You wrote to export such variables. A necessary hint because first, I
> > only defined only within xterm. After exporting, WWW_HOME was effective
> > as you described. 
> 
> It's also possible to define them just for a single command:
>  WWW_HOME=example.org w3m

Thanks for this bash usage information.  

[...]
  
> [-------------------------------suture-------------------------------]
> > My plain text dump of the man-page draft, created with 
> > 
> >   groff -Tascii -man file.1 > file.1.txt 
> > 
> > apparently contains this markup constructions but I neved noticed it. 
> > 
> > use of	 in xterm   	 in tty
> > less -r  bold/underlined bold/cyan
> > less -R  bold/underlined bold/cyan
> > less -u  no markup	 nomarkup
> > less -U	 N^HN 		 N^HN
> 
> (For some reason I long ago forgot, my default pager is "most", which
> I've got configured to show bold as blue and italics as red.)
> 
> > w3m  	 bold/cyan	 bold/cyan
> 
> That's odd - I get that on a TTY, but in an xterm I only see bold and
> underline, no cyan.
> 
> > w3m -r	 N^HN		 N^HN
> > emacs 	 N^HN		 N^HN
> > nano 	 N^HN		 N^HN
> > 
> > With this experience, I would replace
> > 
> >  -r ignore underline or bolding markup constructions that use
> >     backspace (e.g. in nroff)
> > 
> > with
> > 
> >  -r display markup constructions with backspace characters verbatim
> >     (default is to vary font, e.g. printing bold or underlined)
> 
> You're right, I hadn't noticed W3M does this "backwards".  "Verbatim"
> is a bit confusing - which is more verbatim, "^H" or a literal
> backspace-and-doublestrike? - so maybe we should copy less's phrasing
> more directly:
>
>    -r use caret notation to display backspace characters in nroff-style
>       markup (default is to vary font, e.g. printing bold or underlined)
> 
> Oh, wait, another test shows me that w3m supports ANSI colour escapes
> too, and again -r converts the special characters into caret notation
> (in this case ESCAPE to "^[").
> 
>    -r use caret notation to display special escape characters in text
>       (such as ANSI escapes or nroff-style backspaces) instead of
>       processing them as colored or otherwise highlighted text.

Explanation is quite close to Yours now.


> [...]
> > 3. I forgot to introduce a section ENVIRONMENT VARIABLES 
> > 
> > WWW_HOME is certainly worth being mentioned. What else?
> 
> I don't know if there are any others that matter.  Mind you, with all
> the surprises I've found when I doublecheck how w3m behaves, I begin
> to daydream that setting CENTURY=21 might deactivate Gopher support in
> favour of CSS3.

:-)

To be continued ...


Reply to: