From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 11 04:30:23 2020 Received: (at submit) by debbugs.gnu.org; 11 Jul 2020 08:30:23 +0000 Received: from localhost ([127.0.0.1]:43819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1juAtr-0007IG-4K for submit@debbugs.gnu.org; Sat, 11 Jul 2020 04:30:23 -0400 Received: from lists.gnu.org ([209.51.188.17]:45190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1juAto-0007I8-TA for submit@debbugs.gnu.org; Sat, 11 Jul 2020 04:30:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1juAto-0005OM-Dr for bug-gnu-emacs@gnu.org; Sat, 11 Jul 2020 04:30:20 -0400 Received: from sonic308-1.consmr.mail.bf2.yahoo.com ([74.6.130.40]:44675) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1juAtm-0005pm-7X for bug-gnu-emacs@gnu.org; Sat, 11 Jul 2020 04:30:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1594456215; bh=LAl3bPTXpbe3qz/Lm4pvQzr9pTgR6wxqLtMoFML7ZVQ=; h=Date:From:To:Subject:References:From:Subject; b=RoOWfg7q/HmSPrb5nRhcl5niQk5Q1NKrqYwltqHGkczSbM9MtKPL6SA60nsoG71eb4fYAi+0fGksYuQa4tHYSc2zDVI9S25sagLmfpqXQ3PPQcTddG1oCtN741alTDlsi9kQYiiQsDKG1vOWNVeNr3+lKeSQYSMWonFUS8s7/MgRgJY2MA8H5Cf9CK3AVClMM6H51YDp8BcxljzvUkq4NHHA0lEmg+1l89Svd/998zMTJwZxJC2YOnijXI3hWaFFgSu2eJTdqOdORXZCQ1bwJTh0U9TpEZxJSoMUoO3T0C2/y49PEbfyNUk8E/TCdvF5qeRmw5Yx54bs3d/493Gdhg== X-YMail-OSG: 781AAPwVM1kA3726xj9FlW4Dl_s1h9JV9nin_bWk4USdV8XaH__NlxVr_kyeX6C ibeYTMM.R0vY5RZebZb8oCdZJhm4IB1EHeEyrwlbA6q9K1bhZbfOoOeUZTE4ImK41p2ihpYTYqGV soojaQBmWVD3FrVOzmcbJQ7JRTnWcTcAasn9xEG8axgxKdfbaBk6dJ30tPRR7Fa25C4_lyutgA1h LezYYhWNCW8zuZPCOUigCb8Z4gzrGf3iMr5pGTMsqIDO0XMlCaS2UdjvYFY44.BuyND.EfbXHLVl .5sOtWvMdHOMrD3KOSMmBHoEnvSYEnOhAOF.koD4CEDPe0oCnxSKy.8qhsOgugmWcGKBlg1EudeX 9k_q96hVd3giOXBJr8eN62QjEHEG7SwETAqCG_nIxyuCeSEaL_BMUTGpTfskiW4WctJssRWNW3jj Az3GHn4O6wztqCbzGq0mQdYUOmLwzUYzcjjgZtfV0Ny4M7VfXxCWC430TvzoLGJRr1hUpE5lk1TE cbCSoTJgtAtm0b7P8PAwlIn3TIJjcJY8CvuuKIJAs2ExbREttdkAU4GBq.eL.rEEidJyrXxyxuVP 3WFdAQUM06NabAaeuOpC4DpzxBMPZxLrs5l_B5UFoeWibHWC2TdBS_YF2RAssTtNQ9WaSwpMHElt GKwWIiI0uMzpqymihECPOfexoGk5wUwgffOwKt4vmRiVKuKn5CDEfPxy.MghIszzE.Loyjn8HG73 HiJGv6I4l25D14BAnuB9wRhjfLb34ImqrIdRYdOLZJqZOzjCk3lfBVHYT9nMcJqOcrVQLoolYFE5 U0JLnLi.RxJQnrphLzHOjnP3tsvopZ1wMvNbk4byubJo.TQ9qi4dBK_EujFTRDRW6WkR0_6oSa3r l9RQ2gYzR24ctlLxg4E_92ObdPFcL8BA0PfHCeyd1p.2oAj7ca69K5Pa5HKAjOkWNCisTxeW.Ydv AeNdUh14CdXmd_fT7wKf4T7n8HC2oDRB22zw8Xunx_KGMsRJkpQh8F96GWyxEXhdaYhuJGY4o0Rk 9I.48dXkSYUKIF46oK4NcnvmRK5KQd8O70Q03ohQHNuXt4tRxnC0CFZvWvN_yDc8J6jAaJbUG.BY tXjt.G_.t38dzZZFS.dnacYuu05ipwn09v6qPV41sF155f_B_nPNs7DcQWhdVjUxA.vzGaeSLIHh opFDL8T92iMfhg9aX.O3LcuWPxC2UolBGS0icKHlNXQtAvs_kTAiw0i77NXIrzNhyAWos5sS.MXG tXfMbtxiTyT_LG.GVeVlRU4_dYwtp61imSthMo2nbhnVUSRWjHEG_TtqTBRzw7LWM7NbA.UjNrSS IXIgWAivKn8OcApguJKdbEz41q0KAsiP4kff_hiXefw7KuVyeSQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Sat, 11 Jul 2020 08:30:15 +0000 Received: by smtp421.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 71492e49f27a1b14ae82019856961e86; Sat, 11 Jul 2020 08:30:14 +0000 (UTC) Date: Sat, 11 Jul 2020 10:30:13 +0200 From: Ergus To: bug-gnu-emacs@gnu.org Subject: 28.0.50; c-mode issue with electric-pair-mode Message-ID: <20200711083013.t2p6cocfgctcgsev@ergus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: NeoMutt/20180716 References: <20200711083013.t2p6cocfgctcgsev.ref@ergus> X-Mailer: WebService/1.1.16271 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Content-Length: 3699 Received-SPF: pass client-ip=74.6.130.40; envelope-from=spacibba@aol.com; helo=sonic308-1.consmr.mail.bf2.yahoo.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/11 04:30:15 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit 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 (--) --text follows this line-- In c-mode there is an issue of adding some extra spaces in electric-pair-mode after class definitions. For example emacs -Q main.cxx M-x electric-pair-mode M-x c-toggle-auto-newline and then insert: class A { you should get: (# means the cursor) class A { # } now insert } and then you get class A { } # instead of: class A { } # The problem is actually worst if defun-close-semi is in c-cleanup-list because it doesn't work. I need to remove the extra spaces first to make it work. In GNU Emacs 28.0.50 (build 12, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) of 2020-07-10 built on ergus Repository revision: 7caf570662e41dd7cb90efaf8a335918cf1ac0da Repository branch: master System Description: Debian GNU/Linux 10 (buster) Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. main.cxx has auto save data; consider M-x recover-this-file Electric-Pair mode enabled You can run the command ‘c-toggle-auto-newline’ with C-c C-a Undo [2 times] Mark set Making completion list... Configured using: 'configure --prefix=/home/ergus/.local/ --with-mailutils' Configured features: XPM JPEG TIFF GIF PNG CAIRO SOUND DBUS GSETTINGS GLIB NOTIFY INOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS PDUMPER Important settings: value of $LANG: en_GB.UTF-8 locale-coding-system: utf-8-unix Major mode: C++//la Minor modes in effect: electric-pair-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-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 line-number-mode: t transient-mark-mode: t abbrev-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cus-start cus-load elec-pair cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib term/tmux term/xterm xterm byte-opt gv bytecomp byte-compile cconv tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame minibuffer 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 composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray 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 threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 78618 7004) (symbols 48 9526 1) (strings 32 23498 1860) (string-bytes 1 844562) (vectors 16 10057) (vector-slots 8 107261 7421) (floats 8 26 435) (intervals 56 287 3) (buffers 992 12)) From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 11 06:27:03 2020 Received: (at 42319) by debbugs.gnu.org; 11 Jul 2020 10:27:03 +0000 Received: from localhost ([127.0.0.1]:43864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1juCik-0003md-Rp for submit@debbugs.gnu.org; Sat, 11 Jul 2020 06:27:03 -0400 Received: from colin.muc.de ([193.149.48.1]:27798 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1juCii-0003m7-7s for 42319@debbugs.gnu.org; Sat, 11 Jul 2020 06:27:00 -0400 Received: (qmail 35733 invoked by uid 3782); 11 Jul 2020 10:26:53 -0000 Date: 11 Jul 2020 10:26:53 -0000 Message-ID: <20200711102653.35732.qmail@mail.muc.de> From: Alan Mackenzie To: Ergus Subject: Re: bug#42319: 28.0.50; c-mode issue with electric-pair-mode Organization: muc.de e.V. In-Reply-To: X-Newsgroups: gnu.emacs.bug User-Agent: tin/2.4.4-20191224 ("Millburn") (FreeBSD/11.3-RELEASE-p9 (amd64)) X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42319 Cc: 42319@debbugs.gnu.org, acm@muc.de 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 (-) Hello, Ergus. In article you wrote: > In c-mode there is an issue of adding some extra spaces in > electric-pair-mode after class definitions. > For example > emacs -Q main.cxx > M-x electric-pair-mode > M-x c-toggle-auto-newline > and then insert: > class A { > you should get: (# means the cursor) > class A > { > # > } > now insert } and then you get > class A > { > > } > # > instead of: > class A > { > > } > # This happens because of the missing semicolon after the class. CC Mode indents the otherwise empty line as a 'topmost-intro-cont line, since it appears still to be within the class. One workaround for this is to configure CC Mode not to insert a newline after this particular type of brace. For example (push '(class-close before) c-hanging-braces-alist) , to try it out (it's a buffer local variable). > The problem is actually worst if defun-close-semi is in c-cleanup-list > because it doesn't work. That surprises me. It works for me, here. What happens/fails to happen in these circumstances? > I need to remove the extra spaces first to make it work. That indeed feels like a bug. Could you perhaps post your CC Mode configuration (generated by C-c C-b), please, which should help me to reproduce the bug. > In GNU Emacs 28.0.50 (build 12, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0, Xaw scroll bars) > of 2020-07-10 built on ergus > Repository revision: 7caf570662e41dd7cb90efaf8a335918cf1ac0da > Repository branch: master > System Description: Debian GNU/Linux 10 (buster) [ .... ] > Major mode: C++//la > Minor modes in effect: > electric-pair-mode: t > tooltip-mode: t > global-eldoc-mode: t > electric-indent-mode: t > mouse-wheel-mode: t > tool-bar-mode: t > menu-bar-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 > line-number-mode: t > transient-mark-mode: t > abbrev-mode: t [ .... ] -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 11 09:15:27 2020 Received: (at 42319) by debbugs.gnu.org; 11 Jul 2020 13:15:27 +0000 Received: from localhost ([127.0.0.1]:44018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1juFLi-0003ft-Vq for submit@debbugs.gnu.org; Sat, 11 Jul 2020 09:15:27 -0400 Received: from sonic310-13.consmr.mail.bf2.yahoo.com ([74.6.135.123]:36487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1juFLg-0003fd-Cj for 42319@debbugs.gnu.org; Sat, 11 Jul 2020 09:15:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1594473318; bh=i9TIU7xpvDXAweJU9eRSNR7+1m0Jl2AmalLz13Znxsk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=LzZQruh9LR/babYeSobMXJcZOIeYCP6Mem1lU69fiTextzyuACblGmKrFfeSHlkxWVNXT05sEswOEDK82y1RCxbkkgWgVxyv3Zl6+EI1qr110Ux/Jr1wjAIc6biqW+E3rKNXvaIOp4KpVSAA7OKDSFdSLHhAkm5vaPna9m8k5ClAL3ArNRXaFWEgQRy4wK569iDkL1BDeF+1GLRtCRj1YInEAq0vm8zgBgt8LWRzjH7b2rhxcGMc2zgiULf4Rfco0YQD75fcWFpbY/xqcD35Yf3HdoLwRVdzOFHCmf+ir2nY+c9fQCx+34gTbGzYSICjmALZWpK4xXTWNE3p4SfgRw== X-YMail-OSG: x9mdjxoVM1lOZRM7nwTIm2M13AaRICh9tdooEPgpcsWZ8rZnhchd8uaa7eR34yC jWHrjcU7pTZsVFk48i_gdd7dg4yo0lk7uCybsaOmbaLWQrj45lxt5cZ22h.X044Z.OnWzHuz7OhB dhd.78lcYfF8pTZtworPuqOx7yrpUxpB_RairoGnEOMFmf2KPQUY2JQbek.QmnTWZwe9sCbyh95N wTYPWdJqi2YRNH_mLzaIAttWzyOhF9q5dZlEABZFRcmfs2Lh1AWXrzWLE12LfeU0re4nZCtONpjh cRHqqOC4OncqsxC8y6tWSFA.VnzwEtR4RA3sSO7ajWXKck_MNHqR0FDvXB7ciUGM0dLa35JD3RaW Tv5E7bPxH9tCbRr.lcneiwpOyZ7ysASFfKCrJWr873gEA_2GOLiFnatYhfkD78JdXSBJdqVj2W98 e1enTA6a4ZaScqZe7tXE_A7Z5cX86s9a1HQOF_jq20yOQUBVhvcLSqpg2bSGvszrVdqEsDE2FyZt odhSG_as4yX5dPDM93gxTjKCu6n9934jhQmYS6n18GmbPJtRavcqKLhC3ejOQuHIAmEwFxGkxGjQ 9DQpT8AXg16kuJo4WE7U4yH2a1kjDCk2m9AJihgu2KmhxHKecwOpC3MpQ0j4Zzj30Ov2hRoAcpeJ v4TCcyx3mKYZ.w5jOnY7Z3k4gHvqmuLkuXaVyuuWKkUqcxuo.JggNIxZ0CqCS3OmuKDeQL5nxt_V IZApIvsbYE6MV4idKOeuVp.qUTjKm7u859EkJKImi2OJ3wu.YJFpDqTWxMFD9a6rDvYP9tCAC030 .ZAJVrk8yjpV1CWovIsgbzoWNy2EU4MVNdLcAvR_s40qY4sUBFADykP5eFdrCBSAcBTAJrGfq96C N2Huo7_GSnidnGs6JWdWmtnypOzL8nGNHjkaaoMwJHgDFsOTxpB.L4r_x4ckNJHaDkyd0vqI23Ap MMmcEahe3H57nzuQAyMyAAHgsTm0LZRETgx2HVRJrltFQY1rfa1sNnHzqL2nY.wkXYgt2oOZEvo4 Hhn3m1Nj.8DNz8l6DyY9rculSiumxYDTJb3eyOB1NzQZUkESs1GvmkHfoSx0Yg5qL6FPK.viJTWW RJWA_TBB8X2pZGUw_.9wUdJEuOHDUjA5psQzPk9bUiu1HAplOSbcmwGIxooJLZspryMWql54szCZ 9orSZiE7070ApjhM.99se7VFMYbSB3x_R9v9MbLmT4G7LDqNnLvYwqVS.TlVBT4VjI1hKSi.nChL 416eSuRx001j1WBptlIANtVgpf_WyBWGZuc5a9a1UNAAYoZq_iiC_Omtv6_xOmZr9Os0qpSg3Ivq Oo2NgcNLf7IelJKIu0319gzELZ2vb7badfWXzTOiqolJG2tgOx.L5mdSlohgodPhRdW9eFuY- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Sat, 11 Jul 2020 13:15:18 +0000 Received: by smtp425.mail.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 628154ee833070f22c6ef723e7696250; Sat, 11 Jul 2020 13:15:13 +0000 (UTC) Date: Sat, 11 Jul 2020 15:15:12 +0200 From: Ergus To: Alan Mackenzie Subject: Re: bug#42319: 28.0.50; c-mode issue with electric-pair-mode Message-ID: <20200711131512.gur5wyzn5nlhibst@ergus> References: <20200711102653.35732.qmail@mail.muc.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200711102653.35732.qmail@mail.muc.de> User-Agent: NeoMutt/20180716 X-Mailer: WebService/1.1.16271 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7) Content-Length: 2311 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42319 Cc: 42319@debbugs.gnu.org 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, Jul 11, 2020 at 10:26:53AM -0000, Alan Mackenzie wrote: >Hello, Ergus. > > >This happens because of the missing semicolon after the class. CC Mode >indents the otherwise empty line as a 'topmost-intro-cont line, I supposed so. >since it appears still to be within the class. But this is an issue right? because after that } it is already out of the class; ... even without the `;` there is not a class scope to indent right? The same applies to nested classes. Actually AFAIK without the `;` there is a syntax error if we insert anything else except for inline class/variable declarations like: class A { } var; or typedef class A { } type_A; But then the new line after the } should never be added? >One workaround for this is to >configure CC Mode not to insert a newline after this particular type of >brace. For example > >(push '(class-close before) c-hanging-braces-alist) > >, to try it out (it's a buffer local variable). > This works, thanks. I think that this should be the default as it is the most general/expected behavior and doesn't insert extra newline/spaces. This work around seems to be a cleaner solution than the cleanup ;p because it works easier for: ========= For: }; class A { }; # ========= And for: } var; class A { } var; # I think the user never wants this: ========== class A { } ; # ========= or ========= class A { } var; # And for sure not this: ========= class A { } var; # ========= But I am probably wrong. >> The problem is actually worst if defun-close-semi is in c-cleanup-list >> because it doesn't work. > >That surprises me. It works for me, here. What happens/fails to happen >in these circumstances? > Ohh, my bad. I forgot to add defun-close-semi when using -Q for reporting. So please forget it and forgive me. >> I need to remove the extra spaces first to make it work. > >That indeed feels like a bug. Could you perhaps post your CC Mode >configuration (generated by C-c C-b), please, which should help me to >reproduce the bug. > I discovered myself error with this... very useful. Thanks. So probably if you don't think that the extra indentation is an issue you can close this bug. Off-topic: I reported another issue (bug#42270) related with attributes and indentation. did you see it? Very Thanks, Ergus From debbugs-submit-bounces@debbugs.gnu.org Sun Jul 12 06:55:09 2020 Received: (at 42319) by debbugs.gnu.org; 12 Jul 2020 10:55:09 +0000 Received: from localhost ([127.0.0.1]:45469 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1juZdV-0007tP-0U for submit@debbugs.gnu.org; Sun, 12 Jul 2020 06:55:09 -0400 Received: from colin.muc.de ([193.149.48.1]:38592 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1juZdT-0007sm-48 for 42319@debbugs.gnu.org; Sun, 12 Jul 2020 06:55:07 -0400 Received: (qmail 4646 invoked by uid 3782); 12 Jul 2020 10:55:00 -0000 Received: from acm.muc.de (p4fe15904.dip0.t-ipconnect.de [79.225.89.4]) by localhost.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Jul 2020 12:54:59 +0200 Received: (qmail 11018 invoked by uid 1000); 12 Jul 2020 10:54:59 -0000 Date: Sun, 12 Jul 2020 10:54:59 +0000 To: Ergus Subject: Re: bug#42319: 28.0.50; c-mode issue with electric-pair-mode Message-ID: <20200712105459.GA10951@ACM> References: <20200711102653.35732.qmail@mail.muc.de> <20200711131512.gur5wyzn5nlhibst@ergus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200711131512.gur5wyzn5nlhibst@ergus> X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42319 Cc: 42319@debbugs.gnu.org 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 (-) Hello, Ergus. On Sat, Jul 11, 2020 at 15:15:12 +0200, Ergus wrote: > On Sat, Jul 11, 2020 at 10:26:53AM -0000, Alan Mackenzie wrote: > >This happens because of the missing semicolon after the class. CC Mode > >indents the otherwise empty line as a 'topmost-intro-cont line, > I supposed so. > >since it appears still to be within the class. > But this is an issue right? because after that } it is already out of > the class; ... even without the `;` there is not a class scope to indent > right? The same applies to nested classes. The same also applies to structs and unions. Each of these constructs is incomplete without the closing semicolon. > Actually AFAIK without the `;` there is a syntax error if we insert > anything else except for inline class/variable declarations like: Precisely! > class A { > } var; > or > typedef class A { > } type_A; > But then the new line after the } should never be added? You could well be right, here. I'd have to check carefully all the things that can generate a 'class-close syntax before changing the defaults. > >One workaround for this is to > >configure CC Mode not to insert a newline after this particular type of > >brace. For example > >(push '(class-close before) c-hanging-braces-alist) > >, to try it out (it's a buffer local variable). > This works, thanks. I think that this should be the default as it is the > most general/expected behavior and doesn't insert extra > newline/spaces. This work around seems to be a cleaner solution than the > cleanup ;p because it works easier for: > ========= > For: }; > class A { > }; > # > ========= > And for: } var; > class A { > } var; > # > I think the user never wants this: > ========== > class A { > } > ; > # > ========= > or > ========= > class A { > } > var; > # > And for sure not this: > ========= > class A { > } > var; > # > ========= > But I am probably wrong. My experience is that there's virtually _no_ form of indentation which no user wants. But I think I'll look at changing that default. > >> The problem is actually worst if defun-close-semi is in c-cleanup-list > >> because it doesn't work. > >That surprises me. It works for me, here. What happens/fails to happen > >in these circumstances? > Ohh, my bad. I forgot to add defun-close-semi when using -Q for > reporting. So please forget it and forgive me. No problems! Far better than there actually being a bug. ;-) > >> I need to remove the extra spaces first to make it work. > >That indeed feels like a bug. Could you perhaps post your CC Mode > >configuration (generated by C-c C-b), please, which should help me to > >reproduce the bug. > I discovered myself error with this... very useful. Thanks. > So probably if you don't think that the extra indentation is an issue > you can close this bug. I think that indentation is correct, even if a bit awkward. That's why that cleanup is available. So, yes, I'll close the bug, thanks. > Off-topic: > I reported another issue (bug#42270) related with attributes and > indentation. did you see it? Yes, I started working on it on Thursday. Most of that time, I've "just been an hour away from finishing it", so it didn't feel necessary to acknowledge the bug. That was a mistake, sorry. Actually, there're quite a few tricky things in there to sort out and clean up, so it could take a few days yet. > Very Thanks, > Ergus -- Alan Mackenzie (Nuremberg, Germany).