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: Thoughts on getting correct line numbers in the byte compiler's warning messages Date: Sat, 10 Nov 2018 10:59:45 +0000 Message-ID: <20181110105945.GA5515@ACM> References: <20181101175953.GC4504@ACM> <87efbwuqek.fsf@web.de> <20181108110723.GA5041@ACM> <87tvkrngws.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1541847607 8731 195.159.176.226 (10 Nov 2018 11:00:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Nov 2018 11:00:07 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 10 12:00:03 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 1gLQzi-000264-1Z for ged-emacs-devel@m.gmane.org; Sat, 10 Nov 2018 12:00:02 +0100 Original-Received: from localhost ([::1]:37885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLR1o-0000Yy-Dv for ged-emacs-devel@m.gmane.org; Sat, 10 Nov 2018 06:02:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38216) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLR11-0000RI-JW for emacs-devel@gnu.org; Sat, 10 Nov 2018 06:01:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLR0v-00050L-Fm for emacs-devel@gnu.org; Sat, 10 Nov 2018 06:01:21 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:38161 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gLR0v-0004jB-0Q for emacs-devel@gnu.org; Sat, 10 Nov 2018 06:01:17 -0500 Original-Received: (qmail 67443 invoked by uid 3782); 10 Nov 2018 11:01:06 -0000 Original-Received: from acm.muc.de (p5B1460F6.dip0.t-ipconnect.de [91.20.96.246]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 10 Nov 2018 12:01:05 +0100 Original-Received: (qmail 5551 invoked by uid 1000); 10 Nov 2018 10:59:45 -0000 Content-Disposition: inline In-Reply-To: <87tvkrngws.fsf@web.de> 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:231067 Archived-At: Hello, Michael. On Fri, Nov 09, 2018 at 03:06:27 +0100, Michael Heerdegen wrote: > Alan Mackenzie writes: > > Stefan's latest suggestion is to use the above approach just on symbol > > occurrences. (Sorry!). These are preserved through transformations > > much more than cons cells are. > BTW, just to be sure, you know about the already existing variable > `read-with-symbol-positions', right? Only a detail for what you need to > do, though. Oh, yes, we know about this, all right! It's because read-with-symbol-positions doesn't work reliably (there are several bugs open about warning messages reporting wrong positions) that we're trying to develop something better. > > If some code wants to get the starting position of a cons, the source > > code will surely be in a buffer somewhere. As long as there is a symbol > > in the cons (i.e., we don't have ()), surely the cons position can be > > found from the contained symbol, together with backward-up-list in the > > source buffer. Or something like that. > Sure. The problem is how to find the right cons when several such > places exist. Likewise for strings etc. I'm not sure I follow you, here. Surely the "right" cons is the one containing the symbol occurrence whose position is known? Or the one containing that, and so on. Literal strings could also be located, in much the same way as for symbol occurrences. Right at the moment, I don't know how much these things will slow Emacs down by. > My requirement is quite similar to yours, btw. Say, in a buffer at some > position there is a list (X1 X2 X3) and you want to match that with > (i.e. el-search for) pattern `(,P1 ,P2 ,P3) with certain PATTERNS Pi. > In an ideal world, when the Pi are (tried to be) matched against the Xi, > the Pi would know the buffer location of Xi, so that Pi could e.g. use a > `guard' checking the "current" value of point. > Since patterns can do destructuring like above, similar to your case I > would want the position info to somehow survive transformations (mostly > list accessing functions in my case). Yes, it sounds like this could use the "located symbols" feature, too. Right at the moment I'm trying to get SYMBOLP to recognise both normal symbols and "located symbols". This is causing a segfault on building such a test Emacs. :-( > Thanks, > Michael. -- Alan Mackenzie (Nuremberg, Germany).