lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN r


From: Henry Nelson
Subject: Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs
Date: Tue, 11 Jul 2000 10:19:12 +0900 (JST)

On some excellent day in the year 2000, John Smith wrote:

>   We can leave the code as is (i.e. with EXTERN_OR_ACTIVATE patch) - I don't
> mind this (since I won't use it). But I expect complains from users stating
> that 'G' then 'enter' is not equal to 'enter'.

Why was this patch even submitted, and why is it to be left in?  Are there no
criteria at all about the amount of testing and consideration of the pros and
cons that a certain hack should undergo before it is implanted?  When Eduardo
submitted his patch, it was turned down.  Is the present one so much better?
Are we now stuck with yet another half-baked function that no one is going
to take responsibility for to debug and maintain, let alone enhance?

>   Does it really matter? I think we don't have a lot to borrow from them,
> execpt some mailto: URL parsing code and code that generates subject line.
[...]
> P.S.: It's funny to see that we spent more than an hour replying to the mails
> of each other.

I thought this thread had already been talked out.  It really boggles my
mind that a patch pretty much going against the conclusion of the previous
discussion was suddenly presented before lynx-dev again.

If I'm wrong, then please correct me, but I thought what people _really_
wanted was something equivalent to the e)ditor command.  When you press
'e' on a file on local disk, your default editor is called up.  Lynx
still has it's own line editor for handling certain tasks, or if calling
up an external command like vi is not desired.

Likewise, people seemed to want a m)ailer command, a command to call up a
default mailer on mailto: URLs, perhaps even different situations.  This
would be completely separate from Lynx's present mailer interface (which
could be simplified and cleaned up) used for things like sending a page
via the P)rint menu, for example.  Lynx's present mailer is IMO ideal for
public-access use, and perhaps more important was implemented when
anonymous accounts or shell-like use of Lynx was a major consideration.

Anything short of this can really be done quite smoothly already with
the lynxcgi/pseudo-proxy or e)xternal+wrapper mechanisms.

__Henry

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]