Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs

[Vlad Harchev]

On Thu, 13 Jul 2000, Klaus Weide wrote:

> On Thu, 13 Jul 2000, Vlad Harchev wrote:
> > On Wed, 12 Jul 2000, Klaus Weide wrote:
> > > On Mon, 10 Jul 2000, Vlad Harchev wrote:
> > > > On Sun, 9 Jul 2000, Klaus Weide wrote:
> > > > > Another problem is that we haven't even defined what we are talking 
> > > > > about.
> > > > > There are many ways in which lynx can be made to send mail (already, 
> > > > > with
> > > > > its built-in code).  Try to come up with a list as an exercise, it 
> > > > > should
> > > > > have at least 5 or 6 entries... only one of which is "following a 
> > > > > link to
> > > > > a mailto: URL".
> 
> > > On the one hand, you think now your first patch isn't good because it
> > > isn't general enough, it handles only a special case: ACTIVATE on a
> > 
> >     It was not only on mailto:, but on any URL based on prefix matching.
> 
> Yes, but right now we are discussing in the context of alternatives for
> handling mail, aren't we?  (As an aside, handling some other URL types

  I thought you were going to stress the fact that "that approach is not
the most generic" so I replied this way (yes, it was offtopic then).

> like all "ftp:" via some external command makes it much *more* desirable
> to have a way to fall back to lynx's default handling.  That's why I think
> that a CERN rules based translation, which applies to *all* ways an URL
> can be entered or accesed, is less powerful in a way than an ACTIVATE-
> key-specific action.)

 I don't think so for some reason. As for getting original behaviour
conditionally, user can define EXTERNAL command that will invoke lynx with
-cfg=/some/other/cfgfile/that/does-not/force/total/redirection/of/that/url/type
commandline switch, like EXTERNAL:ftp:lynx -cfg=/dev/null %s
 
> > > mailto link.  On the other hand, it's perfectly fine with you to handle
> > > some kinds of mail sending with an external program, but not all of
> > > them?
> > 
> >    We are talking about calling MUA, not MTA - so most items in the list 
> > below 
> > should be handled as they are now.
> 
> Yippie, we are making some progress here.  As far as I remember, this is
> the first time in these discussions about hooks for mailing that someone

  You offend me.:)

> makes this distinction explicitly, for expressing the requirement.  Most
> of the previous discussion was in diffuse terms like "configuring which
> mailer to use".

  Klaus, what else you think we could be talking about in this thread? I
wonder.

> > > Realize that any of the recently discussed "solutions" don't apply
> > > to comments sent with the COMMENT ('c') key.
> >  
> >    This can be easily hacked in. 
> 
> In principle, yes.  Maybe not so easily if all the details of
> setting the default subject are to be preserved.

  May be.

> > > Realize that any of the recently discussed "solutions" don't apply
> > > to mail that is sent when a FORM with ACTION="mailto:..."; is submitted.
> > 
> >    It shouldn't be invoked, of course.
> 
> Are you sure?

  This is the same case as with "Mail this file" - user i snot expected to
type anything - so using MUA is not necessary.
 
> > > Realize that any of the recently discussed "solutions" don't apply
> > > to mail that is sent because of MAIL_SYSTEM_ERROR_LOGGING.
> > 
> >   It shouldn't.
> > 
> > > Realize that any of the recently discussed "solutions" don't apply
> > > to "Mail the file" from the "Printing Options" screen.
> > 
> >   It shouldn't, since user doesn't type the body of the message.
> >  
> > > Does this make sense?  Wouldn't a user expect that an "external
> > > mail handler" (or however it is going to be described) applies to
> > > all of those cases, too?  Or at least some?  Forgetting about those
> > > seems just as incomplete to me as limiting a mechanism to ACTIVATE only.
> > > 
> > > What is the problem you are trying to solve?  The answers depends on
> > > that.
> > 
> >   The use of MUA user asked for for going to mailto: links and (probably) 
> > for
> > sending comments.
> 
> That's a first draft for a definition of the problem, but it still needs
> some work.  What exactly is 'going to'?  Obviously you don't mean just

  I meant 'x','g','G','E' and ACTIVATE commands (probably I missed some other 
exotic comand, but unlikely).

> 'g'oto.  But you also don't meant all ways of accessing a mailto URL -
> think of FORM action.  You also don't mean 'all ways of accessing a mailto

  It seemed to me that LYSubmitForm handles this specially, without
using LYGetfile.c, did I miss something?

> URL except if the mailto URL came form a FORM action' - think of the
> case where a user invokes ELGOTO on a mailto form's submit field.
   
   MUA should be used in that case - what's the problem? I don't think that we
are going to track how the given URL came to recall list - IMO it's a bad
idea.

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

 Best regards,
  -Vlad


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