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: Blink cursor changes, possible W32 breakage. Date: Sun, 21 Jul 2013 18:42:10 +0300 Message-ID: <83eharyl65.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1374421360 25795 80.91.229.3 (21 Jul 2013 15:42:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 21 Jul 2013 15:42:40 +0000 (UTC) Cc: miles@gnu.org, jan.h.d@swipnet.se, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 21 17:42:41 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 1V0vmR-0003Jh-D3 for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2013 17:42:39 +0200 Original-Received: from localhost ([::1]:37967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0vmR-0001BW-0R for ged-emacs-devel@m.gmane.org; Sun, 21 Jul 2013 11:42:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59741) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0vmN-0001B7-IW for emacs-devel@gnu.org; Sun, 21 Jul 2013 11:42:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V0vmJ-0001Aj-ME for emacs-devel@gnu.org; Sun, 21 Jul 2013 11:42:35 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:34445) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V0vmJ-00019K-FW; Sun, 21 Jul 2013 11:42:31 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0MQA00B00LUMU200@a-mtaout22.012.net.il>; Sun, 21 Jul 2013 18:42:11 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MQA00BQ3MAB7JA0@a-mtaout22.012.net.il>; Sun, 21 Jul 2013 18:42:11 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 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:162054 Archived-At: > From: Stefan Monnier > Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org, miles@gnu.org > Date: Sun, 21 Jul 2013 03:45:50 -0400 > > >> 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? Don't we want users to be able to turn those optional features on without suffering adverse consequences that we can prevent? > > 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. The issue we are discussing here is whether it would be a good idea to turn such features off under some conditions. > 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.