From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Malcolm Newsgroups: gmane.emacs.bugs Subject: bug#25987: 25.2; support gcc fixit notes Date: Wed, 14 Oct 2020 18:43:33 -0400 Message-ID: References: <87lgsj1jle.fsf@tromey.com> <1521218887.2913.237.camel@redhat.com> <83muz7pyde.fsf@gnu.org> <83o8lf9p68.fsf@gnu.org> <26f277bb345f10efe6340ac4074960905064fc97.camel@redhat.com> <83362i2nul.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10604"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) Cc: 25987@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 15 00:44:11 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1kSpVD-0002h0-4U for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Oct 2020 00:44:11 +0200 Original-Received: from localhost ([::1]:35670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSpVC-0007cE-2d for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Oct 2020 18:44:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56700) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSpV4-0007bP-Ez for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2020 18:44:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41875) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kSpV4-0002cP-45 for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2020 18:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kSpV4-0006uR-1F for bug-gnu-emacs@gnu.org; Wed, 14 Oct 2020 18:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 14 Oct 2020 22:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs Original-Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160271542126521 (code B ref 25987); Wed, 14 Oct 2020 22:44:01 +0000 Original-Received: (at 25987) by debbugs.gnu.org; 14 Oct 2020 22:43:41 +0000 Original-Received: from localhost ([127.0.0.1]:53421 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSpUi-0006th-PU for submit@debbugs.gnu.org; Wed, 14 Oct 2020 18:43:41 -0400 Original-Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:53265) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSpUg-0006tY-82 for 25987@debbugs.gnu.org; Wed, 14 Oct 2020 18:43:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602715417; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YG/OCdrNwsahS2toYtU5wLHqunvmFd/CnCjmqNXzZ28=; b=N3UDbIuiDWdB6LX9944qmn7b2rfrXBXQWqIS9oy2U+mtUJhPSMykweMOiDrth2rQgmoSDi fLRia7yRdMZ6UR/NyTi4+FjhtqV4hna2OAXMdKBux4KZmBI6KuU34lJQvAe2fZ91YHMWJZ evtMfih2mWP737Qm+ag+l5ZUM4nuodM= Original-Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-233-KVHbiThXMiGwFRwBxKeoOg-1; Wed, 14 Oct 2020 18:43:35 -0400 X-MC-Unique: KVHbiThXMiGwFRwBxKeoOg-1 Original-Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 31773186DD23; Wed, 14 Oct 2020 22:43:34 +0000 (UTC) Original-Received: from ovpn-112-135.phx2.redhat.com (ovpn-112-135.phx2.redhat.com [10.3.112.135]) by smtp.corp.redhat.com (Postfix) with ESMTP id BAB8961177; Wed, 14 Oct 2020 22:43:33 +0000 (UTC) In-Reply-To: <83362i2nul.fsf@gnu.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=dmalcolm@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:190532 Archived-At: On Tue, 2020-10-13 at 17:37 +0300, Eli Zaretskii wrote: > > From: David Malcolm > > Cc: 25987@debbugs.gnu.org > > Date: Mon, 12 Oct 2020 18:27:29 -0400 > > > > I like how -fdiagnostics-parseable-fixits adds extra lines of > > output, > > with a prefix that's ought to be easy to detect. > > Yes, I think that's preferable, indeed. (nods) > > BTW, does Emacs set anything in the environment that GCC could > > detect? > > Yes, Emacs sets INSIDE_EMACS when it runs a sub-process. I'm increasingly warming to the idea of having it be enabled by an environment variable, rather than a command-line option. My thinking is that it's a pain to have to set up the build system to inject a particular command-line option that's intended purely for consumption by an IDE. As an environment variable, the IDE can inject it into the environment, regardless of whatever build system is in use, and then consume the extra output. (For reference GCC's existing environment variables are listed here: https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html ) Something like GCC_EXTRA_DIAGNOSTIC_SOMETHING=foo, for some SOMETHING and some foo? I thought about maybe emitting JSON, which would be extendable. But it would have to be all on one line, which is less optimal, and would be much more verbose than the existing format. So maybe just use the existing format, but fixing it so that columns are columns, as discussed. So perhaps a fix-it aware Emacs mode could set this when compiling: GCC_EXTRA_DIAGNOSTIC_OUTPUT=fixits-v2 (v2 since v1 is the existing format from the cmdline option) In his email, Andrea suggests outputting to a file. How would that work? It strikes me as making it difficult to associate the output from stderr with that to the file, or would the output to the file need to replace that from stderr (in which case what about lines of output from "make"? or other build system messages, etc). Arguably these various approaches are a poor-man's version of a language server (I tried implementing that for GCC a few years ago, but my proof of concept was not successful: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01448.html ) > > Does Emacs have an automated test suite that could test this > > feature? > > Yes, see the tests in the test/ subdirectory of the Emacs tree. (nods) > > Another complication to consider: the locations in a fix-it hint > > refer > > to the original source file, before any changes are made. If the > > user > > interface supports the user e.g. clicking on fix-it hints and > > selectively apply them one by one, then after each fix-it hint is > > applied, all locations after that point potentially need to be > > "fixed > > up" somehow, to reflect the changes to the buffer. > > That could be handled automatically by defining a marker at each > hint's location, then they will move as text is edited. With the caveat that I'm a mere user of Emacs, that sounds reasonable. (I mentioned it more as a complication I thought of that whoever implements this on the Emacs side needs to be aware of). Thoughts? Dave