From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Date: Thu, 19 Mar 2020 17:41:30 -0400 Message-ID: References: <20200319203449.GA4180@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="127186"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Rocky Bernstein , emacs-devel To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 19 22:42:09 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jF2vZ-000X0q-FE for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Mar 2020 22:42:09 +0100 Original-Received: from localhost ([::1]:43480 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jF2vY-00005w-Ia for ged-emacs-devel@m.gmane-mx.org; Thu, 19 Mar 2020 17:42:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52936) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jF2v2-00083F-Ld for emacs-devel@gnu.org; Thu, 19 Mar 2020 17:41:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jF2v1-0004Cg-78 for emacs-devel@gnu.org; Thu, 19 Mar 2020 17:41:36 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13481) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jF2v1-0004CE-2p; Thu, 19 Mar 2020 17:41:35 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3198044F642; Thu, 19 Mar 2020 17:41:33 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A7E8E44F626; Thu, 19 Mar 2020 17:41:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1584654091; bh=qak8qLziZl+yzSEbdYUWBofXsM9CCosR+QwymVgLj1o=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=RVgR36ej/VBlted5P8B0y/fkEcZhuoqXbtwn3lRffQ4G/KxqB4M3r6KrVm6xSNtxs hx20R44CH42ShF2HH9kOps98c6Gs01lNsja1FuEAJ/vvMup6m2/rVkA6cGjZ5XDSSG HJ+qIQKEEPvJSGCozlEuQDePSNiNQCQAPJsRCaaHbU1eePSdRcsJLlBrkZ+kwtMEJ6 Py9W2/paUTyXba/wQSEwuJeTtih0Gjk4YEIUwk1kDZNfo/YCAEerySJRwi+FPCTa7J YpYJUEQw+Wu3CS13FfrJwaSLbfS4KhVd+qyvlIrv32TACiffwQ0zPsJ7gO9KvU4Yhw eDLOCvq4K2Pww== Original-Received: from alfajor (unknown [104.247.241.114]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 74183120406; Thu, 19 Mar 2020 17:41:31 -0400 (EDT) In-Reply-To: <20200319203449.GA4180@ACM> (Alan Mackenzie's message of "Thu, 19 Mar 2020 20:34:49 +0000") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245591 Archived-At: > things like cconv.el here). More to the point, users' macros chew up and > spit out cons cells, and we have no control over them. So whilst we > could, with a lot of tedious effort, clean up our own software to > preserve cons cells (believe me, I've tried), this would fail in users' > macros. I think fat-cons cells are cheap to implement (with (hopefully) no performance impact when not used or weird semantic artifacts like the fat-symbol approach you tried) and can work 99.9% right in the long term with an incremental way to get there. Furthermore it matches the "usual" way to deal with this problem, so there's very little doubt about whether it can work or not. > Since then I've worked a fair bit on creating a "double" Emacs core, one > core being for normal use, the other for byte compiling. There's a fair > amount of work still to do on this, but I know how to do it. The problem > is that I have been discouraged by the prospect of having this solution > vetoed too, since it will make Emacs quite a bit bigger. I'd probably try to veto it, indeed. It might be a good solution in the short-term but it'd just slow down our progress in the long term. Stefan