[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs script options
|
From: |
Greg Minshall |
|
Subject: |
Re: Emacs script options |
|
Date: |
Sat, 18 Nov 2023 06:38:24 -0800 |
Eli Zaretskii <eliz@gnu.org> wrote:
> But if we change that, how can we pass additional options to Emacs
> when invoking it from a script? That is also an important capability,
> and replacing it with what you want seems to be an incompatible
> change, which takes away a capability we have now.
>
> If we want to be able to pass options to the script itself, we need to
> do it in a compatible way, that doesn't lose what we have now.
>
> In any case, could you please show a real-life case where this is
> needed? The -x option was intended to support the use cases where the
> rest of the script is Emacs Lisp code, so what would such a script do
> with an option that is not interpreted by Emacs, and why is that
> needed?
this last point is maybe all i can answer now (your other points are
food for thought, and code-staring). the idea is a generalized facility
that allows script-writers to do whatever they want, define whatever
options they want.
plus, trying to stay out of the way of even current, let alone future,
Emacs options is tricky; realistically, script-writers would need to
require their users to always type double-dashes, e.g.,
----
ls-emacs -- -F
----
which doesn't seem so user-friendly.
in my case, for example, i want to write an Emacs script that has some
familiar options like "-d", "-V", etc., in addition to options to
specify how the script should run (what input files to process, output
files to produce, alterations to behavior).
i could have users do that in an Emacs'y way ('--eval (setq debug 1)').
but, the idea is to provide something that, to the end user, looks like
a standard Unix'y script. if that makes any sense.
cheers, Greg
Re: Emacs script options, Greg Minshall, 2023/11/26
Re: Emacs script options, Sebastian Miele, 2023/11/18