GNU bug report logs - #33441
reading and printing Lisp Objects - what changed from 25.3.1 to 26.1?

Previous Next

Full log

View this message in rfc822 format

From: Peter Milliken <peter.milliken <at> gmail.com>
To: eliz <at> gnu.org
Cc: 33441 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, npostavs <at> gmail.com
Subject: bug#33441: reading and printing Lisp Objects - what changed from 25.3.1 to 26.1?
Date: Wed, 21 Nov 2018 15:21:43 +1100

[Message part 1 (text/plain, inline)]

I'm not sure that I am giving up on Emacs maintenance - the reference Noam
supplied indicates this is a "well known" issue and somebody, has some
intention, at some stage, to do something about it, but given the last
update to referenced bug/email stream was 268 days ago, that intention may
be on the back burner :-)

Faking up a code snippet is not necessarily that easy - and, again, the
problem described in 29220 sounds exactly like the issue I am having. I
have already supplied the GitHub reference to my package and indicated the
file that contains the functions that use/invoke the read/print processes.
This is a working package, so, in my opinion, that satisfies that request
:-) Using the package is not difficult, it is fully documented with its own
user manual and the writing/reading process of the Lisp Objects is
completely transparent to the user and happens automatically the first time
the minor mode is invoked i.e. any maintainer investigating the issue
shouldn't need to spend too much time getting to a point where they can
debug the issue. The file(s) are written to the "user-emacs-directory".

regards
Peter



On Wed, Nov 21, 2018 at 2:46 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Peter Milliken <peter.milliken <at> gmail.com>
> > Date: Wed, 21 Nov 2018 12:52:57 +1100
> > Cc: 33441 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu
> >
> > I think perhaps you might want to put more information/warnings in
> section 19 of the Elisp manual because it
> > is obviously not true anymore that you can simply Print/Read any
> arbitrary Lisp Object.
> >
> > I'm going to trap the error in my extension and just force
> reading/"compiling" from the original text file instead
> > of reading from the intermediate file created by the print process. This
> will just cause a small delay to the user
> > the first time that a set of language templates get loaded in an edit
> session - probably not a big deal. Certainly,
> > it is better than telling people my extension is "broken" and won't work
> with 26.1 and onwards.
>
> I'd urge you not to give up on Emacs maintenance so quickly, and
> provide the reproducer requested by Paul.  Please give us a chance to
> analyze the problem you are having and consider whether and how it
> could or should be fixed.  Leaving the problems unfixed because we
> failed to look into them is not a good paradigm in maintaining such a
> flexible and powerful software package as Emacs is.
>
> Thanks in advance.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.