A not quite stylish proposal for command line processing

A not quite stylish proposal for command line processing

[David Kastrup]

How about
(defun *argv++ nil (pop command-line-args-left))
?

It would allow to write

emacs --eval '(ediff-files (*argv++) (*argv++))' "$FILE1" "$FILE2"

instead of the much more tedious explicit variant.  Note that

emacs --eval "(ediff-files \"$FILE1\" \"$FILE2\")"

is _not_ equivalent since it requires $FILE1 to be properly quoted for
appearing inside of a Lisp string.

Somewhat more Lispish would be
(defvaralias 'argv 'command-line-args-left)
which would at least permit
emacs --eval '(ediff-files (pop argv) (pop argv))' "$FILE1" "$FILE2"

And it is more likely to be found by programmers using "apropos".  And
is actually only one character longer than the *argv++ cuteness.

Comments?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A not quite stylish proposal for command line processing

[Richard Stallman]

    It would allow to write

    emacs --eval '(ediff-files (*argv++) (*argv++))' "$FILE1" "$FILE2"

It is a cute hack, but does anyone really want to use this?

Re: A not quite stylish proposal for command line processing

[Lennart Borgman (gmail)]

Richard Stallman wrote:
>     It would allow to write
> 
>     emacs --eval '(ediff-files (*argv++) (*argv++))' "$FILE1" "$FILE2"
> 
> It is a cute hack, but does anyone really want to use this?


Maybe on w32, but I prefer using emacsclient for this. The command file 
below handles this:

c:\u\ediff.CMD
****** Contents: *******
@rem Put this file (ediff.cmd) in your PATH.
@rem (Created by Setup Helper at Tue Apr 03 20:48:56 2007)
@rem -----------------------------
@rem Starts Emacs ediff (through gnuserv) from command line.
@rem Takes the two file to compare as parameters.
@setlocal
@set f1=%1
@set f2=%2
@set f1=%f1:\=/%
@set f2=%f2:\=/%
@set emacs_cd=%CD:\=/%
@set emacs_client="c:\emacs\p\070403\emacs\bin\emacsclient.exe"
@%emacs_client% -n
@%emacs_client% -e "(setq default-directory \"%emacs_cd%\")"
@%emacs_client% -n  -e "(ediff-files \"%f1%\" \"%f2%\")"

Re: A not quite stylish proposal for command line processing

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     It would allow to write
>
>     emacs --eval '(ediff-files (*argv++) (*argv++))' "$FILE1" "$FILE2"
>
> It is a cute hack, but does anyone really want to use this?

The problem is that the equivalent (pop command-line-args-left) is the
only way to pass strings from the shell or elsewhere without having to
requote them as Lisp strings.  (*argv++) might be quite over the top,
but at least (pop argv) would still be quite concise, much more
Lispish, and it might make it easier for people to actually find the
respective variable.

On a different tack, currently emacsclient behaves different when
parsing --eval and command line arguments and does not support
command-line-args-left.  I am currently fixing this in server.el.
Making emacsclient mimic the normal Emacs commandline more closely
makes it easier to substitute one for the other.

It may be somewhat pointless in checking this in before the multi-tty
merge, but at least I hope to be able to provide a patch for
discussion.

-- 
David Kastrup

Re: A not quite stylish proposal for command line processing

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Richard Stallman wrote:
>>     It would allow to write
>>
>>     emacs --eval '(ediff-files (*argv++) (*argv++))' "$FILE1" "$FILE2"
>>
>> It is a cute hack, but does anyone really want to use this?
>
>
> Maybe on w32, but I prefer using emacsclient for this.

emacsclient does not help here.  And the below assumes that you can
flip backslashes without changing their meaning.  Not likely to be
true for regexps or similar.  Getting them and other strings and
special characters unmolested into Emacs using portable shell scripts
is actually a royal nuisance without using command-line-args-left.

> The command file below handles this:
>
> c:\u\ediff.CMD
> ****** Contents: *******
> @rem Put this file (ediff.cmd) in your PATH.
> @rem (Created by Setup Helper at Tue Apr 03 20:48:56 2007)
> @rem -----------------------------
> @rem Starts Emacs ediff (through gnuserv) from command line.
> @rem Takes the two file to compare as parameters.
> @setlocal
> @set f1=%1
> @set f2=%2
> @set f1=%f1:\=/%
> @set f2=%f2:\=/%
> @set emacs_cd=%CD:\=/%
> @set emacs_client="c:\emacs\p\070403\emacs\bin\emacsclient.exe"
> @%emacs_client% -n
> @%emacs_client% -e "(setq default-directory \"%emacs_cd%\")"
> @%emacs_client% -n  -e "(ediff-files \"%f1%\" \"%f2%\")"

-- 
David Kastrup

Re: A not quite stylish proposal for command line processing

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Richard Stallman wrote:
>>>     It would allow to write
>>>
>>>     emacs --eval '(ediff-files (*argv++) (*argv++))' "$FILE1" "$FILE2"
>>>
>>> It is a cute hack, but does anyone really want to use this?
>>
>> Maybe on w32, but I prefer using emacsclient for this.
> 
> emacsclient does not help here.  And the below assumes that you can
> flip backslashes without changing their meaning.  Not likely to be
> true for regexps or similar.  Getting them and other strings and
> special characters unmolested into Emacs using portable shell scripts
> is actually a royal nuisance without using command-line-args-left.


Yes, you are right. Your idea with command-line-args-left and argument 
handling in emacsclient that are more like those of emacs is the right 
way to go.

Re: A not quite stylish proposal for command line processing

[Richard Stallman]

    The problem is that the equivalent (pop command-line-args-left) is the
    only way to pass strings from the shell or elsewhere without having to
    requote them as Lisp strings.  (*argv++) might be quite over the top,
    but at least (pop argv) would still be quite concise, much more
    Lispish, and it might make it easier for people to actually find the
    respective variable.

It is a fine method of doing this.  If people really want to do this,
then let's install some such thing.

However, I am not sure that the name `argv' is useful now
that even most hackers are not C programmers.  Does any other
language use the name `argv'?

Re: A not quite stylish proposal for command line processing

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     The problem is that the equivalent (pop command-line-args-left) is the
>     only way to pass strings from the shell or elsewhere without having to
>     requote them as Lisp strings.  (*argv++) might be quite over the top,
>     but at least (pop argv) would still be quite concise, much more
>     Lispish, and it might make it easier for people to actually find the
>     respective variable.
>
> It is a fine method of doing this.  If people really want to do this,
> then let's install some such thing.
>
> However, I am not sure that the name `argv' is useful now
> that even most hackers are not C programmers.  Does any other
> language use the name `argv'?

Perl has @ARGV, awk has ARGV, Python has sys.argv, bash has $@ (well,
you can't always win), Ruby has ARGV, lua has arg, Java has args[]...

The v in argv has not survived into all script languages (though quite
better than argc), but it makes the variable name safer against
accidental reuse in our flat Lisp namespace.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: A not quite stylish proposal for command line processing

[Richard Stallman]

    Perl has @ARGV, awk has ARGV, Python has sys.argv, bash has $@ (well,
    you can't always win), Ruby has ARGV, lua has arg, Java has args[]...

Ok, we can have argv too.