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 ... -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/20141109192940.GC3724@lune
