unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Alan Mackenzie <acm@muc.de>
Cc: emacs-devel@gnu.org
Subject: Re: scratch/accurate-warning-pos: next steps.
Date: Tue, 11 Dec 2018 13:43:32 -0800	[thread overview]
Message-ID: <b3ed2c6d-7c99-7a19-5a50-000fe86cd372@cs.ucla.edu> (raw)
In-Reply-To: <20181211205128.GD4911@ACM>

On 12/11/18 12:51 PM, Alan Mackenzie wrote:
> Let's just assume we can get a list of functions from somewhere.
> Exactly how is a minor implementation detail.  I only suggested objdump
> to demonstrate it was possible and easy.  I think the C compiler, any C
> compiler, can generate cross references.  That would be another source
> of the info.

I'm afraid that many C compilers don't generate cross references, and 
that this is not a minor implementation detail that we can assume away.


>> That's OK, if the cost is borne only by people who want accurate
>> diagnostics. People who want compilation speed can simply turn off the
>> accurate-diagnostics flag.
> WHAT????  There is no such flag, will be no such flag, MUST be no such
> flag.  We give accurate diagnostics to EVERYBODY, and we do this FAST.

That would be nice, but if we can't do it quickly (without significant 
slowdowns elsewhere, or major contortions to the code) then perhaps 
we'll have to settle for accurate diagnostics as an option.


> The byte compiler is well over 8000 lines of code, much, possibly 
> most, of which would need to be rewritten

Although it would not be trivial to modify 8000 lines of code in a 
tedious but mostly-systematic way, that is not what I would call an 
enormous project. For perspective, the Emacs patch I'm currently hacking 
on (in a different area) is currently about 3000 lines and I wouldn't be 
surprised if it doubled before it's done. Sometimes even 
reasonably-minor conceptual changes require many tedious changes to the 
source code; that's just life when hacking.


> I suggest you take on the task yourself, or organise a team

Thanks, but this issue is not that high on my priority list.


> people writing macros don't have to and mustn't have
> to care about diagnostic mechanisms.  Lisp hackers deserve to get the
> best diagnostics without any such ugly compromises being made.

As I understand it these annotations are not simply concessions to 
limitations of our location implementation; they also provide 
information that are useful for other reasons. I'm still not seeing 
examples of why it would be hard for users to provide the optional 
annotations, if they want the corresponding advantages.




      parent reply	other threads:[~2018-12-11 21:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 18:00 scratch/accurate-warning-pos: next steps Alan Mackenzie
2018-12-10 18:15 ` Eli Zaretskii
2018-12-10 18:28   ` Alan Mackenzie
2018-12-10 18:39     ` Eli Zaretskii
2018-12-10 19:35       ` Alan Mackenzie
2018-12-10 20:06         ` Eli Zaretskii
2018-12-10 21:03           ` Alan Mackenzie
2018-12-11  6:41             ` Eli Zaretskii
2018-12-11 19:21               ` Stefan Monnier
2018-12-11 19:07             ` Stefan Monnier
2018-12-10 23:54 ` Paul Eggert
2018-12-11 11:34   ` Alan Mackenzie
2018-12-11 18:05     ` Paul Eggert
2018-12-11 19:20       ` Alan Mackenzie
2018-12-11 19:59         ` Paul Eggert
2018-12-11 20:51           ` Alan Mackenzie
2018-12-11 21:11             ` Stefan Monnier
2018-12-11 21:35               ` Alan Mackenzie
2018-12-11 22:58                 ` Stefan Monnier
2018-12-11 21:43             ` Paul Eggert [this message]

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b3ed2c6d-7c99-7a19-5a50-000fe86cd372@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).