From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Redisplay: NS port, high CPU load Date: Tue, 14 Jun 2016 20:02:24 +0300 Message-ID: <83mvmneman.fsf@gnu.org> References: <9793F9E3-979A-4888-8662-F6E0C27C8B37@gmail.com> <20160608195552.GA66865@breton.holly.idiocy.org> <7B0CAF99-689D-4128-8E33-7D9BA8F1823E@gmail.com> <41E503B6-5048-4E20-92CE-1FAD4C05A279@gmail.com> <525668A8-4B0E-4791-A423-F1D4903F4511@gmail.com> <83lh2dpetr.fsf@gnu.org> <83fuslpclx.fsf@gnu.org> <62E0B0C4-4D9B-4E1C-ACE5-06E674C8A342@gmail.com> <837fdsgarj.fsf@gnu.org> <5EBA241B-68F8-4A4D-BEAD-66EACD20333E@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1465924465 3379 80.91.229.3 (14 Jun 2016 17:14:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jun 2016 17:14:25 +0000 (UTC) Cc: alan@idiocy.org, andlind@gmail.com, emacs-devel@gnu.org To: David Reitter Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 14 19:14:19 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bCrur-00017d-A0 for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2016 19:14:17 +0200 Original-Received: from localhost ([::1]:37053 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCrun-0003c3-6Y for ged-emacs-devel@m.gmane.org; Tue, 14 Jun 2016 13:14:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCriZ-0007Tj-LC for emacs-devel@gnu.org; Tue, 14 Jun 2016 13:01:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCriV-00027G-IQ for emacs-devel@gnu.org; Tue, 14 Jun 2016 13:01:34 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56781) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCriV-00027C-FB; Tue, 14 Jun 2016 13:01:31 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4770 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bCriU-0006dR-Dm; Tue, 14 Jun 2016 13:01:30 -0400 In-reply-to: <5EBA241B-68F8-4A4D-BEAD-66EACD20333E@gmail.com> (message from David Reitter on Tue, 14 Jun 2016 20:07:01 +0800) 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-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:204361 Archived-At: > From: David Reitter > Date: Tue, 14 Jun 2016 20:07:01 +0800 > Cc: Anders Lindgren , > Alan Third , > emacs-devel@gnu.org > > OK, I looked into this. I don’t have time right now for a recipe, but what’s happening is that I’m loading (my version of) tabbar.el, which does this: > > (add-hook 'first-change-hook 'tabbar-window-update-tabsets-when-idle) > > Only when first-change-hook is set are those extraneous toolbar refreshes made. The tabbar-window-update function at some point calls (force-window-update (window-buffer)), which may be what triggers the toolbar refresh. OK, thanks, this explains everything. Indeed, calling force-window-update will cause the tool bar to be redisplayed. > So, I think that we should think about disabling hooks such as buffer-list-update-hook, first-change-hook, kill-buffer-hook, for temporary buffers. In my view it just does not make sense to run the hooks for temporary buffers in any sensible scenario. I'm not sure I agree. Forcing redisplay for such buffers might not make sense in most situations (though again, I'm not sure it makes no sense at all), but a hook could do anything at all, and I see no reason to summarily disable it in such buffers. I think it's up to the hook function to be selective if needed. > I also think that this change might affect some modes, if only by triggering bugs. Therefore I would argue that the change to ucs-normalize is the minimal change to fix my bug, and a good housekeeping change in general. I'm okay with the change in ucs-normalize, but I don't think we should do that on the release branch. The situation you describe is quite specialized, and the solution that avoids excess redisplay is to make the hook function more selective about the buffer in which it runs. So I think we are okay with the change you committed to master, and this bug could otherwise be closed. Thanks for looking into this.