From: Alan Mackenzie <acm@muc.de>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: michael_heerdegen@web.de, Eli Zaretskii <eliz@gnu.org>,
emacs-devel@gnu.org, cpitclaudel@gmail.com,
monnier@IRO.UMontreal.CA
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Fri, 30 Nov 2018 18:55:03 +0000 [thread overview]
Message-ID: <20181130185503.GA16256@ACM> (raw)
In-Reply-To: <9dde4ed7-8401-6022-a668-258d48bb7726@cs.ucla.edu>
Hello, Paul.
On Fri, Nov 30, 2018 at 09:50:09 -0800, Paul Eggert wrote:
> On 11/29/18 2:05 PM, Alan Mackenzie wrote:
> > We're not talking about macros generating messages for invalid
> > input. we're talking about generating message positions for the
> > source being compiled.
> I'm not sure what you mean here. The point of this exercise, as I
> understand it, is to generate better diagnostics for Lisp code that has
> problems in it (or is "invalid input" in some sense).
Then you've completely misunderstood.
The point of the exercise is specific, not vague as you have
misformulated it. It is to print the correct source locations in
compiler warnings which are currently being output as wrong locations.
For example, read bug #9109.
> Such code may define macros, and it may use those macros or may use
> macros defined elsewhere. If you're saying that we should talk only
> about problems in the part of the code that uses macros, and not about
> problems in the part of the code that defines macros, then that sounds
> like a conversation that would be too narrow.
Feel free to have that wider conversation, somewhere. I might even join
in. It is orthogonal to the current set of bugs.
> >
> >> I'm afraid we'll have to disagree here, as I can see examples where
> >> symbols-with-pos fails ....
> > I can't. Please give an example, so I can see what you're talking about.
> I attempted to give one in
> <https://lists.gnu.org/r/emacs-devel/2018-11/msg00530.html>, but you
> dismissed it as not relevant to the discussion. As mentioned above, I
> don't see why it's irrelevant.
I hope you now see why it is irrelevant, and will take back the
insinuation that symbols-with-pos fails, in the sense of bug #9101.
> > Symbols-with-pos exists, works, and works well. Conses-with-pos
> > doesn't exist, hence doesn't work. I doubt it can work. Can you
> > create it?
> I think I could, with time.
But you're not going to?
> I hope someone else will do it, though, as the problem does not seem
> that urgent. I would suggest that whoever does it, looks into Stefan's
> ideas in this area, e.g.,
> <https://lists.gnu.org/r/emacs-devel/2018-11/msg00532.html>.
Nobody else is going to do it, and why should they? I've already
explained to you why the approach you suggest won't work, you being
about the only person insisting that it will. If you actually tried it,
as I have, you'd soon find out that I'm right, and why.
And if we only fixed "urgent" bugs, not a lot would get done on Emacs.
These bugs have been hanging around Emacs for many, many years, and it's
about high time they finally got fixed. I have fixed them.
> > is the idea of the two instances of code still live?
> It's live only in the sense that it's better than
> scratch/accurate-warning-pos because of performance issues. I'd rather
> that we did something better than either.
There are no performance "issues". Emacs with this bug fix is minutely
slower than without it, not enough to matter. If you insist there are
"issues", then please perform some timings and report them here.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2018-11-30 18:55 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-17 12:45 scratch/accurate-warning-pos: First tentative successes Alan Mackenzie
2018-11-17 13:13 ` Eli Zaretskii
2018-11-23 13:09 ` scratch/accurate-warning-pos: Solid progress: the branch now bootstraps Alan Mackenzie
2018-11-25 11:26 ` Charles A. Roelli
2018-11-25 14:31 ` Alan Mackenzie
2018-11-25 15:12 ` Andreas Schwab
2018-11-25 15:42 ` Alan Mackenzie
2018-11-25 16:40 ` Eli Zaretskii
2018-11-25 17:59 ` Alan Mackenzie
2018-11-25 18:15 ` Eli Zaretskii
2018-11-25 18:23 ` Alan Mackenzie
2018-11-25 19:36 ` Alan Mackenzie
2018-11-25 16:22 ` Stefan Monnier
2018-11-25 17:35 ` Alan Mackenzie
2018-11-25 18:22 ` Stefan Monnier
2018-11-25 19:54 ` Alan Mackenzie
2018-11-25 20:08 ` Stefan Monnier
2018-11-26 9:52 ` Alan Mackenzie
2018-11-26 10:16 ` Alan Mackenzie
2018-11-25 16:38 ` Eli Zaretskii
2018-11-25 17:27 ` Andreas Schwab
2018-11-25 17:31 ` Alan Mackenzie
2018-11-25 17:39 ` Eli Zaretskii
2018-11-25 18:08 ` Alan Mackenzie
2018-11-25 18:45 ` Paul Eggert
2018-11-25 19:30 ` Alan Mackenzie
2018-11-25 20:12 ` Paul Eggert
2018-11-25 21:29 ` Alan Mackenzie
2018-11-26 1:41 ` Paul Eggert
2018-11-26 3:41 ` Eli Zaretskii
2018-11-26 17:43 ` Paul Eggert
2018-11-26 18:43 ` Alan Mackenzie
2018-11-26 19:18 ` Clément Pit-Claudel
2018-11-26 19:42 ` Alan Mackenzie
2018-11-27 1:07 ` Gemini Lasswell
2018-11-27 1:45 ` Alan Mackenzie
2018-11-27 6:06 ` Eli Zaretskii
2018-11-27 2:48 ` Paul Eggert
2018-11-27 7:43 ` Alan Mackenzie
2018-11-27 20:27 ` Paul Eggert
2018-11-27 21:15 ` Alan Mackenzie
2018-11-27 21:37 ` Paul Eggert
2018-11-27 21:53 ` Alan Mackenzie
2018-11-28 1:11 ` Paul Eggert
2018-11-28 12:04 ` Alan Mackenzie
2018-11-29 21:28 ` Paul Eggert
2018-11-29 22:05 ` Alan Mackenzie
2018-11-30 17:50 ` Paul Eggert
2018-11-30 18:55 ` Alan Mackenzie [this message]
2018-11-30 20:14 ` Paul Eggert
2018-11-30 22:02 ` Alan Mackenzie
2018-11-30 23:46 ` Paul Eggert
2018-12-01 7:35 ` martin rudalics
2018-12-01 8:25 ` Eli Zaretskii
2018-12-01 11:08 ` Alan Mackenzie
2018-12-01 11:36 ` Eli Zaretskii
2018-12-01 12:47 ` Alan Mackenzie
2018-12-01 14:09 ` martin rudalics
2018-12-01 14:30 ` Stefan Monnier
2018-12-01 16:30 ` martin rudalics
2018-12-01 19:56 ` Stefan Monnier
2018-12-01 14:59 ` Eli Zaretskii
2018-12-01 16:31 ` martin rudalics
2018-12-01 16:53 ` Eli Zaretskii
2018-12-01 19:04 ` martin rudalics
2018-12-01 19:22 ` Eli Zaretskii
2018-12-01 17:21 ` Alan Mackenzie
2018-12-01 17:44 ` Michael Heerdegen
2018-12-01 18:58 ` Alan Mackenzie
2018-12-01 20:26 ` Alan Mackenzie
2018-12-01 17:48 ` Eli Zaretskii
2018-12-01 21:00 ` Paul Eggert
2018-12-01 17:50 ` Clément Pit-Claudel
2018-12-01 18:26 ` Yuri Khan
2018-12-01 19:15 ` Clément Pit-Claudel
2018-12-01 21:26 ` Paul Eggert
2018-12-02 6:48 ` Yuri Khan
2018-12-02 18:39 ` Gemini Lasswell
2018-12-03 2:28 ` Stefan Monnier
2018-12-01 19:04 ` martin rudalics
2018-12-02 22:53 ` Dmitry Gutov
2018-12-01 0:26 ` Gemini Lasswell
2018-12-01 11:48 ` Alan Mackenzie
2018-11-27 22:09 ` Stefan Monnier
2018-11-28 2:18 ` Paul Eggert
2018-11-28 2:43 ` Stefan Monnier
2018-11-28 5:13 ` Paul Eggert
2018-11-28 6:03 ` Gemini Lasswell
2018-11-28 5:39 ` Gemini Lasswell
2018-11-28 13:06 ` Stefan Monnier
2018-11-28 6:28 ` Eli Zaretskii
2018-11-28 22:50 ` Paul Eggert
2018-11-29 7:19 ` Eli Zaretskii
2018-11-29 10:54 ` Alan Mackenzie
2018-11-29 11:13 ` Eli Zaretskii
2018-11-29 11:37 ` Alan Mackenzie
2018-11-29 21:12 ` Paul Eggert
2018-11-29 21:28 ` Alan Mackenzie
2018-11-28 0:53 ` Gemini Lasswell
2018-11-26 20:04 ` Stefan Monnier
2018-11-27 2:51 ` Paul Eggert
2018-11-26 9:48 ` Alan Mackenzie
2018-11-26 18:27 ` Paul Eggert
2018-11-25 18:48 ` Gemini Lasswell
2018-11-25 20:02 ` Stefan Monnier
2018-11-26 12:39 ` Alan Mackenzie
2018-11-26 16:14 ` Gemini Lasswell
2018-11-26 17:06 ` Alan Mackenzie
2018-11-26 17:24 ` Alan Mackenzie
2018-11-29 12:26 ` scratch/accurate-warning-pos: Some real world timings Alan Mackenzie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181130185503.GA16256@ACM \
--to=acm@muc.de \
--cc=cpitclaudel@gmail.com \
--cc=eggert@cs.ucla.edu \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=michael_heerdegen@web.de \
--cc=monnier@IRO.UMontreal.CA \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.