From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.devel Subject: Re: Performance degradation from long lines Date: Sun, 30 Dec 2018 18:23:22 +1300 Message-ID: <246ad64a-6fa5-00c0-975a-21859c1f8fd7@orcon.net.nz> References: <665d5f3d84c071632f87f66ffedb6aed@webmail.orcon.net.nz> <9306f417-e1ea-5e23-5d92-53e3988baacb@orcon.net.nz> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1546147328 9404 195.159.176.226 (30 Dec 2018 05:22:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 30 Dec 2018 05:22:08 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 Cc: Eli Zaretskii , Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 30 06:22:04 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gdTY3-0002Kw-I5 for ged-emacs-devel@m.gmane.org; Sun, 30 Dec 2018 06:22:03 +0100 Original-Received: from localhost ([127.0.0.1]:42944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdTa9-0002IP-Sb for ged-emacs-devel@m.gmane.org; Sun, 30 Dec 2018 00:24:13 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:43677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gdTZU-0002I4-TD for emacs-devel@gnu.org; Sun, 30 Dec 2018 00:23:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gdTZU-0004Zi-3Y for emacs-devel@gnu.org; Sun, 30 Dec 2018 00:23:32 -0500 Original-Received: from smtp-2.orcon.net.nz ([60.234.4.43]:40996) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gdTZQ-00048V-E4; Sun, 30 Dec 2018 00:23:28 -0500 Original-Received: from [150.107.172.73] (port=51957 helo=[192.168.20.103]) by smtp-2.orcon.net.nz with esmtpa (Exim 4.86_2) (envelope-from ) id 1gdTZK-0007Hx-FA; Sun, 30 Dec 2018 18:23:22 +1300 In-Reply-To: Content-Language: en-GB X-GeoIP: NZ X-Spam_score: -2.9 X-Spam_score_int: -28 X-Spam_bar: -- X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 60.234.4.43 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:232044 Archived-At: On 28/10/18 11:15 AM, Stefan Monnier wrote: > When introducing such a blacklist of modes, it's always good to also add > some way for a mode to voluntarily flag itself as "black", so the list > has a chance to shrink over time. > > E.g. we could add a symbol property `slow-on-long-lines` which > font-lock-mode could set to announce that it assumes lines aren't > terribly long. I've not implemented this suggestion at this point -- I thought it warranted further discussion, and I wanted to get the other changes dealt with first. It's not entirely clear to me how this should be managed. One approach is that modes which identify themselves this way would be disabled automatically, and users would have no control over it. That would probably be easiest to implement, but I don't particularly like the idea that users lose control and/or visibility over what's being done. However, any approach whereby users do have control would seem to imply some significant complications to the code and user interface; especially as modes flagged in this way are not necessarily loaded at the time when the user is customizing the so-long options. The very simplest thing I can think of is a single boolean user option to say "deal with any flagged modes too" (the currently-loaded instances could be displayed in the UI). Potentially `custom-add-frequent-value' could be employed to present flagged modes as checkbox options which then remain visible even if the user disables them; but that only works for 'hook' and 'alist' custom types, and `so-long-minor-modes' is just a list of symbols. If the user does get to confirm each flagged mode and save that configuration in their custom file, then there's the issue of modes which were flagged at one time (and saved by the user), but were subsequently improved such that the symbol property is no longer needed. In that situation it would be nice to differentiate between "modes that the user saved on purpose" and "modes which the user saved because they used to be flagged". In general, it would be nice if the user could distinguish the automated settings from the ones which they personally selected, in a non-cumbersome manner. I suppose the list of modes could become an alist, with an associated classification for each mode (e.g. 'auto for modes which should be dealt with based upon their symbol property). That would be a breaking change, as `so-long-minor-modes' has existed as a simple list since early 2016, so some kind of migration or other backwards-compatibility support would be needed. I expect that all this would apply to `so-long-variable-overrides' as well. I'm not sure this is necessary for an initial release, mind, but it does seem like a good thing to provide at some point. How would other people approach it? -Phil