From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Fri, 30 Nov 2018 18:55:03 +0000 Message-ID: <20181130185503.GA16256@ACM> References: <20181127074336.GA4705@ACM> <0ec5806a-0cc6-8b9f-6bc2-97875e36a511@cs.ucla.edu> <20181127211539.GB4705@ACM> <8c38f335-b25d-9ef6-110c-6efc4fda9d67@cs.ucla.edu> <20181127215347.GC4705@ACM> <23334086-c0a1-7b34-4234-343719618bd1@cs.ucla.edu> <20181128120443.GA4036@ACM> <20181129220552.GI12576@ACM> <9dde4ed7-8401-6022-a668-258d48bb7726@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543604258 13346 195.159.176.226 (30 Nov 2018 18:57:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2018 18:57:38 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, Eli Zaretskii , emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 30 19:57:34 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gSnym-0003Hs-Ln for ged-emacs-devel@m.gmane.org; Fri, 30 Nov 2018 19:57:32 +0100 Original-Received: from localhost ([::1]:34279 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSo0t-0007s2-35 for ged-emacs-devel@m.gmane.org; Fri, 30 Nov 2018 13:59:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gSo0G-0007ru-3g for emacs-devel@gnu.org; Fri, 30 Nov 2018 13:59:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gSo0B-0004Jq-2D for emacs-devel@gnu.org; Fri, 30 Nov 2018 13:59:04 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:11613 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gSo0A-0004Iv-Fj for emacs-devel@gnu.org; Fri, 30 Nov 2018 13:58:58 -0500 Original-Received: (qmail 12920 invoked by uid 3782); 30 Nov 2018 18:58:55 -0000 Original-Received: from acm.muc.de (p2E5D5BA4.dip0.t-ipconnect.de [46.93.91.164]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 30 Nov 2018 19:58:53 +0100 Original-Received: (qmail 17850 invoked by uid 1000); 30 Nov 2018 18:55:03 -0000 Content-Disposition: inline In-Reply-To: <9dde4ed7-8401-6022-a668-258d48bb7726@cs.ucla.edu> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231541 Archived-At: 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 > , 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., > . 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).