From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#29889: 27.0.50; Slow visual selection Date: Sat, 06 Jan 2018 10:37:27 -0500 Message-ID: References: <87y3lmgphl.fsf@gmail.com> <83tvw9gb26.fsf@gnu.org> <87efndro8q.fsf@gmail.com> <837et4fraf.fsf@gnu.org> <87wp13h3jn.fsf@gmail.com> <724A6161-783D-4CAD-AFBD-40D6AEF2C6E6@gnu.org> <1157A54D-2179-40FB-BE74-294304A9C550@gnu.org> <87608fwzx1.fsf@gmail.com> <83incf9ydr.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1515252980 1850 195.159.176.226 (6 Jan 2018 15:36:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 6 Jan 2018 15:36:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: 29889@debbugs.gnu.org, Sujith To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 06 16:36:16 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1eXqW1-00089B-2B for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Jan 2018 16:36:09 +0100 Original-Received: from localhost ([::1]:39650 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXqY0-0008Pn-BN for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Jan 2018 10:38:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40407) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXqXu-0008NV-8d for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2018 10:38:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXqXr-00077g-0Y for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2018 10:38:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:57840) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eXqXq-00077T-TG for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2018 10:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eXqXq-0005re-Jd for bug-gnu-emacs@gnu.org; Sat, 06 Jan 2018 10:38:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Jan 2018 15:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29889 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29889-submit@debbugs.gnu.org id=B29889.151525305422509 (code B ref 29889); Sat, 06 Jan 2018 15:38:02 +0000 Original-Received: (at 29889) by debbugs.gnu.org; 6 Jan 2018 15:37:34 +0000 Original-Received: from localhost ([127.0.0.1]:38288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXqXO-0005qz-7Y for submit@debbugs.gnu.org; Sat, 06 Jan 2018 10:37:34 -0500 Original-Received: from pmta31.teksavvy.com ([76.10.157.38]:60818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eXqXN-0005qm-0Y for 29889@debbugs.gnu.org; Sat, 06 Jan 2018 10:37:33 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2GjMAAg7FBa/yyKSC1bHAEBAQQBAQoBAYMPMIFaiUmEeo50ggKZP4VFAoQyQxQBAQEBAQEBAQEDaCiFJQEEAXkFCwsNJxIUGDGKPAiuP4MoIQKKEQEBAQEBBQIBJYQgghWGbYsaBZM5kCWhTCiHU5hTNiOBUDIaCDCCaIR0I4pNAQEB X-IPAS-Result: A2GjMAAg7FBa/yyKSC1bHAEBAQQBAQoBAYMPMIFaiUmEeo50ggKZP4VFAoQyQxQBAQEBAQEBAQEDaCiFJQEEAXkFCwsNJxIUGDGKPAiuP4MoIQKKEQEBAQEBBQIBJYQgghWGbYsaBZM5kCWhTCiHU5hTNiOBUDIaCDCCaIR0I4pNAQEB X-IronPort-AV: E=Sophos;i="5.46,322,1511845200"; d="scan'208";a="16923811" Original-Received: from unknown (HELO pastel.home) ([45.72.138.44]) by smtp.teksavvy.com with ESMTP; 06 Jan 2018 10:37:27 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 3013361839; Sat, 6 Jan 2018 10:37:27 -0500 (EST) In-Reply-To: <83incf9ydr.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 Jan 2018 10:37:04 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:141836 Archived-At: > In fact, I cannot understand why the default was changed to t in > 7c23dd4. The discussions leading to those changes all mention the > value 'lazy' (later renamed to 'only') as the default, and there's > nothing I could find explaining why t was eventually deemed a better > default. FWIW I was also surprised to see its default is t rather than `only` (and even more surprised that I hadn't noticed it all this time). I think to make t work well (i.e. to avoid the obvious performance issue discussed in the current bug-report), we'd need to rework the code so as to try and avoid re-allocating a complete brand new string all the time. E.g. special-case the common situation where nothing in the buffer has been modified since last time and only extract some kind of "adjustment" (i.e. something that says "remove last N chars" or "append this string"). Or maybe extract the region lazily: only remember the start and end position of the region in the post-command-hook and postpone extracting the region until either the primary selection is requested or the text is about to be changed/destroyed (i.e. from before-change-function or kill-buffer-hook). > Regardless, I still wonder whether region-extract-function should call > buffer-substring-no-properties, at least when it's used to set the > primary selection. Stefan, any thoughts? We could try to do that to reduce the pain a bit, but region-extract-function should generally preserve text properties (when its output is used by Emacs rather than by another application), so we'd need to add some way to specify whether we want the properties or not. I think I'd rather "fix it right" than add such a hack. Stefan