From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it. Date: Mon, 21 Jan 2019 16:46:13 -0500 Message-ID: References: <20190118175437.GA4095@ACM> <20190118225303.GB4095@ACM> <87fttppc7o.fsf@gmail.com> <20190119110729.GA4644@ACM> <875zukpxe2.fsf@gmail.com> <20190119174505.GA4749@ACM> <87k1j0sble.fsf@gmail.com> <20190119205833.GB4749@ACM> <20190121204544.GC4514@ACM> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="266441"; mail-complaints-to="usenet@ciao.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 21 22:46:54 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.89) (envelope-from ) id 1glhPB-0017FT-7d for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2019 22:46:53 +0100 Original-Received: from localhost ([127.0.0.1]:33885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glhPA-0001MS-7Q for ged-emacs-devel@m.gmane.org; Mon, 21 Jan 2019 16:46:52 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1glhP0-0001Lr-11 for emacs-devel@gnu.org; Mon, 21 Jan 2019 16:46:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1glhOx-00078g-B7 for emacs-devel@gnu.org; Mon, 21 Jan 2019 16:46:41 -0500 Original-Received: from [195.159.176.228] (port=47056 helo=ciao.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1glhOo-00072c-FV for emacs-devel@gnu.org; Mon, 21 Jan 2019 16:46:33 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.89) (envelope-from ) id 1glhOg-0016q1-1r for emacs-devel@gnu.org; Mon, 21 Jan 2019 22:46:22 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:iHiK8H/eOmEhDb0pvenu/eRSF9g= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.228 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:232584 Archived-At: > It is thus clear that the use of post-self-insert-hook is incompatible > with Lisp code which calls self-insert-command, since that use > effectively makes that function undefined. self-insert-command is a command more than a function, so code that calls it should expect it to do "whatever happens when the user hits the corresponding key", more or less. Given all the things self-insert-command does, there's very little you can rely on. If you need to know more precisely what happens, then `insert` is usually a better option. >> expand-abbrev also can be extensive changes during self-insert-command, >> and so can the auto-fill-function. > In practice, they haven't done so. I'm sure some users of Emacs have used abbrevs or auto-fill-functions in very funny ways which break your code's assumptions. Just because you haven't heard from them doesn't mean the problem doesn't exist. >> If you use electric-layout-mode and electric-pair-mode, then all that's >> left for c-electric-brace is to call self-insert-command. > No. There's more to it than that. You mean the c-cleanup-list, I guess. Indeed, before c-electric-brace can be turned into an alias for self-insert-command, we'd need to add another post-self-insert-hook which implements the c-cleanup-list feature. AFAICT from the docstring, it's the only thing still missing. >> I understand that there's a transition needed between these two and this >> intermediate state can require more work, but it's important to keep the >> long term goal in mind when designing the current solution. > Whose long term goal? At the very least mine. > My goal, both long and short term, is to keep CC Mode > working properly. That's orthogonal. To give you a similarly general goal, my own goal is to make it so that any feature which makes sense in many major mode be implemented once and then used in the relevant major modes, rather than being implemented independently for those major modes. This is both for uniformity between major modes, and because it both simplifies and improves many major modes (which would otherwise either not provide the feature or only in very primitive ways). And those maintainers like you who did go to the trouble of being early implementers of the feature suffer through the pain of having to adapt their code once the generic version of the feature becomes available. Sometimes even at the cost of having the new feature working slightly worse in some corner cases. But many of them are quite happy to be able to drop their old code and get rid of that responsibility (i.e. bug reports about regressions can be redirected to Emacs maintainers). Stefan