From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#15740: 24.3.50; enabling & disabling custom themes is slow Date: Sun, 27 Oct 2013 20:08:50 -0700 (PDT) Message-ID: <571c27f7-73bb-4b51-b656-ee81c0d893d0@default> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1382929817 10529 80.91.229.3 (28 Oct 2013 03:10:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Oct 2013 03:10:17 +0000 (UTC) Cc: 15740@debbugs.gnu.org To: Leo Liu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 28 04:10:21 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1VadDf-00089R-6S for geb-bug-gnu-emacs@m.gmane.org; Mon, 28 Oct 2013 04:10:19 +0100 Original-Received: from localhost ([::1]:39759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VadDe-0005qi-NT for geb-bug-gnu-emacs@m.gmane.org; Sun, 27 Oct 2013 23:10:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50496) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VadDV-0005qb-Ve for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 23:10:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VadDP-0007Db-48 for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 23:10:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:33967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VadDO-0007CU-Uu for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 23:10:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VadDO-0007TM-DI for bug-gnu-emacs@gnu.org; Sun, 27 Oct 2013 23:10:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 28 Oct 2013 03:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15740 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15740-submit@debbugs.gnu.org id=B15740.138292974428645 (code B ref 15740); Mon, 28 Oct 2013 03:10:02 +0000 Original-Received: (at 15740) by debbugs.gnu.org; 28 Oct 2013 03:09:04 +0000 Original-Received: from localhost ([127.0.0.1]:47986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VadCR-0007Rw-2V for submit@debbugs.gnu.org; Sun, 27 Oct 2013 23:09:03 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:44928) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VadCM-0007RP-WC for 15740@debbugs.gnu.org; Sun, 27 Oct 2013 23:09:00 -0400 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9S38qRU019590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Oct 2013 03:08:53 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9S38pPb017386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 03:08:51 GMT Original-Received: from abhmt115.oracle.com (abhmt115.oracle.com [141.146.116.67]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9S38peN017381; Mon, 28 Oct 2013 03:08:51 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:79712 Archived-At: > > Not so, custom themes - disabling all enabled themes > > and then enabling one theme is painfully slow, and you see all of > > the changes manifested on the screen, slowly. The same is true if > > there is only one theme enabled: disabling it and enabling another > > is very slow. > > > > Is this something that could be fixed? >=20 > But it works splendidly on OS X and GNU/Linux. Are you sure? I somehow doubt it. Have you tried changing themes when you have multiple frames, say 6 or 10 frames? Try it. > Do you have a recipe to see the slowness? Sure. `emacs -Q'. Then load `doremi.el' and `doremi-cmd.el'. Then use `M-x doremi-custom-themes+' to cycle among themes. With the default value of option `doremi-custom-themes-accumulate-flag', previously enabled themes are disabled when you enable the next one. But even in that case it is very slow. If you let the themes accumulate while cycling (toggle that option), then things get slower and slower and SLOWER, very quickly. (Makes sense: you are accumulating more stuff and disabling more stuff.) I don't really expect cycling with accumulation to be a usable use case (hence the default value of the option), but someone might want to use it occasionally to merge a few themes. And what I described is the case if you have only ONE frame. If you have multiple frames then it is much, much slower still. Compared to what? Compared to color themes. The same library `doremi-cmd.el' gives you command `doremi-color-themes+', for comparison. Doesn't matter how many frames you have: replacing one *color* theme by another appears to be instantaneous, and with no flickering (such as you see with custom themes, where disabling runs through each frame, redisplaying it, and then the subsequent enabling runs through each frame again, redisplaying it). Very simple to compare. You will need library `color-theme.el', available here: http://www.nongnu.org/color-theme. The Do Re Mi files are available on Emacs Wiki: http://www.emacswiki.org/emacs-en/download/doremi.el http://www.emacswiki.org/emacs-en/download/doremi-cmd.el If you want to cycle among themes using some other way than Do Re Mi, feel free. You'll see the same thing, I expect. =20 > > A custom theme is, I believe, heavier duty, saving more > > information than a color theme. A color theme records frame > > parameters, faces, and some variables - no more. > > > > Does this difference in the amount of information account for the > > difference in performance? Dunno. Hoping someone will take a > > look... >=20 > Many years ago when I tried color-theme it couldn't be cleanly > disabled and at times leave some faces in an unusable state that > only a restart could fix. What can I say? Maybe you should try it again, without whatever else you might have mixed into the bag at the time. I have never had such a problem with it, including with Emacs 24. And unlike custom themes, it is trivial to undo most of the effects of a color theme, i.e., to return to whatever settings you had in place before applying any theme. That is apparently not possible with a custom theme - see bug #15687. All you can do is "disable" a custom theme, which leaves you, appearance-wise, in the same (_apparently_ themed) state. OK, disabling does restore `default-frame-alist` and such, but it does not update the existing frames to restore their previous appearance. And it is not just a redisplay thing. If you have file foo.el in a frame that has undergone this operation, and you want to see foo.el in a frame that has the original settings, before you enabled and disabled a custom theme, then you have to use `C-x 5 2' to open foo.el in a new frame. The existing frames are cooked, once and for all. "Disabling" is only relative to other themes. It is a far cry from undoing a theme. Don't get me wrong. Custom themes have their strong points - they have a relatively good Customize interface, and they include more information than color themes do. If the bugs get fixed then people will perhaps rightfully be able to kiss `color-theme.el' goodbye. Until then, custom themes are unfortunately no substitute for color themes.