From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it. Date: Sat, 19 Jan 2019 13:52:53 +0000 Message-ID: <875zukpxe2.fsf@gmail.com> References: <20190117164350.GA18314@ACM> <20190118175437.GA4095@ACM> <20190118225303.GB4095@ACM> <87fttppc7o.fsf@gmail.com> <20190119110729.GA4644@ACM> NNTP-Posting-Host: ciao.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ciao.gmane.org 1547906926 19148 195.159.176.228 (19 Jan 2019 14:08:46 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2019 14:08:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 19 15:08:43 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1gkrIg-0004vv-9B for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 15:08:42 +0100 Original-Received: from localhost ([127.0.0.1]:56126 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkr4A-0001dU-Te for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 08:53:42 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35541) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkr3U-0001d9-Fx for emacs-devel@gnu.org; Sat, 19 Jan 2019 08:53:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkr3S-0002V7-Bh for emacs-devel@gnu.org; Sat, 19 Jan 2019 08:53:00 -0500 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:44189) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gkr3S-0002Tv-2M for emacs-devel@gnu.org; Sat, 19 Jan 2019 08:52:58 -0500 Original-Received: by mail-wr1-x429.google.com with SMTP id z5so18272819wrt.11 for ; Sat, 19 Jan 2019 05:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=g/P+KYhdExH8Fgxv3+vVlnalg/T0/1R7wYhUo0bltVk=; b=m1Kap4SeuWWGAeiGqyzYAKhqUcnOYUAPy04oWcQLDyx9enP8GGdMxCtV2okbGZjNqw 6qaUjkfLxUZSV+E/aWBkG1NEi/Pz+XOd3H2d+bCEFKDHa7eDMhLC/NdB7F4ZYPf4VAU/ Xid9C3ZJ9r/OZUBqGNnbWOCxpcsgNSRY6m0IolSZQkcRgglX1UTUc2Kn7cc0nKcILT7R nX89hR00vXd5FqnNZgu2y4JBJyIfOPPNRT19BMRXjZWHh/NTtZQ2arxLEcxuyJPcenCG pEnI8bb52hDl4rjP/uL7CmR5ZB51n2hyDbIcCi8XP1/wZm2PIkAivbLrpBulOVVGuqC8 1ziw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=g/P+KYhdExH8Fgxv3+vVlnalg/T0/1R7wYhUo0bltVk=; b=iOusNbHs8ezT8uEUVetrpNSFFhstSlaZoYX/Y0i5nS+FywO2YULqndsqsnnFN9/qT7 iHBgorluRXxufpGuIzAhYIejdiwrM/EvzDM+/I05cyZmwjtgqUS+FIvGAKY/QLaDhr1y KSTXn7esjTvteTCmimTshWUtqLqcm8sUxK3R/aGL2PN6xjPU9CRqoQOTOEew88VUI5es FoBFcsb5DxDvuu5QcbTmGs9OuwsXnN9qFR+HXEsaNa57GWKpEj17S+SQ4NQ9wW36hyVY O67FhJ9YEgQogXjA+Ni1zuxkXw/g8TgMO7zbMpJKh7W3Dr9g1aYpmH2E4pfbVRv3ZbIn p59w== X-Gm-Message-State: AJcUukdJn27hMb4/dSfy4ozLrsf812uKhcIf6kgMmChReWKFrjAjns58 Tn+pgBanDw9WP32RWyAi2Apwk3JP X-Google-Smtp-Source: ALg8bN5agKbrk2Fl0xDU29X8XTI07ifKJd7JQNjOv4hwANnKd+C3wgAGQvQxHbk2KVg6KcgwHNGdaw== X-Received: by 2002:adf:de91:: with SMTP id w17mr22187170wrl.320.1547905976159; Sat, 19 Jan 2019 05:52:56 -0800 (PST) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id f137sm39387570wmg.29.2019.01.19.05.52.54 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Jan 2019 05:52:55 -0800 (PST) In-Reply-To: <20190119110729.GA4644@ACM> (Alan Mackenzie's message of "Sat, 19 Jan 2019 11:07:29 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::429 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232489 Archived-At: Alan Mackenzie writes: > I did not "destroy" any behaviour. The behaviour you referred to was > broken, and has been for a long time, ever since its introduction. It > can be fixed. That's not for you to decide whether electric-pair-mode, an optional minor mode with a well-defined contract, is broken. Its main goal is to work the same is all modes, as any global minor mode. > problem, which had nasty side effects which weren't considered at the > time. In particular, it broke CC Mode, even though it took time for that > to become apparent. post-self-insert-hook can be used for lots of things, not only electric-pair-mode and electric-layout-mode. From requesting completions from LSP servers[1] to emulating typewriter sounds[2]. Don't break these things, even if they sound useless to you. [1] https://github.com/joaotavora/eglot/commit/444a8c3b3ec29eceeda26b72493a= 60c44a9bd951 [2] https://stackoverflow.com/questions/11206140/typewriter-sounds-for-emacs >> No. It was about c-auto-newline's interaction with electric-pair-mode. >> It would much better that she disable electric-pair-mode completely when >> working with c-auto-newline. > So telling users to change their work habits is a solution to bugs? I > think not. Presumably Beatrix just wants to pair braces automatically and insert newlines. There are alternatives in Emacs for that. >> Your change makes <>> instead. > > Yes. Automatically pairing a less-than sign with a greater-than sign is > stupid, certainly in CC Mode It's not "stupid" if you tweak electric-pair-inhibit-predicate to don't do it in certain syntactic context. But this isn't the point of this test! The point is that modes react to electric-pair-pairs, a customization variable. You broke that for '<' and '>'. I am unable to do use this electric-pair-mode feature, after your "not stupid at all" change. > It would quickly become intolerably annoying to the user. The only > contexts where it would be sensible are in a template declaration, or in > a #include directive. Only the major mode can determine these things. Excuse me but this is just wrong. It's just wrong. Users and programs can use whatever code to "determine" these things, including cc-mode's code. That code is plugged into electric-pair-inhibit-predicate and that's it! >> Fix this and all the other ones. Incidentally, most of the test >> failures are inside strings and comments, so maybe they are easy fixes. > > OK, I'll have a look at strings and comments. Why does > electric-pair-mode operate inside literals? Is this really the Right > Thing? It's the default behaviour, but you can customize electric-pair-inhibit-predicate and electric-pair-skip-self with M-x customize, or advice-add or somesuch if you don't like it personally. "The Right Thing" is that is works the same way in all modes and follows the customization variables consistently. >> > The false assumption that these tests make is that they can rely on >> > certain settings in post-self-insert-hook. Any major mode is at liber= ty >> > to bind or set this hook, and as pointed out above, CC Mode _must_ bind >> > this to nil in c-electric-brace, etc.. Would you please amend these >> > tests to take this into account. > > This is a critical point, which you have declined to address. Would you > please answer the point in your next post. Major modes are "at liberty" to do that, but they break all minor-mode horizontal to Emacs that rely on this functionality, or have to reimplement them. They're also "at liberty" to change say buffer-undo-list or post-command-hook, or what do I know. But that doesn't mean it's a good idea. It's not. >> > And I ask you, have you tried using c-auto-newline? It is easy to set >> > up (a single line in your c-mode-common-hook, or interactively C-c C-a= ). >> > The CC Mode style system takes care of the rest of the setup most of t= he >> > time. If not, why not? >> I prefer electric-layout-mode since I also use it for other languages. >> Is this not a valid reason? Can not I _have_ this preference? > You didn't answer the question. Have you tried it? Yes, of course. It worked ok as long as you don't use electric-pair-mode. When I turned it on, things broke, so I switched to electric-layout-mode. Which is exactly what happened to Beatrix, but she decided to report a bug instead. And now she and everybody, even those who *don't* use c-auto-newline, get a doubly broken electric-pair-mode in CC-mode. Gee thanks for that, what an accomplishment! > You can have that preference, but given the incompatibility, it won't > get you anywhere.=20 I return the challenge. Have you tried electric-layout-mode before making these claims? >> > I do not attack electric-layout-mode. I merely note that it would be >> > less good (if it could work) than CC Mode's own features in the context >> > of CC Mode. For example, c-auto-newline handles different braces >> > differently, depending on their syntactic context. electric-layout-mo= de >> > does not. electric-layout-mode is not needed in CC Mode. >> For now I just want braces to generate newlines. > That's just your personal use case. For those using the BSD styles, for > example, they want a newline after a function opening brace, but not > after a substatement brace. electric-layout-mode can't do this. For the third of fourth time Have you actually *seen* and read the 8 lines of code below that I posted already before? Have you perhaps considered spending 5 minutes trying them out? (setq electric-layout-rules '(electric-layout-for-c-style-du-jour)) (defun electric-layout-for-c-style-du-jour (inserted) (when (and (derived-mode-p 'c-mode 'c++-mode) (memq inserted '(?{ ?}))) (save-excursion (backward-char) (c-brace-newlines (c-point-syntax))))) (electric-layout-mode 1) It might need a tweak or two to deal with functions that return before|after lists, but nothing special. For braces it is actually useful already. > No, I haven't tried it. There is no usable interface with > electric-layout-mode for CC Mode. I just gave you one, for the second time. But the interface *is* cc-mode. You get this wrong. You have a distored notion of minor-modes. The point is that you don't do anything deliberately destroying them, and they work in your mode, and you don't have to worry about reimplementing their functionality. Don't you think it's silly to be copying implementation details from elec-pair.el into your beloved cc mode files just to support it. Wouldn't you rather delete code like this? ;; Emulate `electric-pair-mode'. (when (and (boundp 'electric-pair-mode) electric-pair-mode) (let ((size (buffer-size)) (c-in-electric-pair-functionality t) post-self-insert-hook) (electric-pair-post-self-insert-function) (setq got-pair-} (and at-eol (eq (c-last-command-char) ?{) (eq (char-after) ?})) electric-pair-deletion (< (buffer-size) size)))) It's becoming a salad in there, and it doesn't have to! > Also that strategy would fragment CC Mode's functionality, making it > less easy to understand and more difficult to maintain. Really? Refactoring things into functions so they can be used by other things is bad? So why did you come up with c-brace-newlines, may I ask? I suppose I shouldn't even draw your attention to it because now i fear you're going to take it apart and obfuscate its behaviour out of spite, just to make my job harder. > Why do you have this stubborn desire for electric-l-m in CC Mode? Because I like minor modes that work consistently across all of Emacs. I've told you this a million times already. >> > You say that things you've had working since Emacs 24.4 are now not >> > working. Do you mean electric-layout-mode? If so, that "working" was >> > an illusion, not reality. I hope I've said enough to explain why that >> > minor mode can't work in CC Mode, and that a better alternative exists. > No answer? This is ridiculous. You say it doesn't work. I show that it works. You don't try it or verify for yourself. GOTO ridiculous. >> Fine, revert it. Can you give me one good objective reason why adding > >> (defun c-self-insert-command (arg) >> (let (post-self-insert-hook) >> (self-insert-command arg))) > >> isn't a better solution, if still temporary? > > It doesn't really do much This is completely true. > it doesn't help much, it's a matter of taste. This is completely false. > It seems your intention is to modify that function in a way which will > break c-electric-thing. What's c-electric-thing? I don't want to break anything for anyone. Explain clearly what would be broken for whom. Explain that exactly, I beg you. You didn't even give me a change to explain how I would use that function, how can you know? Let me try one last time: If you make that function, or some other configurable abstraction, we can modify it so that: * If c-auto-newline is on is works exactly like you want it; * Otherwise it works like it did before 223e7b87872d4a010ae1c9a6f09a9c15aee= 46692 Now explain exactly how and for whom this breaks things, in the present or in the future. >> It'll save some lines off your original change and enable me, the >> tests, and other users to just override it with add-function or >> advice-add or something. > I will not encourage users to break CC Mode. If that is what some users > really want to do, they have access to the source code. Are you going to make users learn Emacs Lisp understand cc-mode's sources? That's the pinnacle of cruelty.=20=20 Jo=C3=A3o