problems with Emacs 28

problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

I rebuilt a new Emacs, namely

   GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
   3.24.5, cairo version 1.16.0) of 2020-10-23

because I wanted an Emacs with support for modules (in particular,
vterm), which isn't possible to get from the Debian repos, IIUC.

Two issues:

1) suddenly no `markdown-mode'? but there is a markdown-mode pack in
   MELPA, which seems to work OOTB. but as a side not, to move major
   modes out of core Emacs seems like a bad idea, since they are
   Emacs' back bone, and besides cannot amount to many bytes, as they
   are just text. I take it spcific reasons made you do it?

2) a lot of errors like this:

     global-keys.el: 
     In toplevel form:
     global-keys.el:8:1: Error: Cannot open load file: No such file or directory, w3m-bookmark

     files-my.el: 
     In toplevel form:
     global-keys.el:8:1: Error: Cannot open load file: No such file or directory, w3m-bookmark

     kill-path.el: 
     In toplevel form:
     kill-path.el:8:1: Error: Cannot open load file: No such file or directory, w3m

     gnus/group.el: 
     In toplevel form:
     kill-path.el:8:1: Error: Cannot open load file: No such file or directory, w3m

   ... and so on, all relating to ny extensions of Emacs-w3m.
   But there *is* such a directory, with files, this is evident no the
   least when I use Emacs-28 _without_ byte compiling my stuff,
   because then Emacs-w3m works great with my add-ons in effect.
   
   And, I set the `load-path' in the Makefile [1]. This has always
   works, and does so even now for everyone (e.g., gnus) even in the
   same string as the w3m reference! So what's going on?


[1] https://dataswamp.org/~incal/emacs-init/Makefile

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Jean Louis]

* Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2020-10-23 20:08]:
> I rebuilt a new Emacs, namely
> 
>    GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>    3.24.5, cairo version 1.16.0) of 2020-10-23
> 
> because I wanted an Emacs with support for modules (in particular,
> vterm), which isn't possible to get from the Debian repos, IIUC.
> 
> Two issues:
> 
> 1) suddenly no `markdown-mode'? but there is a markdown-mode pack in
>    MELPA, which seems to work OOTB. but as a side not, to move major
>    modes out of core Emacs seems like a bad idea, since they are
>    Emacs' back bone, and besides cannot amount to many bytes, as they
>    are just text. I take it spcific reasons made you do it?

I don't think it was ever in Emacs or in GNU ELPA. I have kindly asked
author of markdown-mode to maybe contribute it to GNU ELPA, no answer
yet, maybe email address is outdated, and there are various other
contributors. 

-- 
Jean Louis

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean Louis wrote:

>> 1) suddenly no `markdown-mode'? but there is a markdown-mode pack
>>    in MELPA, which seems to work OOTB. but as a side not, to move
>>    major modes out of core Emacs seems like a bad idea, since they
>>    are Emacs' back bone, and besides cannot amount to many bytes,
>>    as they are just text. I take it spcific reasons made you do it?
>
> I don't think it was ever in Emacs or in GNU ELPA. I have kindly
> asked author of markdown-mode to maybe contribute it to GNU ELPA, no
> answer yet, maybe email address is outdated, and there are various
> other contributors.

Alrighy. Well, if it isn't of poor quality, consider including it as
Markdown is everywhere, even on git.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

More problems with the update.

The byte-compiler, and the docstring, tells me I should use `map-put!'
as `map-put' is decrepated. However when I do that, I get
a "map-not-inplace" error.

The Elisp in particular is this

    ;; remove troublesome Swedish and special chars from autokey
    ;; add more as needed
    (cl-loop
     for (r w)
     in `(("ä" "a")
          ("Ä" "A")
          ("å" "a")
          ("Å" "A")
          ("é" "e")
          ("ö" "o")
          ("Ö" "O")
          ("ń" "n")
          ("ś" "s") )
     do (map-put bibtex-autokey-titleword-change-strings r w) )
     ;; https://dataswamp.org/~incal/emacs-init/my-bibtex.el

What is that bang (explication mark) syntax BTW?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

> The byte-compiler, and the docstring, tells me I should use `map-put!'
> as `map-put' is decrepated. However when I do that, I get
> a "map-not-inplace" error.
>
> The Elisp in particular is this
>
>     ;; remove troublesome Swedish and special chars from autokey
>     ;; add more as needed
>     (cl-loop
>      for (r w)
>      in `(("ä" "a")
>           ("Ä" "A")
>           ("å" "a")
>           ("Å" "A")
>           ("é" "e")
>           ("ö" "o")
>           ("Ö" "O")
>           ("ń" "n")
>           ("ś" "s") )
>      do (map-put bibtex-autokey-titleword-change-strings r w) )
>      ;; https://dataswamp.org/~incal/emacs-init/my-bibtex.el
>
> What is that bang (explication mark) syntax BTW?

Now this is the only error that remains. A Warning with `map-put'; an
error with `map-put!' (after complying with the warning's piece of
advice). (And again, what does the exclamation mark mean?)

The mysterious Emacs-w3m error was solved like this. It wasn't _my_
Emacs-w3m files it couldn't find, it was Emacs-w3m! That's right,
I got it from MELPA when I got the new Emacs, but forgot to add it to
the load path of the Makefile when byte compiling.

That is a bit annoying to do manually for each pack on installs,
actually. Why isn't the elpa/ recursively added to the load path?

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Stefan Monnier]

> Now this is the only error that remains. A Warning with `map-put'; an
> error with `map-put!' (after complying with the warning's piece of
> advice). (And again, what does the exclamation mark mean?)

It has just as much meaning as the `t` in `put`.
[ Except it follows the Scheme tradition of using a final ! in the name
  of functions which operate by side-effect. ]


        Stefan

Re: problems with Emacs 28

[Stefan Monnier]

> Now this is the only error that remains. A Warning with `map-put'; an
> error with `map-put!' (after complying with the warning's piece of
> advice).

AFAIK the piece of advice tells you to

    use map-put! or (setf (map-elt ...) ...) instead

so if `map-put!` doesn't work, maybe it's time to try the other.


        Stefan

Re: problems with Emacs 28

[Michael Heerdegen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> The byte-compiler, and the docstring, tells me I should use `map-put!'
> as `map-put' is decrepated. However when I do that, I get a
> "map-not-inplace" error.

Yes, the replacement is not totally equivalent to the deprecated
function (if it would be, it would not make sense to introduce a
replacement at all).

If you read the docstring of `map-put!' you'll see why you get the
error.

You will probably rather want to use `setf' with an `alist-get' place
expression.  Yes, the recommendation was not a good one in your case.

> What is that bang (explication mark) syntax BTW?

That comes from the scheme tradition: it is used for functions that
modify something (state), unlike "pure" functions that "only" calculate
a return value.  E.g. `+', `car' vs. `setcar!' etc., you get it.

Regards,

Michael.

RE: problems with Emacs 28

[Drew Adams]

> > What is that bang (explication mark) syntax BTW?
> 
> That comes from the scheme tradition: it is used for functions that
> modify something (state), unlike "pure" functions that "only" calculate
> a return value.  E.g. `+', `car' vs. `setcar!' etc., you get it.

FWIW, I think it's a mistake for Emacs to adopt
that convention now, or at least it's a mistake
to adopt it only partially.

If users can't depend on it, to let them know
if a function might modify data destructively,
then it can mislead, and so be even more
"dangerous".  Now, we really need a giant sign
saying that you can't rely on a destructive
function's name having a suffix of `!'.
___

Same thing for Scheme's `?' suffix, to indicate
a predicate.  Elisp uses the more traditional
Lisp suffix of `p' for a predicate.  Introducing
`?' now, in only a partial way, wouldn't help,
and it might confuse.  Of course, that's trivial
compared with the effect of possible confusion
over destructive modification.  (Yes, I know `?'
hasn't been proposed as a suffix for predicates.
Just sayin.)

Re: problems with Emacs 28

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> FWIW, I think it's a mistake for Emacs to adopt
> that convention now, or at least it's a mistake
> to adopt it only partially.

I think it's ok if we end with a handful of functions that
are explicitly labeled that way to indicate they are the
in-place-modifying counterpart of some other existing pure function
where the return value matters.  As long as "!" is rarely seen, it's not
suggesting that Emacs uses exactly the same convention as scheme.

Michael.

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

Michael Heerdegen wrote:

>> FWIW, I think it's a mistake for Emacs to adopt that convention
>> now, or at least it's a mistake to adopt it only partially.
>
> I think it's ok if we end with a handful of functions that are
> explicitly labeled that way to indicate they are the
> in-place-modifying counterpart of some other existing pure function
> where the return value matters. As long as "!" is rarely seen, it's
> not suggesting that Emacs uses exactly the same convention
> as scheme.

Right, good point.

But I still think it looks weird.

Maybe instead of ! one could use -d, like we do with -p rather than ?.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>>> What is that bang (explication mark) syntax BTW?
>> 
>> That comes from the scheme tradition: it is used for functions that
>> modify something (state), unlike "pure" functions that "only"
>> calculate a return value. E.g. `+', `car' vs. `setcar!' etc., you
>> get it.
>
> FWIW, I think it's a mistake for Emacs to adopt that convention now,
> or at least it's a mistake to adopt it only partially.
>
> If users can't depend on it, to let them know if a function might
> modify data destructively, then it can mislead, and so be even more
> "dangerous". Now, we really need a giant sign saying that you can't
> rely on a destructive function's name having a suffix of `!'.
>
> Same thing for Scheme's `?' suffix, to indicate a predicate.
> Elisp uses the more traditional Lisp suffix of `p' for a predicate.
> Introducing `?' now, in only a partial way, wouldn't help, and it
> might confuse. Of course, that's trivial compared with the effect of
> possible confusion over destructive modification. (Yes, I know `?'
> hasn't been proposed as a suffix for predicates. Just sayin.)

Agree 100%. It makes the code disruptive to read and is slower to
type. The usefulness isn't obvious to me, either.


-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> If users can't depend on it, to let them know
> if a function might modify data destructively,
> then it can mislead, and so be even more
> "dangerous".  Now, we really need a giant sign
> saying that you can't rely on a destructive
> function's name having a suffix of `!'.

BTW, we use "destructive" most of the time to denote "might do anything
with the original value" (from "destroy).  Vs. here the ! means
"modifies in place" (you can rely on the value being present in the
original place).

Michael.

RE: problems with Emacs 28

[Drew Adams]

> > If users can't depend on it, to let them know
> > if a function might modify data destructively,
> > then it can mislead, and so be even more
> > "dangerous".  Now, we really need a giant sign
> > saying that you can't rely on a destructive
> > function's name having a suffix of `!'.
> 
> BTW, we use "destructive" most of the time to denote "might do anything
> with the original value" (from "destroy).  Vs. here the ! means
> "modifies in place" (you can rely on the value being present in the
> original place).

Yes.  In general it means that the "function"
might modify data (in particular input data).

Most important here is "modify".  Second most
important is "might".

"Destructive" can be misleading, since if you
intend the modification then, well, it's doing
what you want and expect.

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

Drew Adams wrote:

>>> If users can't depend on it, to let them know if a function might
>>> modify data destructively, then it can mislead, and so be even
>>> more "dangerous". Now, we really need a giant sign saying that you
>>> can't rely on a destructive function's name having a suffix of
>>> `!'.
>> 
>> BTW, we use "destructive" most of the time to denote "might do
>> anything with the original value" (from "destroy). Vs. here the !
>> means "modifies in place" (you can rely on the value being present
>> in the original place).
>
> Yes. In general it means that the "function" might modify data (in
> particular input data).
>
> Most important here is "modify". Second most important is "might".
>
> "Destructive" can be misleading, since if you intend the
> modification then, well, it's doing what you want and expect.

I'm happy to call everything a function but what I remember, and if
I understood it correctly, the terminology was

method - a function belonging to an OOP object

procedure - a function that don't return a value

function - a function that do return a value

destructive - changes the value in the actual argument variables.
It would seem this requires "call by name" or "call by reference", not
"call by value", right? (Unless the value is a memory location,
perhaps...)

side-effect free - the function doesn't do any changes to anything,
this implies non-destructiveness

side-effects - the function can do changes, to the argument variables
but also to other things. Note that, as Mr Adams says, this is often
what is desired

In functional programming, when it is applied as a rulebook rather
than a thought model, e.g., many Haskell programmers, they like to
divide their programs in two parts, one with side-effects, and one
without. This is for different reasons, one advantage would be
modularity, as the side-effect free part can be brought to any other
program without ever screwing anything up.

If it makes sense?

Well, sometimes!

(Please append to the list and make corrections. Complete function
terminology list project!)

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Michael Heerdegen]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> destructive - changes the value in the actual argument variables.
> It would seem this requires "call by name" or "call by reference", not
> "call by value", right? (Unless the value is a memory location,
> perhaps...)

"Might change a passed value".  This is possible in Elisp when the value
is a sequence for example (unless the value is nil - remember your
not-in-place problem?).  `setcar' receives a cons value and modifies it.

Eieio objects and even closures are other examples.


Michael.

Re: problems with Emacs 28

[Jens C. Jensen]

> From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> Date: Tue, 27 Oct 2020 01:29:03 +0100
>
> method - a function belonging to an OOP object
> procedure - a function that don't return a value
> function - a function that do return a value

These are the terms I recall as well. but it seems this terminology is muddy at best, seeing as how you described each one in terms of 'a function that...'. But I'm stumped with what else to call them, `callable' maybe? :-)

> destructive - changes the value in the actual argument variables.
> It would seem this requires "call by name" or "call by reference", not
> "call by value", right? (Unless the value is a memory location,
> perhaps...)

Yes, or if the context is implicit (e.g. in methods mutating local variables).

> side-effect free - the function doesn't do any changes to anything,
> this implies non-destructiveness

Which is also known as a 'pure' function.

> many Haskell programmers, they like to
> divide their programs in two parts, one with side-effects, and one
> without. This is for different reasons, one advantage would be
> modularity, as the side-effect free part can be brought to any other
> program without ever screwing anything up.

And testing side-effect free code tends to be simple, not having to construct class-hierarchies to test (or worse, debug!) some obscure state is a big boon.

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

> These are the terms I recall as well. but it seems this terminology is
> muddy at best, seeing as how you described each one in terms of 'a
> function that...'. But I'm stumped with what else to call them,
> `callable' maybe? :-)

The show must go on...

anonymous function - `lambda' - to be honest, to me it has just been
a cute little function inside a set/list/aggregate function,
where no name is needed, but I take it lambda does other
things elsewhere?

recursive function - see this thread:
  https://lists.gnu.org/archive/html/help-gnu-emacs/2020-10/msg00422.html

mutually recursive functions - difficult to debug, e.g. GNU HURD

overloaded function - two functions with the same name. resolution is
done by time, context, or perhaps by the number/types of arguments?

higher-order function - a function that accepts a function as an
arguments. sounds like the list functions above, maybe higher-order
functions can do this with any function? but isn't this always
possible, anyway? with names, anyway. with code maybe macros are used?
(not keyboard macros). personally I'm a basic technician and does not
bother with that advanced stuff

inherited function - classroom whiteboard drawing that no one uses
anyway

a function of his current mood - Emanuel Berg's post

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Stefan Monnier]

>> side-effect free - the function doesn't do any changes to anything,
>> this implies non-destructiveness
> Which is also known as a 'pure' function.

Are `gensym` and `current-time` side-effect-free?  In my book, they're
definitely not pure.


        Stefan

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>>> side-effect free - the function doesn't do any changes to
>>> anything, this implies non-destructiveness
>>
>> Which is also known as a 'pure' function.
>
> Are `gensym` and `current-time` side-effect-free? In my book,
> they're definitely not pure.

Again, why keep track of this? The things mentioned so far, increased
modularity and ease of debug, aren't anything really substantial, is
it? Besides those depend on so much more anyway.

Also, it isn't as simple as side-effect vs. pure. Because some
side-effects are what you want, and some are harmless.

To me, this seems like yet another theoretical model that is
interesting in its own right, it helps us think and reason, like we
are doing right now, but applied as a rulebook what to do as
a practically working engineer, it'll limit you rather than
enhance you.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

Hey, here is one function we/I forgot to mention - local functions!

Used in Emacs Lisp with `cl-labels'.

Advantages:

- keep everything together

- doesn't fill up the global space

- no call to another function so stack won't bubble up and down, this
  could perhaps be of practical concern if the function is called
  many times repeatedly in, say, a loop

Disadvantages:

- difficult to debug as not separated from main function

- make functions too long (almost as long as the functions in Gnus
  *runs away*)

A problem, that doesn't make sense in theory, but does so in
practice: it has to be removed, put into a defun, and the host
function code changed, if it ever turns up it is beneficial to some
other function

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Eli Zaretskii]

> Date: Fri, 23 Oct 2020 18:50:02 +0200
> From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> I rebuilt a new Emacs, namely
> 
>    GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>    3.24.5, cairo version 1.16.0) of 2020-10-23
> 
> because I wanted an Emacs with support for modules (in particular,
> vterm), which isn't possible to get from the Debian repos, IIUC.
> 
> Two issues:
> 
> 1) suddenly no `markdown-mode'? but there is a markdown-mode pack in
>    MELPA, which seems to work OOTB. but as a side not, to move major
>    modes out of core Emacs seems like a bad idea, since they are
>    Emacs' back bone, and besides cannot amount to many bytes, as they
>    are just text. I take it spcific reasons made you do it?

markdown-mode was never in core Emacs.  You need to look at how you
imported it, perhaps you've put the Lisp files in a directory that
Emacs 28 doesn't search by default.

> 2) a lot of errors like this:
> 
>      global-keys.el: 
>      In toplevel form:
>      global-keys.el:8:1: Error: Cannot open load file: No such file or directory, w3m-bookmark

Looks like the same problem as 1).  Somehow the files you expect to be
available are not on load-path.

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

Eli Zaretskii wrote:

>> 2) a lot of errors like this:
>> 
>>      global-keys.el: 
>>      In toplevel form:
>>      global-keys.el:8:1: Error: Cannot open load file: No such file
>> or directory, w3m-bookmark
>
> Looks like the same problem [...] Somehow the files you expect to be
> available are not on load-path.

But they are added, explicitely

  byte-compile=$(emacs) -batch \
  -eval "(setq load-path (append load-path '(\"~/.emacs.d/emacs-init\" \"~/.emacs.d/emacs-init/ide\" \"~/.emacs.d/emacs-init/w3m\" \"~/.emacs.d/emacs-init/gnus\" \"~/.emacs.d/elpa/slime-20190319.930\" \"~/.emacs.d/elpa/google-translate-20190620.1416\" )))" \
  -f batch-byte-compile

in the Makefile [1] - and that must work, since I do the same thing
with for example all my Gnus stuff - the byte-compiler don't complain,
and they are in effect, I see that right now, using Gnus.


[1] https://dataswamp.org/~incal/emacs-init/Makefile

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Stefan Monnier]

> because I wanted an Emacs with support for modules (in particular,
> vterm), which isn't possible to get from the Debian repos, IIUC.

I suggest you `reportbug` about it (to Debian).

>    I take it spcific reasons made you do it?

Who is "you" above referring to?


        Stefan

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

Stefan Monnier wrote:

>> because I wanted an Emacs with support for modules (in particular,
>> vterm), which isn't possible to get from the Debian repos, IIUC.
>
> I suggest you `reportbug` about it (to Debian).

To be exact, IIUC, you can't provide configure options when installing
from the repos. So you can't use the --with-modules option. However,
modules are supported by default in Emacs 27, which is available in
the experimental Debian distribution. [1] Only, I'm using
Debian stable:

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID:	Debian
  Description:	Debian GNU/Linux 10 (buster)
  Release: 10
  Codename:	buster

>> I take it spcific reasons made you do it?
>
> Who is "you" above referring to?

The people who decide if markdown-mode should be in Emacs or in MELPA.


[1] https://packages.debian.org/source/experimental/emacs

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal

Re: problems with Emacs 28

[Gregory Heytings via Users list for the GNU Emacs text editor]

>
> I rebuilt a new Emacs, namely
>
>   GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
>   3.24.5, cairo version 1.16.0) of 2020-10-23
>
> because I wanted an Emacs with support for modules (in particular, 
> vterm), which isn't possible to get from the Debian repos, IIUC.
>

From the official Debian repos, no.  But a weekly build of master is 
available as an emacs-snapshot package from http://emacs.secretsauce.net .

Re: problems with Emacs 28

[Emanuel Berg via Users list for the GNU Emacs text editor]

Gregory Heytings via Users list for the GNU Emacs text editor wrote:

> From the official Debian repos, no. But a weekly build of master is
> available as an emacs-snapshot package from
> http://emacs.secretsauce.net .

I have already built it manually, but good to know.

-- 
underground experts united
http://user.it.uu.se/~embe8573
https://dataswamp.org/~incal