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#23377: 25.0.93; Completion is extremely slow for insert-char Date: Mon, 25 Apr 2016 22:43:33 -0700 (PDT) Message-ID: References: <2fd9a9b4-fb49-da6e-f13b-0fce4708159a@cs.ucla.edu> <34cb394c-1a2f-4fe5-8a2f-d26702487aef@default> <571EEA4A.3020105@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1461649469 11419 80.91.229.3 (26 Apr 2016 05:44:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Apr 2016 05:44:29 +0000 (UTC) Cc: "N. Jackson" , 23377@debbugs.gnu.org To: Paul Eggert , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Apr 26 07:44:14 2016 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 1auvn9-00025m-Ra for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Apr 2016 07:44:12 +0200 Original-Received: from localhost ([::1]:36324 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auvn9-0002ct-8N for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Apr 2016 01:44:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55372) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auvn5-0002aq-Nu for bug-gnu-emacs@gnu.org; Tue, 26 Apr 2016 01:44:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1auvn0-0000eb-Kn for bug-gnu-emacs@gnu.org; Tue, 26 Apr 2016 01:44:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auvn0-0000eX-Gv for bug-gnu-emacs@gnu.org; Tue, 26 Apr 2016 01:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1auvn0-0007sY-6z for bug-gnu-emacs@gnu.org; Tue, 26 Apr 2016 01:44: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: Tue, 26 Apr 2016 05:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23377 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch confirmed Original-Received: via spool by 23377-submit@debbugs.gnu.org id=B23377.146164942730255 (code B ref 23377); Tue, 26 Apr 2016 05:44:02 +0000 Original-Received: (at 23377) by debbugs.gnu.org; 26 Apr 2016 05:43:47 +0000 Original-Received: from localhost ([127.0.0.1]:47350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1auvml-0007rv-Fh for submit@debbugs.gnu.org; Tue, 26 Apr 2016 01:43:47 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:37564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1auvmj-0007ri-SQ for 23377@debbugs.gnu.org; Tue, 26 Apr 2016 01:43:46 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3Q5hcka001497 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Apr 2016 05:43:38 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3Q5hcMK028630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Apr 2016 05:43:38 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u3Q5hZEM006300; Tue, 26 Apr 2016 05:43:37 GMT In-Reply-To: <571EEA4A.3020105@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] 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:116850 Archived-At: > > if the main reason to disable it is for performance in > > an extreme use case (C-x 8 RET TAB) >=20 > It's not that extreme. It's natural for a user to get the > whole list and then use C-s to find the desired character. "Natural" or not is primarily opinion-based. I sometimes do something similar, so yes, there are times when you might want to do that. I submit that someone who does it regularly is exceptional however, hardly typical. That is, asking Emacs, each time (or even most of the time or much of the time), to show you all of the Unicode chars along with their names, is exceptional. There is nothing wrong with a user choosing _not_ to show the chars by default - absolutely nothing. The question is what the _default_ Emacs behavior should be for users in general. (But the more important question is, again whether to provide a user option.) > Also, there's a problem even in less-"extreme" cases. I just > now tried 'C-x 8 RET B TAB', which lists every character whose > name starts with "B", which filters out the _vast_ majority of candidates - lots of them. And that's just from typing ONE char. > and this took about 18 s on my platform, How long did `C-x 8 RET TAB' take? ;-) Even just typing one char makes a huge difference. Type two and the difference is hugely huge. Type three ... four ... > whereas with Emacs 24.5 it is almost instantaneous. Isn't it almost instantaneous if the char display is turned off (in Emacs 25)? IOW, disabling the new feature should provide the same performance as before. If it does not then yes, there is likely a bug here to be fixed. But if it is the same, and the slowdown comes only from displaying the named characters, then it is not clear that there is a bug. By displaying the chars you are asking Emacs to do more work. > 18 s is waayyy to slow for this sort of user interaction. What sort of user interaction? What do you expect, from typing only `B'? As you can see when you hit TAB after `B', there are still lots of candidate chars, and you are asking Emacs to display all of them. > Stefan's suggestion of a config var sounds good. Yes, it's obvious. It should be a user config var, IOW an option. FWIW, I have some experience with this, as Icicles has had a similar option for many years. IMO, being able to see the matching chars is extremely helpful (and in the case of Icicles, it is enabled by default). But of course if it is enabled then you might not want to be doing things like `C-x 8 RET TAB' or `C-x 8 RET B TAB'. And you might need to be told that, in the doc string. And you certainly should be told about the option to turn off such costly-but-useful behavior. Using `C-x 8 RET TAB' and the like can be reasonable (though still not very useful) when the option is disabled. But doing that makes ~zero sense when it is enabled. Users need to know this, yes. And yes, there are other design possibilities, including, say, treating the char display when it is enabled as if it were disabled, until you've typed at least N chars. In such a design, the non-nil option value could be a number (min # of chars). > It's a bit late to be adding features to the emacs-25 > branch, though, so I'm inclined to revert in emacs-25 > (with a "do not merge to master") and add a customizable > var in master. Add the user option. And add some guidance to the doc. I see no reason to revert the feature or to disable it by default. (But to be clear, I really don't care, personally - I use Icicles.) -- (FWIW #1) -- With Icicles, `C-x 8 RET B TAB' takes only about 1 sec, not 18 sec. Dunno why the difference from what you report. Maybe it has to do with the font used - mine shows a lot of the hex rectangles for BALINESE*, BAMUM*, BRAHMI* etc. chars, because my default font doesn't support them. It shows 2093 candidates altogether. Most of them do display the char, not a hex rectangle, however. `C-x 8 RET TAB' takes about 15 sec, for 38830 candidates. And Icicles spends some extra time composing mouseover text and mode-line text help. (However, that's with Emacs 24.5. I cannot use Emacs 25 for this because 25 crashes on me all the time. But unless the Emacs 25 code does something different for `ucs-names' itself, it should not affect the Icicles code. So I will expect the same kind of time, once I find an Emacs 25 build that doesn't crash.) -- (FWIW #2) -- Option doc. (Note the bit of advice at the end, about _not_ doing things like `C-x 8 RET TAB'.) -- icicle-read-char-by-name-multi-completion-flag is a variable defined in `icicles-opt.el'. Its value is t Documentation: Non-nil means `icicle-read-char-by-name' uses multi-completion. If nil then a candidate is just as in vanilla Emacs. If non-nil then it is a 3-part multi-completion: NAME CODE CHAR, showing three ways to represent the character as text: * NAME is the Unicode name * CODE is the Unicode code point, as a hexidecimal numeral * CHAR is the char itself (as it appears in text, not as an integer) In addition, if non-nil then properties `help-echo' and `icicle-mode-line-help' are put on NAME, showing both NAME and the code point (in hex, octal, and decimal). Setting this option to nil can speed up reading a character considerably, but it does not give you the advantages of seeing the character (WYSIWYG) or matching its code point. Instead of using a nil value, you can also speed things up by: * turning off incremental completion * choosing a strong input pattern, before asking for candidate matching. You can customize this variable. -- (The behavior is not quite the same as for vanilla Emacs. You can complete against the code point or even the displayed char, not just against its name - or complete against any combinations of the three. You can, e.g., complete against a char such as `;' to see its name and code point.)