From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Blink cursor changes, possible W32 breakage. Date: Sun, 21 Jul 2013 22:46:31 -0400 Message-ID: References: <83oba22ymd.fsf@gnu.org> <6B4F86F0-164D-4CBE-8CD2-9BC9326451C4@swipnet.se> <8361w93k8e.fsf@gnu.org> <871u6x4we0.fsf@catnip.gol.com> <58D8CF7D-C157-4D48-93B4-2EFFAA4AAF61@swipnet.se> <8338rd2q1h.fsf@gnu.org> <534E99D7-CC13-4C8D-A80B-EC00995F741A@swipnet.se> <83txjt15hw.fsf@gnu.org> <83li550z3l.fsf@gnu.org> <87ip072t8d.fsf@catnip.gol.com> <83vc46zwsy.fsf@gnu.org> <83zjthy438.fsf@gnu.org> <83k3kky6l3.fsf@gnu.org> <83eharyl65.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1374461201 23470 80.91.229.3 (22 Jul 2013 02:46:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Jul 2013 02:46:41 +0000 (UTC) Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org, miles@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 22 04:46:42 2013 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 1V1693-0000eM-BY for ged-emacs-devel@m.gmane.org; Mon, 22 Jul 2013 04:46:41 +0200 Original-Received: from localhost ([::1]:54476 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1692-0007JQ-V2 for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2013 22:46:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56899) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V168z-0007JK-Jv for emacs-devel@gnu.org; Sun, 21 Jul 2013 22:46:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V168y-0008MI-Mq for emacs-devel@gnu.org; Sun, 21 Jul 2013 22:46:37 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:52526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V168x-0008Lf-2m; Sun, 21 Jul 2013 22:46:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFABK/CFG4rw7r/2dsb2JhbABEukWESRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLY0JhAEDpHqBXoMT X-IPAS-Result: AjgFABK/CFG4rw7r/2dsb2JhbABEukWESRdzgh4BAQQBViMFCws0EhQYDSSIHgbBLY0JhAEDpHqBXoMT X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="19475102" Original-Received: from 184-175-14-235.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([184.175.14.235]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 21 Jul 2013 22:46:25 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 9E616AE1D1; Sun, 21 Jul 2013 22:46:31 -0400 (EDT) In-Reply-To: <83eharyl65.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 21 Jul 2013 18:42:10 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:162061 Archived-At: >> >> No, indeed, but they're not activated unless the user asks for >> >> it explicitly. >> > I don't see how this is relevant. >> It's relevant because most optional features are turned off. > Don't we care about optional features anymore, if, when turned on, > they cause trouble? jit-lock-stealth is a performance tradeoff, burning more CPU cycles in the hope of sometimes providing better interactive behavior. So "keeping Emacs running when it's apparently idle" is not "trouble". > Don't we want users to be able to turn those optional features on > without suffering adverse consequences that we can prevent? I don't think we can prevent them for jit-lock-stealth. We could try and detect when there's nothing more to font-lock and disable the timer at that point. But it's very far form the top of the priority. >> > Are we going to tell users not to enable features if they want Emacs >> > to be friendly to the batteries? That's not going to happen. >> jit-lock-stealth is pretty clearly battery unfriendly. It's in its nature. > Any program, when it works and burns CPU cycles, is battery > unfriendly. jit-lock-stealth does "eager fontification", which implies doing unnecessary work. It's a form of speculation. So it's not just like "any program". > The issue we are discussing here is whether it would be a > good idea to turn such features off under some conditions. Well, we already turn it off in all circumstances except those where the user explicitly requests to turn it on, so I thiunk we cover the 99% of the needs in this area. >> Yes, we did try to make jit-lock-stealth work acceptably, but after many >> attempts, we chose to turn it off instead because there's always some >> situation where it consumes a lot more CPU than what you'd want. > Not here, it doesn't. You're just lucky not to hit the problematic cases. Stefan