(unknown)

(unknown)

[Greg Minshall]

hi.  i would like to be able to write Emacs scripts ("#!...") that allow
a user to enter almost any option to the script itself, *without* having
to use double dashes ("--") to avoid colliding with Emacs option
processing.

looking at "--script" and "-x", this doesn't seem possible.

as a test case, given a simple script foo.sh (*), using "-x", and
invoking it with an option "--eval" gives this error:

----
% ./foo.sh --eval
emacs: Option '--eval' requires an argument
----

(that bare "--eval" *should* be an error if it were meant for Emacs
itself; however, it is meant for the Emacs script, which may have other
ideas of the syntax/semantics of "--eval".)

the below patch to src/emacs.c (**) treats a "-x" (and its "partner"
"-scripteval") like a "--" on the command line, and *seems* to allow
arbitrary options on the command line.  for example, with this patch
installed:

----
% ./foo.sh --eval
command-line-args-left (--eval)
----


i wonder if this might be of use for Emacs?  if there are worries about
backwards compatibility with "-x", well ... "-y" anybody?  :)

(i was thinking of writing a test to go with the patch, but the ERT
framework is maybe a bit awkward for tests of essentially
shell-command-line functionality.  i may have missed it, but i didn't
see anything in ./test/Makefile.in that seemed to be aimed at testing
command-line invocation of Emacs.)

cheers, Greg


(*) foo.sh
----
#!/usr/bin/env -S emacs -x

(message "command-line-args-left %s" command-line-args-left)

1
----


(**) proposed patch
----
diff --git a/src/emacs.c b/src/emacs.c
index 6101ed4004c..6e140177086 100644
--- a/src/emacs.c
+++ b/src/emacs.c
@@ -2795,9 +2795,10 @@ sort_args (int argc, char **argv)
        {
          int match;

-         /* If we have found "--", don't consider
-            any more arguments as options.  */
-         if (argv[from][1] == '-' && argv[from][2] == 0)
+         /* If we have found "--", or a "-x", don't consider any more
+            arguments as options.  */
+         if ((((argv[from][1] == '-') || (argv[from][1] == 'x')) && argv[from][2] == 0)
+             || !strcmp(argv[from], "-scripteval"))
            {
              /* Leave the "--", and everything following it, at the end.  */
              for (; from < argc; from++)
----

Re: (unknown)

[Jim Porter]

On 11/17/2023 7:13 PM, Greg Minshall wrote:
> (i was thinking of writing a test to go with the patch, but the ERT
> framework is maybe a bit awkward for tests of essentially
> shell-command-line functionality.  i may have missed it, but i didn't
> see anything in ./test/Makefile.in that seemed to be aimed at testing
> command-line invocation of Emacs.)

You could probably take some inspiration from the "Synchronous 
processes" section of the file test/lisp/eshell/esh-proc-tests.el. 
Essentially, you can just start a new Emacs instance in your ERT test 
and do whatever you like.

Re: (unknown) -x behavior change

[Greg Minshall]

Jim Porter <jporterbugs@gmail.com> wrote:

> You could probably take some inspiration from the "Synchronous
> processes" section of the file
> test/lisp/eshell/esh-proc-tests.el. Essentially, you can just start a
> new Emacs instance in your ERT test and do whatever you like.

thanks.  that looks likely.

cheers, Greg

ps -- sorry, all, for the lack of Subject:

Re: Emacs script options

[Eli Zaretskii]

> From: Greg Minshall <minshall@umich.edu>
> Date: Fri, 17 Nov 2023 19:13:56 -0800
> 
> hi.  i would like to be able to write Emacs scripts ("#!...") that allow
> a user to enter almost any option to the script itself, *without* having
> to use double dashes ("--") to avoid colliding with Emacs option
> processing.
> 
> looking at "--script" and "-x", this doesn't seem possible.
> 
> as a test case, given a simple script foo.sh (*), using "-x", and
> invoking it with an option "--eval" gives this error:
> 
> ----
> % ./foo.sh --eval
> emacs: Option '--eval' requires an argument
> ----
> 
> (that bare "--eval" *should* be an error if it were meant for Emacs
> itself; however, it is meant for the Emacs script, which may have other
> ideas of the syntax/semantics of "--eval".)

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?

Thanks.

Re: Emacs script options

[Greg Minshall]

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

[Eli Zaretskii]

> cc: emacs-devel@gnu.org
> From: Greg Minshall <minshall@umich.edu>
> Comments: In-reply-to Eli Zaretskii <eliz@gnu.org>
>    message dated "Sat, 18 Nov 2023 09:36:36 +0200."
> Date: Sat, 18 Nov 2023 06:38:24 -0800
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > 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).

How would you pass these -F, -d, -V etc. options to Emacs, or use them
in any other way in the script, whose contents is supposed to be an
Emacs Lisp program?  There's something I'm missing here.  I asked my
question because I thought you had a real-life example of a script you
wanted to use, but in your response you don't show any such example.
Can you show it?

Re: Emacs script options

[Greg Minshall]

Eli Zaretskii <eliz@gnu.org> wrote:

> How would you pass these -F, -d, -V etc. options to Emacs, or use them
> in any other way in the script, whose contents is supposed to be an
> Emacs Lisp program?  There's something I'm missing here.  I asked my
> question because I thought you had a real-life example of a script you
> wanted to use, but in your response you don't show any such example.
> Can you show it?

in this case, the -F, -d, -V are aimed at the elisp code running in the
script, not for Emacs itself.

think of wanting to convert some random unix utility to run as an Emacs
script (rather than as a shell script, say), and trying to make the
command line options (and invocation) the same as the original shell
script.  does that help clarify?

in my case, i have the beginnings of a shell script that is to set up
some state and then invoke Emacs to do some work (org mode stuff).  its
projected getopt(1) strings look like
----
getopt -o "B:C:dhP:V" -l "base-dir:,config-file:,debug,help,publish-dir:,version"
----

presumably most of those options (especially the long ones) don't
conflict with any Emacs command line options.  but, some might ("-d"
does, as it turns out).

i'd like the users (hah!) to be able to type
----
./random-script -d --base-dir ${PWD}/foo
----
rather than
----
./random-script -- -d --base-dir ${PWD}/foo
----

cheers, Greg

(truth in advertising: in addition to this *application*, i also -- for
this application, really -- wrote some emacs-getopt package that would
probably benefit from such a facility.)

Re: Emacs script options

[Eli Zaretskii]

> cc: emacs-devel@gnu.org
> From: Greg Minshall <minshall@umich.edu>
> Comments: In-reply-to Eli Zaretskii <eliz@gnu.org>
>    message dated "Sat, 18 Nov 2023 18:20:56 +0200."
> Date: Sat, 18 Nov 2023 11:36:52 -0800
> 
> Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > How would you pass these -F, -d, -V etc. options to Emacs, or use them
> > in any other way in the script, whose contents is supposed to be an
> > Emacs Lisp program?  There's something I'm missing here.  I asked my
> > question because I thought you had a real-life example of a script you
> > wanted to use, but in your response you don't show any such example.
> > Can you show it?
> 
> in this case, the -F, -d, -V are aimed at the elisp code running in the
> script, not for Emacs itself.

So this is about avoiding the need to type "--" before those options
which you want to be passed to the Lisp code?  Can't you arrange for
another script or shell alias that would inject the "--" part before
invoking the main script?

Re: Emacs script options

[Greg Minshall]

Eli, et al.,

there was an interesting discussion on how to use a two-line shell
script as a spring board into Emacs.  but, possibly not everyone
followed the discussion that far.

but, i would jump back to my suggestion for "-x".  i think it would be a
real benefit to those wanting to write general purpose scripts using
Emacs as the "engine" (or whatever you want to call it).

cheers, Greg

Re: Emacs script options

[Eli Zaretskii]

> cc: emacs-devel@gnu.org
> From: Greg Minshall <minshall@umich.edu>
> Comments: In-reply-to Eli Zaretskii <eliz@gnu.org>
>    message dated "Sat, 18 Nov 2023 09:36:36 +0200."
> Date: Sun, 26 Nov 2023 19:29:25 -0800
> 
> there was an interesting discussion on how to use a two-line shell
> script as a spring board into Emacs.  but, possibly not everyone
> followed the discussion that far.
> 
> but, i would jump back to my suggestion for "-x".  i think it would be a
> real benefit to those wanting to write general purpose scripts using
> Emacs as the "engine" (or whatever you want to call it).

My understanding of this is that one can easily avoid the annoyance of
having to use "--" by at least two different techniques.

As mentioned in

  https://lists.gnu.org/archive/html/emacs-devel/2023-11/msg00864.html

the proposed feature will change the Emacs behavior in incompatible
ways, so there's also a significant disadvantage to this proposal.

So on balance, I think that we should not add this feature.

Re: Emacs script options

[Greg Minshall]

hi, Eli,

> My understanding of this is that one can easily avoid the annoyance of
> having to use "--" by at least two different techniques.
> 
> As mentioned in
> 
>   https://lists.gnu.org/archive/html/emacs-devel/2023-11/msg00864.html

there are ways.  they have the random problem here or there.  but, even
if they didn't, i think it would be cleaner, and maybe more robust, to
have something in the "#!/usr/bin/emacs" line that would stop parsing
any Emacs options at the end of that line (rather than looking at any
command line options the end-user gave when invoking the script).

> the proposed feature will change the Emacs behavior in incompatible
> ways, so there's also a significant disadvantage to this proposal.

it's definitely a good idea to not introduce incompatibilities.  (though
i'd be curious to see how people are using "-x" with other Emacs
options, whether on the "#!/usr/bin/emacs" line, or on the command
line.)

how about "-y"? :)

cheers, Greg

Re: Emacs script options

[Sebastian Miele]

> From: Greg Minshall <minshall@umich.edu>
> Date: Fri, 2023-11-17 19:13 -0800
>
> hi.  i would like to be able to write Emacs scripts ("#!...") that allow
> a user to enter almost any option to the script itself, *without* having
> to use double dashes ("--") to avoid colliding with Emacs option
> processing.
>
> looking at "--script" and "-x", this doesn't seem possible.
>
> as a test case, given a simple script foo.sh (*), using "-x", and
> invoking it with an option "--eval" gives this error:
>
> ----
> % ./foo.sh --eval
> emacs: Option '--eval' requires an argument
> ----
>
> (that bare "--eval" *should* be an error if it were meant for Emacs
> itself; however, it is meant for the Emacs script, which may have other
> ideas of the syntax/semantics of "--eval".)
>
> the below patch to src/emacs.c (**) treats a "-x" (and its "partner"
> "-scripteval") like a "--" on the command line, and *seems* to allow
> arbitrary options on the command line.  for example, with this patch
> installed:
>
> ----
> % ./foo.sh --eval
> command-line-args-left (--eval)
> ----

On Linux that can be achieved by defining a custom interpreter.  E.g.,
put the following into ‘/path/to/emacs-script’:

  #!/bin/sh
  script=$1
  shift
  exec emacs -Q --batch --load $script -- "$@"

Then, with the following in a ‘test-script’

  #!/path/to/emacs-script
  ;; -*- mode: emacs-lisp; lexical-binding: t -*-
  (message "%s" command-line-args-left)

‘test-script --eval’ prints "(-- --eval)".

On Linux, and when ‘emacs-script’ is in the PATH, the ‘/path/to/’ in the
shebang even can be omitted.

However, the workaround is not possible on at least some non-Linux
systems, because not all systems allow something interpreted as an
interpreter in a shebang, see
https://en.wikipedia.org/wiki/Shebang_(Unix)#Syntax.

Re: Emacs script options

[Greg Minshall]

Sebastian Miele <iota@whxvd.name> wrote:

> On Linux that can be achieved by defining a custom interpreter.  E.g.,
> put the following into ‘/path/to/emacs-script’:

yes, thanks.  R has similar (Rscript in R itself; r in littler).  for a
script writer, it's somewhat of a barrier, wondering how many potential
users' machines will have such a script installed; for users, it's one
more hurdle between them and making use of a provided script.

one could also *imagine* (i.e., i think this could work) a packaging
step that would turn one's elisp script into a string and embed it
inside a "#!/bin/sh" script that would unquote the string and feed it
(along with the command line arguments) to Emacs.  if that worked, it at
least would remove the minor hurdle of needing the custom interpreter
you suggest (since everything -- in my fantaxy -- would be in one file).
it seems very messy, though.

cheers, Greg

Re: Emacs script options

[Jens Schmidt]

On 2023-11-18  20:49, Greg Minshall wrote:

> one could also *imagine* (i.e., i think this could work) a packaging
> step that would turn one's elisp script into a string and embed it
> inside a "#!/bin/sh" script that would unquote the string and feed it
> (along with the command line arguments) to Emacs.  if that worked, it at
> least would remove the minor hurdle of needing the custom interpreter
> you suggest (since everything -- in my fantaxy -- would be in one file).
> it seems very messy, though.

What about this one, which nicely plays with the meaning of ";" in
Emacs and the Bourne shell:

------------------------- test -------------------------
#!/bin/sh
: ; exec emacs --script "$0" -- "$@"
(message "%S" command-line-args-left)
------------------------- test -------------------------

Might not be very portable.  And I couldn't cram the lexical-bindings
line in, yet.

Re: Emacs script options

[Jens Schmidt]

On 2023-11-19  22:39, Jens Schmidt wrote:

> And I couldn't cram the lexical-bindings
> line in, yet.

But of course like this:

------------------------- test -------------------------
#!/bin/sh
: ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
(message "%S" command-line-args-left)
------------------------- test -------------------------

Re: Emacs script options

[Greg Minshall]

Jens,

> ------------------------- test -------------------------
> #!/bin/sh
> : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
> (message "%S" command-line-args-left)
> ------------------------- test -------------------------

no way, NO way near hack'y enough.  :)

that is, in fact, truly, truly impressive!

(i'd still vote for something like my mod for "-x", but i can run with
this!)

thank you very much!

cheers, Greg

Re: Emacs script options

[Jens Schmidt]

On 2023-11-20  02:19, Greg Minshall wrote:

> no way, NO way near hack'y enough.  :)

I couldn't stand the fact that my hack was taken already plus
that it is flawed, so I set off to extend it with a work-around
for the lexical-binding issue.

While there are surely other methods to achieve what below code
does, supposedly also more stable ones, I wanted to go for
brevity to keep the non-script overhead small:

------------------------- escript -------------------------
#!/bin/sh
: ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-

;; Work around `eval-buffer' not recognizing the lexical-binding
;; stanza when the comment containing it does not start at first
;; column (bug#67321).
(unless (ignore-errors (funcall (let ((v t)) (lambda () v))))
  (with-current-buffer (car eval-buffer-list)
    (goto-char (point-min)) (search-forward "; -*-")
    (delete-region (point-min) (match-beginning 0))
    (eval-buffer)))

;; Script payload.
(message "%S:%S" lexical-binding command-line-args-left)

;; Explicitly exit Emacs to not return from the second-level
;; `eval-buffer'.
(kill-emacs 0)

;;; Local Variables:
;;; mode: emacs-lisp
;;; End:
------------------------- escript -------------------------

(Thanks to Sebastian for opening the bug, BTW.  When looking at
the previous, now merged bug, it seems that this won't be
something easy to get through.)

Re: Emacs script options

[Sebastian Miele]

> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Date: Tue, 2023-11-21 22:13 +0100
>
> On 2023-11-20  02:19, Greg Minshall wrote:
>
>> no way, NO way near hack'y enough.  :)
>
> I couldn't stand the fact that my hack was taken already plus
> that it is flawed, so I set off to extend it with a work-around
> for the lexical-binding issue.
>
> While there are surely other methods to achieve what below code
> does, supposedly also more stable ones, I wanted to go for
> brevity to keep the non-script overhead small:
>
> ------------------------- escript -------------------------
> #!/bin/sh
> : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
>
> ;; Work around `eval-buffer' not recognizing the lexical-binding
> ;; stanza when the comment containing it does not start at first
> ;; column (bug#67321).
> (unless (ignore-errors (funcall (let ((v t)) (lambda () v))))
>   (with-current-buffer (car eval-buffer-list)
>     (goto-char (point-min)) (search-forward "; -*-")
>     (delete-region (point-min) (match-beginning 0))
>     (eval-buffer)))
>
> ;; Script payload.
> (message "%S:%S" lexical-binding command-line-args-left)
>
> ;; Explicitly exit Emacs to not return from the second-level
> ;; `eval-buffer'.
> (kill-emacs 0)
>
> ;;; Local Variables:
> ;;; mode: emacs-lisp
> ;;; End:
> ------------------------- escript -------------------------

Thank you, I noted this trick for the future.

For the record, Gerd Möllemann mentioned yet another trick on
https://debbugs.gnu.org/67321:

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Wed, 2023-11-22 15:59 +0100
>
> cat >somefile <<EOF
> ; -*- lexical-binding: t -*-
> (message "%s" lexical-binding)
> EOF
> emacs --script somefile

Re: Emacs script options

[Jens Schmidt]

On 2023-11-22  19:17, Sebastian Miele wrote:

> For the record, Gerd Möllemann mentioned yet another trick on
> https://debbugs.gnu.org/67321:
> 
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Wed, 2023-11-22 15:59 +0100
>>
>> cat >somefile <<EOF
>> ; -*- lexical-binding: t -*-
>> (message "%s" lexical-binding)
>> EOF
>> emacs --script somefile

Hmja, only this leaves somefile behind, which I intentionally wanted
to avoid.  (At least in Bash one could get more or less safely rid of
that with a "trap 'rm -f somefile' EXIT", but anyway.)

Re: Emacs script options

[Greg Minshall]

Jens,

> While there are surely other methods to achieve what below code
> does, supposedly also more stable ones, I wanted to go for
> brevity to keep the non-script overhead small:

yes, i would say the below code *is* sufficiently hacky!

but, i would go back to my suggestion for "-x".  i think it would be a
real benefit to those wanting to write general purpose scripts using
Emacs as the "engine" (or whatever).

cheers, Greg

> ------------------------- escript -------------------------
> #!/bin/sh
> : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
> 
> ;; Work around `eval-buffer' not recognizing the lexical-binding
> ;; stanza when the comment containing it does not start at first
> ;; column (bug#67321).
> (unless (ignore-errors (funcall (let ((v t)) (lambda () v))))
>   (with-current-buffer (car eval-buffer-list)
>     (goto-char (point-min)) (search-forward "; -*-")
>     (delete-region (point-min) (match-beginning 0))
>     (eval-buffer)))
> 
> ;; Script payload.
> (message "%S:%S" lexical-binding command-line-args-left)
> 
> ;; Explicitly exit Emacs to not return from the second-level
> ;; `eval-buffer'.
> (kill-emacs 0)
> 
> ;;; Local Variables:
> ;;; mode: emacs-lisp
> ;;; End:
> ------------------------- escript -------------------------

Re: Emacs script options

[Jens Schmidt]

Hi Greg,

On 2023-11-24  05:22, Greg Minshall wrote:

> but, i would go back to my suggestion for "-x".  i think it would be a
> real benefit to those wanting to write general purpose scripts using
> Emacs as the "engine" (or whatever).

only I have the gut feeling that this branch of your thread drifted
off too far from your initial request, so that you keeping up to your
suggestion won't be noticed here.

So probably you'd like to bump an earlier branch, and/or include Eli
in the Cc.

								Jens

Re: Emacs script options

[Sebastian Miele]

> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Date: Sun, 2023-11-19 22:47 +0100
>
> ------------------------- test -------------------------
> #!/bin/sh
> : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t -*-
> (message "%S" command-line-args-left)
> ------------------------- test -------------------------

This is the trick that Doom Emacs employs, see
https://github.com/doomemacs/doomemacs/blob/master/bin/doom.

But it has a problem with lexical binding.  Consider:

  #!/bin/sh
  : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t; mode: emacs-lisp -*-

  (defmacro lexical-binding-p ()
    '(let* ((x t)
            (f (lambda () x))
            (x nil))
       (funcall f)))

  (message "%s %s" lexical-binding (lexical-binding-p))

When I run it as a script, the output is "nil nil", i.e., the script
definitely does not run with lexical binding enabled.  When I evaluate
it in a buffer, the output is "t t".

When I discovered the problem some while ago, I wanted to report it as
an issue to Doom Emacs, but the bars for reporting issues to that
specific project were set to high for me to actually go through the
process.

But maybe it should be reported as an Emacs bug?

Re: Emacs script options

[Jens Schmidt]

On 2023-11-20  07:10, Sebastian Miele wrote:

> This is the trick that Doom Emacs employs, see
> https://github.com/doomemacs/doomemacs/blob/master/bin/doom.

Aw, I was afraid that somebody might have code-golfed that already.

> But it has a problem with lexical binding.  Consider:
> 
>   #!/bin/sh
>   : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t; mode: emacs-lisp -*-
> 
>   (defmacro lexical-binding-p ()
>     '(let* ((x t)
>             (f (lambda () x))
>             (x nil))
>        (funcall f)))
> 
>   (message "%s %s" lexical-binding (lexical-binding-p))
> 
> When I run it as a script, the output is "nil nil", i.e., the script
> definitely does not run with lexical binding enabled.  When I evaluate
> it in a buffer, the output is "t t".

I tried byte-compiling something similar yesterday, which also
indicated that the byte-compiler compiles with lexical bindings.  Only
the scripting machinery sees dynamical bindings.

> When I discovered the problem some while ago, I wanted to report it as
> an issue to Doom Emacs, but the bars for reporting issues to that
> specific project were set to high for me to actually go through the
> process.
> 
> But maybe it should be reported as an Emacs bug?

I think chances are good that this gets accepted.  It seems that the
scripting machinery expects a semicolon in the very first column,
without that the lexical-binding line is not recognized.  Even a 
space before the semicolon breaks the recognition.

The problem is in function `lisp_file_lexically_bound_p' from lread.c,
which is indeed much more strict in its recognition of the -*- ... -*-
stanza than the functions `set-auto-mode-1' and
`hack-local-variables-prop-line' from files.el.  The Emacs manual
((emacs) Specifying File Variables) only mentions that the stanza
has to be in the first line (or the second one if the first is taken
by a she-bang), without any restriction where the comment has to start.

Would you or Greg report that as a bug?

Re: Emacs script options

[Sebastian Miele]

> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> Date: Mon, 2023-11-20 21:10 +0100
>
> On 2023-11-20  07:10, Sebastian Miele wrote:
>
>> But it has a problem with lexical binding.  Consider:
>>
>>   #!/bin/sh
>>   : ; exec emacs --script "$0" -- "$@" #; -*- lexical-binding: t; mode: emacs-lisp -*-
>>
>>   (defmacro lexical-binding-p ()
>>     '(let* ((x t)
>>             (f (lambda () x))
>>             (x nil))
>>        (funcall f)))
>>
>>   (message "%s %s" lexical-binding (lexical-binding-p))
>>
>> When I run it as a script, the output is "nil nil", i.e., the script
>> definitely does not run with lexical binding enabled.  When I evaluate
>> it in a buffer, the output is "t t".
>
> I tried byte-compiling something similar yesterday, which also
> indicated that the byte-compiler compiles with lexical bindings.  Only
> the scripting machinery sees dynamical bindings.
>
> […]  It seems that the scripting machinery expects a semicolon in the
> very first column, without that the lexical-binding line is not
> recognized.  Even a space before the semicolon breaks the recognition.
>
> The problem is in function `lisp_file_lexically_bound_p' from lread.c,
> which is indeed much more strict in its recognition of the -*- ... -*-
> stanza than the functions `set-auto-mode-1' and
> `hack-local-variables-prop-line' from files.el.  The Emacs manual
> ((emacs) Specifying File Variables) only mentions that the stanza
> has to be in the first line (or the second one if the first is taken
> by a she-bang), without any restriction where the comment has to
> start.

Thank you for the additional investigation into and information about
the issue.

> Would you or Greg report that as a bug?

Done, https://debbugs.gnu.org/cgi/bugreport.cgi?bug=67321.

Re: Emacs script options

[Bob Rogers]

   From: Sebastian Miele <iota@whxvd.name>
   Date: Sat, 18 Nov 2023 20:18:00 +0100

   > From: Greg Minshall <minshall@umich.edu>
   > Date: Fri, 2023-11-17 19:13 -0800

   . . .

   > the below patch to src/emacs.c (**) treats a "-x" (and its "partner"
   > "-scripteval") like a "--" on the command line, and *seems* to allow
   > arbitrary options on the command line.  for example, with this patch
   > installed:
   >
   > ----
   > % ./foo.sh --eval
   > command-line-args-left (--eval)
   > ----

   On Linux that can be achieved by defining a custom interpreter . . .

   However, the workaround is not possible on at least some non-Linux
   systems, because not all systems allow something interpreted as an
   interpreter in a shebang, see
   https://en.wikipedia.org/wiki/Shebang_(Unix)#Syntax.

A more portable option might be for emacs itself to change its startup
behavior if invoked under a special name.  For example, if you used an
"emacscript" alias, emacs would assume "--batch --load" and defer the
rest of its argument processing to the script.  That would make life
easy on Unix-like systems.  And you could just do

	emacscript script-name.el ...

on non-Unix systems.

   ================
   From: Greg Minshall <minshall@umich.edu>
   Date: Sat, 18 Nov 2023 11:36:52 -0800

   . . .

   i'd like the users (hah!) to be able to type
   ----
   ./random-script -d --base-dir ${PWD}/foo
   ----
   rather than
   ----
   ./random-script -- -d --base-dir ${PWD}/foo
   ----

   cheers, Greg

   (truth in advertising: in addition to this *application*, i also -- for
   this application, really -- wrote some emacs-getopt package that would
   probably benefit from such a facility.)

I am reminded of the emacs-lisp email server I wrote 30 years ago
. . . it ran for about 8 years.  "emacs --batch" on steroids.  ;-}

					-- Bob

Re: Emacs script options

[Eli Zaretskii]

> Date: Sat, 18 Nov 2023 21:04:11 -0800
> From: Bob Rogers <rogers@rgrjr.com>
> CC: emacs-devel@gnu.org,
>     Eli Zaretskii <eliz@gnu.org>
> 
> A more portable option might be for emacs itself to change its startup
> behavior if invoked under a special name.

The GNU Coding Standards frown on such practices:

  Please don't make the behavior of a utility depend on the name used to
  invoke it.  It is useful sometimes to make a link to a utility with a
  different name, and that should not change what it does.  Thus, if you
  make 'foo' a link to 'ls', the program should behave the same regardless
  of which of those names is used to invoke it.

(unknown)

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Date: Tue, 12 Mar 2024 23:02:10 -0400 (EDT)
> 
> branch: master
> commit 6b40d557c4a9a4152565c1a1b0da49a1aaaec84f
> Author: Po Lu <luangruo@yahoo.com>
> Commit: Po Lu <luangruo@yahoo.com>
> 
>     Port more notification senders to non-XDG systems
>     
>     * doc/lispref/os.texi (Desktop Notifications): Document that
>     `:timeout' is now implemented.
>     
>     * java/org/gnu/emacs/EmacsDesktopNotification.java
>     (EmacsDesktopNotification): New field delay.
>     (display1): Set delay on Android 8.0 and up.
>     
>     * lisp/erc/erc-desktop-notifications.el
>     (erc-notifications-notify): Call Android or Haiku notification
>     functions on those systems.
>     
>     * lisp/gnus/gnus-notifications.el (gnus-notifications-action)
>     (gnus-notification-close): Remove dismissed notifications from
>     the notification to message map.
>     (gnus-notifications-notify): Call android-notifications-notify
>     if possible.
>     
>     * src/androidselect.c (android_init_emacs_desktop_notification):
>     Update accordingly.
>     (android_notifications_notify_1): New argument TIMEOUT.
>     (Fandroid_notifications_notify): New argument QCtimeout.
>     (syms_of_androidselect) <QCtimeout>: New symbol.

This causes the following byte-compilation warning:

  In gnus-notification-close:
  gnus/gnus-notifications.el:91:36: Warning: Unused lexical argument `reason'

(unknown)

[Pedro Andres Aranda Gutierrez]

On Sat, 11 Mar 2023 04:45:21 -0800, Ongaro <david.ongaro@hamburg.de> wrote

> I don't understand this argument. If you're an Emacs user who uses
> tree-sitter the probability is high that you're also a developer so you
> need development tools like a compiler anyway. Especially in a
> "professional" programming environment. A sys-admin banning that would
> be an admin banning you from work.

Two things to bring another perspective:

1.- the probability is high, but what do we do with the (1-p)... shy
them away? ;-)
2.- with the current landscape, even professional developers can't
sometimes do what they need.
There is this balance between productivity and security, which I do
understand. I've already seen a couple of frighting attacks...

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

(unknown)

[Pedro Andres Aranda Gutierrez]

Joao Tavora wrote:

> This indeed works, I've fixed the manual which previously said that
> setting the variable globally "doesn't make sense".  It can be useful,
> if you know what you're doing.

;-)

> But I don't know if we should be recommending this over the use of
> eglot-server-program + :initializationOptions as described in section
> 5.1 User-specific configuration.  Will see.

Fine, I don't know either whether you should _recommend_.

But, at least mentioning that this can be done to have an initial configuration
to start with... There is no one fits all and some tweaks may be needed
in some projects, but an initial config can speed up the process and it is
'as bad as' putting the dir-locals in your git repo and someone opening it
with -say- vscode or vi ;-)

/PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
run a leader-deposed hook here, but we can't yet

(unknown)

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1571 bytes --]

Rob writes:
> Regarding the writes to HOME, etc.  I think David covered that fairly
> well -- Debian runs emacs to "do things" (build .elcs, run tests, etc.)
> at package build time, package install time, and during package testing.
> In all of these cases, we're likely to want to avoid side-effects outside
> the build/test dir like writing .elc or .eln files to the current user's
> HOME, whether that's /root/ or /home/*.  It sounds like we may be able
> to accomplish that by redirecting everything to a temp dir, which is
> likely fine.

I know this may come late and be redundant, but just my .01 cents of
experience:
I have my own tweaked Debian infra to build emacs29 for Ubuntu and I have
native-compile enabled. All .eln files generated during build from the
emacs (git) source are stored in /usr/lib/emacs-xyz and are never
recompiled when I run emacs.

What actually gets natively compiled to $HOME/.emacs.d/eln-cache is any
package that I download from (m)elpa-xyz as a result of my
HOME/.emacs.d/init.el

I may be doing something wrong, but AFAIK it seems to work and I have the
same functionality on my Ubuntu natively-compiled Emacs and on the macOS
(both running +/- the same snapshot of the emacs master git branch), where
I have no native compilation.

I hope I somehow contributed something ;-)
/PA
-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2037 bytes --]

(unknown)

[Gregory Heytings]

a29a3ad55d breaks the build of master with:

cedet/semantic/symref/list.el:35:2: Error: Wrong type argument: number-or-marker-p, nil

(unknown)

[Pedro Andres Aranda Gutierrez]

[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]

> Date: Sat, 28 May 2022 08:43:13 +0800
> From: Po Lu <luangruo@yahoo.com>
> To: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Subject: Re: ns-do-applescript
> Message-ID: <87leumebby.fsf@yahoo.com>
> Content-Type: text/plain

> Richard Stallman <rms@gnu.org> writes:

> > I have never heard of "osascript".  What is that?  What systems
> > support it?  Does it exist on GNU/Linux?

> It's only present in macOS.
Right

> > Basically, what are the differences that make it better to use
> > osascript than applescript?

> I think that binary _is_ Apple's proprietary AppleScript interpreter,
Indeed it is

> but using it in a subprocess to retrieve only contacts data (which is
> already possible on free systems) must be more acceptable than Emacs
> including a C primitive to do the same thing.

Not only that. You can do things like raising Emacs to the top and other
system actions that would otherwise require (Objective-)?C functions in the
Emacs executable.

Best, /PA

-- 
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

[-- Attachment #2: Type: text/html, Size: 2842 bytes --]

(unknown)

[Davin Pearson]

[-- Attachment #1.1: Type: text/plain, Size: 795 bytes --]

I was wondering if you could make the following improvement to
GNU Emacs: Make it so that fonts with a nil for background-colour
have the fontification of the inner symbols shines through
to appear over higher layers, like so:

*abc* is fontified as a blue foreground with nil background

"*abc*" is fontified in light blue background with a black foreground
but should appear with a light blue background and a blue foreground.

Here is the Elisp code that I want the behaviour of which changed:

(set-face-foreground 'dmp-face--fg:blue "#000")
(set-face-background 'dmp-face--fg:blue nil)

("\\*.*\\*" 0 'dmp-face--fg:blue t)



-- 
Sorry about the delay in getting back to you.
I am only allowed my computer once per week
so that makes for a two-three week round trip in
getting back to you.

[-- Attachment #1.2: Type: text/html, Size: 1041 bytes --]

[-- Attachment #2: old-screenshot-20211212-181211.png --]
[-- Type: image/png, Size: 261635 bytes --]

[-- Attachment #3: new-screenshot-20121212-181236.png --]
[-- Type: image/png, Size: 262908 bytes --]

(unknown)

[telegraph]

From telegraph@gmx.net  Mon Aug 23 20:37:01 2021
From: Gregor Zattler <telegraph@gmx.net>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: xterm [menu] key definition
In-Reply-To: <87k0kcovp4.fsf@no.workgroup>
References: <20210819024728.kgnf6jmpakqdto4p.ref@Ergus>
 <20210819024728.kgnf6jmpakqdto4p@Ergus> <87k0kcovp4.fsf@no.workgroup>
Mail-Followup-To: emacs-devel <emacs-devel@gnu.org>
Date: Mon, 23 Aug 2021 20:36:58 +0200
Message-ID: <87h7fgovn9.fsf@no.workgroup>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:HRO/ZXce88Iozn+9UJq+ekk0abWiVqAiW05nvxhROUw4xLXvaVA
 I8MJYVw59QFHLg4As0OZgf1yCpriSS+YQsdNhys754yK6pB/wk2+6i/PbDMRG3YQWQXBUpo
 tvTC4EpNZXzi5CJg4d4uCg+Wj9SxoajT3JMmIXMug1Xz00P1aemSpf0v6oIf5wFAQ/lSwTr
 D/dkF2dL88+BwVa6vBhhw==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:x+ng0FuV5Xw=:c1ueAnEJSAQkxkyqjZnCx1
 KN6IxRv+LnP6G96c416OIk26JuOsdDTIyiXvEUq6QzrLXZ5rgupHYTCvwJQGBvSvaDphMyFDW
 ST49PCmrRrxwWE1dbBVQ27MMr+q1Ny0ITq7KtafxKw1tmDO6FXXA5N8RaecNs6vDmCQtpbW9z
 /HKAM7MjtdvPVAgtFnY/AYbwK+/jXHEFARP5XNgHbQOOdf9n6GiLAP55AehHp6mv7J+f1yr/Y
 ciX0YuEm8kHEixainZ80as4FOQarr0Vetdd59a+BwIafQxT2iUR+brhxxJxEBH4GR7/F7yN5G
 Ftp4iQDM45po2gmJlveQrUj25Urfz6f0reLHFwE/OfQq9wHaElOvOeZUnOsE6xnxh/PL7kASV
 mbYfUxKk1iCdDC8thJtevvbox8fw8bwCSSzcgwwN1SvtkFXGmZxk1ah64ue4Re/slO35L2voM
 fN+xxT6j8MJwtERNEhJZxeGBgQMVlQ+HuErhFhx5zq96HJgNZh6mHER4/hwHyJ7VPWJDpcMqu
 +gQD5H75FMDrPdWeti2lUxpPbqNcVvEvlziv4agxtJGYTNn75GtI526JU20W/5f1oZuwwoFre
 f+oXHczb6XnEctuTuUlJfPQkBvqDfWTk0X7KvzqmyYJyNjJOmo74O/kIIySZbfhruL3HLs7ba
 r2ofHxlQsyJvZRiJ2sX8xbA5aYVI7830NBkvi3aQeQ2PpHpI3FUg8Z0+Hcumly9COz75+GbM3
 pSje0giAF92ACLFp9kbyeRwKJpdpaZy81alSigFqMF9l6gHvY9v1EP3lHX6L1vC1w9S/bTqoQ
 yioc6IwC4iqTnPQV4agbfB7Xyy3IRD2TDh3ntAVihDXMb6IjBr6jSL3dB8hKU9JUAOiBuGy20
 DtvVNkoryKhJQFjg9N8qtjj7NdZuG+iX4bhej2GzQc6/jqOvev4umnj8n1l7AWUiSJWeT3Mec
 auVYAJHcixI79uAPvWH/7R8F2vLv+mtt/oO+3OTz1KDSntG+OiwefVZFSn6tvtfi0cA2GRH/q
 HpF7JyrC/S5FP0PaE9nXV2526YQacHrPSpmbJB5sMxwpOBQ6UYbTV0y9OqtDIkKBh9mwOJ8jL
 nkPnOo63oY9QmXA63umgtmElXMZvdLieT/clPOiVNacWQUdXuMJKa29kw==
Content-Transfer-Encoding: quoted-printable

Hi Ergus,
* Gregor Zattler <telegraph@gmx.net> [2021-08-23; 20:35]:
> * Ergus <spacibba@aol.com> [2021-08-19; 04:47]:
>> I don't actually know about any keyboard with a print
>> button...
>
> wouldn't that be the PrtSc key which is on every standard PC
> keyboard right of F12 and above of Insert?
>
>> But I suppose there should be some. If someone has it;
>> please could you check with xev and cat+xterm what it
>> sends?
>
> Said key gives via cat on xterm:
>
> ^[[2~
>
> and xev says the same.

on debian buster, that is.


Ciao; Gregor
=2D-
 -... --- .-. . -.. ..--.. ...-.-

(unknown)

[telegraph]

From telegraph@gmx.net  Mon Aug 23 20:35:54 2021
From: Gregor Zattler <telegraph@gmx.net>
To: emacs-devel <emacs-devel@gnu.org>
Subject: Re: xterm [menu] key definition
In-Reply-To: <20210819024728.kgnf6jmpakqdto4p@Ergus>
References: <20210819024728.kgnf6jmpakqdto4p.ref@Ergus>
 <20210819024728.kgnf6jmpakqdto4p@Ergus>
Mail-Followup-To: emacs-devel <emacs-devel@gnu.org>
Date: Mon, 23 Aug 2021 20:35:51 +0200
Message-ID: <87k0kcovp4.fsf@no.workgroup>
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:sxHfD7zdrmCrHJSZln2GfPWmdbMMIDsRDQsLpU/nfq2YcMnLSwp
 hYDoOFW4h00C5RkEQiWqTD0Ghszr1rlMksOFjeCzf6UdQ6KCjGfM9H/0FNpGLz//8NEoqgM
 S5utAAvPbhusMs8u3C+lcawvEbL65zJofM+Ydv0o9vvHaRqEnoH26xvM2TKzTcYI3D+cvMJ
 tbufjgNLdJD0dp/gT0Usg==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:0O6w3nRKzCM=:0yGavBBfSnyh5UA4ZyLNTu
 xZveGSXWYdvpP90089lYIVteVaqX2TjAGj5I0C+mVPtjbh++j7XzPszGW59UNb8XhbXv/RRAU
 PaKuQZQs2zeJi6m/mnUR28wuFqa9EJFXsUMLywX7A9pcq+nj88RJDkFOyOUucK8ZRDJczVJtq
 hCRthc8vZLS9I7t/BScUxTX0Gkr572eqLRSK7ZAnzyi28WyMc4Q67ujkJYogQakM7BESX2mqb
 n+cqLaM/SkXB4ftaF7C8YmAY7GFK64ACinZ71HIBSIVZhIDaFwmTiO3KSz0zuGFf9pYBndhTr
 iuv3dGLvRCBxYAxZ/8PDf2xts3TXZK6WpjTyQVjthqj5y9OwIYt2kZrgnV0PrbFfAm1H6RPcT
 xQqoU1Xhi3xaLOnNKx5DQp+M3P5/x1uu24XDKzXlVaAmN3r8tMcfbLFbE8Rk5+ikVt5xVHvXM
 pZHJA5ggu0HowH10nfZZ4b9dmeCitsqF9dVOA/sv9WsRdQ+M33ZsdYpk5UTaurTjfVU6JWaOG
 gScUUAQx9O2Iltx9m/jOlfw9aOZQ4cv9uNRiJc0ujo0Iv3T2oqkKoBjTVj5WUY2mqfPkKIhLe
 PqiVdMC2viIT1LzxgCRzghRqizF0E6OGu1twlQNqBMxo8J1MbU5OYo/uJ/QoF4DMY7Z7TgVyc
 4X3WbN7qsken+icUxr5UljsAhpg3Y9VdcF1aLJuFObC5ceIlMAylmUt0MzVfdhDGf4fy7lMWD
 3WVTDeehE5N+vf+gtoktTNzUUVujv6vDihkwb8M8cWBC0iDlLFf7a74EyzY+B4Hgc3Lc4HXGz
 C1HnGSPrG5xCYjzjGRaEulxTMjIBoCaBjj7UamceG6e+8preYjhjJlboGUEc2jWUAhUlK1E/I
 U92uRwgIm+mLukfNLQO/jzObm/a6Xd8xI8DXV3NGzqLWBNR5zZrhXErR2CM9bYihuPyN6Mw+t
 +v9efj6W3mrNpQEjsquqT7OrC3PVSRX8ZER0SkyOmvje3HyALBssD5NBvtOl1YBiYAFN2IbdH
 f2lclpuTkYQ73x9fe5OxwVoz71ASxro8z+oG1pRYVnwfWLwbNw+UK2n9qWxEblnARL9lfLqAr
 LRIc8W9CUi1Q6qGkLmdnpUYMF9eR2jPfzzqbhwIyj7rdZtkfYFCveiAPQ==
Content-Transfer-Encoding: quoted-printable

Hi Ergus,
* Ergus <spacibba@aol.com> [2021-08-19; 04:47]:
> I don't actually know about any keyboard with a print
> button...

wouldn't that be the PrtSc key which is on every standard PC
keyboard right of F12 and above of Insert?

> But I suppose there should be some. If someone has it;
> please could you check with xev and cat+xterm what it
> sends?

Said key gives via cat on xterm:

^[[2~

and xev says the same.

Ciao; Gregor
=2D-
 -... --- .-. . -.. ..--.. ...-.-

(unknown)

[Troy Hinckley]

Subject: Load order for elisp files
User-agent: mu4e 1.2.0; emacs 28.0.50

I am trying to better understand the bootstrap process for Emacs and I
have run into a chicken and egg problem. When looking for where the
basic functions are defined, I can see that defmacro and defun are defined in
byte-run.el. However the code needed to evaluate a macro is in
backquote.el. But backquote.el uses defun, which is defined in
byte-run.el. Which of these files is loaded first, and how does Emacs
work around this apparent causality dilemma?

(unknown)

[Ag Ibragimov]

Spacemacs (community-driven Emacs distribution/config) has a feature called Layers, Doom-Emacs (another community-driven Emacs config) has a similar feature (I think they are called Modules).

A Layer is a bundle of [related] Emacs packages that work together and very often tightly integrate (with one another) to provide a comprehensive set of features to achieve specific goals. For example, there are many language-specific Spacemacs layers: Python, Lua, Haskell, etc.
For example, the Python layer includes basic Python-related packages and sets defaults for Flycheck, Company, etc.
There also layers for tools like Docker or layers for version-control, et al.

So my question is: Has anyone ever thought about designing a sort of standardized module system? It would be great if we could have a unified model for creating such bundles.
Wouldn't be nice if for example, instead of discovering, installing and configuring a bunch of related packages, an Emacs user would say: "install LaTeX module" and then "customize "LaTeX module", etc.

Emacs ecosystem is growing. There are hundreds (maybe more) packages; standardizing a system that would allow the "plug-n-play" experience would be very nice. Otherwise, everyone would continue solving same problems in their own, unique ways, increasing entropy towards the "Lisp curse."

(unknown)

[siraben]

I'm new to contributing, so I was wondering if this is a viable
project to get started on.

I've noticed that development on the Emacs Calc has stalled
recently. /lisp/calc shows no commits since January 1 2018, which was
a copyright year update. I would like to contribute documentation to
many of the undocumented functions, and work on the symbolic
integration algorithm which, despite its complexity, still has great
difficulty with integration by parts and by substitution.

What are some recommended starting points for first-time contributors?

Thanks,

Ben Phipathananunth

(unknown)

[Mark Oteiza]

Hi,

I wrote the following to get rid of the 'apply' here.  The
expansion is something that, according to how byte-switch is described,
should compile to a switch/jumptable, but it isn't happening.

Applying the following, doing M-x byte-compile-file, and inspecting the
.elc/disassembly I am seeing a series of goto-if-nil.  Am I doing
something wrong?

diff --git a/lisp/json.el b/lisp/json.el
index 64486258cc..6990ddd0f5 100644
--- a/lisp/json.el
+++ b/lisp/json.el
@@ -683,6 +683,23 @@ json-readtable
     table)
   "Readtable for JSON reader.")
 
+(defmacro json-readtable-dispatch (char)
+  "Dispatch reader function for CHAR."
+  (declare (debug (symbolp)))
+  (let ((table
+         '((?t json-read-keyword "true")
+           (?f json-read-keyword "false")
+           (?n json-read-keyword "null")
+           (?{ json-read-object)
+           (?\[ json-read-array)
+           (?\" json-read-string)))
+        res)
+    (dolist (c '(?- ?+ ?. ?0 ?1 ?2 ?3 ?4 ?5 ?6 ?7 ?8 ?9))
+      (push (list c 'json-read-number) table))
+    (pcase-dolist (`(,c . ,rest) table)
+      (push `((= ,char ,c) (,@rest)) res))
+    `(cond ,@res (t (signal 'json-readtable-error ,char)))))
+
 (defun json-read ()
   "Parse and return the JSON object following point.
 Advances point just past JSON object."
@@ -690,10 +707,7 @@ json-read
   (let ((char (json-peek)))
     (if (zerop char)
         (signal 'json-end-of-file nil)
-      (let ((record (cdr (assq char json-readtable))))
-        (if (functionp (car record))
-            (apply (car record) (cdr record))
-          (signal 'json-readtable-error record))))))
+      (json-readtable-dispatch char))))
 
 ;; Syntactic sugar for the reader
 

(unknown)

[Paul Pogonyshev]

>>> Have you tried to measure the impact of your patch on the actual problem?
>> I mentioned 3%.
>
>That's the percentage impact on the number of lambdas.  I'm curious
>about its impact on actual problematic aspects, such as speed and code
>size (and compilation time, I guess).
>
>> Yes, it is practically negligible, but this is a first small patch and
>> I'm willing to work on improving generators further.
>
>Of course.

Actually, forget it. It's too complicated to jump through all the hoops here.

I would just be glad if someone applied the patch from bug 26068. It's a
fix, not an optimization, and there is example of a form, evaluation of
which it fixes.

And if you reply, *please*, keep me on CC, otherwise I won't see your
mail.

Paul

Re: (unknown)

[Mark Oteiza]

Paul Pogonyshev <pogonyshev@gmail.com> writes:

>>>> Have you tried to measure the impact of your patch on the actual problem?
>>> I mentioned 3%.
>>
>>That's the percentage impact on the number of lambdas.  I'm curious
>>about its impact on actual problematic aspects, such as speed and code
>>size (and compilation time, I guess).
>>
>>> Yes, it is practically negligible, but this is a first small patch and
>>> I'm willing to work on improving generators further.
>>
>>Of course.
>
> Actually, forget it. It's too complicated to jump through all the hoops here.

Darn.  Such improvements would be nice.

> I would just be glad if someone applied the patch from bug 26068. It's a
> fix, not an optimization, and there is example of a form, evaluation of
> which it fixes.

Applied, thanks.  AFAICT it didn't break any tests and didn't exacerbate
bug#12119 which the previous code was fixing.

Re: (unknown)

[Paul Pogonyshev]

>> I would just be glad if someone applied the patch from bug 26068. It's a
>> fix, not an optimization, and there is example of a form, evaluation of
>> which it fixes.
>
> Applied, thanks.  AFAICT it didn't break any tests and didn't exacerbate
> bug#12119 which the previous code was fixing.

Thank you. If you are familiar with the code involved, can you please also
look at bug 26073? It's related, but more difficult to fix. I added a patch to
the bug report, but I don't think the patch is ready for application. Maybe
someone could finish it.

Paul

(unknown)

[Chris Gregory]

Here is another patch that does more of this.
-- 
Chris Gregory

diff --git a/src/eval.c b/src/eval.c
index e50e26a..9e1d612 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1313,20 +1313,12 @@ internal_condition_case (Lisp_Object (*bfun) (void), Lisp_Object handlers,
 			 Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun ();
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun ();
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case but call BFUN with ARG as its argument.  */
@@ -1364,20 +1356,12 @@ internal_condition_case_2 (Lisp_Object (*bfun) (Lisp_Object, Lisp_Object),
 			   Lisp_Object (*hfun) (Lisp_Object))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val);
-    }
-  else
-    {
-      Lisp_Object val = bfun (arg1, arg2);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (arg1, arg2);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val) : val;
 }
 
 /* Like internal_condition_case but call BFUN with NARGS as first,
@@ -1393,20 +1377,12 @@ internal_condition_case_n (Lisp_Object (*bfun) (ptrdiff_t, Lisp_Object *),
 						Lisp_Object *args))
 {
   struct handler *c = push_handler (handlers, CONDITION_CASE);
-  if (sys_setjmp (c->jmp))
-    {
-      Lisp_Object val = handlerlist->val;
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return hfun (val, nargs, args);
-    }
-  else
-    {
-      Lisp_Object val = bfun (nargs, args);
-      clobbered_eassert (handlerlist == c);
-      handlerlist = handlerlist->next;
-      return val;
-    }
+  bool is_returning = sys_setjmp (c->jmp);
+  Lisp_Object val = is_returning ? handlerlist->val : bfun (nargs, args);
+
+  clobbered_eassert (handlerlist == c);
+  handlerlist = handlerlist->next;
+  return is_returning ? hfun (val, nargs, args) : val;
 }
 
 struct handler *

Re: (unknown)

[Andreas Schwab]

On Dez 28 2016, Chris Gregory <czipperz@gmail.com> wrote:

> Here is another patch that does more of this.

Nothing of that is valid C.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

(unknown)

[Takesi Ayanokoji]

[-- Attachment #1: Type: text/plain, Size: 392 bytes --]

Hi developers.

I translated GNU Emacs manual "The Emacs Edirot" from English to Japanese.

  Emacs-24.5: https://ayatakesi.github.io/#emacs-24.5-emacs
  Emacs-25.1: https://ayatakesi.github.io/#emacs-25.1-emacs

So, how should I take next action.
Submit it to somewhere, or else?
(Currently I am sharing it by GitHub.)

Any ideas?

Thanks.

---
Ayanokoji Takesi <ayanokoji.takesi@gmail.com>

[-- Attachment #2: Type: text/html, Size: 1450 bytes --]

Re: (unknown)

[Byung-Hee HWANG (황병희, 黃炳熙)]

Takesi Ayanokoji <ayanokoji.takesi@gmail.com> 께서 쓰시길,
 《記事 全文
 <CAN7WbibOXQGSCYbzErB9e9X3YinM3OmBinApAM15hecx4O7-PA@mail.gmail.com>
 에서》:

> Hi developers.
>
> I translated GNU Emacs manual "The Emacs Edirot" from English to Japanese.
>
>   Emacs-24.5: https://ayatakesi.github.io/#emacs-24.5-emacs
>   Emacs-25.1: https://ayatakesi.github.io/#emacs-25.1-emacs
>
> So, how should I take next action.
> Submit it to somewhere, or else?
> (Currently I am sharing it by GitHub.)
>
> Any ideas?
>
> Thanks.

Takesi-san, it is very hard work, i think. You are strong man. Anyway
thanks thanks thanks!!!

Sincerely,

-- 
^고맙습니다 _地平天成_ 감사합니다_^))//

(unknown)

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

Hi!

About a year ago, the long time maintainer of the official Emacs user
interface on OS X (the "nextstep" or "NS" user interface), retired from
Emacs. This is very unfortunately, as he did a very, very good job for
during the years he was active.

When I found out about this, about six months ago, I stepped up as I had
some knowledge after having worked along side of him on some NS-related
features.

Unfortunately, my personal situation has since changed so I no longer can
handle the NS user interface by myself.

In other words, I'm looking for someone or a group of people who are
interested in enhancing Emacs on OS X, or at least making sure that it
doesn't stop working.

To make it easier to start working on the NS port, I've updated the README
and add a WISHLIST of features that I would like to see implemented.

I will still be around, but I find that time no longer permits me doing
much core development work.

Sincerely,
    Anders Lindgren

[-- Attachment #2: Type: text/html, Size: 1211 bytes --]

(unknown)

[steve]

From: Steve Purcell <steve@sanityinc.com>
Date: Mon, 8 Feb 2016 20:47:43 +1300
Subject: [PATCH] Safer prompt-regexp for postgres/vertica in
 sql-interactive-mode
--text follows this line--

Fixes issue 22596, whereby "_" is now not considered a word constituent
character in sql-interactive-mode, so prompts like "foo_dev# " are not
correctly detected.
---
 lisp/progmodes/sql.el | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/lisp/progmodes/sql.el b/lisp/progmodes/sql.el
index fd59f46..90c8dfe 100644
--- a/lisp/progmodes/sql.el
+++ b/lisp/progmodes/sql.el
@@ -462,9 +462,9 @@ sql-product-alist
      :list-all ("\\d+" . "\\dS+")
      :list-table ("\\d+ %s" . "\\dS+ %s")
      :completion-object sql-postgres-completion-object
-     :prompt-regexp "^\\w*=[#>] "
+     :prompt-regexp "^[[:alpha:]_]*=[#>] "
      :prompt-length 5
-     :prompt-cont-regexp "^\\w*[-(][#>] "
+     :prompt-cont-regexp "^[[:alpha:]_]*[-(][#>] "
      :input-filter sql-remove-tabs-filter
      :terminator ("\\(^\\s-*\\\\g$\\|;\\)" . "\\g"))
 
@@ -514,9 +514,9 @@ sql-product-alist
      :sqli-comint-func sql-comint-vertica
      :list-all ("\\d" . "\\dS")
      :list-table "\\d %s"
-     :prompt-regexp "^\\w*=[#>] "
+     :prompt-regexp "^[[:alpha:]_]*=[#>] "
      :prompt-length 5
-     :prompt-cont-regexp "^\\w*[-(][#>] ")
+     :prompt-cont-regexp "^[[:alpha:]_]*[-(][#>] ")
     )
   "An alist of product specific configuration settings.
 
-- 
2.7.1

Re: (unknown)

[Steve Purcell]

Sorry, messed up sending that patch by email, but it's hopefully helpful
nonetheless.

-Steve

(unknown)

[David Kastrup]

Unless objected to timely, I intend to push this change tomorrow.  It
should not affect current operation but brings Emacs' behavior for
synthesized Lisp events containing an "up-" modifier in line with the
current behavior of "down-" events.  Such events are not produced by
Emacs itself; no change in behavior for existing code is expected.

I have code that might eventually make it into ELPA that benefits from
these changes.

Re: (unknown)

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> Unless objected to timely, I intend to push this change tomorrow.  It
> should not affect current operation but brings Emacs' behavior for
> synthesized Lisp events containing an "up-" modifier in line with the
> current behavior of "down-" events.  Such events are not produced by
> Emacs itself; no change in behavior for existing code is expected.
>
> I have code that might eventually make it into ELPA that benefits from
> these changes.

Ugh.  Sorry for the Subject line.  This concerns the patch in the
message with title:

[PATCH] Deal gracefully with up-events (Bug#19746)

-- 
David Kastrup

(unknown)

[Eli Zaretskii]

Bootstrapping master from the git repo, I see multiple error messages
like this:

  Eager macro-expansion failure: (error "Lisp nesting exceeds `max-lisp-eval-depth'")

Does anyone else see this?

Re: (unknown)

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Bootstrapping master from the git repo, I see multiple error messages
> like this:
>
>   Eager macro-expansion failure: (error "Lisp nesting exceeds
> `max-lisp-eval-depth'")
>
> Does anyone else see this?

Yes, I get the same thing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

(unknown)

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

Hi,

I'm a gnus newbie and using it for about two weeks in just one of my IMAP
mail accounts. I like it so far, but wonder at its marking system...

To the question: Does it make sense to not use gnus-ancient-mark "O"
completely? I want to see old marks that I laboriously set in previous
sessions, such as the gnus-del-mark "r" mark. It seems to be replaced by
"O" all the time.

If so how would I achieve this?

-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 621 bytes --]

Re: (unknown)

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> To the question: Does it make sense to not use gnus-ancient-mark "O"
> completely? I want to see old marks that I laboriously set in previous
> sessions, such as the gnus-del-mark "r" mark. It seems to be replaced
> by "O" all the time. 

"r" just marks stuff as read, and this isn't saved beyond that.  Any way
of marking stuff as read ends up in the same data set, so it's all
displayed as "O".

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: (unknown)

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

I see, so the difference between "r" and "R" is just for the current
"summary mode" session.

Curious, when does adaptive scoring kick in then? It does differentiate
between "r" and "R" doesn't it?

Thanks (and sorry for not including a subject, I stupidly forgot)
João

On Sat, Jul 6, 2013 at 4:22 PM, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > To the question: Does it make sense to not use gnus-ancient-mark "O"
> > completely? I want to see old marks that I laboriously set in previous
> > sessions, such as the gnus-del-mark "r" mark. It seems to be replaced
> > by "O" all the time.
>
> "r" just marks stuff as read, and this isn't saved beyond that.  Any way
> of marking stuff as read ends up in the same data set, so it's all
> displayed as "O".
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>   bloggy blog http://lars.ingebrigtsen.no/
>



-- 
João Távora

[-- Attachment #2: Type: text/html, Size: 1610 bytes --]

Re: (unknown)

[Lars Ingebrigtsen]

João Távora <joaotavora@gmail.com> writes:

> I see, so the difference between "r" and "R" is just for the current
> "summary mode" session.

Yes.

> Curious, when does adaptive scoring kick in then? It does
> differentiate between "r" and "R" doesn't it?

Adaptive scoring kicks in as you're leaving the summary buffer, I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

(unknown)

[Eli Zaretskii]

Dmitry, could you please explain the reason(s) for the change below?

Vertical positions in a window can never be large enough to justify
using ptrdiff_t (on platforms where that is wider than a 32-bit
'int').  These are pixel positions on the Emacs display, so they
cannot be too large.  The type of 'first_vpos' looks especially
strange, since it is explicitly set to 1 at most.  I'm not aware of a
platform where an 'int' is not wide enough for a value 1 ;-)

Using inappropriate data types makes the code harder to read and
understand, because it hints that something non-obvious is going on
somewhere.

	 * xdisp.c (try_window_id): Change type of 'first_vpos' and 'vpos'
	 to ptrdiff_t.

  --- src/xdisp.c 2012-06-28 12:29:37 +0000
  +++ src/xdisp.c 2012-06-29 11:48:08 +0000
  @@ -17761,8 +17761,8 @@ try_window_id (struct window *w)
       {
	 /* Displayed to end of window, but no line containing text was
	   displayed.  Lines were deleted at the end of the window.  */
  -      int first_vpos = WINDOW_WANTS_HEADER_LINE_P (w) ? 1 : 0;
  -      int vpos = XFASTINT (w->window_end_vpos);
  +      ptrdiff_t first_vpos = WINDOW_WANTS_HEADER_LINE_P (w) ? 1 : 0;
  +      ptrdiff_t vpos = XFASTINT (w->window_end_vpos);
	 struct glyph_row *current_row = current_matrix->rows + vpos;
	 struct glyph_row *desired_row = desired_matrix->rows + vpos;