Re: w3m -> standard, lynx -> optional
On 2004-01-29, Panu Kalliokoski <pkalliok@cs.helsinki.fi> wrote:
> As a regular links and w3m user, I decided to throw in my two cents. I
> regard links as a featureful and self-contained browser for beginning to
> experienced users, whereas w3m is IMO more oriented towards power users
> and is better integrated to the rest of Unix userland.
I would like ELinks to use existing libraries and formats a little more
than it currently does, but it is better than you seem to realise
(I refer to your comment on external-viewer configuration.)
Have you any examples of how ELinks might better integrate with Unix
and cater to 'power users'?
> I use w3m a lot more than links, so my knowledge about links is inferior
> to that about w3m. Please feel free to correct me if I'm wrong.
I've used ELinks as my primary browser for a few years, and I've
even contributed a little code, so my knowledge of it is fairly
extensive, while I know relatively little about W3M. I'll proceed
to address your points.
> (1) the most important feature of w3m (for me) that is lacking for links
> hasn't, surprisingly, even been stated in this thread (at least I wasn't
> able to spot it). It is the ability of going back and forth and follow
> links without ever losing history. Many browsers work like, you can go
> back or forwards in history but if you ever follow a link your "future
> history" will be gone. In w3m, you can jump into any page you've ever
> been in during that session with "s" (as long as you don't explicitly
> throw your history away with "B").
Since version 0.3, ELinks has had forward history and an option
(document.history.keep_unhistory) to keep the forward history
('unhistory') even when one follows a link after navigating backwards
thru history. Unfortunately, this option was broken in 0.9, but maybe
we'll have it working again soon. It is an easy fix,
we just need to agree that the old behaviour was correct.
> (2) w3m can be used as a pager, which is invaluable when you test
> programs that produce HTML; you just tack "| w3m" to the end of the
> pipeline.
ELinks has a -stdin option, but it doesn't work for interactive
usage (i.e., without -dump or -source). I can file a bug report
(bugzilla.elinks.or.cz); maybe it isn't too difficult to fix.
> (3) this has also received some attention in the thread, but w3m is
> *modal* when it comes to editing form fields (you can enter / exit edit
> mode by pressing return). This is powerful and confusing to beginners,
> as is the modality of vi.
Yes, this is still To Be Done.
> (4) w3m uses metamail for opening different content-types. The most
> irritating feature for me in links is that every time I start to use it
> on some new account, I have to copy a kazillion settings from some
> earlier account. I know, most "ordinary users" have usually only one
> account they work on...
ELinks supports mailcap files since 0.4 and mime.types files since 0.9.
> (5) w3m doesn't have incremental display and isn't very
> "thread-oriented" otherwise either. Whether this is a pro or a con
> depends on where you come from.
It is a con when one wants to load a 400KB CVSweb page
from the ELinks maintainer's server over his microwave link.
> (6) the default behavior for editing textareas in links and lynx is very
> irritating. At least in lynx, you can use a proper editor for editing
> textareas. But in w3m, this is the *only* behavior supported. For me,
> that's a pro; but for most people, I expect that to be a con.
ELinks allows one to use an external editor: press F4 or ^T
while a text area is selected.
When we add modal editing, we can include an option to immediately start
an external editor when one indicates that one wishes to edit the text
in a text area; would this suffice?
> (7) links has a menu and uses dialog boxes for most everything. I hate
> this but I expect most people to like it.
'Ex-mode', for issuing a few basic commands, is in CVS, and still under
development. 0.9.0 has type-ahead searching (i.e., incremental search)
for hyperlinked text, and ELinks CVS has the same for all text. Almost
any action one can take thru the menus can be bound to a key. One still
cannot avoid menus and dialog boxes entirely, but we're working on it.
> (8) w3m's help texts are hilarious. (This is off-topic; please don't be
> offended.)
See Setup->Language->Leet. Er, wait--you said hilarious, not dumb.
How about this? |INTERNAL("Could not assing boundary");| It once was
'Counld not assing boundary', and the corrected spelling for 'could'
drops some charm, but I still love that 'assing'!
ELinks has dropped some amazing code from its venerable pops,
Links 0.96; bugzilla.elinks.or.cz has some nice pieces for its quips
file. However, you should be _glad_ that you aren't running this:
#define G_DEFAULT_BFU_BG_COLOR (getenv("USER") && (!strcasecmp(getenv("USER"), "mikulas") || !strcasecmp(getenv("USER"), "mpat7421")) ? 0xffffff : 0xdddddd)
load_url(ftl->url, fd?fd->f_data?fd->f_data->url:NULL:NULL, &ftl->stat, PRI_FRAME, cache_mode, -1);
if ((o.plain = l ? l->plain : 1) == -1) o.plain = 0;
goto i_think_i_will_soon_get_mad_from_the_programming;
...but you said 'help texts'; sorry, but I couldn't resist furthering
the digression. I hope that the Debian devels will not hate me...
> Because of this orientedness of links towards everyday users and w3m
> towards power users (as I see it), I would recommend using some version
> of links as the default text-mode browser, even though I deem w3m a
> better program overall.
When I read the original debian-devel announcement, I thought that W3M
was a reasonable choice over ELinks: ELinks has--IMHO--more haphazard
development and sees a fair share of bugs (quick as the developers are
to fix them). OTOH, I tend to run CVS snapshots of ELinks for weeks on
end with many tabs open, and W3M releases for minutes at a time with
only one tab, so I have no idea what I'm talking about.
> Yours,
> Panu Kalliokoski
-- Miciah <miciah@myrealbox.com>
Reply to: