[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On Fri, Sep 19, 2003 at 12:15:54PM -0400, Stefan Monnier wrote:
> > Because of this behavior, I can't use the following:
> > emacs -f w3m http://some.news.site/daily-news.html&
The only way this bug report makes sense to me is if w3m was already special
casing for command-line arguments, i.e., if it had code like this:
(defun w3m (&optional url ...)
(when (null url)
...try to get command-line args...))
> That was not intended.
> I'm not sure how best to get both behaviors.
> What do people think of a patch like the one below ?
> + (condition-case nil
> + (funcall tem)
> + ((invalid-function wrong-number-of-arguments)
> + (command-execute tem))))
> ((member argi '("-eval" "-execute"))
> (eval (read (or argval (pop command-line-args-left)))))
That's sort of convoluted, and likely to cause confusion (because different
functions will be called in different ways for not-very-obvious reasons). It
seems much preferable for command-line functions to be called one consistent
way, either interactively or non-interactively -- and certainly in the
majority of cases, interactive would make sense (for the same reason that you
wanted it for gdb).
A function like w3m that (if I presume correctly) special-cases command
line arguments, if it use code in its interactive spec (instead of a string),
it could just add the special case to the interactive spec code. If it uses
a string interactive spec, I'm not sure; it could change to using code, or I
suppose `interactive' could add a special directive that says `if called from
the command line, try to read arguments from there too.' Since I suspect
hardly any functions try to do this, though, probably it's OK to just convert
to using a code-form interactive spec.
Saa, shall we dance? (from a dance-class advertisement)