GNU bug report logs -
#19362
25.0.50; Fix `pp.el' in line with new `elisp-mode.el'
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Sat, 13 Dec 2014 02:48:01 UTC
Severity: minor
Tags: moreinfo, notabug
Found in version 25.0.50
Done: npostavs <at> users.sourceforge.net
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19362 in the body.
You can then email your comments to 19362 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Sat, 13 Dec 2014 02:48:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Drew Adams <drew.adams <at> oracle.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 13 Dec 2014 02:48:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Library `elisp-mode.el' was added after Emacs 24.4. Prior to that,
functions such as `pp-eval-last-sexp' were aligned with the non-pp
sister functions from `lisp-mode.el', such as `eval-last-sexp'.
This is no longer the case. Please bring `pp.el' up to be parallel with
the behavior of `elisp-mode.el', just as it was parallel with the same
and similar code that was previously in `lisp-mode.el'.
In particular, `pp-eval-last-sexp' had the same evaluation behavior as
`eval-lisp-mode'. The addition of pretty-printing was pretty much the
only difference. The two no longer correspond. Please fix this
disparity.
In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
of 2014-10-20 on LEG570
Bzr revision: 118168 rgm <at> gnu.org-20141020195941-icp42t8ttcnud09g
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --enable-checking=yes,glyphs CPPFLAGS=-DGLYPH_DEBUG=1'
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Sat, 30 Apr 2016 16:27:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 19362 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
> Library `elisp-mode.el' was added after Emacs 24.4. Prior to that,
> functions such as `pp-eval-last-sexp' were aligned with the non-pp
> sister functions from `lisp-mode.el', such as `eval-last-sexp'.
>
> This is no longer the case. Please bring `pp.el' up to be parallel with
> the behavior of `elisp-mode.el', just as it was parallel with the same
> and similar code that was previously in `lisp-mode.el'.
>
> In particular, `pp-eval-last-sexp' had the same evaluation behavior as
> `eval-lisp-mode'. The addition of pretty-printing was pretty much the
> only difference. The two no longer correspond. Please fix this
> disparity.
What are the differences you think should be fixed?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Sat, 30 Apr 2016 17:38:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 19362 <at> debbugs.gnu.org (full text, mbox):
> > Library `elisp-mode.el' was added after Emacs 24.4. Prior to that,
> > functions such as `pp-eval-last-sexp' were aligned with the non-pp
> > sister functions from `lisp-mode.el', such as `eval-last-sexp'.
> >
> > This is no longer the case. Please bring `pp.el' up to be parallel with
> > the behavior of `elisp-mode.el', just as it was parallel with the same
> > and similar code that was previously in `lisp-mode.el'.
> >
> > In particular, `pp-eval-last-sexp' had the same evaluation behavior as
> > `eval-lisp-mode'. The addition of pretty-printing was pretty much the
> > only difference. The two no longer correspond. Please fix this
> > disparity.
>
> What are the differences you think should be fixed?
Should be aligned as it was before. Someone evolved the one
without evolving the other in tandem.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Sat, 30 Apr 2016 17:44:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 19362 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> > Library `elisp-mode.el' was added after Emacs 24.4. Prior to that,
>> > functions such as `pp-eval-last-sexp' were aligned with the non-pp
>> > sister functions from `lisp-mode.el', such as `eval-last-sexp'.
>> >
>> > This is no longer the case. Please bring `pp.el' up to be parallel with
>> > the behavior of `elisp-mode.el', just as it was parallel with the same
>> > and similar code that was previously in `lisp-mode.el'.
>> >
>> > In particular, `pp-eval-last-sexp' had the same evaluation behavior as
>> > `eval-lisp-mode'. The addition of pretty-printing was pretty much the
>> > only difference. The two no longer correspond. Please fix this
>> > disparity.
>>
>> What are the differences you think should be fixed?
>
> Should be aligned as it was before. Someone evolved the one
> without evolving the other in tandem.
Do you have a list of things that you think should be aligned?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Sat, 30 Apr 2016 18:17:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 19362 <at> debbugs.gnu.org (full text, mbox):
> Do you have a list of things that you think should be aligned?
No, but diff of the source code should show it. ;-)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Sat, 30 Apr 2016 18:34:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 19362 <at> debbugs.gnu.org (full text, mbox):
Drew Adams <drew.adams <at> oracle.com> writes:
>> Do you have a list of things that you think should be aligned?
>
> No, but diff of the source code should show it. ;-)
I'm afraid that if you don't have anything specific you want to have
fixed, there won't be any more progress happening in this bug report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Fri, 01 Jul 2016 02:05:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 19362 <at> debbugs.gnu.org (full text, mbox):
tags 19362 moreinfo
quit
Drew Adams <drew.adams <at> oracle.com> writes:
>> Do you have a list of things that you think should be aligned?
>
> No, but diff of the source code should show it. ;-)
I tried diffing pp.el and elisp-mode.el, but it was unenlightening.
Like this bug report.
Added tag(s) moreinfo.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Fri, 01 Jul 2016 02:05:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Fri, 01 Jul 2016 03:09:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 19362 <at> debbugs.gnu.org (full text, mbox):
> >> Do you have a list of things that you think should be aligned?
> >
> > No, but diff of the source code should show it. ;-)
>
> I tried diffing pp.el and elisp-mode.el, but it was unenlightening.
> Like this bug report.
Yes, well, it's quite difficult. Some of the code from lisp-mode.el
was moved to elisp-mode.el. And then it was modified, in some cases
radically. Dunno why, except that some of the changes seem to have
involved integrating eldoc. But most of the changes presumably do not
concern this bug, which is only about the part of lisp-mode.el that
had functions that correspond to pp.el functions.)
===> The starting point is `eval-last-sexp', which used to correspond
directly with `pp-eval-last-sexp'. The former was (presumably)
improved, but the latter was not modified similarly.
Some functions were renamed to add the prefix `elisp-' or `elisp--'
(e.g. `elisp--preceding-sexp', `elisp--eval-last-sexp',
`elisp--eval-last-sexp-print-value', `elisp--eval-last-sexp-fake-value',
`elisp--eval-defun-1', `elisp--eval-defun'), so knowing that can help.
In some cases they were just renamed. In other cases the code was
changed quite a bit. But again, this bug is only about the pp-like
code.
This is not something you will understand in 5 minutes. It likely
requires understanding the changes that were made to `eval-last-sexp'
and its supporting functions, and then doing the right thing (not
necessarily exactly the same thing) for `pp-eval-last-sexp'. The
pp.el code was slightly different from the Emacs 24.4 (and prior)
lisp-mode.el code (different helper functions, and one does not
involve pretty-printing), but they generally mirror one another.
Using their former correspondence as a guide should help.
I cannot help more than this. It is unfortunate that the person
who changed the non-pp version did not think to act similarly for
the pp version. I discovered it late, myself. Once things are
properly understood, perhaps the code fix will be minor. Dunno.
With luck, you will find and understand the changes made to
`eval-last-sexp' as a straightforward improvement that do not
involve all of the other changes from lisp-mode.el code to
elisp-mode.el code. With luck, perhaps the person(s) who made
the changes to the non-pp code can look at this bug. No doubt
that would be easiest.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Wed, 06 Jul 2016 20:40:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 19362 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jun 30, 2016 at 11:07 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
>> >> Do you have a list of things that you think should be aligned?
>> >
>> > No, but diff of the source code should show it. ;-)
>>
>> I tried diffing pp.el and elisp-mode.el, but it was unenlightening.
>> Like this bug report.
>
> Yes, well, it's quite difficult. Some of the code from lisp-mode.el
> was moved to elisp-mode.el. And then it was modified, in some cases
> radically. Dunno why, except that some of the changes seem to have
> involved integrating eldoc. But most of the changes presumably do not
> concern this bug, which is only about the part of lisp-mode.el that
> had functions that correspond to pp.el functions.)
>
> ===> The starting point is `eval-last-sexp', which used to correspond
> directly with `pp-eval-last-sexp'. The former was (presumably)
> improved, but the latter was not modified similarly.
>
> Some functions were renamed to add the prefix `elisp-' or `elisp--'
> (e.g. `elisp--preceding-sexp', `elisp--eval-last-sexp',
> `elisp--eval-last-sexp-print-value', `elisp--eval-last-sexp-fake-value',
> `elisp--eval-defun-1', `elisp--eval-defun'), so knowing that can help.
> In some cases they were just renamed. In other cases the code was
> changed quite a bit. But again, this bug is only about the pp-like
> code.
>
> This is not something you will understand in 5 minutes. It likely
> requires understanding the changes that were made to `eval-last-sexp'
> and its supporting functions, and then doing the right thing (not
> necessarily exactly the same thing) for `pp-eval-last-sexp'. The
> pp.el code was slightly different from the Emacs 24.4 (and prior)
> lisp-mode.el code (different helper functions, and one does not
> involve pretty-printing), but they generally mirror one another.
> Using their former correspondence as a guide should help.
>
> I cannot help more than this. It is unfortunate that the person
> who changed the non-pp version did not think to act similarly for
> the pp version. I discovered it late, myself. Once things are
> properly understood, perhaps the code fix will be minor. Dunno.
But do you know of any concrete cases where there is a difference in
behaviour? Or is this report just about code duplication (or lack
thereof)?
I found #10495 "pp-eval-last-sexp doesn't work on a `symbol' in
quotes", but that was reported against 24.0.92, so perhaps these
functions were in fact never "aligned"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Wed, 06 Jul 2016 22:37:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 19362 <at> debbugs.gnu.org (full text, mbox):
> But do you know of any concrete cases where there is a difference in
> behaviour? Or is this report just about code duplication (or lack
> thereof)?
1. I don't know about concrete cases; sorry.
2. This report is an enhancement request; it doesn't report a bug.
In the past, `eval-last-sexp' and `pp-eval-last-sexp' did about the
same thing, apart from the pretty-printing part (which the latter
farms out to another function). My guess is that _improvements_
were made to the former case (only). Just what those improvements
were and why they were made I don't know.
> I found #10495 "pp-eval-last-sexp doesn't work on a `symbol' in
> quotes", but that was reported against 24.0.92, so perhaps these
> functions were in fact never "aligned"?
The functions used to be mostly "aligned", but it's possible that
the difference Michael points out in #10495 was present. I don't
know.
In any case, I was not really referring to the interactive behavior
but to the code/behavior after the sexp has been determined. In
the case of `eval-last-sexp' I guess that means the code other
than `elisp--preceding-sexp'. I'm interested in both, but I don't
think I was paying attention to differences that are covered by the
`elisp--preceding-sexp' code.
Michael's bug is all about extending what `elisp--preceding-sexp'
does to pp.el. It could perhaps be a good start, in terms of
realignment. On the other hand, that behavior seems to be overly
DWIM, making heuristic assumptions about what sexp you _really_
wanted to evaluate. I'm not sure that's always such a good thing.
I'd probably rather have that DWIM be a user choice (option).
`pp-eval-last-sexp' is much simpler.
In any case, what `elisp--preceding-sexp' is/does is not really
what I had in mind about the code divergence, as you rightfully
observed. So I guess this bug report is somewhat complementary
to Michael's report.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Wed, 06 Jul 2016 23:38:01 GMT)
Full text and
rfc822 format available.
Message #37 received at 19362 <at> debbugs.gnu.org (full text, mbox):
On Wed, Jul 6, 2016 at 6:35 PM, Drew Adams <drew.adams <at> oracle.com> wrote:
>> But do you know of any concrete cases where there is a difference in
>> behaviour? Or is this report just about code duplication (or lack
>> thereof)?
>
> 1. I don't know about concrete cases; sorry.
>
> 2. This report is an enhancement request; it doesn't report a bug.
>
> In the past, `eval-last-sexp' and `pp-eval-last-sexp' did about the
> same thing, apart from the pretty-printing part (which the latter
> farms out to another function).
So you're not talking about the difference between pp-to-string vs
elisp--eval-last-sexp-print-value.
> My guess is that _improvements_
> were made to the former case (only). Just what those improvements
> were and why they were made I don't know.
[...]
> In any case, I was not really referring to the interactive behavior
> but to the code/behavior after the sexp has been determined. In
> the case of `eval-last-sexp' I guess that means the code other
> than `elisp--preceding-sexp'.
And you're not talking about the difference between (pp-last-sexp) vs
(eval-sexp-add-defvars (elisp--preceding-sexp)).
What's left? They both call eval in the middle. eval-last-sexp honours
eval-expression-debug-on-error while pp-eval-last-sexp does not (this
was the case for the old lisp-mode.el code in 24.3 as well). Other
than that I don't see anything of significance.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Wed, 06 Jul 2016 23:52:02 GMT)
Full text and
rfc822 format available.
Message #40 received at 19362 <at> debbugs.gnu.org (full text, mbox):
> > In the past, `eval-last-sexp' and `pp-eval-last-sexp' did about the
> > same thing, apart from the pretty-printing part (which the latter
> > farms out to another function).
>
> So you're not talking about the difference between pp-to-string vs
> elisp--eval-last-sexp-print-value.
>
> > My guess is that _improvements_
> > were made to the former case (only). Just what those improvements
> > were and why they were made I don't know.
> [...]
> > In any case, I was not really referring to the interactive behavior
> > but to the code/behavior after the sexp has been determined. In
> > the case of `eval-last-sexp' I guess that means the code other
> > than `elisp--preceding-sexp'.
>
> And you're not talking about the difference between (pp-last-sexp) vs
> (eval-sexp-add-defvars (elisp--preceding-sexp)).
>
> What's left? They both call eval in the middle. eval-last-sexp honours
> eval-expression-debug-on-error while pp-eval-last-sexp does not (this
> was the case for the old lisp-mode.el code in 24.3 as well). Other
> than that I don't see anything of significance.
Sorry, but I have no more time to devote to this. I pointed to a
time where the code was more or less the same between the two, and
to a time where it had been changed to be really quite different.
It seemed (and still seems) clear to me that the non-pp version was
altered considerably - probably improving something, or adapting to
some other change (lexical binding, perhaps?), and the pp version
was not altered similarly. My guess is that the pp version was
considered less important or was simply overlooked/ignored.
I think it deserves a similar look. If no one wants to do that,
so be it.
If you feel you've taken a careful look and understand what changed
and why, and that none of the changes can be usefully extended to
pp, fine. I'm not looking at this anymore, so you'll get no argument
from me. I think I've said all I want to say about this. Thanks for
having taken a look.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Thu, 07 Jul 2016 00:27:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 19362 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
tags 19362 notabug
close 19362
quit
Drew Adams <drew.adams <at> oracle.com> writes:
>
> Sorry, but I have no more time to devote to this. I pointed to a
> time where the code was more or less the same between the two, and
> to a time where it had been changed to be really quite different.
Well, we could have all saved some time if you had taken your own advice
to diff the code; not pp.el vs elisp-mode.el, but emacs-24.5's
lisp-mode.el vs the new elisp-mode.el. You can see in the attached diff
(exerpted to leave only the relevant functions) that the only changes
are renaming of functions, and some minor refactoring in
elisp--preceding-sexp (it now handles ‘foo’ as well as `foo').
[elisp-lisp-mode.diff (text/x-diff, attachment)]
Added tag(s) notabug.
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Thu, 07 Jul 2016 00:27:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
19362 <at> debbugs.gnu.org and Drew Adams <drew.adams <at> oracle.com>
Request was from
npostavs <at> users.sourceforge.net
to
control <at> debbugs.gnu.org
.
(Thu, 07 Jul 2016 00:27:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#19362
; Package
emacs
.
(Thu, 07 Jul 2016 02:35:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 19362 <at> debbugs.gnu.org (full text, mbox):
> Well, we could have all saved some time if you had taken your own advice
> to diff the code; not pp.el vs elisp-mode.el, but emacs-24.5's
> lisp-mode.el vs the new elisp-mode.el. You can see in the attached diff
> (exerpted to leave only the relevant functions) that the only changes
> are renaming of functions, and some minor refactoring in
> elisp--preceding-sexp (it now handles ‘foo’ as well as `foo').
I never suggested diffing pp.el against either lisp-mode.el or
elisp-mode.el. And actually I did compare lisp-mode.el with
elisp-mode.el and different versions of lisp-mode.el. I said
this, which I maintain:
> Yes, well, it's quite difficult. Some of the code from lisp-mode.el
> was moved to elisp-mode.el. And then it was modified, in some cases
> radically. Dunno why, except that some of the changes seem to have
> involved integrating eldoc. But most of the changes presumably do not
> concern this bug, which is only about the part of lisp-mode.el that
> had functions that correspond to pp.el functions.)
It should be clear that wrt what I was following (and comparing)
of the evolution, what I saw was not just renaming of functions
and minor refactoring. But of course I was also trying to see
how the changes compared to the pp.el code - what corresponding
changes might be in order for pp.el. That was, uh, the point of
the report. Whatever. Thanks for taking a look anyway. Sorry
that you apparently wasted your time.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 04 Aug 2016 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 319 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.