From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Tom Tromey Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Mar 2017 21:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 25987@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.14887505241381 (code B ref -1); Sun, 05 Mar 2017 21:49:01 +0000 Received: (at submit) by debbugs.gnu.org; 5 Mar 2017 21:48:44 +0000 Received: from localhost ([127.0.0.1]:41449 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cke1D-0000MC-QX for submit@debbugs.gnu.org; Sun, 05 Mar 2017 16:48:44 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cke1B-0000Lz-0Q for submit@debbugs.gnu.org; Sun, 05 Mar 2017 16:48:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cke14-0006r9-3l for submit@debbugs.gnu.org; Sun, 05 Mar 2017 16:48:35 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:42094) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cke14-0006qy-0B for submit@debbugs.gnu.org; Sun, 05 Mar 2017 16:48:34 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cke12-0005s4-5X for bug-gnu-emacs@gnu.org; Sun, 05 Mar 2017 16:48:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cke0y-0006nc-SJ for bug-gnu-emacs@gnu.org; Sun, 05 Mar 2017 16:48:32 -0500 Received: from gproxy3-pub.mail.unifiedlayer.com ([69.89.30.42]:55020) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1cke0y-0006kJ-8L for bug-gnu-emacs@gnu.org; Sun, 05 Mar 2017 16:48:28 -0500 Received: (qmail 14469 invoked by uid 0); 5 Mar 2017 21:48:06 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy3.mail.unifiedlayer.com with SMTP; 5 Mar 2017 21:48:06 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw3 with id sMo11u0072f2jeq01Mo4bY; Sun, 05 Mar 2017 14:48:06 -0700 X-Authority-Analysis: v=2.1 cv=WOnsABcR c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=6Iz7jQTuP9IA:10 a=ZZ9aQZciIvDeoGKFjbAA:9 a=ao9AAyzj6h5c4hyZ:21 a=uWkv48RfckupUjmw:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Date:Subject:To:From:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=4xvU36TKnclxafVxEo3+zRiGEgFIhIWJv7OtpqdOQDM=; b=Kx/YAPUCkc5HWpOPW/S3kJfTzC U2RYl3cigW6J6MLEkt3al4zEKMLIqq4ciPMNIxl8v8zzglYuSrMJXl24XNZQzJOL0Lywj12Q2ESzQ ZhrrOYY+6Jw6PWbsoq0Evqfr0; Received: from 71-218-43-111.hlrn.qwest.net ([71.218.43.111]:54548 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cke0W-0001Xk-Uz; Sun, 05 Mar 2017 14:48:01 -0700 From: Tom Tromey X-Attribution: Tom Date: Sun, 05 Mar 2017 14:47:57 -0700 Message-ID: <87lgsj1jle.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box522.bluehost.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 71.218.43.111 X-Exim-ID: 1cke0W-0001Xk-Uz X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 71-218-43-111.hlrn.qwest.net (bapiya) [71.218.43.111]:54548 X-Source-Auth: tom+tromey.com X-Email-Count: 1 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) With -fdiagnostics-parseable-fixits, GCC can emit "fixit" notes that tell how to apply a patch to fix a problem. For example for this: struct x { int field; }; struct x y; int main() { return y.feld; } I get: q.c: In function =E2=80=98main=E2=80=99: q.c:8:12: error: =E2=80=98struct x=E2=80=99 has no member named =E2=80=98fe= ld=E2=80=99; did you mean =E2=80=98field=E2=80=99? return y.feld; ^~~~ field fix-it:"q.c":{8:12-8:16}:"field" The documentation, from the gcc manual: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @item -fdiagnostics-parseable-fixits @opindex fdiagnostics-parseable-fixits Emit fix-it hints in a machine-parseable format, suitable for consumption by IDEs. For each fix-it, a line will be printed after the relevant diagnostic, starting with the string ``fix-it:''. For example: @smallexample fix-it:"test.c":@{45:3-45:21@}:"gtk_widget_show_all" @end smallexample The location is expressed as a half-open range, expressed as a count of bytes, starting at byte 1 for the initial column. In the above example, bytes 3 through 20 of line 45 of ``test.c'' are to be replaced with the given string: @smallexample 00000000011111111112222222222 12345678901234567890123456789 gtk_widget_showall (dlg); ^^^^^^^^^^^^^^^^^^ gtk_widget_show_all @end smallexample The filename and replacement string escape backslash as ``\\", tab as ``\t'= ', newline as ``\n'', double quotes as ``\"'', non-printable characters as oct= al (e.g. vertical tab as ``\013''). An empty replacement string indicates that the given range is to be removed. An empty range (e.g. ``45:3-45:3'') indicates that the string is to be inserted at the given position. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I think Emacs should support this in compilation mode buffers. A few thoughts on the implementation: * The filename quoting stuff will require a bit of unquoting * The offsets are byte offsets, not columns, which is a bit of a pain (or at least, it is for me since I don't know how to handle that in elisp) * One way for this to work would be to display the buffer and=20 show the proposed change as an overlay; and then use y-or-n-p to ask whether it should be applied. I was thinking something like: (defun compilation--fixit-make-overlay (start end text) (let ((overlay (make-overlay start end))) (overlay-put overlay 'face 'diff-removed) (overlay-put overlay 'after-string (propertize text 'face 'diff-added)) overlay)) With this approach perhaps nothing could be done if the fixit was already visited, or if the buffer text already matches the replacement. * However other approaches are possible, like letting the user request no confirmation, or request "auto-apply all changes" or something. Maybe a fixit should be associated with the previous error somehow. * Allowing "fixit" to be handled specially in compile mode might mean adding a new "type" value, not sure. Tom In GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.22.8) of 2017-03-02 built on bapiya Repository revision: 6e788ef0e262fafc014c21f4ad52cc5dc9f1715b Windowing system distributor 'Fedora Project', version 11.0.11901000 System Description: Fedora release 25 (Twenty Five) Configured using: 'configure --prefix=3D/home/tromey/Emacs/install/ --with-modules' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES Important settings: value of $LANG: en_US.utf8 value of $XMODIFIERS: @im=3Dibus locale-coding-system: utf-8-unix Major mode: Emacs-Lisp Minor modes in effect: shell-dirtrack-mode: t diff-auto-refine-mode: t flyspell-mode: t which-function-mode: t global-auto-revert-mode: t erc-services-mode: t erc-list-mode: t erc-menu-mode: t erc-autojoin-mode: t erc-ring-mode: t erc-networks-mode: t erc-pcomplete-mode: t erc-track-mode: t erc-match-mode: t erc-netsplit-mode: t erc-hl-nicks-mode: t erc-button-mode: t erc-fill-mode: t erc-stamp-mode: t erc-irccontrols-mode: t erc-noncommands-mode: t erc-move-to-prompt-mode: t erc-readonly-mode: t savehist-mode: t tooltip-mode: t global-eldoc-mode: t eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t auto-fill-function: do-auto-fill transient-mark-mode: t Recent messages: Discard changes to this group and exit? (y or n) y Are you sure you want to quit reading news? (y or n) y Saving Gnus registry (13456 entries) to ~/.gnus.registry.eieio... Saving Gnus registry (size 13456) to ~/.gnus.registry.eieio...done Saving file /home/tromey/.newsrc... Wrote /home/tromey/.newsrc Saving /home/tromey/.newsrc.eld... Saving file /home/tromey/.newsrc.eld... Wrote /home/tromey/.newsrc.eld Saving /home/tromey/.newsrc.eld...done Load-path shadows: /home/tromey/.emacs.d/elpa/bubbles-0.5/bubbles hides /home/tromey/Emacs/ins= tall/share/emacs/25.2/lisp/play/bubbles /home/tromey/.emacs.d/elpa/soap-client-3.1.1/soap-inspect hides /home/trome= y/Emacs/install/share/emacs/25.2/lisp/net/soap-inspect /home/tromey/.emacs.d/elpa/soap-client-3.1.1/soap-client hides /home/tromey= /Emacs/install/share/emacs/25.2/lisp/net/soap-client Features: (org-bullets org-element org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view image-mode org-bibtex bibtex org-bbdb org-w3m org org-macro org-footnote org-pcomplete org-list org-faces org-entities noutline outline org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat org-macs org-loaddefs gnus-html xml url-cache mm-url url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf gnus-draft xref project mail-hist nnir url-util url-parse url-vars shr-color shr dom subr-x browse-url flow-fill mm-archive smiley gnus-cite gnus-async gnus-bcklg qp gnus-ml disp-table gnus-topic nndraft nnmh nnfolder utf-7 bbdb-gnus bbdb-mua bbdb-com crm gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg nntp gnus-cache gnus-registry registry eieio-compat eieio-base gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo parse-time gnus-spec gnus-int gnus-range gnus-win gnus gnus-ems nnheader cus-edit find-dired bug-reference texinfo vc-mtn vc-hg tabify man term/xterm xterm shadow emacsbug network-stream nsm starttls tls gnutls mailalias smtpmail sort mailcap bbdb-message sendmail mail-extr vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs whitespace log-edit message idna dired rfc822 mml mml-sec epg mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev mail-utils gmm-utils mailheader pcvs-util cc-mode cc-fonts cc-guess cc-menus cc-cmds shell rx dabbrev eieio-opt speedbar sb-image ezimage dframe find-func copyright debug add-log vc-git diff-mode easy-mmode misearch multi-isearch jka-compr flyspell ispell diminish edmacro kmacro projectile grep compile ibuf-ext ibuffer dash appt diary-lib diary-loaddefs cal-menu calendar cal-loaddefs which-func imenu minimap autorevert filenotify cus-start cus-load status erc-services erc-list erc-menu erc-join erc-ring erc-networks erc-pcomplete pcomplete erc-track erc-match erc-netsplit erc-hl-nicks color erc-button erc-fill erc-stamp wid-edit erc-goodies erc erc-backend erc-compat format-spec auth-source eieio gnus-util mm-util help-fns mail-prsvr password-cache thingatpt pp warnings advice vc-dir ewoc vc vc-dispatcher cc-styles cc-align cc-engine cc-vars cc-defs bbdb bbdb-site timezone ange-ftp comint ansi-color ring server savehist finder-inf dwarf-mode-autoloads gdb-shell-autoloads eieio-core lisppaste-autoloads pydoc-info-autoloads info-look cl-seq cl-macs cl weblogger-autoloads info package epg-config seq byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv cl-loaddefs pcase cl-lib bbdb-loaddefs time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 997972 86208) (symbols 48 117986 0) (miscs 40 21518 46) (strings 32 431164 32131) (string-bytes 1 10881610) (vectors 16 99059) (vector-slots 8 2222084 4114) (floats 8 851 728) (intervals 56 31730 1034) (buffers 976 62)) From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Mar 2017 18:37:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tom Tromey Cc: 25987@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148882537823999 (code B ref 25987); Mon, 06 Mar 2017 18:37:01 +0000 Received: (at 25987) by debbugs.gnu.org; 6 Mar 2017 18:36:18 +0000 Received: from localhost ([127.0.0.1]:43109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckxUY-0006F1-6H for submit@debbugs.gnu.org; Mon, 06 Mar 2017 13:36:18 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ckxUW-0006En-ET for 25987@debbugs.gnu.org; Mon, 06 Mar 2017 13:36:16 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ckxUN-00032a-C0 for 25987@debbugs.gnu.org; Mon, 06 Mar 2017 13:36:11 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ckxUN-00032W-83; Mon, 06 Mar 2017 13:36:07 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2297 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ckxUM-0004e0-H1; Mon, 06 Mar 2017 13:36:07 -0500 Date: Mon, 06 Mar 2017 20:35:55 +0200 Message-Id: <83efyai778.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87lgsj1jle.fsf@tromey.com> (message from Tom Tromey on Sun, 05 Mar 2017 14:47:57 -0700) References: <87lgsj1jle.fsf@tromey.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Tom Tromey > Date: Sun, 05 Mar 2017 14:47:57 -0700 > > I think Emacs should support this in compilation mode buffers. I agree, it would be a good feature. > A few thoughts on the implementation: > > * The filename quoting stuff will require a bit of unquoting Perhaps shell-unquote-argument will help? > * The offsets are byte offsets, not columns, which is a bit of a pain > (or at least, it is for me since I don't know how to handle that in > elisp) Ouch! why did they do it in bytes? That's worth a bug report, IMO. Anyway, filepos-to-bufferpos could help with this problem. > * One way for this to work would be to display the buffer and > show the proposed change as an overlay; Or maybe a tooltip on GUI frames? > * However other approaches are possible, like letting the user request > no confirmation, or request "auto-apply all changes" or something. > Maybe a fixit should be associated with the previous error somehow. Is there perhaps some "prior art" for this in other IDEs out there? Thanks. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Tom Tromey Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Mar 2017 13:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org, Tom Tromey Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.14888948814629 (code B ref 25987); Tue, 07 Mar 2017 13:55:02 +0000 Received: (at 25987) by debbugs.gnu.org; 7 Mar 2017 13:54:41 +0000 Received: from localhost ([127.0.0.1]:43744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clFZZ-0001Ca-FI for submit@debbugs.gnu.org; Tue, 07 Mar 2017 08:54:41 -0500 Received: from gproxy9-pub.mail.unifiedlayer.com ([69.89.20.122]:45544 helo=gproxy9.mail.unifiedlayer.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clFZX-0001CM-5z for 25987@debbugs.gnu.org; Tue, 07 Mar 2017 08:54:39 -0500 Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id DE3181E0720 for <25987@debbugs.gnu.org>; Tue, 7 Mar 2017 06:54:27 -0700 (MST) Received: from box522.bluehost.com ([74.220.219.122]) by CMOut01 with id t1uP1u00b2f2jeq011uSSW; Tue, 07 Mar 2017 06:54:27 -0700 X-Authority-Analysis: v=2.1 cv=Ath9goNP c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=6Iz7jQTuP9IA:10 a=uCwpq-ptF4TB8Hgb_poA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=xYOgTudTSINgmhP3bhnKlMI0Ub1dvOis43S4GvTIUjM=; b=VCYQWXchK5s6yfun08OSia8tqe vIrB79EL9BUjZAXFOpRzR2zsu3/MLTvMUwV+0nxJMkG8P05E4VQ6hd1tdZByVfwU8whwePdJ2jAGq VevYj7LFhiIqtTI5cZIPd0nft; Received: from 67-6-181-22.hlrn.qwest.net ([67.6.181.22]:56774 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1clFZH-0000Ru-H6; Tue, 07 Mar 2017 06:54:23 -0700 From: Tom Tromey References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> X-Attribution: Tom Date: Tue, 07 Mar 2017 06:54:15 -0700 In-Reply-To: <83efyai778.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Mar 2017 20:35:55 +0200") Message-ID: <878toh19bs.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box522.bluehost.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 67.6.181.22 X-Exim-ID: 1clFZH-0000Ru-H6 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 67-6-181-22.hlrn.qwest.net (bapiya) [67.6.181.22]:56774 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.5 (/) Eli> Ouch! why did they do it in bytes? That's worth a bug report, IMO. I'll see if I can find out the rationale. >> * One way for this to work would be to display the buffer and >> show the proposed change as an overlay; Eli> Or maybe a tooltip on GUI frames? Yeah. Or even buttonizing the text so it could be fixed by clicking or C-RET or something like that. >> * However other approaches are possible, like letting the user request >> no confirmation, or request "auto-apply all changes" or something. >> Maybe a fixit should be associated with the previous error somehow. Eli> Is there perhaps some "prior art" for this in other IDEs out there? It's a good question but I don't know the answer. Tom From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Mar 2017 15:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tom Tromey Cc: 25987@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148890214517087 (code B ref 25987); Tue, 07 Mar 2017 15:56:02 +0000 Received: (at 25987) by debbugs.gnu.org; 7 Mar 2017 15:55:45 +0000 Received: from localhost ([127.0.0.1]:44766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clHSj-0004RW-5x for submit@debbugs.gnu.org; Tue, 07 Mar 2017 10:55:45 -0500 Received: from eggs.gnu.org ([208.118.235.92]:56941) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clHSh-0004RK-JS for 25987@debbugs.gnu.org; Tue, 07 Mar 2017 10:55:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clHSZ-0007Dy-Ap for 25987@debbugs.gnu.org; Tue, 07 Mar 2017 10:55:38 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38974) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clHSZ-0007Dt-7c; Tue, 07 Mar 2017 10:55:35 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4033 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1clHSX-00009U-MO; Tue, 07 Mar 2017 10:55:34 -0500 Date: Tue, 07 Mar 2017 17:55:06 +0200 Message-Id: <83tw75gjz9.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <878toh19bs.fsf@tromey.com> (message from Tom Tromey on Tue, 07 Mar 2017 06:54:15 -0700) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Tom Tromey > Cc: Tom Tromey , 25987@debbugs.gnu.org > Date: Tue, 07 Mar 2017 06:54:15 -0700 > > Eli> Ouch! why did they do it in bytes? That's worth a bug report, IMO. > > I'll see if I can find out the rationale. Thanks. > >> * However other approaches are possible, like letting the user request > >> no confirmation, or request "auto-apply all changes" or something. > >> Maybe a fixit should be associated with the previous error somehow. > > Eli> Is there perhaps some "prior art" for this in other IDEs out there? > > It's a good question but I don't know the answer. Maybe it's worth asking on emacs-devel. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Tom Tromey Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Mar 2017 18:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org, Tom Tromey Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.14889980969339 (code B ref 25987); Wed, 08 Mar 2017 18:35:02 +0000 Received: (at 25987) by debbugs.gnu.org; 8 Mar 2017 18:34:56 +0000 Received: from localhost ([127.0.0.1]:46634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clgQK-0002QZ-FZ for submit@debbugs.gnu.org; Wed, 08 Mar 2017 13:34:56 -0500 Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:36584) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1clgQJ-0002QM-0V for 25987@debbugs.gnu.org; Wed, 08 Mar 2017 13:34:55 -0500 Received: (qmail 12667 invoked by uid 0); 8 Mar 2017 18:34:43 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy2.mail.unifiedlayer.com with SMTP; 8 Mar 2017 18:34:43 -0000 Received: from box522.bluehost.com ([74.220.219.122]) by cmgw4 with id tWaf1u00H2f2jeq01Wai3y; Wed, 08 Mar 2017 11:34:43 -0700 X-Authority-Analysis: v=2.1 cv=R4+QR7hX c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=6Iz7jQTuP9IA:10 a=Twlkf-z8AAAA:8 a=nsm7zcIx6NiVIp9evpIA:9 a=b7jcOwihhWAA:10 a=eqUqhmPFYAgA:10 a=-74SuR6ZdpOK_LpdRCUo:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=taGUQx7SkmwNwi2yg/8W8ynuDFbiIcH4ltiTV+s7chg=; b=s7O2fDstFiewMVFDQwet+J+tPD pQaVUg19JIBWSCVTzYnHY0rbiBmxUs1WP2e8yYEbzm4gciKo34UVsbx5WTmZfjqLIG9Yw1xtAgaSG 4swmPJp7xhXvd4ElI3T+GG8sU; Received: from 67-6-181-22.hlrn.qwest.net ([67.6.181.22]:53386 helo=pokyo) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1clgQ2-0008Jb-VR; Wed, 08 Mar 2017 11:34:39 -0700 From: Tom Tromey References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <83tw75gjz9.fsf@gnu.org> X-Attribution: Tom Date: Wed, 08 Mar 2017 11:34:38 -0700 In-Reply-To: <83tw75gjz9.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 07 Mar 2017 17:55:06 +0200") Message-ID: <87a88v7h35.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box522.bluehost.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 67.6.181.22 X-Exim-ID: 1clgQ2-0008Jb-VR X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 67-6-181-22.hlrn.qwest.net (pokyo) [67.6.181.22]:53386 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-Spam-Score: 2.7 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Tom> I'll see if I can find out the rationale. Eli> Thanks. The reason is compatibility with clang, which had this option first. http://releases.llvm.org/3.8.0/tools/clang/docs/UsersManual.html#cmdoption-fdiagnostics-parseable-fixits [...] Content analysis details: (2.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [69.89.18.3 listed in psbl.surriel.com] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [69.89.18.3 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [69.89.18.3 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 2.7 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Tom> I'll see if I can find out the rationale. Eli> Thanks. The reason is compatibility with clang, which had this option first. http://releases.llvm.org/3.8.0/tools/clang/docs/UsersManual.html#cmdoption-fdiagnostics-parseable-fixits [...] Content analysis details: (2.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [69.89.18.3 listed in wl.mailspike.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [69.89.18.3 listed in list.dnswl.org] 2.7 RCVD_IN_PSBL RBL: Received via a relay in PSBL [69.89.18.3 listed in psbl.surriel.com] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid Tom> I'll see if I can find out the rationale. Eli> Thanks. The reason is compatibility with clang, which had this option first. http://releases.llvm.org/3.8.0/tools/clang/docs/UsersManual.html#cmdoption-fdiagnostics-parseable-fixits Tom From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Tom Tromey Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Mar 2017 18:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tom Tromey Cc: 25987@debbugs.gnu.org, Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148899872010259 (code B ref 25987); Wed, 08 Mar 2017 18:46:02 +0000 Received: (at 25987) by debbugs.gnu.org; 8 Mar 2017 18:45:20 +0000 Received: from localhost ([127.0.0.1]:46638 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clgaO-0002fO-HC for submit@debbugs.gnu.org; Wed, 08 Mar 2017 13:45:20 -0500 Received: from gproxy9-pub.mail.unifiedlayer.com ([69.89.20.122]:56822 helo=gproxy9.mail.unifiedlayer.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clgaN-0002fC-97 for 25987@debbugs.gnu.org; Wed, 08 Mar 2017 13:45:19 -0500 Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 2C9301E08EF for <25987@debbugs.gnu.org>; Wed, 8 Mar 2017 11:45:11 -0700 (MST) Received: from box522.bluehost.com ([74.220.219.122]) by cmgw3 with id tWl31u00J2f2jeq01Wl6PL; Wed, 08 Mar 2017 11:45:11 -0700 X-Authority-Analysis: v=2.1 cv=WOnsABcR c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=6Iz7jQTuP9IA:10 a=JIVOxcAaAAAA:8 a=ONy5B95qJStNmMpJs7YA:9 a=qjdIn5W-ogUA:10 a=3oOLeku9CYwbEqEY-gKj:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=25iSmpbLL63H/sXPlrD29oJL+gt/SyAGQ5igSRB55II=; b=pbCvDDhM5AJqUinzH0hAXr0pec FoB/IM2WQ5g0L1KOz+7lBr461AJGwYxR+PvDRvE9Rzss47mu154YULkvz5QB+qrzx100qJFhe+T82 DrZmDXhKEIA/1kbLPGVG2lVSD; Received: from 67-6-181-22.hlrn.qwest.net ([67.6.181.22]:53512 helo=pokyo) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1clga6-0002C5-UK; Wed, 08 Mar 2017 11:45:03 -0700 From: Tom Tromey References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> X-Attribution: Tom Date: Wed, 08 Mar 2017 11:44:59 -0700 In-Reply-To: <878toh19bs.fsf@tromey.com> (Tom Tromey's message of "Tue, 07 Mar 2017 06:54:15 -0700") Message-ID: <874lz37glw.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box522.bluehost.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 67.6.181.22 X-Exim-ID: 1clga6-0002C5-UK X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 67-6-181-22.hlrn.qwest.net (pokyo) [67.6.181.22]:53512 X-Source-Auth: tom+tromey.com X-Email-Count: 4 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli> Is there perhaps some "prior art" for this in other IDEs out there? Tom> It's a good question but I don't know the answer. David Malcolm (who wrote the gcc feature) pointed me at the Eclipse bug for this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=497670 It sounds like they're going to integrate it into their "quick fix" feature, which is an Eclipse thing. They also discuss the need to attach the fixit to an earlier error. Tom From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Mar 2017 19:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tom Tromey Cc: 25987@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148900099013826 (code B ref 25987); Wed, 08 Mar 2017 19:24:01 +0000 Received: (at 25987) by debbugs.gnu.org; 8 Mar 2017 19:23:10 +0000 Received: from localhost ([127.0.0.1]:46666 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clhB0-0003av-2l for submit@debbugs.gnu.org; Wed, 08 Mar 2017 14:23:10 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60119) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clhAy-0003aj-UD for 25987@debbugs.gnu.org; Wed, 08 Mar 2017 14:23:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clhAq-0002j5-IS for 25987@debbugs.gnu.org; Wed, 08 Mar 2017 14:23:03 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34278) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clhAq-0002j1-Ex; Wed, 08 Mar 2017 14:23:00 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1512 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1clhAp-0006SI-NP; Wed, 08 Mar 2017 14:23:00 -0500 Date: Wed, 08 Mar 2017 21:22:35 +0200 Message-Id: <837f3zh8uc.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <87a88v7h35.fsf@tromey.com> (message from Tom Tromey on Wed, 08 Mar 2017 11:34:38 -0700) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <83tw75gjz9.fsf@gnu.org> <87a88v7h35.fsf@tromey.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Tom Tromey > Cc: Tom Tromey , 25987@debbugs.gnu.org > Date: Wed, 08 Mar 2017 11:34:38 -0700 > > Tom> I'll see if I can find out the rationale. > > Eli> Thanks. > > The reason is compatibility with clang, which had this option first. > http://releases.llvm.org/3.8.0/tools/clang/docs/UsersManual.html#cmdoption-fdiagnostics-parseable-fixits Thanks. So maybe GCC should have a similar option, named differently, which would report in characters. Anyway, "we have the technology" in Emacs to deal with this. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Mar 2017 19:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tom Tromey Cc: 25987@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148900137514410 (code B ref 25987); Wed, 08 Mar 2017 19:30:02 +0000 Received: (at 25987) by debbugs.gnu.org; 8 Mar 2017 19:29:35 +0000 Received: from localhost ([127.0.0.1]:46682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clhHC-0003kM-Sy for submit@debbugs.gnu.org; Wed, 08 Mar 2017 14:29:35 -0500 Received: from eggs.gnu.org ([208.118.235.92]:33429) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clhHB-0003k9-LX for 25987@debbugs.gnu.org; Wed, 08 Mar 2017 14:29:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clhH1-0004lX-S7 for 25987@debbugs.gnu.org; Wed, 08 Mar 2017 14:29:28 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34348) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clhH1-0004lT-Oh; Wed, 08 Mar 2017 14:29:23 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1552 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1clhH1-0002Cr-3e; Wed, 08 Mar 2017 14:29:23 -0500 Date: Wed, 08 Mar 2017 21:28:59 +0200 Message-Id: <8360jjh8jo.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <874lz37glw.fsf@tromey.com> (message from Tom Tromey on Wed, 08 Mar 2017 11:44:59 -0700) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <874lz37glw.fsf@tromey.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Tom Tromey > Cc: Eli Zaretskii , 25987@debbugs.gnu.org > Date: Wed, 08 Mar 2017 11:44:59 -0700 > > David Malcolm (who wrote the gcc feature) pointed me at the Eclipse bug > for this: > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=497670 > > It sounds like they're going to integrate it into their "quick fix" > feature, which is an Eclipse thing. Thanks. Quick fixes work by presenting a kind of tooltip. We should probably have something similar, but it cannot be the only UI, to support TTY and GUI users who don't like the mouse. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Richard Stallman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 04:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org, tom@tromey.com Reply-To: rms@gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148903324717771 (code B ref 25987); Thu, 09 Mar 2017 04:21:02 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 04:20:47 +0000 Received: from localhost ([127.0.0.1]:46968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clpZH-0004cZ-60 for submit@debbugs.gnu.org; Wed, 08 Mar 2017 23:20:47 -0500 Received: from eggs.gnu.org ([208.118.235.92]:42126) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clpZF-0004cN-G4 for 25987@debbugs.gnu.org; Wed, 08 Mar 2017 23:20:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clpZ9-0005r3-2y for 25987@debbugs.gnu.org; Wed, 08 Mar 2017 23:20:40 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:40768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clpYr-0005ma-Rl; Wed, 08 Mar 2017 23:20:21 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1clpYq-0005R3-RY; Wed, 08 Mar 2017 23:20:20 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman In-reply-to: <837f3zh8uc.fsf@gnu.org> (message from Eli Zaretskii on Wed, 08 Mar 2017 21:22:35 +0200) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <83tw75gjz9.fsf@gnu.org> <87a88v7h35.fsf@tromey.com> <837f3zh8uc.fsf@gnu.org> Message-Id: Date: Wed, 08 Mar 2017 23:20:20 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > The reason is compatibility with clang, which had this option first. > > http://releases.llvm.org/3.8.0/tools/clang/docs/UsersManual.html#cmdoption-fdiagnostics-parseable-fixits > Thanks. So maybe GCC should have a similar option, named differently, > which would report in characters. I am not sure whether that is serious or in jest. Do you have a serious suggestion for a change in GCC? If so, what would it be? -- Dr Richard Stallman President, Free Software Foundation (gnu.org, fsf.org) Internet Hall-of-Famer (internethalloffame.org) Skype: No way! See stallman.org/skype.html. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 15:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: rms@gnu.org Cc: 25987@debbugs.gnu.org, tom@tromey.com Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.14890738393451 (code B ref 25987); Thu, 09 Mar 2017 15:38:01 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 15:37:19 +0000 Received: from localhost ([127.0.0.1]:47855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm07y-0000tb-Oc for submit@debbugs.gnu.org; Thu, 09 Mar 2017 10:37:18 -0500 Received: from eggs.gnu.org ([208.118.235.92]:51487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm07x-0000tO-EX for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 10:37:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cm07n-0005f3-Ss for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 10:37:12 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49061) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cm07n-0005ez-P4; Thu, 09 Mar 2017 10:37:07 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2203 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cm07g-00042R-KV; Thu, 09 Mar 2017 10:37:01 -0500 Date: Thu, 09 Mar 2017 17:36:39 +0200 Message-Id: <831su6h37c.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Richard Stallman on Wed, 08 Mar 2017 23:20:20 -0500) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <83tw75gjz9.fsf@gnu.org> <87a88v7h35.fsf@tromey.com> <837f3zh8uc.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Richard Stallman > CC: tom@tromey.com, 25987@debbugs.gnu.org > Date: Wed, 08 Mar 2017 23:20:20 -0500 > > > > The reason is compatibility with clang, which had this option first. > > > http://releases.llvm.org/3.8.0/tools/clang/docs/UsersManual.html#cmdoption-fdiagnostics-parseable-fixits > > > Thanks. So maybe GCC should have a similar option, named differently, > > which would report in characters. > > I am not sure whether that is serious or in jest. It's serious. > Do you have a serious suggestion for a change in GCC? > If so, what would it be? Like I wrote: I think GCC should introduce a (differently-named) option which would report positions inside a line in terms of characters, not bytes. Reports in bytes require applications that use these hints to somehow preserve or reconstruct the original encoding of the file as it was presented to the compiler, something that could be a pain. I understand why GCC developers wanted to be bug-compatible with clang, to allow the various front-ends use GCC without any changes, but it sounds wrong for GCC to be forever stuck with this bad design decision made by clang. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 16:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tom Tromey , 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148907629614169 (code B ref 25987); Thu, 09 Mar 2017 16:19:02 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 16:18:16 +0000 Received: from localhost ([127.0.0.1]:47909 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm0lc-0003gT-9r for submit@debbugs.gnu.org; Thu, 09 Mar 2017 11:18:16 -0500 Received: from mail-wm0-f46.google.com ([74.125.82.46]:33983) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm0la-0003gG-LE for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 11:18:15 -0500 Received: by mail-wm0-f46.google.com with SMTP id 196so36695961wmm.1 for <25987@debbugs.gnu.org>; Thu, 09 Mar 2017 08:18:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8yHxMk+uvk8ISqj3v7FyvKXH/2ItGv138C99i4HJmkg=; b=sZqPBeLOABzVhV2SNV6NN1Z5phnKs3+YXkvm+V1kmnLL2avCoG9uYW+hy5/NW3NspO rkefxjlpyyhgh+pJBRbZQ+u2RyNNDGpanCaMMXXzGlSntTs+1W/j0BQxPW/dJpt8asp7 mRsVA9Zdvv+VrcaXYByUyiNvpgb+Zymw9h1iTsTOZ4xHIR1HkCCLH4/fSaripEawUkpT 1DBaY6ak90OgKnSAM1GdfPJIXAJxJ3j3GvehR2wFB6VynegDgCBcaRmjo19qg9roHTmD iPVMebzerSfMX6HDN1e+2dyliCYHUk/pDq7mf2k5LapR2/7A/+78S6uReEaVYVRCJGB5 ETdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8yHxMk+uvk8ISqj3v7FyvKXH/2ItGv138C99i4HJmkg=; b=S3dSGjz/ydrS7T9jt08dObACXKZ2+92bjmL0w1BtC5vx84UElQk1hPal3lQo4wzknb 8ZC+1ihiMuPQ390OCqQGmhEVt0wl/72XiUO47YBfkodqYrHP/k4CXeVZCrANHA34Xh/K ZN7NayYVu7U/qzxLXN6u5lOrFadVNEh36svuB28Ipu2IKfvwZrRUmAz4Md6jutJ2JCZU D2oSHd23n/sfpbkx6r4wVIzoCrlmpzy9T6vg7Kgo7Mevrsod+KpzJb2yGcB9ee7ydb7R 0CVXNCGiA+MN/9YV2DbZge37ALfZIgla79DMNumn/JsMRQf1w1eem6W7B+LPIN5oRYsx tM6Q== X-Gm-Message-State: AMke39kHiEA1SroYVVxCIJZanQn4e80LP8JCJAIo3dW8Fu6VmnA/1a3rUSe2Nsi1t54hrg== X-Received: by 10.28.137.211 with SMTP id l202mr11188541wmd.118.1489076288291; Thu, 09 Mar 2017 08:18:08 -0800 (PST) Received: from [192.168.0.133] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id j184sm27851108wmd.31.2017.03.09.08.18.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 08:18:07 -0800 (PST) References: <87lgsj1jle.fsf@tromey.com> From: Dmitry Gutov Message-ID: Date: Thu, 9 Mar 2017 18:18:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <87lgsj1jle.fsf@tromey.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) On 05.03.2017 23:47, Tom Tromey wrote: > * One way for this to work would be to display the buffer and > show the proposed change as an overlay; and then use y-or-n-p > to ask whether it should be applied. I was thinking something like: > > (defun compilation--fixit-make-overlay (start end text) > (let ((overlay (make-overlay start end))) > (overlay-put overlay 'face 'diff-removed) > (overlay-put overlay 'after-string > (propertize text 'face 'diff-added)) > overlay)) > > With this approach perhaps nothing could be done if the fixit was > already visited, or if the buffer text already matches the > replacement. I'm not sure we want to tie this feature to compilation-mode. Many modes that derive from it don't support fix-its, e.g. those of them that run the test suites. And even for those that do, Compilation provides a very basic UI. Even to find and apply all fix-its, we'd need to add some new buffer, to show the list. On the other hand, this can be a quick-and-dirty way to try out the feature and how handy it is. Showing the "quick fix" buttons on top of the fix-it text can be it (not sure it that's the UI you had in mind). From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 16:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Tom Tromey Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148907746615917 (code B ref 25987); Thu, 09 Mar 2017 16:38:02 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 16:37:46 +0000 Received: from localhost ([127.0.0.1]:47923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm14T-00048e-Fl for submit@debbugs.gnu.org; Thu, 09 Mar 2017 11:37:46 -0500 Received: from mail-wr0-f177.google.com ([209.85.128.177]:34435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm14R-00048P-CY for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 11:37:43 -0500 Received: by mail-wr0-f177.google.com with SMTP id l37so48798657wrc.1 for <25987@debbugs.gnu.org>; Thu, 09 Mar 2017 08:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z/d+8DAqmvNDrYXFEuUZCHH9gAFyIvzBqcnHtUsA3vA=; b=KGiNGj6OfXWgrlyhKp7tX2V2M1F+aBAYCXiH8ZxLGV3yYDy7HSiF65VaTfscG+SSOY LwGNczpzoFwEwL80lCGaFwNCZNe89PKRMgE+UPfExOco1usrCjfLdCHPGFo1Vs8cWdMu C3JiWNAAJSOCyksnDh3AA/KdreavBzeg2xJI/b5R0kigMT2skzScPc3BI28bTrg5pMxi WTNB42uuGPC/oAKRdITD0+qnwjViMXkrnxiXXAm5NxB4j54N0WVOveKLi/rAsOIGhmXd nmMZRPpWChr1fDVyIlGZ7KfAuJJI0VRqY0EO82aejXyeyIyTwVj6MpEmJHvq+lk9hWxG 07/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z/d+8DAqmvNDrYXFEuUZCHH9gAFyIvzBqcnHtUsA3vA=; b=l11zEq4ky9J5a9rhJZSGZiD9V7BzLEV2QZXYqZXS9PVBrFr3zlPtqFzqHKDqochK7q CaMcVttS7q0ZzJEh76sUaynIgD3d2U6MtG9yiOOGbb48DlIYOfk7QeYjsGVfAD8KaKxb Rpw6aoz2CXPFGaszpSrdFNKWZeRMd1kDVHi+hZsUpF7N4EPPg/OVQMhWsbWr5QdMj1QL aAM0g0RNBCGAW5w3cCvJqdRArBgLYAdtFSUNKAuAgq4QF15jCMJV0pZOTXgHtnkMatw4 X7EBhC33o3SdsqhTE41/dN3QqcHGDi3ZH9DmEJ62mWieG18rqPi7yfmh0+1JAJXQJyun +SCA== X-Gm-Message-State: AMke39nkPAYN+IjOh1J4VwnDYTsCxEsZJkR5gFZBJr4Hx91O1H9QtRat3WRlPam8mErFvA== X-Received: by 10.223.177.18 with SMTP id l18mr11766299wra.96.1489077457490; Thu, 09 Mar 2017 08:37:37 -0800 (PST) Received: from [192.168.0.133] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id 61sm8855260wrs.29.2017.03.09.08.37.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 08:37:36 -0800 (PST) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <874lz37glw.fsf@tromey.com> <8360jjh8jo.fsf@gnu.org> From: Dmitry Gutov Message-ID: <11da16db-d636-8cb2-142e-5d240cd88d1c@yandex.ru> Date: Thu, 9 Mar 2017 18:37:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <8360jjh8jo.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.8 (/) On 08.03.2017 21:28, Eli Zaretskii wrote: > Quick fixes work by presenting a kind of tooltip. We should probably > have something similar, but it cannot be the only UI, to support TTY > and GUI users who don't like the mouse. Tooltip or not, that's a visualization concern. I think a better first question would be where this feature would fit among the existing Emacs tools. If we look at Eclipse and friends, we can observe that (almost?) every warning or error that the IDE shows to the user comes with a set of actions, suggesting possible fixes, improvements, etc. Thinking along these lines, the closest things we have are Flymake and Flyspell. The third-party Flycheck is even better is several respects (e.g. it can show a listing of all problems in the file buffer), but sadly we won't be able to use it, since the primary author is sternly against copyright assignment. But it'd be good to teach Flymake about fixits, and when we can't use tooltips, use a text-based prompts a la Flyspell. Bonus points for teaching Flymake to use multiple checkers in one file, and making Flyspell one of them. I guess the first difficulty is how to reconcile project-global compilation logs with buffer-local warnings and errors. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 16:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 25987@debbugs.gnu.org, tom@tromey.com Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148907842317779 (code B ref 25987); Thu, 09 Mar 2017 16:54:01 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 16:53:43 +0000 Received: from localhost ([127.0.0.1]:47928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm1Jv-0004ch-AD for submit@debbugs.gnu.org; Thu, 09 Mar 2017 11:53:43 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm1Ju-0004cV-2M for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 11:53:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cm1Jj-0004Xh-JY for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 11:53:36 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cm1Jj-0004Xd-Gk; Thu, 09 Mar 2017 11:53:31 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2310 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cm1Ji-0004Sd-Kp; Thu, 09 Mar 2017 11:53:31 -0500 Date: Thu, 09 Mar 2017 18:53:08 +0200 Message-Id: <83pohqfl3f.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Dmitry Gutov on Thu, 9 Mar 2017 18:18:04 +0200) References: <87lgsj1jle.fsf@tromey.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Dmitry Gutov > Date: Thu, 9 Mar 2017 18:18:04 +0200 > > I'm not sure we want to tie this feature to compilation-mode. Many modes > that derive from it don't support fix-its, e.g. those of them that run > the test suites. And even for those that do, Compilation provides a very > basic UI. So you suggest a separate minor mode, is that right? From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 16:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 25987@debbugs.gnu.org, tom@tromey.com Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148907861218107 (code B ref 25987); Thu, 09 Mar 2017 16:57:02 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 16:56:52 +0000 Received: from localhost ([127.0.0.1]:47932 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm1Mx-0004hx-Ow for submit@debbugs.gnu.org; Thu, 09 Mar 2017 11:56:52 -0500 Received: from eggs.gnu.org ([208.118.235.92]:50791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm1Mw-0004hk-Ra for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 11:56:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cm1Mn-0006E1-40 for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 11:56:45 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50180) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cm1Mn-0006Dw-0I; Thu, 09 Mar 2017 11:56:41 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2312 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cm1Mm-00051j-4Y; Thu, 09 Mar 2017 11:56:40 -0500 Date: Thu, 09 Mar 2017 18:56:18 +0200 Message-Id: <83mvcufky5.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <11da16db-d636-8cb2-142e-5d240cd88d1c@yandex.ru> (message from Dmitry Gutov on Thu, 9 Mar 2017 18:37:30 +0200) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <874lz37glw.fsf@tromey.com> <8360jjh8jo.fsf@gnu.org> <11da16db-d636-8cb2-142e-5d240cd88d1c@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 25987@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 9 Mar 2017 18:37:30 +0200 > > If we look at Eclipse and friends, we can observe that (almost?) every > warning or error that the IDE shows to the user comes with a set of > actions, suggesting possible fixes, improvements, etc. > > Thinking along these lines, the closest things we have are Flymake and > Flyspell. The third-party Flycheck is even better is several respects > (e.g. it can show a listing of all problems in the file buffer), but > sadly we won't be able to use it, since the primary author is sternly > against copyright assignment. It sounds gross to ask people to use Flymake just to be able to use something like this. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 17:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org, tom@tromey.com Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148908107628667 (code B ref 25987); Thu, 09 Mar 2017 17:38:01 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 17:37:56 +0000 Received: from localhost ([127.0.0.1]:47963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm20h-0007SJ-FH for submit@debbugs.gnu.org; Thu, 09 Mar 2017 12:37:55 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:34961) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm20f-0007S5-CX for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 12:37:53 -0500 Received: by mail-wm0-f68.google.com with SMTP id z63so12070554wmg.2 for <25987@debbugs.gnu.org>; Thu, 09 Mar 2017 09:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cq9YAfgFAvvECDuhk6nE+DDlWaWHt2Yd5SemxKtpTx0=; b=YODIm5xw+D8zW6XrdVf/JgdDqei1KIAZK5s2IWLD0d60DO4YU1/uRjKy/alXrUPdpi 7SP1On+cJXhg0TVHvAv8ToDbiIePCmhIZB0vgechQnSpSEDVLbyxjPxDLTqLDglob+yQ bGEFBz0+9OaNZpyt3DakJ4EenpwOW6E/ahii1mxwuxppbQjxMYHDHcc7ROApVpB0PCFk VSDbXTlVbCuMrJrCkZtP0rFuNUqLs7bDcSG5OVSP+2KAQaNISOq/Cv8iD22xlBjVtPjQ TpCK5Vo1Bs0TBO0aL/zOOtcrn4UUTvxUXHXXNEpMC0IzPcBeZEFKWNVBvjFGKyMz3Phs /+Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cq9YAfgFAvvECDuhk6nE+DDlWaWHt2Yd5SemxKtpTx0=; b=SqzREQv55vIcSv/0jt/GYIBq/PR85Uq0GsxWBc8w+b8TYBQmEGLGhwhAkRSbdA2CWN PQP/qIiKA9FtgES/i/VjgChX/D9RoBvPcGCDQdhhNw6K+pP3QhR9W0L5iBl5Wg3zusth vE7Cf+9dHemTx9wIHa5FpvNqwbtNScuvoti36nWUD9ni+aq1Cu1X9s/e7XNUcyVkkZe+ lp5PqOsghdRCDAfxA8QYV0RxLR9sy53/J0FXvP1jHeOqfVTz8h8uxqrhDLEXZ0pyl8Xj lzfChHdbQkh4+JFJAVWt58ixbAeddanb8XllyU2F2MghQyjlkoHQoiXQ/5j+FbuzTv6n wUaQ== X-Gm-Message-State: AMke39mxhejDwGxvx3C/V5ZkfXq5AqWAoILWsBGzGdrUpMSyauCSa181dS7Qw1YE9Nfj8Q== X-Received: by 10.28.13.80 with SMTP id 77mr10840046wmn.88.1489081067630; Thu, 09 Mar 2017 09:37:47 -0800 (PST) Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id e72sm9638997wma.5.2017.03.09.09.37.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 09:37:46 -0800 (PST) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <874lz37glw.fsf@tromey.com> <8360jjh8jo.fsf@gnu.org> <11da16db-d636-8cb2-142e-5d240cd88d1c@yandex.ru> <83mvcufky5.fsf@gnu.org> From: Dmitry Gutov Message-ID: Date: Thu, 9 Mar 2017 19:37:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <83mvcufky5.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) On 09.03.2017 18:56, Eli Zaretskii wrote: > It sounds gross to ask people to use Flymake just to be able to use > something like this. What's gross about that? Don't we like Flymake? From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 17:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org, tom@tromey.com Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148908177029940 (code B ref 25987); Thu, 09 Mar 2017 17:50:01 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 17:49:30 +0000 Received: from localhost ([127.0.0.1]:47972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm2Bu-0007mq-2d for submit@debbugs.gnu.org; Thu, 09 Mar 2017 12:49:30 -0500 Received: from mail-wm0-f50.google.com ([74.125.82.50]:34874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm2Bs-0007md-Ob for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 12:49:29 -0500 Received: by mail-wm0-f50.google.com with SMTP id v186so145154100wmd.0 for <25987@debbugs.gnu.org>; Thu, 09 Mar 2017 09:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=MMNNBLNiOLHgt0fsfInGapSlQby9Jtz/P2VXOBmygYQ=; b=gqEVcrGMhd4p/4f8I+mf7yeXK2uLLfsZ1TOH3QZCrDVSkLRgzvsIi0ux7Oh5rFndEF B2aiVBVYOGa77Jy8zklOp1xWf1ccKFsljeC/t/aOcC0PJdMuWiuzGH9o9xpggcIshKQi 8RD7C08d2h8UYz/v/TMrPG4K+tMP/4C672ZRFkz2kax6yVacMPbtSvxGd22x7E8IQE/g XKIVf+k+9+cDY6LgcNyo9jywjPpZtwFnR9/maP3UlgTKRad+x4DRyIeKCuWlF8wjAwOX /zUOjLtPcwVVRTbj9w44vLmPiOH7gJJEcIOWUAeNwJskp3UeJGF6uyUu8ioo2bqVEqft b4+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MMNNBLNiOLHgt0fsfInGapSlQby9Jtz/P2VXOBmygYQ=; b=BFoLH4AlgZxxQRXo1yOSArRr28pwcQUFdX9xaAVxFFpv9SlRm9r94h+ZrhXB5xweti OauZgK6FpHtBmMyCChLaq+VrwPGWbYfD5Rm6NHp2dCIxhAYSc8yMZsJstNPIh8RPSE6G bB4NgJIdW6fK3uvuSgJmQq1qzzY9xlbyf/E87g87/aGfqzYbTsY17oG0N+NrVYktE9/u WrktMauAGMWgBH9xGmib5rD63Cya4dwHLpTJl9trQVxPfIe7PAA2ttIMDd+gek8xauxx htglZsysp4AQTNekZigqmE4iYbX3ZMq1r0Xhf8LwJGCuFOoEkz8kTvz62DvQe6r9zaNN tGYw== X-Gm-Message-State: AMke39naTYuC13dGgRT+7zlNFyaODFBFEj/BPspqEzF+iUJ2BCuyDk+VP+WvPmMg+shjAw== X-Received: by 10.28.35.66 with SMTP id j63mr12406599wmj.84.1489081762971; Thu, 09 Mar 2017 09:49:22 -0800 (PST) Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id z198sm9614974wmz.24.2017.03.09.09.49.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 09:49:22 -0800 (PST) References: <87lgsj1jle.fsf@tromey.com> <83pohqfl3f.fsf@gnu.org> From: Dmitry Gutov Message-ID: <33b3eca2-5e34-43d1-fccf-b4bd8e5f6ee6@yandex.ru> Date: Thu, 9 Mar 2017 19:49:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <83pohqfl3f.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) On 09.03.2017 18:53, Eli Zaretskii wrote: > So you suggest a separate minor mode, is that right? A minor mode would be a good way toward the "quick-and-dirty" solution. But we'd still want in-buffer indicators and a way to promptly invalidate them as soon as the user makes some changes. Ideally, also a way to refresh them automatically (e.g. as soon as the user saves the changes). These requirements spell "Flymake" to me. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 18:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 25987@debbugs.gnu.org, tom@tromey.com Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.14890843871587 (code B ref 25987); Thu, 09 Mar 2017 18:34:01 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 18:33:07 +0000 Received: from localhost ([127.0.0.1]:47999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm2s7-0000PX-KM for submit@debbugs.gnu.org; Thu, 09 Mar 2017 13:33:07 -0500 Received: from eggs.gnu.org ([208.118.235.92]:52202) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm2s6-0000P2-93 for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 13:33:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cm2rx-0000ro-6D for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 13:33:01 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cm2ra-0000aF-89; Thu, 09 Mar 2017 13:32:34 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3462 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cm2rZ-0003rr-4L; Thu, 09 Mar 2017 13:32:33 -0500 Date: Thu, 09 Mar 2017 20:32:08 +0200 Message-Id: <83k27yfgif.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Dmitry Gutov on Thu, 9 Mar 2017 19:37:45 +0200) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <874lz37glw.fsf@tromey.com> <8360jjh8jo.fsf@gnu.org> <11da16db-d636-8cb2-142e-5d240cd88d1c@yandex.ru> <83mvcufky5.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: 25987@debbugs.gnu.org, tom@tromey.com > From: Dmitry Gutov > Date: Thu, 9 Mar 2017 19:37:45 +0200 > > On 09.03.2017 18:56, Eli Zaretskii wrote: > > > It sounds gross to ask people to use Flymake just to be able to use > > something like this. > > What's gross about that? It's a large package, and its purpose is not just fix compilation errors. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 18:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 25987@debbugs.gnu.org, tom@tromey.com Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.14890845591838 (code B ref 25987); Thu, 09 Mar 2017 18:36:02 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 18:35:59 +0000 Received: from localhost ([127.0.0.1]:48003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm2ut-0000Ta-40 for submit@debbugs.gnu.org; Thu, 09 Mar 2017 13:35:59 -0500 Received: from eggs.gnu.org ([208.118.235.92]:53122) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm2ur-0000TN-KA for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 13:35:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cm2uj-0001sc-Vb for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 13:35:51 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cm2uj-0001sR-St; Thu, 09 Mar 2017 13:35:49 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3464 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cm2ui-0001Sx-F9; Thu, 09 Mar 2017 13:35:49 -0500 Date: Thu, 09 Mar 2017 20:35:24 +0200 Message-Id: <83h932fgcz.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <33b3eca2-5e34-43d1-fccf-b4bd8e5f6ee6@yandex.ru> (message from Dmitry Gutov on Thu, 9 Mar 2017 19:49:19 +0200) References: <87lgsj1jle.fsf@tromey.com> <83pohqfl3f.fsf@gnu.org> <33b3eca2-5e34-43d1-fccf-b4bd8e5f6ee6@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Cc: tom@tromey.com, 25987@debbugs.gnu.org > From: Dmitry Gutov > Date: Thu, 9 Mar 2017 19:49:19 +0200 > > On 09.03.2017 18:53, Eli Zaretskii wrote: > > > So you suggest a separate minor mode, is that right? > > A minor mode would be a good way toward the "quick-and-dirty" solution. > > But we'd still want in-buffer indicators and a way to promptly > invalidate them as soon as the user makes some changes. > > Ideally, also a way to refresh them automatically (e.g. as soon as the > user saves the changes). These requirements spell "Flymake" to me. We could do both, of course. Or Flymake could turn on that minor mode. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 21:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org, tom@tromey.com Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.148909477131277 (code B ref 25987); Thu, 09 Mar 2017 21:27:01 +0000 Received: (at 25987) by debbugs.gnu.org; 9 Mar 2017 21:26:11 +0000 Received: from localhost ([127.0.0.1]:48084 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm5Za-00088P-P6 for submit@debbugs.gnu.org; Thu, 09 Mar 2017 16:26:10 -0500 Received: from mail-wm0-f53.google.com ([74.125.82.53]:36031) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cm5ZZ-00088D-77 for 25987@debbugs.gnu.org; Thu, 09 Mar 2017 16:26:09 -0500 Received: by mail-wm0-f53.google.com with SMTP id n11so149117485wma.1 for <25987@debbugs.gnu.org>; Thu, 09 Mar 2017 13:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=RDNR1LqsN+ISXhvz3H+C0scEmoUl83TFqALmmWKNylU=; b=KpThiWRrwo8S4cY8d+0MbM9C9o6FolPTBvKcUQyYxNx2qq7Zenz46QdB4T7GSd+RRI HDkbMjI0tXuxQI/kvAVozd7lheHSJY+7H6Rgqxq6v3RgKpELMwoh/LsFdB3B2Lj9t/ue SzXq71WcGTR6Imgsr87+2vGSPSfIei0cjuD4byMy7q4VXGVnXOT0SkuEsb7hmD8/8GPL UEhh0Y/WSCiV4166amAxWkxBcsdT7dgY4kMaykLcRoGGPINpot9P3UJTttJkoLJ4qMll R5t/+BQjilHJHv/OWfVDFFWYKS7uioTdEU/HFbkA9PQJVBP3hISDkneSKKmKhcFUlfx7 0kVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RDNR1LqsN+ISXhvz3H+C0scEmoUl83TFqALmmWKNylU=; b=V3TmHjApIMOJzWQnaN0rXHNY0kRBPiIkdzHbP6IFZA2ZsQ5tw+GerIFd3W4fAOiBWH fjDr1CbLQmxQo8tirBGVrByjl5Odnkqd6vEuZWbP/XhGTTDkoDedsHVnJl3+nLSh6UhG w0b0j3o/c3S7yys+yjeQpbzgQjkEbaUpTOeFzv2Sr7dKO9tILYjrdJnPyR79pqx0LHiL m+bkSMxs48q6IZGVUceljW+FHgPu+GEgmdD00k7a5g8PyzpX3GXqOfwzuoMs9QQ14M6p VY9v6tOeUIqK5PQfJa2B0gzQf+e4hds1vX4G1N2HRj1W8mSw/JYv9PCvjGvN7z+6A/Of yNIA== X-Gm-Message-State: AMke39nhj2tLNwCwYax/PUyK+RvI05VrBocf9nrd7f5Kaa8UjEvoniQArDZ+jXDLatxkVA== X-Received: by 10.28.52.137 with SMTP id b131mr12688865wma.30.1489094763345; Thu, 09 Mar 2017 13:26:03 -0800 (PST) Received: from [192.168.1.3] ([185.105.173.41]) by smtp.googlemail.com with ESMTPSA id c9sm192646wmf.18.2017.03.09.13.26.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 13:26:02 -0800 (PST) References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <874lz37glw.fsf@tromey.com> <8360jjh8jo.fsf@gnu.org> <11da16db-d636-8cb2-142e-5d240cd88d1c@yandex.ru> <83mvcufky5.fsf@gnu.org> <83k27yfgif.fsf@gnu.org> From: Dmitry Gutov Message-ID: <93fec26b-4716-f199-e6e7-c9d7faedecb6@yandex.ru> Date: Thu, 9 Mar 2017 23:26:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <83k27yfgif.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) On 09.03.2017 20:32, Eli Zaretskii wrote: >>> It sounds gross to ask people to use Flymake just to be able to use >>> something like this. >> >> What's gross about that? > > It's a large package, and its purpose is not just fix compilation > errors. Its purpose is just showing them, and we, ideally, need both. Flymake is moderately large because it includes some checker definitions. We could extract the core to a separate file. Anyway, yes, a minor mode that would act on the fixits inside the Compilation buffer might be helpful. But that's basically ignoring the prior art in IDEs that you asked about, where "quick fixes" go together with in-buffer visualizations. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Tom Tromey Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Aug 2017 03:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 25987@debbugs.gnu.org, Tom Tromey Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.150199030027038 (code B ref 25987); Sun, 06 Aug 2017 03:32:02 +0000 Received: (at 25987) by debbugs.gnu.org; 6 Aug 2017 03:31:40 +0000 Received: from localhost ([127.0.0.1]:43970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deCI0-000722-KS for submit@debbugs.gnu.org; Sat, 05 Aug 2017 23:31:40 -0400 Received: from gproxy2-pub.mail.unifiedlayer.com ([69.89.18.3]:48016) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deCHy-00071o-Bi for 25987@debbugs.gnu.org; Sat, 05 Aug 2017 23:31:39 -0400 Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 6C88E1E09EE for <25987@debbugs.gnu.org>; Sat, 5 Aug 2017 21:31:29 -0600 (MDT) Received: from box522.bluehost.com ([74.220.219.122]) by cmgw4 with id tfXP1v00h2f2jeq01fXSxc; Sat, 05 Aug 2017 21:31:29 -0600 X-Authority-Analysis: v=2.2 cv=aJeAkf1m c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=KeKAF7QvOSUA:10 a=vaJtXVxTAAAA:8 a=AhS_egAj-RsG7vl5rnIA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=0T97B+riDUBvkCmncp4Uj9k4dYt45RJrbg/2gzoKw8A=; b=ZGhfFJ3BIGIW2mkvRwPwq6uWAa lQ7P82cm0NEhowC9Sd+z5lhdBE/vDqiVg8Sg9ROL3oxnEiI2QkJFwA9nIf4bk1Or+s1qBGYUpGwLq oA9I6m6hesraqVhr1l2ZYLgak; Received: from 75-166-24-97.hlrn.qwest.net ([75.166.24.97]:34900 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1deCHj-0011w3-E7; Sat, 05 Aug 2017 21:31:23 -0600 From: Tom Tromey References: <87lgsj1jle.fsf@tromey.com> X-Attribution: Tom Date: Sat, 05 Aug 2017 21:31:22 -0600 In-Reply-To: (Dmitry Gutov's message of "Thu, 9 Mar 2017 18:18:04 +0200") Message-ID: <87mv7de5it.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box522.bluehost.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.24.97 X-Exim-ID: 1deCHj-0011w3-E7 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-24-97.hlrn.qwest.net (bapiya) [75.166.24.97]:34900 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) >>>>> "Dmitry" == Dmitry Gutov writes: >> * One way for this to work would be to display the buffer and >> show the proposed change as an overlay; and then use y-or-n-p >> to ask whether it should be applied. I was thinking something like: [...] Dmitry> I'm not sure we want to tie this feature to compilation-mode. Many Dmitry> modes that derive from it don't support fix-its, e.g. those of them Dmitry> that run the test suites. And even for those that do, Compilation Dmitry> provides a very basic UI. To me it seems very natural. I compile, then as I next-error through the results, Emacs offers to apply a change. I think it's fine that some sub-modes don't support fix-its. Actually I don't understand how that would be a problem. Presumably `grep' or whatever isn't going to emit a fixit note anyhow. Dmitry> Even to find and apply all fix-its, we'd need to add some new buffer, Dmitry> to show the list. That doesn't seem necessary to me either. Tom From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Tom Tromey Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Aug 2017 03:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 25987@debbugs.gnu.org, Eli Zaretskii , Tom Tromey Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.150199048327308 (code B ref 25987); Sun, 06 Aug 2017 03:35:02 +0000 Received: (at 25987) by debbugs.gnu.org; 6 Aug 2017 03:34:43 +0000 Received: from localhost ([127.0.0.1]:43975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deCKx-00076N-3n for submit@debbugs.gnu.org; Sat, 05 Aug 2017 23:34:43 -0400 Received: from gproxy6-pub.mail.unifiedlayer.com ([67.222.39.168]:36239) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1deCKu-000768-U6 for 25987@debbugs.gnu.org; Sat, 05 Aug 2017 23:34:42 -0400 Received: from cmgw4 (unknown [10.0.90.85]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 2F6BC1E0786 for <25987@debbugs.gnu.org>; Sat, 5 Aug 2017 21:34:33 -0600 (MDT) Received: from box522.bluehost.com ([74.220.219.122]) by cmgw4 with id tfaW1v0022f2jeq01faZzR; Sat, 05 Aug 2017 21:34:33 -0600 X-Authority-Analysis: v=2.2 cv=aJeAkf1m c=1 sm=1 tr=0 a=GsOEXm/OWkKvwdLVJsfwcA==:117 a=GsOEXm/OWkKvwdLVJsfwcA==:17 a=KeKAF7QvOSUA:10 a=vaJtXVxTAAAA:8 a=8IKrs8vvOidCoWTx8LcA:9 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=+JS6bHqr3/wPGWRR9qFxfiKgi2dGZ3LO5xAHqB8nqTY=; b=D/MqqgcgUtaxQulMwNFsSgdRXU qfuqL26cRd491qa6Dmc9RU+RBgCp6G2K/7nGKbpRcHzL3Vw14Ew2ktPz9I6lPxqHUE34Zdj/gHzFy c+sqqEJh65fjcMgL+I1FclFhJ; Received: from 75-166-24-97.hlrn.qwest.net ([75.166.24.97]:34912 helo=bapiya) by box522.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1deCKj-0014RZ-UD; Sat, 05 Aug 2017 21:34:30 -0600 From: Tom Tromey References: <87lgsj1jle.fsf@tromey.com> <83efyai778.fsf@gnu.org> <878toh19bs.fsf@tromey.com> <874lz37glw.fsf@tromey.com> <8360jjh8jo.fsf@gnu.org> <11da16db-d636-8cb2-142e-5d240cd88d1c@yandex.ru> X-Attribution: Tom Date: Sat, 05 Aug 2017 21:34:24 -0600 In-Reply-To: <11da16db-d636-8cb2-142e-5d240cd88d1c@yandex.ru> (Dmitry Gutov's message of "Thu, 9 Mar 2017 18:37:30 +0200") Message-ID: <87ini1e5dr.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box522.bluehost.com X-AntiAbuse: Original Domain - debbugs.gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 75.166.24.97 X-Exim-ID: 1deCKj-0014RZ-UD X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-24-97.hlrn.qwest.net (bapiya) [75.166.24.97]:34912 X-Source-Auth: tom+tromey.com X-Email-Count: 5 X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTIyLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) >>>>> "Dmitry" == Dmitry Gutov writes: Dmitry> Thinking along these lines, the closest things we have are Flymake and Dmitry> Flyspell. The third-party Flycheck is even better is several respects Dmitry> (e.g. it can show a listing of all problems in the file buffer), but Dmitry> sadly we won't be able to use it, since the primary author is sternly Dmitry> against copyright assignment. It'd be great to evolve Flymake into something more like Flycheck. Dmitry> But it'd be good to teach Flymake about fixits, and when we can't use Dmitry> tooltips, use a text-based prompts a la Flyspell. I think this would be a good addition, kind of like LSP mode; but also not really necessary -- at least for me, I usually use M-x compile for C and C++ projects, and some integration with next-error would be more than sufficient. Tom From debbugs-submit-bounces@debbugs.gnu.org Wed Oct 25 23:28:28 2017 Received: (at control) by debbugs.gnu.org; 26 Oct 2017 03:28:28 +0000 Received: from localhost ([127.0.0.1]:33792 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7YqJ-0005lX-TB for submit@debbugs.gnu.org; Wed, 25 Oct 2017 23:28:27 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1e7YqG-0005lE-PF for control@debbugs.gnu.org; Wed, 25 Oct 2017 23:28:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e7YqA-0007Nq-J4 for control@debbugs.gnu.org; Wed, 25 Oct 2017 23:28:19 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50207) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e7YqA-0007Ne-FP for control@debbugs.gnu.org; Wed, 25 Oct 2017 23:28:18 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1e7YqA-00036g-7V for control@debbugs.gnu.org; Wed, 25 Oct 2017 23:28:18 -0400 Subject: control message for bug 29004 To: X-Mailer: mail (GNU Mailutils 2.99.98) Message-Id: From: Glenn Morris Date: Wed, 25 Oct 2017 23:28:18 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) forcemerge 25987 29004 From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes References: <87lgsj1jle.fsf@tromey.com> In-Reply-To: <87lgsj1jle.fsf@tromey.com> Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Mar 2018 17:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.152122009111520 (code B ref 25987); Fri, 16 Mar 2018 17:09:01 +0000 Received: (at 25987) by debbugs.gnu.org; 16 Mar 2018 17:08:11 +0000 Received: from localhost ([127.0.0.1]:37229 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ewspv-0002zk-D0 for submit@debbugs.gnu.org; Fri, 16 Mar 2018 13:08:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43590) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ewsWc-0002X9-53 for 25987@debbugs.gnu.org; Fri, 16 Mar 2018 12:48:14 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 810B57FEB5 for <25987@debbugs.gnu.org>; Fri, 16 Mar 2018 16:48:08 +0000 (UTC) Received: from ovpn-117-5.phx2.redhat.com (ovpn-117-5.phx2.redhat.com [10.3.117.5]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3E9B06375A for <25987@debbugs.gnu.org>; Fri, 16 Mar 2018 16:48:08 +0000 (UTC) Message-ID: <1521218887.2913.237.camel@redhat.com> From: David Malcolm Date: Fri, 16 Mar 2018 12:48:07 -0400 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 16 Mar 2018 16:48:08 +0000 (UTC) X-Spam-Score: -5.0 (-----) X-Mailman-Approved-At: Fri, 16 Mar 2018 13:08:10 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) [I'm not familiar with this bug-tracking system; let's see if this works] I'm the author of the -fdiagnostics-parseable-fixits feature in GCC; I maintain the GCC diagnostics subsystem. As Tom(?) noted, I made -fdiagnostics-parseable-fixits report in bytes, partly because that's the status quo for all of GCC's "column" reporting, and partly because that's what clang implemented for this. It appears that Emacs can already decode from byte-offsets in a line back to columns, so this seems like a compatibility detail in case we fix everything to use real column numbers. I'm also an Emacs user (though not a Emacs developer, sorry; my Lisp is practically non-existent) - I just wondered what the status of this is. I'm keen to be able to use it (GCC will get better faster!), even if it's just a new command in compilation mode to go ahead and apply a fix-it hint for the current diagnostic, as seen by next-error, if it has one, maybe prettifying the printing of such lines, with the user having to manually supply -fdiagnostics-parseable-fixits somehow. FWIW GCC 8 is gaining lots more fix-it hints (including ones that add newlines, for missing "#include" suggestions); see: https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/ for a blog post I wrote about it. Thanks; hope this is constructive. Dave From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 16 Mar 2018 20:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Malcolm Cc: 25987@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.15212315574325 (code B ref 25987); Fri, 16 Mar 2018 20:20:02 +0000 Received: (at 25987) by debbugs.gnu.org; 16 Mar 2018 20:19:17 +0000 Received: from localhost ([127.0.0.1]:37314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ewvor-00017h-Hn for submit@debbugs.gnu.org; Fri, 16 Mar 2018 16:19:17 -0400 Received: from eggs.gnu.org ([208.118.235.92]:43944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ewvoq-00017V-BU for 25987@debbugs.gnu.org; Fri, 16 Mar 2018 16:19:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ewvoi-0007EX-Bf for 25987@debbugs.gnu.org; Fri, 16 Mar 2018 16:19:11 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34793) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ewvoi-0007EQ-7u; Fri, 16 Mar 2018 16:19:08 -0400 Received: from [176.228.60.248] (port=1339 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ewvoh-000777-ML; Fri, 16 Mar 2018 16:19:08 -0400 Date: Fri, 16 Mar 2018 22:19:09 +0200 Message-Id: <83muz7pyde.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <1521218887.2913.237.camel@redhat.com> (message from David Malcolm on Fri, 16 Mar 2018 12:48:07 -0400) References: <87lgsj1jle.fsf@tromey.com> <1521218887.2913.237.camel@redhat.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.0 (-----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: David Malcolm > Date: Fri, 16 Mar 2018 12:48:07 -0400 > > It appears that Emacs can already decode from byte-offsets in a line > back to columns Actually, doing this translation is a pain, because it requires to know the original encoding used by GCC for its messages, and that info is gone by the time we have the text decoded in an Emacs buffer. Emacs can guess the encoding, but that guesswork is bound to fail. So reporting the offsets in characters (a.k.a. columns) is really a necessity. Thanks. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Oct 2020 18:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160200828415374 (code B ref 25987); Tue, 06 Oct 2020 18:19:02 +0000 Received: (at 25987) by debbugs.gnu.org; 6 Oct 2020 18:18:04 +0000 Received: from localhost ([127.0.0.1]:54108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kPrXH-0003zu-T3 for submit@debbugs.gnu.org; Tue, 06 Oct 2020 14:18:04 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:56090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kPrXE-0003zS-Ig for 25987@debbugs.gnu.org; Tue, 06 Oct 2020 14:18:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602008280; 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=utkPp9rT1g++RKRA1gcFaa64mBtC+gEOqw5FDxNcyUE=; b=MWcRs5o6StCWK9VkFIuy9C2QKFg2d0f0XN4fFPS4DmZtfixGqjCRjRTL+uPH7LAohPRVNT +2UnlT/TxngQhD9MhnGki/Ow3FCl9Jj/QCnGMIxrtnfA+uXzOtG6gigpNsK7oLmUgY+wMJ f8ywDvkHAd3KC4EnJmDZ1QVpqyCCaW8= 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-75-nVZ4H36qMOWtiNWVrsuROQ-1; Tue, 06 Oct 2020 14:17:57 -0400 X-MC-Unique: nVZ4H36qMOWtiNWVrsuROQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BCD9956BFE; Tue, 6 Oct 2020 18:17:56 +0000 (UTC) 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 539936EF43; Tue, 6 Oct 2020 18:17:56 +0000 (UTC) Message-ID: From: David Malcolm Date: Tue, 06 Oct 2020 14:17:55 -0400 In-Reply-To: <83muz7pyde.fsf@gnu.org> References: <87lgsj1jle.fsf@tromey.com> <1521218887.2913.237.camel@redhat.com> <83muz7pyde.fsf@gnu.org> User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, 2018-03-16 at 22:19 +0200, Eli Zaretskii wrote: > > From: David Malcolm > > Date: Fri, 16 Mar 2018 12:48:07 -0400 > > > > It appears that Emacs can already decode from byte-offsets in a > > line > > back to columns > > Actually, doing this translation is a pain, because it requires to > know the original encoding used by GCC for its messages, and that > info > is gone by the time we have the text decoded in an Emacs buffer. > Emacs can guess the encoding, but that guesswork is bound to > fail. So > reporting the offsets in characters (a.k.a. columns) is really a > necessity. > > Thanks. Sorry for the long delay in responding. In GCC 11 we've revamped the column number handling in how we emit diagnostics; see: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555632.html GCC 11 diagnostics now (by default) should use actual column numbers, rather than byte counts. We haven't changed -fdiagnostics-parseable-fixits; it still emits its range information in terms of byte offsets (and e.g. Eclipse already consumes that option); this is bug-for-bug compatible with clang, I believe (which had that option first). Note that characters != columns, or, at least, we have to be careful about what we mean. Consider the case of 🙂 aka SLIGHTLY SMILING FACE (U+1F642) which is a single unicode code point, but occupies two columns, with its UTF-8 encoding requiring four bytes. When I type it into an Emacs buffer, and look at the column number I see that Emacs appears to treat the character as occupying two columns. Is that the kind of column numbering you would want for machine- readable fix-it hints? Similarly, the column numbering emitted by GCC 11 diagnostics is affected by tab characters as tab stops, which seems to reflect Emacs behavior as well. I can add an additional option for fix-it hints that's similar to -fdiagnostics-parseable-fixits, but with a different output format (or to add an argument to that option, perhaps). Before I do that, I wanted to check that it would be consumable by Emacs. What works for you? Would it help to send the proposed GCC patch to this bug address (or to the emacs-devel list?). The existing option is documented here: https://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-parseable-fixits Alternatively, we already have a JSON output option (-fdiagnostics- format=json); perhaps something like that could be used? Feature freeze for GCC 11 is about a month away; I'd love for Emacs to be able to consume GCC fix-it hints (and have GCC and Emacs fix my typos for me) Dave From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Oct 2020 18:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Malcolm Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160200943117119 (code B ref 25987); Tue, 06 Oct 2020 18:38:02 +0000 Received: (at 25987) by debbugs.gnu.org; 6 Oct 2020 18:37:11 +0000 Received: from localhost ([127.0.0.1]:54118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kPrpn-0004S3-Bj for submit@debbugs.gnu.org; Tue, 06 Oct 2020 14:37:11 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51790) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kPrpi-0004RY-LD for 25987@debbugs.gnu.org; Tue, 06 Oct 2020 14:37:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57259) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kPrpc-0006zT-Jg; Tue, 06 Oct 2020 14:37:01 -0400 Received: from [176.228.60.248] (port=4282 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kPrpb-0003nT-8q; Tue, 06 Oct 2020 14:37:00 -0400 Date: Tue, 06 Oct 2020 21:37:03 +0300 Message-Id: <83o8lf9p68.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from David Malcolm on Tue, 06 Oct 2020 14:17:55 -0400) References: <87lgsj1jle.fsf@tromey.com> <1521218887.2913.237.camel@redhat.com> <83muz7pyde.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: David Malcolm > Cc: 25987@debbugs.gnu.org > Date: Tue, 06 Oct 2020 14:17:55 -0400 > > In GCC 11 we've revamped the column number handling in how we emit > diagnostics; see: > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555632.html > > GCC 11 diagnostics now (by default) should use actual column numbers, > rather than byte counts. That's good news, thanks. > We haven't changed -fdiagnostics-parseable-fixits; it still emits its > range information in terms of byte offsets (and e.g. Eclipse already > consumes that option); this is bug-for-bug compatible with clang, I > believe (which had that option first). So fixit hints will still count bytes? Or will GCC 11 emit such hints even without -fdiagnostics-parseable-fixits on the command line? > Note that characters != columns, or, at least, we have to be careful > about what we mean. Consider the case of 🙂 aka SLIGHTLY SMILING FACE > (U+1F642) which is a single unicode code point, but occupies two > columns, with its UTF-8 encoding requiring four bytes. > > When I type it into an Emacs buffer, and look at the column number I > see that Emacs appears to treat the character as occupying two columns. > Is that the kind of column numbering you would want for machine- > readable fix-it hints? Yes. Emacs computes the width of each character by using UCD, the Unicode Character Database (specifically, the EastAsianWidth.txt file that is part of the UCD). If GCC gets its column counts from a similar DB, then it will match what Emacs does. > Similarly, the column numbering emitted by GCC 11 diagnostics is > affected by tab characters as tab stops, which seems to reflect Emacs > behavior as well. Yes. > I can add an additional option for fix-it hints that's similar to > -fdiagnostics-parseable-fixits, but with a different output format (or > to add an argument to that option, perhaps). If an option is needed for getting the hints, then a special option which reports columns in hints will be appreciated, as it will make the Emacs support for processing those hints 100% accurate and devoid of encoding guesswork. > Before I do that, I wanted to check that it would be consumable by > Emacs. What works for you? Would it help to send the proposed GCC > patch to this bug address (or to the emacs-devel list?). I don't know how many people here build their own GCC, and thus could try the patch, but if sending the patch is not too much trouble, perhaps posting it on emacs-devel would be a good idea. If you do that, please cite this bug report, so that people who try that could respond here with their experience. > Alternatively, we already have a JSON output option (-fdiagnostics- > format=json); perhaps something like that could be used? Emacs can parse JSON. What are the pros and cons of the JSON alternative wrt to the text alternative? > Feature freeze for GCC 11 is about a month away; I'd love for Emacs to > be able to consume GCC fix-it hints (and have GCC and Emacs fix my > typos for me) Agreed; let's try to make that happen. Thanks. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 Oct 2020 22:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160254166130791 (code B ref 25987); Mon, 12 Oct 2020 22:28:01 +0000 Received: (at 25987) by debbugs.gnu.org; 12 Oct 2020 22:27:41 +0000 Received: from localhost ([127.0.0.1]:44270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kS6I8-00080Y-Qn for submit@debbugs.gnu.org; Mon, 12 Oct 2020 18:27:41 -0400 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:38344) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kS6I4-00080N-6e for 25987@debbugs.gnu.org; Mon, 12 Oct 2020 18:27:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1602541656; 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: in-reply-to:in-reply-to:references:references; bh=kv5M84xSoWNJu92zJFPbJ7C4dOnMchJdRfsA+3OjzGw=; b=YDhGwUucR28Vcs2DdhHwW6obDFiWDOu/gh6ajl6lYzc7687sxtqyKbZG2vQ5hT2TznIA21 kxE+aK9WrWPa2jVWdcMWzDkEBayY9OLlOUph60mBYvDvJ99RVxPepD70BUrJr6TmI/IJn9 xUDOLXtixrNUk26nlOA/pS3DTq8rBRg= 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-11-EJO9qhY1Ph2WaERuUN-OcA-1; Mon, 12 Oct 2020 18:27:31 -0400 X-MC-Unique: EJO9qhY1Ph2WaERuUN-OcA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A71C4185A0C4; Mon, 12 Oct 2020 22:27:30 +0000 (UTC) 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 2F6C510013DB; Mon, 12 Oct 2020 22:27:29 +0000 (UTC) Message-ID: <26f277bb345f10efe6340ac4074960905064fc97.camel@redhat.com> From: David Malcolm Date: Mon, 12 Oct 2020 18:27:29 -0400 In-Reply-To: <83o8lf9p68.fsf@gnu.org> References: <87lgsj1jle.fsf@tromey.com> <1521218887.2913.237.camel@redhat.com> <83muz7pyde.fsf@gnu.org> <83o8lf9p68.fsf@gnu.org> User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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 Content-Type: multipart/mixed; boundary="=-n3E9E9o33IMfHcokYE/T" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-n3E9E9o33IMfHcokYE/T Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Tue, 2020-10-06 at 21:37 +0300, Eli Zaretskii wrote: > > From: David Malcolm > > Cc: 25987@debbugs.gnu.org > > Date: Tue, 06 Oct 2020 14:17:55 -0400 > > > > In GCC 11 we've revamped the column number handling in how we emit > > diagnostics; see: > > > > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555632.html > > > > GCC 11 diagnostics now (by default) should use actual column > > numbers, > > rather than byte counts. > > That's good news, thanks. > > > We haven't changed -fdiagnostics-parseable-fixits; it still emits > > its > > range information in terms of byte offsets (and e.g. Eclipse > > already > > consumes that option); this is bug-for-bug compatible with clang, I > > believe (which had that option first). > > So fixit hints will still count bytes? Or will GCC 11 emit such > hints even without -fdiagnostics-parseable-fixits on the command > line? > > > Note that characters != columns, or, at least, we have to be > > careful > > about what we mean. Consider the case of 🙂 aka SLIGHTLY SMILING > > FACE > > (U+1F642) which is a single unicode code point, but occupies two > > columns, with its UTF-8 encoding requiring four bytes. > > > > When I type it into an Emacs buffer, and look at the column number > > I > > see that Emacs appears to treat the character as occupying two > > columns. > > Is that the kind of column numbering you would want for machine- > > readable fix-it hints? > > Yes. Emacs computes the width of each character by using UCD, the > Unicode Character Database (specifically, the EastAsianWidth.txt file > that is part of the UCD). If GCC gets its column counts from a > similar DB, then it will match what Emacs does. > > > Similarly, the column numbering emitted by GCC 11 diagnostics is > > affected by tab characters as tab stops, which seems to reflect > > Emacs > > behavior as well. > > Yes. > > > I can add an additional option for fix-it hints that's similar to > > -fdiagnostics-parseable-fixits, but with a different output format > > (or > > to add an argument to that option, perhaps). > > If an option is needed for getting the hints, then a special option > which reports columns in hints will be appreciated, as it will make > the Emacs support for processing those hints 100% accurate and devoid > of encoding guesswork. > > > Before I do that, I wanted to check that it would be consumable by > > Emacs. What works for you? Would it help to send the proposed GCC > > patch to this bug address (or to the emacs-devel list?). > > I don't know how many people here build their own GCC, and thus could > try the patch, but if sending the patch is not too much trouble, > perhaps posting it on emacs-devel would be a good idea. If you do > that, please cite this bug report, so that people who try that could > respond here with their experience. > > > Alternatively, we already have a JSON output option (-fdiagnostics- > > format=json); perhaps something like that could be used? > > Emacs can parse JSON. What are the pros and cons of the JSON > alternative wrt to the text alternative? The existing "-fdiagnostics-format=json" GCC option replaces the existing diagnostic output with a big blob of JSON to stderr, all on one line. Although I implemented it, I now feel it to be rather half- baked. I like how -fdiagnostics-parseable-fixits adds extra lines of output, with a prefix that's ought to be easy to detect. BTW, does Emacs set anything in the environment that GCC could detect? > > Feature freeze for GCC 11 is about a month away; I'd love for Emacs > > to > > be able to consume GCC fix-it hints (and have GCC and Emacs fix my > > typos for me) > > Agreed; let's try to make that happen. I put together a test file showing various features to try to ensure that GCC and Emacs interoperate on this. I'm attaching it. This can also be seen on Compiler Explorer at: https://godbolt.org/z/zazejq which adds the existing -fdiagnostics-parseable-fixits -fdiagnostics-generate-patch options. Ideas for other test cases are most welcome. Does Emacs have an automated test suite that could test this feature? A long-postponed goal for me for GCC's testsuite is to ensure that fix- it hints apply and actually fix the problem (clang's testsuite has tests that verify this for clang's fix-it hints). 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. GCC's own code implements this in gcc/edit-context.{c|h}, for implementing - fdiagnostics-generate-patch, which applies all fix-its "atomically" - but the use-case I thinking of involves clicking on fix-it hints one- by-one in the compilation buffer, perhaps replacing the fix-it output with an "Apply fix" button. (to cover this case I made sure the demo file contained examples of a fix-it hint that adds a line, and one that has multiple fix-it hints on the same line). Thoughts? Dave --=-n3E9E9o33IMfHcokYE/T Content-Disposition: attachment; filename="demo.c" Content-Type: text/x-csrc; name="demo.c"; charset="UTF-8" Content-Transfer-Encoding: base64 LyogQSBkdW1teSBpbmNsdWRlLCB0byBvZmZzZXQgdGhlIGZpeC1pdCBpbmNsdWRlIGluIHRlc3Rf MSBiZWxvdy4gICovCiNpbmNsdWRlIDxzdGRpby5oPgoKc3RydWN0IHZlcnQKewogIGludCBjb2xv cjsKfTsKCnZvaWQgKnRlc3RfMSAodm9pZCkKewogIC8qIC1XaW1wbGljaXQtZnVuY3Rpb24tZGVj bGFyYXRpb24gc2hvdWxkIGdlbmVyYXRlIGEgZml4LWl0IGhpbnQgdGhhdAogICAgIGFkZHMgYSB3 aG9sZSBuZXcgbGluZSBzdWdnZXN0aW5nIGEgI2luY2x1ZGUsIGFkZGVkIGFmdGVyIHRoZQogICAg IGV4aXN0aW5nICNpbmNsdWRlLiAgKi8KICByZXR1cm4gbWFsbG9jICg0MDk2KTsKfQoKdm9pZCB0 ZXN0XzJhIChzdHJ1Y3QgdmVydCAqdikKewogIC8qIFNvbWUgbm9uLUFTQ0lJIHRleHQgcHJlY2Vk aW5nIGEgZml4LWl0IGhpbnQuICAqLwogIC8qIPCfmYIg8J+ZgiDwn5mCICovIHYtPmNvbG91ciA9 IDA7Cn0KCnZvaWQgdGVzdF8yYiAoc3RydWN0IHZlcnQgKnYpCnsKICAvKiBTb21lIG90aGVyIG5v bi1BU0NJSSB0ZXh0IHByZWNlZGluZyBhIGZpeC1pdCBoaW50LiAgKi8KICAvKiDPgCDPgCDPgCAq LyB2LT5jb2xvdXIgPSAwOwp9Cgp2b2lkIHRlc3RfMmMgKHN0cnVjdCB2ZXJ0ICp2KQp7CiAgLyog WWV0IG1vcmUgbm9uLUFTQ0lJIHRleHQgcHJlY2VkaW5nIGEgZml4LWl0IGhpbnQuICAqLwogIC8q IOaWh+Wtl+WMluOBkSAqLyB2LT5jb2xvdXIgPSAwOwp9Cgp2b2lkIHRlc3RfMyAoc3RydWN0IHZl cnQgKnYpCnsKCSAgLyogVGFicyBhbmQgc3BhY2VzIHByZWNlZGluZyBhIGZpeC1pdCBoaW50LiAg Ki8KCSAgdi0+Y29sb3VyID0gMDsKfQoKdm9pZCB0ZXN0XzQgKHN0cnVjdCB2ZXJ0ICp2KQp7CiAg LyogTW9yZSB0aGFuIG9uZSBmaXgtaXQgb24gdGhlIHNhbWUgbGluZS4gICovCiAgaWYgKHYtPmNv bG91cikgdi0+Y29sb3VyICs9IDI7Cn0KCmRvdWJsZSB0ZXN0XzUgKHZvaWQpCnsKICAvKiBOb24t QVNDSUkgcmVwbGFjZW1lbnQuICAqLwogIGNvbnN0IGRvdWJsZSB0d29fz4AgPSAoMy4xNDEgKiAy KTsKICByZXR1cm4gdHdvX3BpOwp9Cg== --=-n3E9E9o33IMfHcokYE/T-- From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Oct 2020 07:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Malcolm Cc: 25987@debbugs.gnu.org, Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.16025744574142 (code B ref 25987); Tue, 13 Oct 2020 07:35:01 +0000 Received: (at 25987) by debbugs.gnu.org; 13 Oct 2020 07:34:17 +0000 Received: from localhost ([127.0.0.1]:45041 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSEp7-00014k-2Z for submit@debbugs.gnu.org; Tue, 13 Oct 2020 03:34:17 -0400 Received: from mab.sdf.org ([205.166.94.33]:44112 helo=ma.sdf.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSEp5-00014b-8P for 25987@debbugs.gnu.org; Tue, 13 Oct 2020 03:34:16 -0400 Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1kSEos-0000un-FT; Tue, 13 Oct 2020 07:34:02 +0000 From: Andrea Corallo References: <87lgsj1jle.fsf@tromey.com> <1521218887.2913.237.camel@redhat.com> <83muz7pyde.fsf@gnu.org> <83o8lf9p68.fsf@gnu.org> <26f277bb345f10efe6340ac4074960905064fc97.camel@redhat.com> Date: Tue, 13 Oct 2020 07:34:02 +0000 In-Reply-To: <26f277bb345f10efe6340ac4074960905064fc97.camel@redhat.com> (David Malcolm's message of "Mon, 12 Oct 2020 18:27:29 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) David Malcolm writes: > On Tue, 2020-10-06 at 21:37 +0300, Eli Zaretskii wrote: >> > From: David Malcolm >> > Cc: 25987@debbugs.gnu.org >> > Date: Tue, 06 Oct 2020 14:17:55 -0400 >> >=20 >> > In GCC 11 we've revamped the column number handling in how we emit >> > diagnostics; see: >> >=20=20=20 >> > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555632.html >> >=20 >> > GCC 11 diagnostics now (by default) should use actual column >> > numbers, >> > rather than byte counts. >>=20 >> That's good news, thanks. >>=20 >> > We haven't changed -fdiagnostics-parseable-fixits; it still emits >> > its >> > range information in terms of byte offsets (and e.g. Eclipse >> > already >> > consumes that option); this is bug-for-bug compatible with clang, I >> > believe (which had that option first). >>=20 >> So fixit hints will still count bytes? Or will GCC 11 emit such >> hints even without -fdiagnostics-parseable-fixits on the command >> line? >>=20 >> > Note that characters !=3D columns, or, at least, we have to be >> > careful >> > about what we mean. Consider the case of =F0=9F=99=82 aka SLIGHTLY SM= ILING >> > FACE >> > (U+1F642) which is a single unicode code point, but occupies two >> > columns, with its UTF-8 encoding requiring four bytes. >> >=20 >> > When I type it into an Emacs buffer, and look at the column number >> > I >> > see that Emacs appears to treat the character as occupying two >> > columns. >> > Is that the kind of column numbering you would want for machine- >> > readable fix-it hints? >>=20 >> Yes. Emacs computes the width of each character by using UCD, the >> Unicode Character Database (specifically, the EastAsianWidth.txt file >> that is part of the UCD). If GCC gets its column counts from a >> similar DB, then it will match what Emacs does. >>=20 >> > Similarly, the column numbering emitted by GCC 11 diagnostics is >> > affected by tab characters as tab stops, which seems to reflect >> > Emacs >> > behavior as well. >>=20 >> Yes. >>=20 >> > I can add an additional option for fix-it hints that's similar to >> > -fdiagnostics-parseable-fixits, but with a different output format >> > (or >> > to add an argument to that option, perhaps). >>=20 >> If an option is needed for getting the hints, then a special option >> which reports columns in hints will be appreciated, as it will make >> the Emacs support for processing those hints 100% accurate and devoid >> of encoding guesswork. >>=20 >> > Before I do that, I wanted to check that it would be consumable by >> > Emacs. What works for you? Would it help to send the proposed GCC >> > patch to this bug address (or to the emacs-devel list?). >>=20 >> I don't know how many people here build their own GCC, and thus could >> try the patch, but if sending the patch is not too much trouble, >> perhaps posting it on emacs-devel would be a good idea. If you do >> that, please cite this bug report, so that people who try that could >> respond here with their experience. >>=20 >> > Alternatively, we already have a JSON output option (-fdiagnostics- >> > format=3Djson); perhaps something like that could be used? >>=20 >> Emacs can parse JSON. What are the pros and cons of the JSON >> alternative wrt to the text alternative? > > The existing "-fdiagnostics-format=3Djson" GCC option replaces the > existing diagnostic output with a big blob of JSON to stderr, all on > one line. Although I implemented it, I now feel it to be rather half- > baked. > > I like how -fdiagnostics-parseable-fixits adds extra lines of output, > with a prefix that's ought to be easy to detect. > > BTW, does Emacs set anything in the environment that GCC could detect? Hi Dave, If we are searching for a way to ask GCC to dump a file instead of logging to sterr I think Emacs could easily set the env variable before invoking the compilation. Which one I think is to be agreed as would be probably used by a flymake back-end or same other special case as the one discussed. >> > Feature freeze for GCC 11 is about a month away; I'd love for Emacs >> > to >> > be able to consume GCC fix-it hints (and have GCC and Emacs fix my >> > typos for me) >>=20 >> Agreed; let's try to make that happen. > > I put together a test file showing various features to try to ensure > that GCC and Emacs interoperate on this. I'm attaching it. > > This can also be seen on Compiler Explorer at: > https://godbolt.org/z/zazejq > which adds the existing > -fdiagnostics-parseable-fixits -fdiagnostics-generate-patch > options. > > Ideas for other test cases are most welcome. > > Does Emacs have an automated test suite that could test this feature? > A long-postponed goal for me for GCC's testsuite is to ensure that fix- > it hints apply and actually fix the problem (clang's testsuite has > tests that verify this for clang's fix-it hints). Yes we have a testsuite, we could have a test that runs only with like GCC versions >=3D 11 or keep in the testsuite some pre cooked GCC output. Some tests should be easy to write. Andrea From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 13 Oct 2020 14:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Malcolm Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160259987522725 (code B ref 25987); Tue, 13 Oct 2020 14:38:01 +0000 Received: (at 25987) by debbugs.gnu.org; 13 Oct 2020 14:37:55 +0000 Received: from localhost ([127.0.0.1]:48129 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSLR5-0005uS-Fy for submit@debbugs.gnu.org; Tue, 13 Oct 2020 10:37:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60158) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSLR3-0005u3-Hg for 25987@debbugs.gnu.org; Tue, 13 Oct 2020 10:37:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36478) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSLQx-0002nJ-1z; Tue, 13 Oct 2020 10:37:47 -0400 Received: from [176.228.60.248] (port=2109 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kSLQw-0003Zf-H1; Tue, 13 Oct 2020 10:37:46 -0400 Date: Tue, 13 Oct 2020 17:37:54 +0300 Message-Id: <83362i2nul.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <26f277bb345f10efe6340ac4074960905064fc97.camel@redhat.com> (message from David Malcolm on Mon, 12 Oct 2020 18:27:29 -0400) References: <87lgsj1jle.fsf@tromey.com> <1521218887.2913.237.camel@redhat.com> <83muz7pyde.fsf@gnu.org> <83o8lf9p68.fsf@gnu.org> <26f277bb345f10efe6340ac4074960905064fc97.camel@redhat.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. > BTW, does Emacs set anything in the environment that GCC could detect? Yes, Emacs sets INSIDE_EMACS when it runs a sub-process. > Does Emacs have an automated test suite that could test this feature? Yes, see the tests in the test/ subdirectory of the Emacs tree. > 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. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes 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 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160271542126521 (code B ref 25987); Wed, 14 Oct 2020 22:44:01 +0000 Received: (at 25987) by debbugs.gnu.org; 14 Oct 2020 22:43:41 +0000 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 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= 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 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) 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) Message-ID: From: David Malcolm Date: Wed, 14 Oct 2020 18:43:33 -0400 In-Reply-To: <83362i2nul.fsf@gnu.org> 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> User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Oct 2020 07:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Malcolm Cc: 25987@debbugs.gnu.org, Eli Zaretskii Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160274807329046 (code B ref 25987); Thu, 15 Oct 2020 07:48:02 +0000 Received: (at 25987) by debbugs.gnu.org; 15 Oct 2020 07:47:53 +0000 Received: from localhost ([127.0.0.1]:54073 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSxzN-0007YP-DT for submit@debbugs.gnu.org; Thu, 15 Oct 2020 03:47:53 -0400 Received: from mab.sdf.org ([205.166.94.33]:49892 helo=ma.sdf.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kSxzL-0007YH-6v for 25987@debbugs.gnu.org; Thu, 15 Oct 2020 03:47:51 -0400 Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1kSxzE-0005TA-UR; Thu, 15 Oct 2020 07:47:44 +0000 From: Andrea Corallo 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> Date: Thu, 15 Oct 2020 07:47:44 +0000 In-Reply-To: (David Malcolm's message of "Wed, 14 Oct 2020 18:43:33 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) David Malcolm writes: [...] >> >> 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? Yes, INSIDE_EMACS is not an option if we want to have GCC to depose special files, would work if is just a matter of changing format but I don't think this is the case (more on this below). > 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). Here come the trouble. Ideally would be great to just emit to stderr and integrate with compilation-mode. My understanding is that this would just not work for parallel builds as the output on stderr can be intermixed, so the idea to dump to a special file. I think (may be wrong) that this guided patching (but also the navigation through the hierarchical hints that your static analyzer produces) should be all handled by an ipotethical dedicated gcc-mode that consume these json files. I toyed already with this approach for the static analyzer hints here [1]. You are correct suggesting that the connection from the stderr output in compilation-mode may not be trivial but assuming this is a requirement we have quite some info in the diagnostic message to search for the corresponding diagnostic in the json. "bar.c:350:3: error: invalid conversion to type 'foo_t'" Maybe we could even add a diagnostic ID to make the connection simpler? Or the other option is that we make it working saftely only for non parallel builds just using stderr, but I don't think this is very future proof, especially given you are constantly adding cool new features to GCC we could make use of :) Andrea [1] From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Oct 2020 13:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Malcolm Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160276999925030 (code B ref 25987); Thu, 15 Oct 2020 13:54:02 +0000 Received: (at 25987) by debbugs.gnu.org; 15 Oct 2020 13:53:19 +0000 Received: from localhost ([127.0.0.1]:54876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT3h1-0006Ve-DQ for submit@debbugs.gnu.org; Thu, 15 Oct 2020 09:53:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT3gz-0006VS-Qu for 25987@debbugs.gnu.org; Thu, 15 Oct 2020 09:53:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50705) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kT3gu-00025h-Fa; Thu, 15 Oct 2020 09:53:12 -0400 Received: from [176.228.60.248] (port=1680 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kT3gt-0003vW-Fs; Thu, 15 Oct 2020 09:53:12 -0400 Date: Thu, 15 Oct 2020 16:53:25 +0300 Message-Id: <83mu0ny4ru.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from David Malcolm on Wed, 14 Oct 2020 18:43:33 -0400) 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> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: David Malcolm > Cc: 25987@debbugs.gnu.org > Date: Wed, 14 Oct 2020 18:43:33 -0400 > > 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). I'm not sure how a separate file comes into this. Aren't we talking about the "normal" GCC diagnostic output, just augmented by hints? That has the advantage that it is also human-readable, and could help the user make changes other than accepting the hints. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Oct 2020 14:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org, David Malcolm Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160277179329102 (code B ref 25987); Thu, 15 Oct 2020 14:24:02 +0000 Received: (at 25987) by debbugs.gnu.org; 15 Oct 2020 14:23:13 +0000 Received: from localhost ([127.0.0.1]:56137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT49x-0007ZK-JG for submit@debbugs.gnu.org; Thu, 15 Oct 2020 10:23:13 -0400 Received: from mab.sdf.org ([205.166.94.33]:50164 helo=ma.sdf.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT49w-0007ZD-PI for 25987@debbugs.gnu.org; Thu, 15 Oct 2020 10:23:13 -0400 Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1kT49p-0001PB-Mp; Thu, 15 Oct 2020 14:23:05 +0000 From: Andrea Corallo 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> <83mu0ny4ru.fsf@gnu.org> Date: Thu, 15 Oct 2020 14:23:05 +0000 In-Reply-To: <83mu0ny4ru.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 15 Oct 2020 16:53:25 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: David Malcolm >> Cc: 25987@debbugs.gnu.org >> Date: Wed, 14 Oct 2020 18:43:33 -0400 >> >> 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). > > I'm not sure how a separate file comes into this. Aren't we talking > about the "normal" GCC diagnostic output, just augmented by hints? > That has the advantage that it is also human-readable, and could help > the user make changes other than accepting the hints. I explained this in my last mail on this thread, to make it short using stderr can't work reliably for parallel builds. Maybe we decide that's good enought but has to be considered now as IMO it's a strong limitation. Andrea From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Oct 2020 14:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Andrea Corallo Cc: 25987@debbugs.gnu.org, dmalcolm@redhat.com Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160277219829910 (code B ref 25987); Thu, 15 Oct 2020 14:30:02 +0000 Received: (at 25987) by debbugs.gnu.org; 15 Oct 2020 14:29:58 +0000 Received: from localhost ([127.0.0.1]:56155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT4GT-0007mM-SK for submit@debbugs.gnu.org; Thu, 15 Oct 2020 10:29:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT4GS-0007m5-1t for 25987@debbugs.gnu.org; Thu, 15 Oct 2020 10:29:56 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51538) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kT4GK-00075C-VP; Thu, 15 Oct 2020 10:29:48 -0400 Received: from [176.228.60.248] (port=3923 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kT4GI-0006Az-5l; Thu, 15 Oct 2020 10:29:47 -0400 Date: Thu, 15 Oct 2020 17:29:59 +0300 Message-Id: <83blh3y32w.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Andrea Corallo on Thu, 15 Oct 2020 14:23:05 +0000) 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> <83mu0ny4ru.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Andrea Corallo > Cc: David Malcolm , 25987@debbugs.gnu.org > Date: Thu, 15 Oct 2020 14:23:05 +0000 > > > I'm not sure how a separate file comes into this. Aren't we talking > > about the "normal" GCC diagnostic output, just augmented by hints? > > That has the advantage that it is also human-readable, and could help > > the user make changes other than accepting the hints. > > I explained this in my last mail on this thread, to make it short using > stderr can't work reliably for parallel builds. That's not a problem the feature discussed here can fix: it happens with any parallel build run by "M-x compile". The solution to that is elsewhere (e.g., in using the GNU Make's command-line switches which control parallelsim). From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Oct 2020 14:45:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org, dmalcolm@redhat.com Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160277309831371 (code B ref 25987); Thu, 15 Oct 2020 14:45:01 +0000 Received: (at 25987) by debbugs.gnu.org; 15 Oct 2020 14:44:58 +0000 Received: from localhost ([127.0.0.1]:56173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT4Uz-00089v-Og for submit@debbugs.gnu.org; Thu, 15 Oct 2020 10:44:57 -0400 Received: from mab.sdf.org ([205.166.94.33]:60710 helo=ma.sdf.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kT4Uy-00089n-CV for 25987@debbugs.gnu.org; Thu, 15 Oct 2020 10:44:56 -0400 Received: from akrl by ma.sdf.org with local (Exim 4.92) (envelope-from ) id 1kT4Uu-0002uW-6W; Thu, 15 Oct 2020 14:44:52 +0000 From: Andrea Corallo 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> <83mu0ny4ru.fsf@gnu.org> <83blh3y32w.fsf@gnu.org> Date: Thu, 15 Oct 2020 14:44:52 +0000 In-Reply-To: <83blh3y32w.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 15 Oct 2020 17:29:59 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Andrea Corallo >> Cc: David Malcolm , 25987@debbugs.gnu.org >> Date: Thu, 15 Oct 2020 14:23:05 +0000 >> >> > I'm not sure how a separate file comes into this. Aren't we talking >> > about the "normal" GCC diagnostic output, just augmented by hints? >> > That has the advantage that it is also human-readable, and could help >> > the user make changes other than accepting the hints. >> >> I explained this in my last mail on this thread, to make it short using >> stderr can't work reliably for parallel builds. > > That's not a problem the feature discussed here can fix: it happens > with any parallel build run by "M-x compile". Yes, but this is less severe as the line is tipically preserved and the regexps we use for the goto-error are not affected, so in practice it works. The case of the patch is more sensitive. > The solution to that is > elsewhere (e.g., in using the GNU Make's command-line switches which > control parallelsim). That is saying is good enough. I'm fine with that in case, but this was to explain why the separate file came in. Andrea From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Oct 2020 14:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.16032055416604 (code B ref 25987); Tue, 20 Oct 2020 14:53:02 +0000 Received: (at 25987) by debbugs.gnu.org; 20 Oct 2020 14:52:21 +0000 Received: from localhost ([127.0.0.1]:46328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kUszp-0001iO-Iz for submit@debbugs.gnu.org; Tue, 20 Oct 2020 10:52:21 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:38535) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kUszl-0001iE-EE for 25987@debbugs.gnu.org; Tue, 20 Oct 2020 10:52:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603205533; 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: in-reply-to:in-reply-to:references:references; bh=UucMi9sLcjj/0VxJsNzJiYLKciIRiAJ9co28cY4JaSU=; b=E/Hi/IAHny6g7Wdu0hH+1N26vAzlCaHOO19Z7hFd5G1+Qap0GlAbgfYvd4e11lKzNaSaIX JgIS5GxpfI7XuaPxv0UPgrPryXtcD4INvGu5+zY1KvRKZeL6Yqnj2C9EA+LwIXzmK6vvS5 7vBa/f5MWWuvv+jN01xYGxATesEHNDI= 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-414-Z7YtNQd5OF-hl1qrWKUCyQ-1; Tue, 20 Oct 2020 10:52:08 -0400 X-MC-Unique: Z7YtNQd5OF-hl1qrWKUCyQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 045AC57052; Tue, 20 Oct 2020 14:52:07 +0000 (UTC) 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 617AA10013C1; Tue, 20 Oct 2020 14:52:06 +0000 (UTC) Message-ID: <8666386379d22239075d9237f00f40469c5be454.camel@redhat.com> From: David Malcolm Date: Tue, 20 Oct 2020 10:52:05 -0400 In-Reply-To: <83362i2nul.fsf@gnu.org> 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> User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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 Content-Type: multipart/mixed; boundary="=-4h98EPL4w39tKOwjGwZm" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-4h98EPL4w39tKOwjGwZm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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. > > > BTW, does Emacs set anything in the environment that GCC could > > detect? > > Yes, Emacs sets INSIDE_EMACS when it runs a sub-process. > > > Does Emacs have an automated test suite that could test this > > feature? > > Yes, see the tests in the test/ subdirectory of the Emacs tree. > > > 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. Thanks Eli and Andrea. I've implemented a proof-of-concept of this. I'm attaching the patch for discussion/review purposes (it probably doesn't quite apply cleanly to gcc master as I had some other diagnostic stuff in that working copy; it also hasn't yet been subjected to the usual testing for a gcc patch). I'm also attaching the stderr with GCC_EXTRA_DIAGNOSTIC_OUTPUT=fixits-v2 in the env when using the patched gcc to compile the demo.c file from message #82. Hopefully the output looks consumable by Emacs. One possible issue: in the final diagnostic, there's a fix-it hint with non-ASCII replacement text, replacing "two_pi" with "two_π" (where the final char in the latter is GREEK SMALL LETTER PI, U+03C0) This replacement currently expressed as encoded bytes i.e: fix-it:"demo.c":{51:10-51:16}:"two_\317\200" where \317\200 is the octal-escaped representation of the two bytes of the UTF-8 encoding of the character. Is this going to work for Emacs? Dave --=-4h98EPL4w39tKOwjGwZm Content-Disposition: attachment; filename="demo.out" Content-Type: text/plain; name="demo.out"; charset="UTF-8" Content-Transfer-Encoding: base64 ZGVtby5jOiBJbiBmdW5jdGlvbiDigJh0ZXN0XzHigJk6CmRlbW8uYzoxNDoxMDogd2FybmluZzog aW1wbGljaXQgZGVjbGFyYXRpb24gb2YgZnVuY3Rpb24g4oCYbWFsbG9j4oCZIFstV2ltcGxpY2l0 LWZ1bmN0aW9uLWRlY2xhcmF0aW9uXQogICAxNCB8ICAgcmV0dXJuIG1hbGxvYyAoNDA5Nik7CiAg ICAgIHwgICAgICAgICAgXn5+fn5+CmRlbW8uYzozOjE6IG5vdGU6IGluY2x1ZGUg4oCYPHN0ZGxp Yi5oPuKAmSBvciBwcm92aWRlIGEgZGVjbGFyYXRpb24gb2Yg4oCYbWFsbG9j4oCZCiAgICAyIHwg I2luY2x1ZGUgPHN0ZGlvLmg+CiAgKysrIHwrI2luY2x1ZGUgPHN0ZGxpYi5oPgogICAgMyB8IApm aXgtaXQ6ImRlbW8uYyI6ezM6MS0zOjF9OiIjaW5jbHVkZSA8c3RkbGliLmg+XG4iCmRlbW8uYzox NDoxMDogd2FybmluZzogaW5jb21wYXRpYmxlIGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGJ1aWx0 LWluIGZ1bmN0aW9uIOKAmG1hbGxvY+KAmSBbLVdidWlsdGluLWRlY2xhcmF0aW9uLW1pc21hdGNo XQogICAxNCB8ICAgcmV0dXJuIG1hbGxvYyAoNDA5Nik7CiAgICAgIHwgICAgICAgICAgXn5+fn5+ CmRlbW8uYzoxNDoxMDogbm90ZTogaW5jbHVkZSDigJg8c3RkbGliLmg+4oCZIG9yIHByb3ZpZGUg YSBkZWNsYXJhdGlvbiBvZiDigJhtYWxsb2PigJkKZGVtby5jOiBJbiBmdW5jdGlvbiDigJh0ZXN0 XzJh4oCZOgpkZW1vLmM6MjA6MjE6IGVycm9yOiDigJhzdHJ1Y3QgdmVydOKAmSBoYXMgbm8gbWVt YmVyIG5hbWVkIOKAmGNvbG91cuKAmTsgZGlkIHlvdSBtZWFuIOKAmGNvbG9y4oCZPwogICAyMCB8 ICAgLyog8J+ZgiDwn5mCIPCfmYIgKi8gdi0+Y29sb3VyID0gMDsKICAgICAgfCAgICAgICAgICAg ICAgICAgICAgIF5+fn5+fgogICAgICB8ICAgICAgICAgICAgICAgICAgICAgY29sb3IKZml4LWl0 OiJkZW1vLmMiOnsyMDoyMS0yMDoyN306ImNvbG9yIgpkZW1vLmM6IEluIGZ1bmN0aW9uIOKAmHRl c3RfMmLigJk6CmRlbW8uYzoyNjoxODogZXJyb3I6IOKAmHN0cnVjdCB2ZXJ04oCZIGhhcyBubyBt ZW1iZXIgbmFtZWQg4oCYY29sb3Vy4oCZOyBkaWQgeW91IG1lYW4g4oCYY29sb3LigJk/CiAgIDI2 IHwgICAvKiDPgCDPgCDPgCAqLyB2LT5jb2xvdXIgPSAwOwogICAgICB8ICAgICAgICAgICAgICAg ICAgXn5+fn5+CiAgICAgIHwgICAgICAgICAgICAgICAgICBjb2xvcgpmaXgtaXQ6ImRlbW8uYyI6 ezI2OjE4LTI2OjI0fToiY29sb3IiCmRlbW8uYzogSW4gZnVuY3Rpb24g4oCYdGVzdF8yY+KAmToK ZGVtby5jOjMyOjIxOiBlcnJvcjog4oCYc3RydWN0IHZlcnTigJkgaGFzIG5vIG1lbWJlciBuYW1l ZCDigJhjb2xvdXLigJk7IGRpZCB5b3UgbWVhbiDigJhjb2xvcuKAmT8KICAgMzIgfCAgIC8qIOaW h+Wtl+WMluOBkSAqLyB2LT5jb2xvdXIgPSAwOwogICAgICB8ICAgICAgICAgICAgICAgICAgICAg Xn5+fn5+CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICBjb2xvcgpmaXgtaXQ6ImRlbW8uYyI6 ezMyOjIxLTMyOjI3fToiY29sb3IiCmRlbW8uYzogSW4gZnVuY3Rpb24g4oCYdGVzdF8z4oCZOgpk ZW1vLmM6Mzg6MTQ6IGVycm9yOiDigJhzdHJ1Y3QgdmVydOKAmSBoYXMgbm8gbWVtYmVyIG5hbWVk IOKAmGNvbG91cuKAmTsgZGlkIHlvdSBtZWFuIOKAmGNvbG9y4oCZPwogICAzOCB8ICAgICAgICAg ICB2LT5jb2xvdXIgPSAwOwogICAgICB8ICAgICAgICAgICAgICBefn5+fn4KICAgICAgfCAgICAg ICAgICAgICAgY29sb3IKZml4LWl0OiJkZW1vLmMiOnszODoxNC0zODoyMH06ImNvbG9yIgpkZW1v LmM6IEluIGZ1bmN0aW9uIOKAmHRlc3RfNOKAmToKZGVtby5jOjQ0OjEwOiBlcnJvcjog4oCYc3Ry dWN0IHZlcnTigJkgaGFzIG5vIG1lbWJlciBuYW1lZCDigJhjb2xvdXLigJk7IGRpZCB5b3UgbWVh biDigJhjb2xvcuKAmT8KICAgNDQgfCAgIGlmICh2LT5jb2xvdXIpIHYtPmNvbG91ciArPSAyOwog ICAgICB8ICAgICAgICAgIF5+fn5+fgogICAgICB8ICAgICAgICAgIGNvbG9yCmZpeC1pdDoiZGVt by5jIjp7NDQ6MTAtNDQ6MTZ9OiJjb2xvciIKZGVtby5jOjQ0OjIxOiBlcnJvcjog4oCYc3RydWN0 IHZlcnTigJkgaGFzIG5vIG1lbWJlciBuYW1lZCDigJhjb2xvdXLigJk7IGRpZCB5b3UgbWVhbiDi gJhjb2xvcuKAmT8KICAgNDQgfCAgIGlmICh2LT5jb2xvdXIpIHYtPmNvbG91ciArPSAyOwogICAg ICB8ICAgICAgICAgICAgICAgICAgICAgXn5+fn5+CiAgICAgIHwgICAgICAgICAgICAgICAgICAg ICBjb2xvcgpmaXgtaXQ6ImRlbW8uYyI6ezQ0OjIxLTQ0OjI3fToiY29sb3IiCmRlbW8uYzogSW4g ZnVuY3Rpb24g4oCYdGVzdF814oCZOgpkZW1vLmM6NTE6MTA6IGVycm9yOiDigJh0d29fcGnigJkg dW5kZWNsYXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pOyBkaWQgeW91IG1lYW4g4oCY dHdvX8+A4oCZPwogICA1MSB8ICAgcmV0dXJuIHR3b19waTsKICAgICAgfCAgICAgICAgICBefn5+ fn4KICAgICAgfCAgICAgICAgICB0d29fz4AKZml4LWl0OiJkZW1vLmMiOns1MToxMC01MToxNn06 InR3b19cMzE3XDIwMCIKZGVtby5jOjUxOjEwOiBub3RlOiBlYWNoIHVuZGVjbGFyZWQgaWRlbnRp ZmllciBpcyByZXBvcnRlZCBvbmx5IG9uY2UgZm9yIGVhY2ggZnVuY3Rpb24gaXQgYXBwZWFycyBp bgo= --=-4h98EPL4w39tKOwjGwZm Content-Disposition: attachment; filename*0=0001-Add-GCC_EXTRA_DIAGNOSTIC_OUTPUT-environment-variable.pat; filename*1=ch Content-Type: text/x-patch; name="0001-Add-GCC_EXTRA_DIAGNOSTIC_OUTPUT-environment-variable.patch"; charset="UTF-8" Content-Transfer-Encoding: base64 RnJvbSAyZTFlZDZlYTdlYTFlNTI0ZjJmNWI1MDM1MzI3ZWQyODBmZmY0NzVkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBEYXZpZCBNYWxjb2xtIDxkbWFsY29sbUByZWRoYXQuY29tPgpE YXRlOiBNb24sIDE5IE9jdCAyMDIwIDIwOjE5OjQ4IC0wNDAwClN1YmplY3Q6IFtQQVRDSF0gQWRk IEdDQ19FWFRSQV9ESUFHTk9TVElDX09VVFBVVCBlbnZpcm9ubWVudCB2YXJpYWJsZSBmb3IKIGZp eC1pdCBoaW50cwoKR0NDIGhhcyBoYWQgdGhlIGFiaWxpdHkgdG8gZW1pdCBmaXgtaXQgaGludHMg aW4gbWFjaGluZS1yZWFkYWJsZSBmb3JtCnNpbmNlIEdDQyA3IHZpYSAtZmRpYWdub3N0aWNzLXBh cnNlYWJsZS1maXhpdHMgYW5kCi1mZGlhZ25vc3RpY3MtZ2VuZXJhdGUtcGF0Y2guCgpUaGUgZm9y bWVyIGVtaXRzIGFkZGl0aW9uYWwgc3BlY2lhbGx5LWZvcm1hdHRlZCBsaW5lcyB0byBzdGRlcnI7 IHRoZQpvcHRpb24gYW5kIGl0cyBmb3JtYXQgd2VyZSBkaXJlY3RseSB0YWtlbiBmcm9tIGEgcHJl LWV4aXN0aW5nIG9wdGlvbgppbiBjbGFuZy4KCklkZWFsbHkgdGhpcyBjb3VsZCBiZSB1c2VkIGJ5 IElERXMgc28gdGhhdCB0aGUgdXNlciBjYW4gc2VsZWN0IHNwZWNpZmljCmZpeC1pdCBoaW50cyBh bmQgaGF2ZSB0aGUgSURFIGFwcGx5IHRoZW0gdG8gdGhlIHVzZXIncyBzb3VyY2UgY29kZQoocGVy aGFwcyB0dXJuaW5nIHRoZW0gaW50byBjbGlja2FibGUgZWxlbWVudHMsIHBlcmhhcHMgd2l0aCBh bgoiQXBwbHkgQWxsIiBvcHRpb24sIGV0YykuICBFY2xpcHNlIENEVCBoYXMgc3VwcG9ydGVkIHRo aXMgb3B0aW9uIGluCnRoaXMgd2F5IGZvciBhIGZldyB5ZWFyczoKICBodHRwczovL2J1Z3MuZWNs aXBzZS5vcmcvYnVncy9zaG93X2J1Zy5jZ2k/aWQ9NDk3NjcwCgpBcyBhIHVzZXIgb2YgRW1hY3Mg SSB3b3VsZCBsaWtlIEVtYWNzIHRvIHN1cHBvcnQgc3VjaCBhIGZlYXR1cmUuCmh0dHBzOi8vZGVi YnVncy5nbnUub3JnL2NnaS9idWdyZXBvcnQuY2dpP2J1Zz0yNTk4NyB0cmFja3Mgc3VwcG9ydGlu ZwpHQ0MgZml4LWl0IG91dHB1dCBpbiBFbWFjcy4gIFRoZSBkaXNjdXNzaW9uIHRoZXJlIGlkZW50 aWZpZXMgdHdvIGlzc3Vlcwp3aXRoIHRoZSBleGlzdGluZyBvcHRpb246CgooYSkgY29sdW1ucyBp biB0aGUgb3V0cHV0IGFyZSBzcGVjaWZpZWQgYXMgYnl0ZS1vZmZzZXRzIHdpdGhpbiB0aGUKbGlu ZSAoZm9yIGV4YWN0IGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgb3B0aW9uIGluIGNsYW5nKSwgd2hl cmVhcyBlbWFjcwp3b3VsZCBwcmVmZXIgdG8gY29uc3VtZSB0aGVtIGFzIHdoYXQgR0NDIDExIGNh bGxzICJkaXNwbGF5IGNvbHVtbnMiLgpodHRwczovL2djYy5nbnUub3JnL29ubGluZWRvY3MvZ2Nj L0RpYWdub3N0aWMtTWVzc2FnZS1Gb3JtYXR0aW5nLU9wdGlvbnMuaHRtbCNpbmRleC1mZGlhZ25v c3RpY3MtY29sdW1uLXVuaXQKCihiKSBpbmplY3RpbmcgYSBjb21tYW5kLWxpbmUgb3B0aW9uIGlu dG8gdGhlIGJ1aWxkIGlzIGEgZmlkZGx5IG1hbnVhbApzdGVwLCB2YXJ5aW5nIGJldHdlZW4gYnVp bGQgc3lzdGVtcy4gIEl0J3MgZmFyIGVhc2llciBmb3IgdGhlCnVzZXIgaWYgRW1hY3Mgc2ltcGx5 IHNldHMgYW4gZW52aXJvbm1lbnQgdmFyaWFibGUgd2hlbiBjb21waWxpbmcsCkdDQyB1c2VzIHRo aXMgdG8gZW5hYmxlIHRoZSBvcHRpb24gaWYgaXQgcmVjb2duaXplcyB0aGUgdmFsdWUsIGFuZAp0 aGUgZW1hY3MgY29tcGlsYXRpb24gYnVmZmVyIGRlY29kZXMgdGhlIGFkZGl0aW9uYWwgbGluZXMg b2Ygb3V0cHV0CmFuZCBhZGRzIGFwcHJvcHJpYXRlIHdpZGdldHMuICBJbiBzb21lIHdheXMgaXQg aXMgYSB3b3JrYXJvdW5kIGZvcgpub3QgaGF2aW5nIGEgbGFuZ3VhZ2Ugc2VydmVyLiAgRG9pbmcg aXQgdGhpcyB3YXkgbWVhbnMgdGhhdCBmb3IgdGhlCnZhcmlvdXMgY29tYmluYXRpb25zIG9mIG9s ZGVyIGFuZCBuZXdlciBHQ0MgYW5kIG9sZGVyIGFuZCBuZXdlciBFbWFjcwp0aGF0IGEgc3VmZmlj aWVudGx5IG1vZGVybiBjb21iaW5hdGlvbiBvZiBib3RoIGNhbiBhdXRvbWF0aWNhbGx5CnN1cHBv cnQgdGhlIHJpY2ggZml4LWl0IFVJLCB3aGVyZWFzIG90aGVyIGNvbWJpbmF0aW9ucyB3aWxsIGVp dGhlcgpub3QgcHJvdmlkZSB0aGUgZW52dmFyLCBvciBzaWxlbnRseSBpZ25vcmUgaXQsIGdyYWNl ZnVsbHkgZG9pbmcKbm90aGluZyBleHRyYS4KCkhlbmNlIHRoaXMgcGF0Y2ggYWRkcyBhIG5ldyBH Q0NfRVhUUkFfRElBR05PU1RJQ19PVVRQVVQgZW52aXJvbm1lbnQKdmFyaWFibGUgdG8gR0NDIHdo aWNoIGVuYWJsZXMgb3V0cHV0IG9mIG1hY2hpbmUtcGFyc2VhYmxlIGZpeC1pdCBoaW50cy4KCkdD Q19FWFRSQV9ESUFHTk9TVElDX09VVFBVVD1maXhpdHMtdjEgaXMgZXF1aXZhbGVudCB0byB0aGUg ZXhpc3RpbmcKLWZkaWFnbm9zdGljcy1wYXJzZWFibGUtZml4aXRzIG9wdGlvbi4KCkdDQ19FWFRS QV9ESUFHTk9TVElDX09VVFBVVD1maXhpdHMtdjIgaXMgdGhlIHNhbWUsIGJ1dCBjaGFuZ2VzIHRo ZQpjb2x1bW4gb3V0cHV0IG1vZGUgdG8gImRpc3BsYXkgY29sdW1ucyIgcmF0aGVyIHRoYW4gYnl0 ZXMsIGFzCnJlcXVpcmVkIGJ5IEVtYWNzLgoKZ2NjL0NoYW5nZUxvZzoKCSogZGlhZ25vc3RpYy5j IChkaWFnbm9zdGljX2luaXRpYWxpemUpOiBFbGltaW5hdGUKCXBhcnNlYWJsZV9maXhpdHNfcCBp biBmYXZvciBvZiBpbml0aWFsaXppbmcgZXh0cmFfb3V0cHV0X2tpbmQgZnJvbQoJR0NDX0VYVFJB X0RJQUdOT1NUSUNfT1VUUFVULgoJKGNvbnZlcnRfY29sdW1uX3VuaXQpOiBOZXcgZnVuY3Rpb24s IHNwbGl0IG91dCBmcm9tLi4uCgkoZGlhZ25vc3RpY19jb252ZXJ0ZWRfY29sdW1uKTogLi4udGhp cy4KCShwcmludF9wYXJzZWFibGVfZml4aXRzKTogQWRkICJjb2x1bW5fdW5pdCIgYW5kICJ0YWJz dG9wIiBwYXJhbXMuCglVc2UgdGhlbSB0byBjYWxsIGNvbnZlcnRfY29sdW1uX3VuaXQgb24gdGhl IGNvbHVtbiB2YWx1ZXMuCgkoZGlhZ25vc3RpY19yZXBvcnRfZGlhZ25vc3RpYyk6IEVsaW1pbmF0 ZSBjb25kaXRpb25hbCBvbgoJcGFyc2VhYmxlX2ZpeGl0c19wIGluIGZhdm9yIG9mIGEgc3dpdGNo IHN0YXRlbWVudCBvbgoJZXh0cmFfb3V0cHV0X2tpbmQsIHBhc3NpbmcgdGhlIGFwcHJvcHJpYXRl IHZhbHVlcyB0byB0aGUgbmV3CglwYXJhbXMgb2YgcHJpbnRfcGFyc2VhYmxlX2ZpeGl0cy4KCShz ZWxmdGVzdDo6dGVzdF9wcmludF9wYXJzZWFibGVfZml4aXRzX25vbmUpOiBVcGRhdGUgZm9yIG5l dwoJcGFyYW1zIG9mIHByaW50X3BhcnNlYWJsZV9maXhpdHMuCgkoc2VsZnRlc3Q6OnRlc3RfcHJp bnRfcGFyc2VhYmxlX2ZpeGl0c19pbnNlcnQpOiBMaWtld2lzZS4KCShzZWxmdGVzdDo6dGVzdF9w cmludF9wYXJzZWFibGVfZml4aXRzX3JlbW92ZSk6IExpa2V3aXNlLgoJKHNlbGZ0ZXN0Ojp0ZXN0 X3ByaW50X3BhcnNlYWJsZV9maXhpdHNfcmVwbGFjZSk6IExpa2V3aXNlLgoJKHNlbGZ0ZXN0Ojp0 ZXN0X3ByaW50X3BhcnNlYWJsZV9maXhpdHNfYnl0ZXNfdnNfZGlzcGxheV9jb2x1bW5zKToKCU5l dy4KCShzZWxmdGVzdDo6ZGlhZ25vc3RpY19jX3Rlc3RzKTogQ2FsbCBpdC4KCSogZGlhZ25vc3Rp Yy5oIChlbnVtIGRpYWdub3N0aWNzX2V4dHJhX291dHB1dF9raW5kKTogTmV3LgoJKGRpYWdub3N0 aWNfY29udGV4dDo6cGFyc2VhYmxlX2ZpeGl0c19wKTogRGVsZXRlIGZpZWxkIGluIGZhdm9yCglv Zi4uLgoJKGRpYWdub3N0aWNfY29udGV4dDo6ZXh0cmFfb3V0cHV0X2tpbmQpOiAuLi50aGlzIG5l dyBmaWVsZC4KCSogZG9jL2ludm9rZS50ZXhpIChFbnZpcm9ubWVudCBWYXJpYWJsZXMpOiBBZGQK CUdDQ19FWFRSQV9ESUFHTk9TVElDX09VVFBVVC4KCSogb3B0cy5jIChjb21tb25faGFuZGxlX29w dGlvbik6IFVwZGF0ZSBoYW5kbGluZyBvZgoJT1BUX2ZkaWFnbm9zdGljc19wYXJzZWFibGVfZml4 aXRzIGZvciBjaGFuZ2UgdG8gZGlhZ25vc3RpY19jb250ZXh0CglmaWVsZHMuCi0tLQogZ2NjL2Rp YWdub3N0aWMuYyAgICB8IDEzOCArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKyst LS0tLS0tLQogZ2NjL2RpYWdub3N0aWMuaCAgICB8ICAyMyArKysrKysrLQogZ2NjL2RvYy9pbnZv a2UudGV4aSB8ICAxOSArKysrKysKIGdjYy9vcHRzLmMgICAgICAgICAgfCAgIDQgKy0KIDQgZmls ZXMgY2hhbmdlZCwgMTU1IGluc2VydGlvbnMoKyksIDI5IGRlbGV0aW9ucygtKQoKZGlmZiAtLWdp dCBhL2djYy9kaWFnbm9zdGljLmMgYi9nY2MvZGlhZ25vc3RpYy5jCmluZGV4IDFiNmM5ODQ1ODky Li43NzI0ZjBlMDUwYiAxMDA2NDQKLS0tIGEvZ2NjL2RpYWdub3N0aWMuYworKysgYi9nY2MvZGlh Z25vc3RpYy5jCkBAIC0yMTksNyArMjE5LDE0IEBAIGRpYWdub3N0aWNfaW5pdGlhbGl6ZSAoZGlh Z25vc3RpY19jb250ZXh0ICpjb250ZXh0LCBpbnQgbl9vcHRzKQogICBjb250ZXh0LT5zaG93X2xp bmVfbnVtYmVyc19wID0gZmFsc2U7CiAgIGNvbnRleHQtPm1pbl9tYXJnaW5fd2lkdGggPSAwOwog ICBjb250ZXh0LT5zaG93X3J1bGVyX3AgPSBmYWxzZTsKLSAgY29udGV4dC0+cGFyc2VhYmxlX2Zp eGl0c19wID0gZmFsc2U7CisgIGlmIChjb25zdCBjaGFyICp2YXIgPSBnZXRlbnYgKCJHQ0NfRVhU UkFfRElBR05PU1RJQ19PVVRQVVQiKSkKKyAgICB7CisgICAgICBpZiAoIXN0cmNtcCAodmFyLCAi Zml4aXRzLXYxIikpCisJY29udGV4dC0+ZXh0cmFfb3V0cHV0X2tpbmQgPSBFWFRSQV9ESUFHTk9T VElDX09VVFBVVF9maXhpdHNfdjE7CisgICAgICBlbHNlIGlmICghc3RyY21wICh2YXIsICJmaXhp dHMtdjIiKSkKKwljb250ZXh0LT5leHRyYV9vdXRwdXRfa2luZCA9IEVYVFJBX0RJQUdOT1NUSUNf T1VUUFVUX2ZpeGl0c192MjsKKyAgICAgIC8qIFNpbGVudGx5IGlnbm9yZSB1bnJlY29nbml6ZWQg dmFsdWVzLiAgKi8KKyAgICB9CiAgIGNvbnRleHQtPmNvbHVtbl91bml0ID0gRElBR05PU1RJQ1Nf Q09MVU1OX1VOSVRfRElTUExBWTsKICAgY29udGV4dC0+Y29sdW1uX29yaWdpbiA9IDE7CiAgIGNv bnRleHQtPnRhYnN0b3AgPSA4OwpAQCAtMzU4LDI5ICszNjUsNDAgQEAgZGlhZ25vc3RpY19nZXRf Y29sb3JfZm9yX2tpbmQgKGRpYWdub3N0aWNfdCBraW5kKQogfQogCiAvKiBHaXZlbiBhbiBleHBh bmRlZF9sb2NhdGlvbiwgY29udmVydCB0aGUgY29sdW1uICh3aGljaCBpcyBpbiAxLWJhc2VkIGJ5 dGVzKQotICAgdG8gdGhlIHJlcXVlc3RlZCB1bml0cyBhbmQgb3JpZ2luLiAgUmV0dXJuIC0xIGlm IHRoZSBjb2x1bW4gaXMKLSAgIGludmFsaWQgKDw9IDApLiAgKi8KLWludAotZGlhZ25vc3RpY19j b252ZXJ0ZWRfY29sdW1uIChkaWFnbm9zdGljX2NvbnRleHQgKmNvbnRleHQsIGV4cGFuZGVkX2xv Y2F0aW9uIHMpCisgICB0byB0aGUgcmVxdWVzdGVkIHVuaXRzLCB3aXRob3V0IGNvbnZlcnRpbmcg dGhlIG9yaWdpbi4KKyAgIFJldHVybiAtMSBpZiB0aGUgY29sdW1uIGlzIGludmFsaWQgKDw9IDAp LiAgKi8KKworc3RhdGljIGludAorY29udmVydF9jb2x1bW5fdW5pdCAoZW51bSBkaWFnbm9zdGlj c19jb2x1bW5fdW5pdCBjb2x1bW5fdW5pdCwKKwkJICAgICBpbnQgdGFic3RvcCwKKwkJICAgICBl eHBhbmRlZF9sb2NhdGlvbiBzKQogewogICBpZiAocy5jb2x1bW4gPD0gMCkKICAgICByZXR1cm4g LTE7CiAKLSAgaW50IG9uZV9iYXNlZF9jb2w7Ci0gIHN3aXRjaCAoY29udGV4dC0+Y29sdW1uX3Vu aXQpCisgIHN3aXRjaCAoY29sdW1uX3VuaXQpCiAgICAgeworICAgIGRlZmF1bHQ6CisgICAgICBn Y2NfdW5yZWFjaGFibGUgKCk7CisKICAgICBjYXNlIERJQUdOT1NUSUNTX0NPTFVNTl9VTklUX0RJ U1BMQVk6Ci0gICAgICBvbmVfYmFzZWRfY29sID0gbG9jYXRpb25fY29tcHV0ZV9kaXNwbGF5X2Nv bHVtbiAocywgY29udGV4dC0+dGFic3RvcCk7Ci0gICAgICBicmVhazsKKyAgICAgIHJldHVybiBs b2NhdGlvbl9jb21wdXRlX2Rpc3BsYXlfY29sdW1uIChzLCB0YWJzdG9wKTsKIAogICAgIGNhc2Ug RElBR05PU1RJQ1NfQ09MVU1OX1VOSVRfQllURToKLSAgICAgIG9uZV9iYXNlZF9jb2wgPSBzLmNv bHVtbjsKLSAgICAgIGJyZWFrOwotCi0gICAgZGVmYXVsdDoKLSAgICAgIGdjY191bnJlYWNoYWJs ZSAoKTsKKyAgICAgIHJldHVybiBzLmNvbHVtbjsKICAgICB9Cit9CiAKKy8qIEdpdmVuIGFuIGV4 cGFuZGVkX2xvY2F0aW9uLCBjb252ZXJ0IHRoZSBjb2x1bW4gKHdoaWNoIGlzIGluIDEtYmFzZWQg Ynl0ZXMpCisgICB0byB0aGUgcmVxdWVzdGVkIHVuaXRzIGFuZCBvcmlnaW4uICBSZXR1cm4gLTEg aWYgdGhlIGNvbHVtbiBpcworICAgaW52YWxpZCAoPD0gMCkuICAqLworaW50CitkaWFnbm9zdGlj X2NvbnZlcnRlZF9jb2x1bW4gKGRpYWdub3N0aWNfY29udGV4dCAqY29udGV4dCwgZXhwYW5kZWRf bG9jYXRpb24gcykKK3sKKyAgaW50IG9uZV9iYXNlZF9jb2wKKyAgICA9IGNvbnZlcnRfY29sdW1u X3VuaXQgKGNvbnRleHQtPmNvbHVtbl91bml0LCBjb250ZXh0LT50YWJzdG9wLCBzKTsKKyAgaWYg KG9uZV9iYXNlZF9jb2wgPD0gMCkKKyAgICByZXR1cm4gLTE7CiAgIHJldHVybiBvbmVfYmFzZWRf Y29sICsgKGNvbnRleHQtPmNvbHVtbl9vcmlnaW4gLSAxKTsKIH0KIApAQCAtOTIwLDExICs5Mzgs MTYgQEAgcHJpbnRfZXNjYXBlZF9zdHJpbmcgKHByZXR0eV9wcmludGVyICpwcCwgY29uc3QgY2hh ciAqdGV4dCkKICAgcHBfY2hhcmFjdGVyIChwcCwgJyInKTsKIH0KIAotLyogSW1wbGVtZW50YXRp b24gb2YgLWZkaWFnbm9zdGljcy1wYXJzZWFibGUtZml4aXRzLiAgUHJpbnQgYQotICAgbWFjaGlu ZS1wYXJzZWFibGUgdmVyc2lvbiBvZiBhbGwgZml4aXRzIGluIFJJQ0hMT0MgdG8gUFAuICAqLwor LyogSW1wbGVtZW50YXRpb24gb2YgLWZkaWFnbm9zdGljcy1wYXJzZWFibGUtZml4aXRzIGFuZAor ICAgR0NDX0VYVFJBX0RJQUdOT1NUSUNfT1VUUFVULgorICAgUHJpbnQgYSBtYWNoaW5lLXBhcnNl YWJsZSB2ZXJzaW9uIG9mIGFsbCBmaXhpdHMgaW4gUklDSExPQyB0byBQUCwKKyAgIHVzaW5nIENP TFVNTl9VTklUIHRvIGV4cHJlc3MgY29sdW1ucy4KKyAgIFVzZSBUQUJTVE9QIHdoZW4gaGFuZGxp bmcgRElBR05PU1RJQ1NfQ09MVU1OX1VOSVRfRElTUExBWS4gICovCiAKIHN0YXRpYyB2b2lkCi1w cmludF9wYXJzZWFibGVfZml4aXRzIChwcmV0dHlfcHJpbnRlciAqcHAsIHJpY2hfbG9jYXRpb24g KnJpY2hsb2MpCitwcmludF9wYXJzZWFibGVfZml4aXRzIChwcmV0dHlfcHJpbnRlciAqcHAsIHJp Y2hfbG9jYXRpb24gKnJpY2hsb2MsCisJCQllbnVtIGRpYWdub3N0aWNzX2NvbHVtbl91bml0IGNv bHVtbl91bml0LAorCQkJaW50IHRhYnN0b3ApCiB7CiAgIGdjY19hc3NlcnQgKHBwKTsKICAgZ2Nj X2Fzc2VydCAocmljaGxvYyk7CkBAIC05NDIsOSArOTY1LDEzIEBAIHByaW50X3BhcnNlYWJsZV9m aXhpdHMgKHByZXR0eV9wcmludGVyICpwcCwgcmljaF9sb2NhdGlvbiAqcmljaGxvYykKICAgICAg IC8qIEZvciBjb21wYXRpYmlsaXR5IHdpdGggY2xhbmcsIHByaW50IGFzIGEgaGFsZi1vcGVuIHJh bmdlLiAgKi8KICAgICAgIGxvY2F0aW9uX3QgbmV4dF9sb2MgPSBoaW50LT5nZXRfbmV4dF9sb2Mg KCk7CiAgICAgICBleHBhbmRlZF9sb2NhdGlvbiBuZXh0X2V4cGxvYyA9IGV4cGFuZF9sb2NhdGlv biAobmV4dF9sb2MpOworICAgICAgaW50IHN0YXJ0X2NvbAorCT0gY29udmVydF9jb2x1bW5fdW5p dCAoY29sdW1uX3VuaXQsIHRhYnN0b3AsIHN0YXJ0X2V4cGxvYyk7CisgICAgICBpbnQgbmV4dF9j b2wKKwk9IGNvbnZlcnRfY29sdW1uX3VuaXQgKGNvbHVtbl91bml0LCB0YWJzdG9wLCBuZXh0X2V4 cGxvYyk7CiAgICAgICBwcF9wcmludGYgKHBwLCAiOnslaTolaS0laTolaX06IiwKLQkJIHN0YXJ0 X2V4cGxvYy5saW5lLCBzdGFydF9leHBsb2MuY29sdW1uLAotCQkgbmV4dF9leHBsb2MubGluZSwg bmV4dF9leHBsb2MuY29sdW1uKTsKKwkJIHN0YXJ0X2V4cGxvYy5saW5lLCBzdGFydF9jb2wsCisJ CSBuZXh0X2V4cGxvYy5saW5lLCBuZXh0X2NvbCk7CiAgICAgICBwcmludF9lc2NhcGVkX3N0cmlu ZyAocHAsIGhpbnQtPmdldF9zdHJpbmcgKCkpOwogICAgICAgcHBfbmV3bGluZSAocHApOwogICAg IH0KQEAgLTEyMTAsMTAgKzEyMzcsMjIgQEAgZGlhZ25vc3RpY19yZXBvcnRfZGlhZ25vc3RpYyAo ZGlhZ25vc3RpY19jb250ZXh0ICpjb250ZXh0LAogICBpZiAoY29udGV4dC0+c2hvd19vcHRpb25f cmVxdWVzdGVkKQogICAgIHByaW50X29wdGlvbl9pbmZvcm1hdGlvbiAoY29udGV4dCwgZGlhZ25v c3RpYywgb3JpZ19kaWFnX2tpbmQpOwogICAoKmRpYWdub3N0aWNfZmluYWxpemVyIChjb250ZXh0 KSkgKGNvbnRleHQsIGRpYWdub3N0aWMsIG9yaWdfZGlhZ19raW5kKTsKLSAgaWYgKGNvbnRleHQt PnBhcnNlYWJsZV9maXhpdHNfcCkKKyAgc3dpdGNoIChjb250ZXh0LT5leHRyYV9vdXRwdXRfa2lu ZCkKICAgICB7Ci0gICAgICBwcmludF9wYXJzZWFibGVfZml4aXRzIChjb250ZXh0LT5wcmludGVy LCBkaWFnbm9zdGljLT5yaWNobG9jKTsKKyAgICBkZWZhdWx0OgorICAgICAgYnJlYWs7CisgICAg Y2FzZSBFWFRSQV9ESUFHTk9TVElDX09VVFBVVF9maXhpdHNfdjE6CisgICAgICBwcmludF9wYXJz ZWFibGVfZml4aXRzIChjb250ZXh0LT5wcmludGVyLCBkaWFnbm9zdGljLT5yaWNobG9jLAorCQkJ ICAgICAgRElBR05PU1RJQ1NfQ09MVU1OX1VOSVRfQllURSwKKwkJCSAgICAgIGNvbnRleHQtPnRh YnN0b3ApOworICAgICAgcHBfZmx1c2ggKGNvbnRleHQtPnByaW50ZXIpOworICAgICAgYnJlYWs7 CisgICAgY2FzZSBFWFRSQV9ESUFHTk9TVElDX09VVFBVVF9maXhpdHNfdjI6CisgICAgICBwcmlu dF9wYXJzZWFibGVfZml4aXRzIChjb250ZXh0LT5wcmludGVyLCBkaWFnbm9zdGljLT5yaWNobG9j LAorCQkJICAgICAgRElBR05PU1RJQ1NfQ09MVU1OX1VOSVRfRElTUExBWSwKKwkJCSAgICAgIGNv bnRleHQtPnRhYnN0b3ApOwogICAgICAgcHBfZmx1c2ggKGNvbnRleHQtPnByaW50ZXIpOworICAg ICAgYnJlYWs7CiAgICAgfQogICBkaWFnbm9zdGljX2FjdGlvbl9hZnRlcl9vdXRwdXQgKGNvbnRl eHQsIGRpYWdub3N0aWMtPmtpbmQpOwogICBkaWFnbm9zdGljLT54X2RhdGEgPSBOVUxMOwpAQCAt MjAxMiw3ICsyMDUxLDcgQEAgdGVzdF9wcmludF9wYXJzZWFibGVfZml4aXRzX25vbmUgKCkKICAg cHJldHR5X3ByaW50ZXIgcHA7CiAgIHJpY2hfbG9jYXRpb24gcmljaGxvYyAobGluZV90YWJsZSwg VU5LTk9XTl9MT0NBVElPTik7CiAKLSAgcHJpbnRfcGFyc2VhYmxlX2ZpeGl0cyAoJnBwLCAmcmlj aGxvYyk7CisgIHByaW50X3BhcnNlYWJsZV9maXhpdHMgKCZwcCwgJnJpY2hsb2MsIERJQUdOT1NU SUNTX0NPTFVNTl9VTklUX0JZVEUsIDgpOwogICBBU1NFUlRfU1RSRVEgKCIiLCBwcF9mb3JtYXR0 ZWRfdGV4dCAoJnBwKSk7CiB9CiAKQEAgLTIwMzEsNyArMjA3MCw3IEBAIHRlc3RfcHJpbnRfcGFy c2VhYmxlX2ZpeGl0c19pbnNlcnQgKCkKICAgbG9jYXRpb25fdCB3aGVyZSA9IGxpbmVtYXBfcG9z aXRpb25fZm9yX2NvbHVtbiAobGluZV90YWJsZSwgMTApOwogICByaWNobG9jLmFkZF9maXhpdF9p bnNlcnRfYmVmb3JlICh3aGVyZSwgImFkZGVkIGNvbnRlbnQiKTsKIAotICBwcmludF9wYXJzZWFi bGVfZml4aXRzICgmcHAsICZyaWNobG9jKTsKKyAgcHJpbnRfcGFyc2VhYmxlX2ZpeGl0cyAoJnBw LCAmcmljaGxvYywgRElBR05PU1RJQ1NfQ09MVU1OX1VOSVRfQllURSwgOCk7CiAgIEFTU0VSVF9T VFJFUSAoImZpeC1pdDpcInRlc3QuY1wiOns1OjEwLTU6MTB9OlwiYWRkZWQgY29udGVudFwiXG4i LAogCQlwcF9mb3JtYXR0ZWRfdGV4dCAoJnBwKSk7CiB9CkBAIC0yMDUzLDcgKzIwOTIsNyBAQCB0 ZXN0X3ByaW50X3BhcnNlYWJsZV9maXhpdHNfcmVtb3ZlICgpCiAgIHdoZXJlLm1fZmluaXNoID0g bGluZW1hcF9wb3NpdGlvbl9mb3JfY29sdW1uIChsaW5lX3RhYmxlLCAyMCk7CiAgIHJpY2hsb2Mu YWRkX2ZpeGl0X3JlbW92ZSAod2hlcmUpOwogCi0gIHByaW50X3BhcnNlYWJsZV9maXhpdHMgKCZw cCwgJnJpY2hsb2MpOworICBwcmludF9wYXJzZWFibGVfZml4aXRzICgmcHAsICZyaWNobG9jLCBE SUFHTk9TVElDU19DT0xVTU5fVU5JVF9CWVRFLCA4KTsKICAgQVNTRVJUX1NUUkVRICgiZml4LWl0 OlwidGVzdC5jXCI6ezU6MTAtNToyMX06XCJcIlxuIiwKIAkJcHBfZm9ybWF0dGVkX3RleHQgKCZw cCkpOwogfQpAQCAtMjA3NSwxMSArMjExNCw1OSBAQCB0ZXN0X3ByaW50X3BhcnNlYWJsZV9maXhp dHNfcmVwbGFjZSAoKQogICB3aGVyZS5tX2ZpbmlzaCA9IGxpbmVtYXBfcG9zaXRpb25fZm9yX2Nv bHVtbiAobGluZV90YWJsZSwgMjApOwogICByaWNobG9jLmFkZF9maXhpdF9yZXBsYWNlICh3aGVy ZSwgInJlcGxhY2VtZW50Iik7CiAKLSAgcHJpbnRfcGFyc2VhYmxlX2ZpeGl0cyAoJnBwLCAmcmlj aGxvYyk7CisgIHByaW50X3BhcnNlYWJsZV9maXhpdHMgKCZwcCwgJnJpY2hsb2MsIERJQUdOT1NU SUNTX0NPTFVNTl9VTklUX0JZVEUsIDgpOwogICBBU1NFUlRfU1RSRVEgKCJmaXgtaXQ6XCJ0ZXN0 LmNcIjp7NToxMC01OjIxfTpcInJlcGxhY2VtZW50XCJcbiIsCiAJCXBwX2Zvcm1hdHRlZF90ZXh0 ICgmcHApKTsKIH0KIAorLyogVmVyaWZ5IHRoYXQgcHJpbnRfcGFyc2VhYmxlX2ZpeGl0cyBjb3Jy ZWN0bHkgaGFuZGxlcworICAgRElBR05PU1RJQ1NfQ09MVU1OX1VOSVRfQllURSB2cyBESUFHTk9T VElDU19DT0xVTU5fVU5JVF9DT0xVTU4uICAqLworCitzdGF0aWMgdm9pZAordGVzdF9wcmludF9w YXJzZWFibGVfZml4aXRzX2J5dGVzX3ZzX2Rpc3BsYXlfY29sdW1ucyAoKQoreworICBsaW5lX3Rh YmxlX3Rlc3QgbHR0OworICByaWNoX2xvY2F0aW9uIHJpY2hsb2MgKGxpbmVfdGFibGUsIFVOS05P V05fTE9DQVRJT04pOworCisgIC8qIDEtYmFzZWQgYnl0ZSBvZmZzZXRzOiAgICAgMTIzNDU2Nzc3 Nzg4ODg5OTk5MDAwMDEyMzQ1NjcuICAqLworICBjb25zdCBjaGFyICpjb25zdCBjb250ZW50ID0g InNtaWxlIFx4ZjBceDlmXHg5OFx4ODIgY29sb3VyXG4iOworICAvKiAxLWJhc2VkIGRpc3BsYXkg Y29sczogICAgIDEyMzQ1NlsuLi4uLi43LTguLi4uLl05MDEyMzQ1LiAgKi8KKyAgY29uc3QgaW50 IHRhYnN0b3AgPSA4OworCisgIHRlbXBfc291cmNlX2ZpbGUgdG1wIChTRUxGVEVTVF9MT0NBVElP TiwgIi5jIiwgY29udGVudCk7CisgIGNvbnN0IGNoYXIgKmNvbnN0IGZuYW1lID0gdG1wLmdldF9m aWxlbmFtZSAoKTsKKworICBsaW5lbWFwX2FkZCAobGluZV90YWJsZSwgTENfRU5URVIsIGZhbHNl LCBmbmFtZSwgMCk7CisgIGxpbmVtYXBfbGluZV9zdGFydCAobGluZV90YWJsZSwgMSwgMTAwKTsK KyAgbGluZW1hcF9hZGQgKGxpbmVfdGFibGUsIExDX0xFQVZFLCBmYWxzZSwgTlVMTCwgMCk7Cisg IHNvdXJjZV9yYW5nZSB3aGVyZTsKKyAgd2hlcmUubV9zdGFydCA9IGxpbmVtYXBfcG9zaXRpb25f Zm9yX2NvbHVtbiAobGluZV90YWJsZSwgMTIpOworICB3aGVyZS5tX2ZpbmlzaCA9IGxpbmVtYXBf cG9zaXRpb25fZm9yX2NvbHVtbiAobGluZV90YWJsZSwgMTcpOworICByaWNobG9jLmFkZF9maXhp dF9yZXBsYWNlICh3aGVyZSwgImNvbG9yIik7CisKKyAgY29uc3QgaW50IGJ1Zl9sZW4gPSBzdHJs ZW4gKGZuYW1lKSArIDEwMDsKKyAgY2hhciAqY29uc3QgZXhwZWN0ZWQgPSBYTkVXVkVDIChjaGFy LCBidWZfbGVuKTsKKworICB7CisgICAgcHJldHR5X3ByaW50ZXIgcHA7CisgICAgcHJpbnRfcGFy c2VhYmxlX2ZpeGl0cyAoJnBwLCAmcmljaGxvYywgRElBR05PU1RJQ1NfQ09MVU1OX1VOSVRfQllU RSwKKwkJCSAgICB0YWJzdG9wKTsKKyAgICBzbnByaW50ZiAoZXhwZWN0ZWQsIGJ1Zl9sZW4sCisJ ICAgICAgImZpeC1pdDpcIiVzXCI6ezE6MTItMToxOH06XCJjb2xvclwiXG4iLCBmbmFtZSk7Cisg ICAgQVNTRVJUX1NUUkVRIChleHBlY3RlZCwgcHBfZm9ybWF0dGVkX3RleHQgKCZwcCkpOworICB9 CisgIHsKKyAgICBwcmV0dHlfcHJpbnRlciBwcDsKKyAgICBwcmludF9wYXJzZWFibGVfZml4aXRz ICgmcHAsICZyaWNobG9jLCBESUFHTk9TVElDU19DT0xVTU5fVU5JVF9ESVNQTEFZLAorCQkJICAg IHRhYnN0b3ApOworICAgIHNucHJpbnRmIChleHBlY3RlZCwgYnVmX2xlbiwKKwkgICAgICAiZml4 LWl0OlwiJXNcIjp7MToxMC0xOjE2fTpcImNvbG9yXCJcbiIsIGZuYW1lKTsKKyAgICBBU1NFUlRf U1RSRVEgKGV4cGVjdGVkLCBwcF9mb3JtYXR0ZWRfdGV4dCAoJnBwKSk7CisgIH0KKworICBYREVM RVRFVkVDIChleHBlY3RlZCk7Cit9CisKIC8qIFZlcmlmeSB0aGF0CiAgICAgIGRpYWdub3N0aWNf Z2V0X2xvY2F0aW9uX3RleHQgKC4uLiwgU0hPV19DT0xVTU4pCiAgICBnZW5lcmF0ZXMgRVhQRUNU RURfTE9DX1RFWFQsIGdpdmVuIEZJTEVOQU1FLCBMSU5FLCBDT0xVTU4sIHdpdGgKQEAgLTIyMDIs NiArMjI4OSw3IEBAIGRpYWdub3N0aWNfY190ZXN0cyAoKQogICB0ZXN0X3ByaW50X3BhcnNlYWJs ZV9maXhpdHNfaW5zZXJ0ICgpOwogICB0ZXN0X3ByaW50X3BhcnNlYWJsZV9maXhpdHNfcmVtb3Zl ICgpOwogICB0ZXN0X3ByaW50X3BhcnNlYWJsZV9maXhpdHNfcmVwbGFjZSAoKTsKKyAgdGVzdF9w cmludF9wYXJzZWFibGVfZml4aXRzX2J5dGVzX3ZzX2Rpc3BsYXlfY29sdW1ucyAoKTsKICAgdGVz dF9kaWFnbm9zdGljX2dldF9sb2NhdGlvbl90ZXh0ICgpOwogICB0ZXN0X251bV9kaWdpdHMgKCk7 CiAKZGlmZiAtLWdpdCBhL2djYy9kaWFnbm9zdGljLmggYi9nY2MvZGlhZ25vc3RpYy5oCmluZGV4 IDFkMmZhMTE5NjQzLi5lODhkNjNjMjEyOCAxMDA2NDQKLS0tIGEvZ2NjL2RpYWdub3N0aWMuaAor KysgYi9nY2MvZGlhZ25vc3RpYy5oCkBAIC02OSw2ICs2OSwyMiBAQCBlbnVtIGRpYWdub3N0aWNf cGF0aF9mb3JtYXQKICAgRFBGX0hUTUwKIH07CiAKKy8qIEFuIGVudW0gZm9yIGNhcHR1cmluZyB2 YWx1ZXMgb2YgR0NDX0VYVFJBX0RJQUdOT1NUSUNfT1VUUFVULAorICAgYW5kIGZvciAtZmRpYWdu b3N0aWNzLXBhcnNlYWJsZS1maXhpdHMuICAqLworCitlbnVtIGRpYWdub3N0aWNzX2V4dHJhX291 dHB1dF9raW5kCit7CisgIC8qIE5vIGV4dHJhIG91dHB1dCwgb3IgYW4gdW5yZWNvZ25pemVkIHZh bHVlLiAgKi8KKyAgRVhUUkFfRElBR05PU1RJQ19PVVRQVVRfbm9uZSwKKworICAvKiBFbWl0IGZp eC1pdCBoaW50cyB1c2luZyB0aGUgImZpeGl0cy12MSIgZm9ybWF0LCBlcXVpdmFsZW50IHRvCisg ICAgIC1mZGlhZ25vc3RpY3MtcGFyc2VhYmxlLWZpeGl0cy4gICovCisgIEVYVFJBX0RJQUdOT1NU SUNfT1VUUFVUX2ZpeGl0c192MSwKKworICAvKiBFbWl0IGZpeC1pdCBoaW50cyB1c2luZyB0aGUg ImZpeGl0cy12MiIgZm9ybWF0LiAgKi8KKyAgRVhUUkFfRElBR05PU1RJQ19PVVRQVVRfZml4aXRz X3YyCit9OworCiAvKiBBIGRpYWdub3N0aWMgaXMgZGVzY3JpYmVkIGJ5IHRoZSBNRVNTQUdFIHRv IHNlbmQsIHRoZSBGSUxFIGFuZCBMSU5FIG9mCiAgICBpdHMgY29udGV4dCBhbmQgaXRzIEtJTkQg KGljZSwgZXJyb3IsIHdhcm5pbmcsIG5vdGUsIC4uLikgIFNlZSBjb21wbGV0ZQogICAgbGlzdCBp biBkaWFnbm9zdGljLmRlZi4gICovCkBAIC0yOTYsOSArMzEyLDEwIEBAIHN0cnVjdCBkaWFnbm9z dGljX2NvbnRleHQKICAgICAgc291cmNlIG91dHB1dC4gICovCiAgIGJvb2wgc2hvd19ydWxlcl9w OwogCi0gIC8qIElmIHRydWUsIHByaW50IGZpeGl0cyBpbiBtYWNoaW5lLXBhcnNlYWJsZSBmb3Jt IGFmdGVyIHRoZQotICAgICByZXN0IG9mIHRoZSBkaWFnbm9zdGljLiAgKi8KLSAgYm9vbCBwYXJz ZWFibGVfZml4aXRzX3A7CisgIC8qIFVzZWQgdG8gc3BlY2lmeSBhZGRpdGlvbmFsIGRpYWdub3N0 aWMgb3V0cHV0IHRvIGJlIGVtaXR0ZWQgYWZ0ZXIgdGhlCisgICAgIHJlc3Qgb2YgdGhlIGRpYWdu b3N0aWMuICBUaGlzIGlzIGZvciBpbXBsZW1lbnRpbmcKKyAgICAgLWZkaWFnbm9zdGljcy1wYXJz ZWFibGUtZml4aXRzIGFuZCBHQ0NfRVhUUkFfRElBR05PU1RJQ19PVVRQVVQuICAqLworICBlbnVt IGRpYWdub3N0aWNzX2V4dHJhX291dHB1dF9raW5kIGV4dHJhX291dHB1dF9raW5kOwogCiAgIC8q IFdoYXQgdW5pdHMgdG8gdXNlIHdoZW4gb3V0cHV0dGluZyB0aGUgY29sdW1uIG51bWJlci4gICov CiAgIGVudW0gZGlhZ25vc3RpY3NfY29sdW1uX3VuaXQgY29sdW1uX3VuaXQ7CmRpZmYgLS1naXQg YS9nY2MvZG9jL2ludm9rZS50ZXhpIGIvZ2NjL2RvYy9pbnZva2UudGV4aQppbmRleCA1NWY3YTk4 NTRhYS4uZjgzZmU4ZjczNWMgMTAwNjQ0Ci0tLSBhL2djYy9kb2MvaW52b2tlLnRleGkKKysrIGIv Z2NjL2RvYy9pbnZva2UudGV4aQpAQCAtMzE5OTgsNiArMzE5OTgsMjUgQEAgUmVjb2duaXplIEVV Q0pQIGNoYXJhY3RlcnMuCiBJZiBAZW52e0xBTkd9IGlzIG5vdCBkZWZpbmVkLCBvciBpZiBpdCBo YXMgc29tZSBvdGhlciB2YWx1ZSwgdGhlbiB0aGUKIGNvbXBpbGVyIHVzZXMgQGNvZGV7bWJsZW59 IGFuZCBAY29kZXttYnRvd2N9IGFzIGRlZmluZWQgYnkgdGhlIGRlZmF1bHQgbG9jYWxlIHRvCiBy ZWNvZ25pemUgYW5kIHRyYW5zbGF0ZSBtdWx0aWJ5dGUgY2hhcmFjdGVycy4KKworQGl0ZW0gR0ND X0VYVFJBX0RJQUdOT1NUSUNfT1VUUFVUCitJZiBAZW52e0dDQ19FWFRSQV9ESUFHTk9TVElDX09V VFBVVH0gaXMgc2V0IHRvIG9uZSBvZiB0aGUgZm9sbG93aW5nIHZhbHVlcywKK3RoZW4gYWRkaXRp b25hbCB0ZXh0IHdpbGwgYmUgZW1pdHRlZCB0byBzdGRlcnIgd2hlbiBmaXgtaXQgaGludHMgYXJl CitlbWl0dGVkLiAgQG9wdGlvbnstZmRpYWdub3N0aWNzLXBhcnNlYWJsZS1maXhpdHN9IGFuZAor QG9wdGlvbnstZm5vLWRpYWdub3N0aWNzLXBhcnNlYWJsZS1maXhpdHN9IHRha2UgcHJlY2VkZW5j ZSBvdmVyIHRoaXMKK2Vudmlyb25tZW50IHZhcmlhYmxlLgorCitAdGFibGUgQHNhbXAKK0BpdGVt IGZpeGl0cy12MQorRW1pdCBwYXJzZWFibGUgZml4LWl0IGhpbnRzLCBlcXVpdmFsZW50IHRvCitA b3B0aW9uey1mZGlhZ25vc3RpY3MtcGFyc2VhYmxlLWZpeGl0c30uICBJbiBwYXJ0aWN1bGFyLCBj b2x1bW5zIGFyZQorZXhwcmVzc2VkIGFzIGEgY291bnQgb2YgYnl0ZXMsIHN0YXJ0aW5nIGF0IGJ5 dGUgMSBmb3IgdGhlIGluaXRpYWwgY29sdW1uLgorCitAaXRlbSBmaXhpdHMtdjIKK0FzIEBjb2Rl e2ZpeGl0cy12MX0sIGJ1dCBjb2x1bW5zIGFyZSBleHByZXNzZWQgYXMgZGlzcGxheSBjb2x1bW5z LAorYXMgcGVyIEBvcHRpb257LWZkaWFnbm9zdGljcy1jb2x1bW4tdW5pdD1kaXNwbGF5fS4KK0Bl bmQgdGFibGUKKwogQGVuZCB0YWJsZQogCiBAbm9pbmRlbnQKZGlmZiAtLWdpdCBhL2djYy9vcHRz LmMgYi9nY2Mvb3B0cy5jCmluZGV4IGRhNTAzYzMyZGQwLi5iNzc2ZjNiMzFlMSAxMDA2NDQKLS0t IGEvZ2NjL29wdHMuYworKysgYi9nY2Mvb3B0cy5jCkBAIC0yNDIyLDcgKzI0MjIsOSBAQCBjb21t b25faGFuZGxlX29wdGlvbiAoc3RydWN0IGdjY19vcHRpb25zICpvcHRzLAogICAgICAgYnJlYWs7 CiAKICAgICBjYXNlIE9QVF9mZGlhZ25vc3RpY3NfcGFyc2VhYmxlX2ZpeGl0czoKLSAgICAgIGRj LT5wYXJzZWFibGVfZml4aXRzX3AgPSB2YWx1ZTsKKyAgICAgIGRjLT5leHRyYV9vdXRwdXRfa2lu ZCA9ICh2YWx1ZQorCQkJICAgICAgID8gRVhUUkFfRElBR05PU1RJQ19PVVRQVVRfZml4aXRzX3Yx CisJCQkgICAgICAgOiBFWFRSQV9ESUFHTk9TVElDX09VVFBVVF9ub25lKTsKICAgICAgIGJyZWFr OwogCiAgICAgY2FzZSBPUFRfZmRpYWdub3N0aWNzX2NvbHVtbl91bml0XzoKLS0gCjIuMjYuMgoK --=-4h98EPL4w39tKOwjGwZm-- From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Oct 2020 15:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Malcolm Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160320925412949 (code B ref 25987); Tue, 20 Oct 2020 15:55:02 +0000 Received: (at 25987) by debbugs.gnu.org; 20 Oct 2020 15:54:14 +0000 Received: from localhost ([127.0.0.1]:46454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kUtxl-0003Mn-Tt for submit@debbugs.gnu.org; Tue, 20 Oct 2020 11:54:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kUtxk-0003Ma-PT for 25987@debbugs.gnu.org; Tue, 20 Oct 2020 11:54:13 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57965) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUtxf-0003I6-Eq; Tue, 20 Oct 2020 11:54:07 -0400 Received: from [176.228.60.248] (port=2164 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kUtxe-0001Hv-Pf; Tue, 20 Oct 2020 11:54:07 -0400 Date: Tue, 20 Oct 2020 18:54:16 +0300 Message-Id: <837drkopuf.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8666386379d22239075d9237f00f40469c5be454.camel@redhat.com> (message from David Malcolm on Tue, 20 Oct 2020 10:52:05 -0400) 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> <8666386379d22239075d9237f00f40469c5be454.camel@redhat.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: David Malcolm > Cc: 25987@debbugs.gnu.org > Date: Tue, 20 Oct 2020 10:52:05 -0400 > > One possible issue: in the final diagnostic, there's a fix-it hint with > non-ASCII replacement text, replacing "two_pi" with "two_π" (where the > final char in the latter is GREEK SMALL LETTER PI, U+03C0) > > This replacement currently expressed as encoded bytes i.e: > > fix-it:"demo.c":{51:10-51:16}:"two_\317\200" > > where \317\200 is the octal-escaped representation of the two bytes of > the UTF-8 encoding of the character. > > Is this going to work for Emacs? You mean, GCC doesn't actually emit the UTF-8 encoding of π, it emits its ASCII-fied representation? We'd need to decode that, but is that really justified? Why not emit UTF-8? From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Nov 2020 19:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160512341827900 (code B ref 25987); Wed, 11 Nov 2020 19:37:02 +0000 Received: (at 25987) by debbugs.gnu.org; 11 Nov 2020 19:36:58 +0000 Received: from localhost ([127.0.0.1]:42906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kcvvO-0007Fw-1U for submit@debbugs.gnu.org; Wed, 11 Nov 2020 14:36:58 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:44233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kcvvL-0007Fn-SQ for 25987@debbugs.gnu.org; Wed, 11 Nov 2020 14:36:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605123415; 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=tuZMKWiUDAcxTPoFkuQRWue6/VxLyaLtFv4v8MblFZA=; b=WdbCHPnRA1QO16vDTX9WW9MpAjZgt/cJl7auow0zTfbBVOoZT4xRn3um3779VnDmnZvk20 gWB3gXjz9fL/kGzeYNEZbOpdZie71oxxTnEN0OFu2f3T/ORdMtxt6wM2LxgTzo+M2UABli vL5fc1Kn/HfYxS5UXvwpSiAoWjqBBuw= 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-483-0kB7baU8OUiP_mR4poWbLw-1; Wed, 11 Nov 2020 14:36:51 -0500 X-MC-Unique: 0kB7baU8OUiP_mR4poWbLw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7006E5F9C2; Wed, 11 Nov 2020 19:36:50 +0000 (UTC) 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 0B4C75C629; Wed, 11 Nov 2020 19:36:49 +0000 (UTC) Message-ID: From: David Malcolm Date: Wed, 11 Nov 2020 14:36:49 -0500 In-Reply-To: <837drkopuf.fsf@gnu.org> 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> <8666386379d22239075d9237f00f40469c5be454.camel@redhat.com> <837drkopuf.fsf@gnu.org> User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, 2020-10-20 at 18:54 +0300, Eli Zaretskii wrote: > > From: David Malcolm > > Cc: 25987@debbugs.gnu.org > > Date: Tue, 20 Oct 2020 10:52:05 -0400 > > > > One possible issue: in the final diagnostic, there's a fix-it hint > > with > > non-ASCII replacement text, replacing "two_pi" with "two_π" (where > > the > > final char in the latter is GREEK SMALL LETTER PI, U+03C0) > > > > This replacement currently expressed as encoded bytes i.e: > > > > fix-it:"demo.c":{51:10-51:16}:"two_\317\200" > > > > where \317\200 is the octal-escaped representation of the two bytes > > of > > the UTF-8 encoding of the character. > > > > Is this going to work for Emacs? > > You mean, GCC doesn't actually emit the UTF-8 encoding of π, it emits > its ASCII-fied representation? We'd need to decode that, but is that > really justified? Why not emit UTF-8? I have an implementation that simply emits UTF-8 in quotes, escaping backslash, tab, newline, and doublequotes as before. (we have to escape at least newline, given that fix-it hint replacement text can contain them, and we're using newline to terminate the parseable hint). However, the filename also needs to be escaped. Currently I'm applying the same escaping rules to both filename and replacement text. What is the encoding of the filename? What if the bytes in a filename aren't UTF-8 encoded? How does emacs handle this case? I tried creating file with the name "byte 0xff" .txt, and with valid UTF-8 non- ascii names and emacs reported them as \377.txt and with the UTF-8 names respectively, so perhaps I should simply emit the bytes and pretend they are UTF-8? Dave [1] https://dwheeler.com/essays/fixing-unix-linux-filenames.html From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Nov 2020 13:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Malcolm Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160518926713670 (code B ref 25987); Thu, 12 Nov 2020 13:55:01 +0000 Received: (at 25987) by debbugs.gnu.org; 12 Nov 2020 13:54:27 +0000 Received: from localhost ([127.0.0.1]:44021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kdD3S-0003YQ-OM for submit@debbugs.gnu.org; Thu, 12 Nov 2020 08:54:27 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56908) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kdD3Q-0003YD-SY for 25987@debbugs.gnu.org; Thu, 12 Nov 2020 08:54:25 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52211) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdD3L-0004F1-ID; Thu, 12 Nov 2020 08:54:19 -0500 Received: from [176.228.60.248] (port=4748 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kdD3K-0004UH-GV; Thu, 12 Nov 2020 08:54:19 -0500 Date: Thu, 12 Nov 2020 15:54:31 +0200 Message-Id: <83mtzmznmw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from David Malcolm on Wed, 11 Nov 2020 14:36:49 -0500) 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> <8666386379d22239075d9237f00f40469c5be454.camel@redhat.com> <837drkopuf.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: David Malcolm > Cc: 25987@debbugs.gnu.org > Date: Wed, 11 Nov 2020 14:36:49 -0500 > > On Tue, 2020-10-20 at 18:54 +0300, Eli Zaretskii wrote: > > > From: David Malcolm > > > Cc: 25987@debbugs.gnu.org > > > Date: Tue, 20 Oct 2020 10:52:05 -0400 > > > > > > One possible issue: in the final diagnostic, there's a fix-it hint > > > with > > > non-ASCII replacement text, replacing "two_pi" with "two_π" (where > > > the > > > final char in the latter is GREEK SMALL LETTER PI, U+03C0) > > > > > > This replacement currently expressed as encoded bytes i.e: > > > > > > fix-it:"demo.c":{51:10-51:16}:"two_\317\200" > > > > > > where \317\200 is the octal-escaped representation of the two bytes > > > of > > > the UTF-8 encoding of the character. > > > > > > Is this going to work for Emacs? > > > > You mean, GCC doesn't actually emit the UTF-8 encoding of π, it emits > > its ASCII-fied representation? We'd need to decode that, but is that > > really justified? Why not emit UTF-8? > > I have an implementation that simply emits UTF-8 in quotes, escaping > backslash, tab, newline, and doublequotes as before. (we have to > escape at least newline, given that fix-it hint replacement text can > contain them, and we're using newline to terminate the parseable hint). Sorry, I've lost the context: where did those non-ASCII names come from? are they names of variables in the user's program? If so, in what encoding does GCC quote portions of the source code in its warning/error messages? Does it use the exact byte stream it found in the source, or does it perform any conversions of the encoding? > However, the filename also needs to be escaped. Currently I'm applying > the same escaping rules to both filename and replacement text. > What is the encoding of the filename? What if the bytes in a filename > aren't UTF-8 encoded? How does emacs handle this case? Emacs has a separate variable for the encoding of file names, which gets set from the locale settings. But this is not necessarily relevant to the issue at hand, because we are talking about processing output from a sub-process (GCC) which includes both file names and other stuff, such as fragments of the source code. When Emacs processes sub-process output, it generally assumes all of it is encoded in the same encoding. So if, for example, you encode non-ASCII variables in UTF-8 while the file names are emitted in some other encoding (perhaps because the locale's codeset is not UTF-8), then there will be complications: we will have to read the output from GCC in its raw form, and then decode "by hand" (in Lisp) each part of it as appropriate (which means we will need to be able to identifye each such part). So it's important to understand the situation and its limitations for proposing the best solution. > I tried creating file with the name "byte 0xff" .txt, and with valid > UTF-8 non- ascii names and emacs reported them as \377.txt and with > the UTF-8 names respectively, so perhaps I should simply emit the > bytes and pretend they are UTF-8? What do you mean by "pretend" in this context? From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Nov 2020 16:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160528604723984 (code B ref 25987); Fri, 13 Nov 2020 16:48:02 +0000 Received: (at 25987) by debbugs.gnu.org; 13 Nov 2020 16:47:27 +0000 Received: from localhost ([127.0.0.1]:49243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kdcER-0006Em-0V for submit@debbugs.gnu.org; Fri, 13 Nov 2020 11:47:27 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:45414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kdcEO-0006Ed-QV for 25987@debbugs.gnu.org; Fri, 13 Nov 2020 11:47:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605286044; 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=+SmHzVzC11QZRbmvAPuAvqnE9klAX7vAuPSAoWbJMVo=; b=eT/TesnxenRc3TZEEJZyIiwEsww+NmiBH5ivdCfdHPJ1oLBysAudTyYMhBQPGUoCy6XbjR GwQrV1rEDcXp5eDGzAPup5jpx7JNzfzBZj6ikQPxSO7DsELcHM7h7+XkS+l+2hHyACSYLb WTmIC2PRoy1Afs+NozsQ+yeweQYoI8U= 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-578-N02Ta3uuOW-wbhgLAlfM6A-1; Fri, 13 Nov 2020 11:47:20 -0500 X-MC-Unique: N02Ta3uuOW-wbhgLAlfM6A-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E4345185E486; Fri, 13 Nov 2020 16:47:19 +0000 (UTC) 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 72FDE46; Fri, 13 Nov 2020 16:47:19 +0000 (UTC) Message-ID: <0b88a592c7611d740b9dfa4bd4d853d14264be8d.camel@redhat.com> From: David Malcolm Date: Fri, 13 Nov 2020 11:47:18 -0500 In-Reply-To: <83mtzmznmw.fsf@gnu.org> 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> <8666386379d22239075d9237f00f40469c5be454.camel@redhat.com> <837drkopuf.fsf@gnu.org> <83mtzmznmw.fsf@gnu.org> User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, 2020-11-12 at 15:54 +0200, Eli Zaretskii wrote: > > From: David Malcolm > > Cc: 25987@debbugs.gnu.org > > Date: Wed, 11 Nov 2020 14:36:49 -0500 > > > > On Tue, 2020-10-20 at 18:54 +0300, Eli Zaretskii wrote: > > > > From: David Malcolm > > > > Cc: 25987@debbugs.gnu.org > > > > Date: Tue, 20 Oct 2020 10:52:05 -0400 > > > > > > > > One possible issue: in the final diagnostic, there's a fix-it > > > > hint > > > > with > > > > non-ASCII replacement text, replacing "two_pi" with "two_π" > > > > (where > > > > the > > > > final char in the latter is GREEK SMALL LETTER PI, U+03C0) > > > > > > > > This replacement currently expressed as encoded bytes i.e: > > > > > > > > fix-it:"demo.c":{51:10-51:16}:"two_\317\200" > > > > > > > > where \317\200 is the octal-escaped representation of the two > > > > bytes > > > > of > > > > the UTF-8 encoding of the character. > > > > > > > > Is this going to work for Emacs? > > > > > > You mean, GCC doesn't actually emit the UTF-8 encoding of π, it > > > emits > > > its ASCII-fied representation? We'd need to decode that, but is > > > that > > > really justified? Why not emit UTF-8? > > > > I have an implementation that simply emits UTF-8 in quotes, > > escaping > > backslash, tab, newline, and doublequotes as before. (we have to > > escape at least newline, given that fix-it hint replacement text > > can > > contain them, and we're using newline to terminate the parseable > > hint). > > Sorry, I've lost the context: where did those non-ASCII names come > from? are they names of variables in the user's program? The names are identifiers from the user's program (names of variables, types, macros, etc), where an error has been issued, typically due to a misspelling of an identifier. For example, somewhere there's a declaration of a constant named "two_π", and later the code erroneously references it as "two_pi"; we want to emit a diagnostic saying: did you mean "two_π"? and provide a machine-readable fix-it hint suggesting the replacement of the pertinent source range with "two_π". GCC converts the source code from any encoding specified by -finput- charset= to use UTF-8 internally... https://gcc.gnu.org/onlinedocs/cpp/Character-sets.html > If so, in > what encoding does GCC quote portions of the source code in its > warning/error messages? > Does it use the exact byte stream it found in > the source, or does it perform any conversions of the encoding? ...however there's a bug in GCC in how we print the source code itself, where we blithely emit the undecoded bytes directly to stderr when quoting the lines of source. This GCC bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067 (aka PR other/93067). We ought to encode the source code into UTF-8 when printing it (which may be a no-op for the common case). The annotation lines we print under the source lines for fix-it hints and labels are already printed in UTF-8, however. That said, the above bug is orthogonal to the fix-it hint issue, which prints the names in a different way (using UTF-8 encoded strings in GCC's symbol table, rather than scraping them from the filesystem, which is how the buggy source-quoting routines work). > > However, the filename also needs to be escaped. Currently I'm > > applying > > the same escaping rules to both filename and replacement text. > > What is the encoding of the filename? What if the bytes in a > > filename > > aren't UTF-8 encoded? How does emacs handle this case? > > Emacs has a separate variable for the encoding of file names, which > gets set from the locale settings. But this is not necessarily > relevant to the issue at hand, because we are talking about > processing > output from a sub-process (GCC) which includes both file names and > other stuff, such as fragments of the source code. When Emacs > processes sub-process output, it generally assumes all of it is > encoded in the same encoding. So if, for example, you encode > non-ASCII variables in UTF-8 while the file names are emitted in some > other encoding (perhaps because the locale's codeset is not UTF-8), > then there will be complications: we will have to read the output > from > GCC in its raw form, and then decode "by hand" (in Lisp) each part of > it as appropriate (which means we will need to be able to identifye > each such part). > > So it's important to understand the situation and its limitations for > proposing the best solution. As far as I can tell GCC handles filenames as raw bytes, and doesn't make any attempt to decode them, and emits them as bytes again in diagnostic messages. > > I tried creating file with the name "byte 0xff" .txt, and with > > valid > > UTF-8 non- ascii names and emacs reported them as \377.txt and with > > the UTF-8 names respectively, so perhaps I should simply emit the > > bytes and pretend they are UTF-8? > > What do you mean by "pretend" in this context? By "pretend" I mean simply re-emitting the bytes of the filename to stderr and ignoring encoding issues in them, despite the fact that the rest of the stream is supposed to be UTF-8-encoded. Currently the parseable-fixits option uses IS_PRINT on each "char" (i.e. byte) so that any non-printable bytes get octal-escaped. Is that acceptable for filenames? The other approach, to "pretend they're UTF- 8", would mean to not escape such bytes, so that if they are UTF-8 they are faithfully re-emitted. I think I like the approach where the filename part of the fixit line is octal-escaped, and the replacement text is UTF-8, but I don't know what's going to be best for you. Hope the above clarifies things. Dave From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Nov 2020 14:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: David Malcolm Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.160536370522830 (code B ref 25987); Sat, 14 Nov 2020 14:22:02 +0000 Received: (at 25987) by debbugs.gnu.org; 14 Nov 2020 14:21:45 +0000 Received: from localhost ([127.0.0.1]:50176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kdwQz-0005wA-8J for submit@debbugs.gnu.org; Sat, 14 Nov 2020 09:21:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kdwQx-0005vw-Eb for 25987@debbugs.gnu.org; Sat, 14 Nov 2020 09:21:43 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55046) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kdwQs-0004DN-2z; Sat, 14 Nov 2020 09:21:38 -0500 Received: from [176.228.60.248] (port=1552 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kdwQr-00085X-G9; Sat, 14 Nov 2020 09:21:37 -0500 Date: Sat, 14 Nov 2020 16:21:25 +0200 Message-Id: <83tutsuihm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <0b88a592c7611d740b9dfa4bd4d853d14264be8d.camel@redhat.com> (message from David Malcolm on Fri, 13 Nov 2020 11:47:18 -0500) 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> <8666386379d22239075d9237f00f40469c5be454.camel@redhat.com> <837drkopuf.fsf@gnu.org> <83mtzmznmw.fsf@gnu.org> <0b88a592c7611d740b9dfa4bd4d853d14264be8d.camel@redhat.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: David Malcolm > Cc: 25987@debbugs.gnu.org > Date: Fri, 13 Nov 2020 11:47:18 -0500 > > The names are identifiers from the user's program (names of variables, > types, macros, etc), where an error has been issued, typically due to a > misspelling of an identifier. For example, somewhere there's a > declaration of a constant named "two_π", and later the code erroneously > references it as "two_pi"; we want to emit a diagnostic saying: > did you mean "two_π"? > and provide a machine-readable fix-it hint suggesting the replacement > of the pertinent source range with "two_π". > > GCC converts the source code from any encoding specified by -finput- > charset= to use UTF-8 internally... > > https://gcc.gnu.org/onlinedocs/cpp/Character-sets.html And then GCC outputs these identifiers in UTF-8? Or does it convert back to the original input-charset? > ...however there's a bug in GCC in how we print the source code itself, > where we blithely emit the undecoded bytes directly to stderr when > quoting the lines of source. This GCC bug is > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067 (aka PR > other/93067). We ought to encode the source code into UTF-8 when > printing it (which may be a no-op for the common case). I'm not sure you are right here: I think it is better for GCC to use the original bytestream, because the user's locale might not support UTF-8 well; it is better to show the source to the user in the encoding in which it was written. However, I'm not familiar with GCC internals, so it is not clear to me whether the bug report will indeed affect the way source fragments will be output: the bug report only talks about converting the input, and I don't know enough to understand how will that affect output. > The annotation lines we print under the source lines for fix-it > hints and labels are already printed in UTF-8, however. The annotations are in US English, though, right? If not, when will they include non-ASCII characters? > That said, the above bug is orthogonal to the fix-it hint issue, which > prints the names in a different way (using UTF-8 encoded strings in > GCC's symbol table, rather than scraping them from the filesystem, > which is how the buggy source-quoting routines work). > [...] > As far as I can tell GCC handles filenames as raw bytes, and doesn't > make any attempt to decode them, and emits them as bytes again in > diagnostic messages. This is okay, but since the other parts are in UTF-8, this will complicate things, as I mentioned in my previous message. > > > I tried creating file with the name "byte 0xff" .txt, and with > > > valid > > > UTF-8 non- ascii names and emacs reported them as \377.txt and with > > > the UTF-8 names respectively, so perhaps I should simply emit the > > > bytes and pretend they are UTF-8? > > > > What do you mean by "pretend" in this context? > > By "pretend" I mean simply re-emitting the bytes of the filename to > stderr and ignoring encoding issues in them, despite the fact that the > rest of the stream is supposed to be UTF-8-encoded. As explained, it will be easier for Emacs to process GCC output if its encoding is consistent. > Currently the parseable-fixits option uses IS_PRINT on each "char" > (i.e. byte) so that any non-printable bytes get octal-escaped. Is that > acceptable for filenames? The other approach, to "pretend they're UTF- > 8", would mean to not escape such bytes, so that if they are UTF-8 they > are faithfully re-emitted. > > I think I like the approach where the filename part of the fixit line > is octal-escaped, and the replacement text is UTF-8, but I don't know > what's going to be best for you. Given your description, it sounds like it will not be simple whatever you do. I guess we should first try getting the plain-ASCII case to work, as that is the most frequent use case anyway. From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Nov 2020 19:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 25987@debbugs.gnu.org Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.16053832036693 (code B ref 25987); Sat, 14 Nov 2020 19:47:02 +0000 Received: (at 25987) by debbugs.gnu.org; 14 Nov 2020 19:46:43 +0000 Received: from localhost ([127.0.0.1]:52058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ke1VS-0001jt-RC for submit@debbugs.gnu.org; Sat, 14 Nov 2020 14:46:43 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:55243) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ke1VQ-0001jk-0j for 25987@debbugs.gnu.org; Sat, 14 Nov 2020 14:46:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605383199; 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=9i8LcgO23nRhxiVyeyAQFXDB2sF0yUDGk63708hD/Hs=; b=LKJKpYOjcNdNiKKX6FQvLQSCjLTheQZNDggZUoBWz7hban/eedemHLdUHrvYgqJ4gLyaqN PGcU1m78iebVPCYW2vhLQlz9tpw+1AsbuF/bCW83JFXnxQVw7w6ByqcYBLN78QlyiXk1Wz /EbSfXmQUrphicqlBqPA0NnbV3Gcsrc= 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-196-RXBQApD0Py2Vi7_0pSoC8A-1; Sat, 14 Nov 2020 14:46:31 -0500 X-MC-Unique: RXBQApD0Py2Vi7_0pSoC8A-1 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 AE4BC5700A; Sat, 14 Nov 2020 19:46:30 +0000 (UTC) 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 46E2660C13; Sat, 14 Nov 2020 19:46:30 +0000 (UTC) Message-ID: From: David Malcolm Date: Sat, 14 Nov 2020 14:46:29 -0500 In-Reply-To: <83tutsuihm.fsf@gnu.org> 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> <8666386379d22239075d9237f00f40469c5be454.camel@redhat.com> <837drkopuf.fsf@gnu.org> <83mtzmznmw.fsf@gnu.org> <0b88a592c7611d740b9dfa4bd4d853d14264be8d.camel@redhat.com> <83tutsuihm.fsf@gnu.org> User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, 2020-11-14 at 16:21 +0200, Eli Zaretskii wrote: > > From: David Malcolm > > Cc: 25987@debbugs.gnu.org > > Date: Fri, 13 Nov 2020 11:47:18 -0500 > > > > The names are identifiers from the user's program (names of > > variables, > > types, macros, etc), where an error has been issued, typically due > > to a > > misspelling of an identifier. For example, somewhere there's a > > declaration of a constant named "two_π", and later the code > > erroneously > > references it as "two_pi"; we want to emit a diagnostic saying: > > did you mean "two_π"? > > and provide a machine-readable fix-it hint suggesting the > > replacement > > of the pertinent source range with "two_π". > > > > GCC converts the source code from any encoding specified by > > -finput- > > charset= to use UTF-8 internally... > > > > https://gcc.gnu.org/onlinedocs/cpp/Character-sets.html > > And then GCC outputs these identifiers in UTF-8? Or does it convert > back to the original input-charset? It emits them as UTF-8 when emitting diagnostics. > > ...however there's a bug in GCC in how we print the source code > > itself, > > where we blithely emit the undecoded bytes directly to stderr when > > quoting the lines of source. This GCC bug is > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93067 (aka PR > > other/93067). We ought to encode the source code into UTF-8 when > > printing it (which may be a no-op for the common case). > > I'm not sure you are right here: I think it is better for GCC to use > the original bytestream, because the user's locale might not support > UTF-8 well; it is better to show the source to the user in the > encoding in which it was written. This seems to me to lead to a bigger question: what should the encoding of GCC's stderr be? Right now I believe we emit a mix of UTF-8 and other encodings, as noted in my earlier post. > However, I'm not familiar with GCC internals, so it is not clear to > me > whether the bug report will indeed affect the way source fragments > will be output: the bug report only talks about converting the input, > and I don't know enough to understand how will that affect output. > > > The annotation lines we print under the source lines for fix-it > > hints and labels are already printed in UTF-8, however. > > The annotations are in US English, though, right? If not, when will > they include non-ASCII characters? Annotation lines can contain labels as of GCC 9, and these can contain identifiers; for example in this C++ type mismatch error, where the types of the pertinent expressions are labeled: $ g++ t.cc t.cc: In function 'int test(const shape&, const shape&)': t.cc:15:4: error: no match for 'operator+' (operand types are 'boxed_value' and 'boxed_value') 14 | return (width(s1) * height(s1) | ~~~~~~~~~~~~~~~~~~~~~~ | | | boxed_value<[...]> 15 | + width(s2) * height(s2)); | ^ ~~~~~~~~~~~~~~~~~~~~~~ | | | boxed_value<[...]> where "boxed_value" is an identifier and in theory could have non-ASCII characters in it. > > That said, the above bug is orthogonal to the fix-it hint issue, > > which > > prints the names in a different way (using UTF-8 encoded strings in > > GCC's symbol table, rather than scraping them from the filesystem, > > which is how the buggy source-quoting routines work). > > [...] > > As far as I can tell GCC handles filenames as raw bytes, and > > doesn't > > make any attempt to decode them, and emits them as bytes again in > > diagnostic messages. > > This is okay, but since the other parts are in UTF-8, this will > complicate things, as I mentioned in my previous message. > > > > > I tried creating file with the name "byte 0xff" .txt, and with > > > > valid > > > > UTF-8 non- ascii names and emacs reported them as \377.txt and > > > > with > > > > the UTF-8 names respectively, so perhaps I should simply emit > > > > the > > > > bytes and pretend they are UTF-8? > > > > > > What do you mean by "pretend" in this context? > > > > By "pretend" I mean simply re-emitting the bytes of the filename to > > stderr and ignoring encoding issues in them, despite the fact that > > the > > rest of the stream is supposed to be UTF-8-encoded. > > As explained, it will be easier for Emacs to process GCC output if > its > encoding is consistent. Indeed. I'll raise this issue on the GCC mailing list. > > Currently the parseable-fixits option uses IS_PRINT on each "char" > > (i.e. byte) so that any non-printable bytes get octal-escaped. Is > > that > > acceptable for filenames? The other approach, to "pretend they're > > UTF- > > 8", would mean to not escape such bytes, so that if they are UTF-8 > > they > > are faithfully re-emitted. > > > > I think I like the approach where the filename part of the fixit > > line > > is octal-escaped, and the replacement text is UTF-8, but I don't > > know > > what's going to be best for you. > > Given your description, it sounds like it will not be simple whatever > you do. > > I guess we should first try getting the plain-ASCII case to work, as > that is the most frequent use case anyway. I added some test cases and posted the patch to the gcc-patches mailing list here: "[PATCH/RFC] Add GCC_EXTRA_DIAGNOSTIC_OUTPUT environment variable for fix-it hints" https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559105.html Thanks Dave From unknown Fri Sep 19 22:29:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#25987: 25.2; support gcc fixit notes Resent-From: David Malcolm Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Jan 2021 21:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25987 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 25987@debbugs.gnu.org Cc: Eli Zaretskii , Andrea Corallo Received: via spool by 25987-submit@debbugs.gnu.org id=B25987.161066027328938 (code B ref 25987); Thu, 14 Jan 2021 21:38:02 +0000 Received: (at 25987) by debbugs.gnu.org; 14 Jan 2021 21:37:53 +0000 Received: from localhost ([127.0.0.1]:39470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0AJU-0007We-QI for submit@debbugs.gnu.org; Thu, 14 Jan 2021 16:37:53 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:32913) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0AJR-0007WU-0Q for 25987@debbugs.gnu.org; Thu, 14 Jan 2021 16:37:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1610660268; 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=ff0VN2VDkGhKVLeyUxfzZC/0vaV9stX9ogtA5OlA7l8=; b=gXXq1VWm8C5o1ijbYpiVgNZGtbWwWInqstUERelyVnUsJjOI60vK43F7Eu6NmeYcxrdN3a a4/nYIBy+31k9h2GkYMCLE3pSMP81hm4JKqbuF737JTVzWtTI5IMkNYWol+Glq5i+DDIXJ jYog5s3cFxwpYWg7evECb4hNYVD6+b8= 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-470-50iE5mllNnKSruH8raJw_g-1; Thu, 14 Jan 2021 16:37:45 -0500 X-MC-Unique: 50iE5mllNnKSruH8raJw_g-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A6905800050; Thu, 14 Jan 2021 21:37:44 +0000 (UTC) Received: from ovpn-112-159.phx2.redhat.com (ovpn-112-159.phx2.redhat.com [10.3.112.159]) by smtp.corp.redhat.com (Postfix) with ESMTP id 25ABE10016F6; Thu, 14 Jan 2021 21:37:43 +0000 (UTC) Message-ID: <9f937ef9d77e1dc7e9186ad44bfe4472cb328427.camel@redhat.com> From: David Malcolm Date: Thu, 14 Jan 2021 16:37:43 -0500 In-Reply-To: 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> User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) I've now pushed the patch: "[PATCH/RFC] Add GCC_EXTRA_DIAGNOSTIC_OUTPUT environment variable for fix-it hints" https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559105.html to the gcc master branch targeting gcc-11: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f10960558540636800cf5d3d6355969621fbc17e Dave