From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii <eliz@gnu.org> Newsgroups: gmane.emacs.devel Subject: Re: Criticism of jit-lock--antiblink-post-command Date: Wed, 27 Nov 2019 18:10:34 +0200 Message-ID: <8336e9qozp.fsf@gnu.org> References: <20191126195236.GA5104@ACM> <jwv5zj61i0j.fsf-monnier+emacs@gnu.org> <83sgmaq64l.fsf@gnu.org> <jwvk17lphd7.fsf-monnier+emacs@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="80314"; mail-complaints-to="usenet@blaine.gmane.org" Cc: acm@muc.de, joaotavora@gmail.com, emacs-devel@gnu.org To: Stefan Monnier <monnier@iro.umontreal.ca> Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 27 17:11:14 2019 Return-path: <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org> Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>) id 1iZzuM-000Kjy-6k for ged-emacs-devel@m.gmane.org; Wed, 27 Nov 2019 17:11:14 +0100 Original-Received: from localhost ([::1]:40056 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org>) id 1iZzuK-0000Gw-GQ for ged-emacs-devel@m.gmane.org; Wed, 27 Nov 2019 11:11:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57157) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <eliz@gnu.org>) id 1iZztb-0000Go-MC for emacs-devel@gnu.org; Wed, 27 Nov 2019 11:10:28 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52819) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@gnu.org>) id 1iZzta-0007io-MU; Wed, 27 Nov 2019 11:10:26 -0500 Original-Received: from [176.228.60.248] (port=2941 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from <eliz@gnu.org>) id 1iZzta-0007kz-51; Wed, 27 Nov 2019 11:10:26 -0500 In-reply-to: <jwvk17lphd7.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Wed, 27 Nov 2019 08:46:41 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." <emacs-devel.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/emacs-devel>, <mailto:emacs-devel-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/emacs-devel> List-Post: <mailto:emacs-devel@gnu.org> List-Help: <mailto:emacs-devel-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/emacs-devel>, <mailto:emacs-devel-request@gnu.org?subject=subscribe> Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" <emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org> Xref: news.gmane.org gmane.emacs.devel:242799 Archived-At: <http://permalink.gmane.org/gmane.emacs.devel/242799> > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: acm@muc.de, joaotavora@gmail.com, emacs-devel@gnu.org > Date: Wed, 27 Nov 2019 08:46:41 -0500 > > >> The intention is that when it's not useful it's harmless. > >> IOW if there's a good reason to turn it off, it's probably a bug. > > I don't think I agree. A post-command-hook that is not useful just > > takes CPU cycles, and likewise a timer which does nothing when its > > function is invoked. > > AFAIK we don't try very hard to avoid such waste. We should, though. > E.g. every time we run redisplay, it will check at every position if > there is a `display` or `invisible` property, even in those buffers > where no code ever has nor ever will add one of those properties. No, the display engine doesn't check for these properties at every position, it only checks that at positions where some property changes (by looking at the interval tree). And properties can be added manually, not just by code, btw. > > And in any case, a feature that changes behavior should have a knob to > > disable it. > > We like such knobs in Emacs, indeed. My argument was not against having > such a knob Well, by saying "if it needs to be turned off, it's a bug", you seemed to be saying that it doesn't need to be turned off. Apologies for my misunderstanding.