From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: ASCII-folded search [was: Re: Upcoming loss of usability ...] Date: Fri, 26 Jun 2015 13:34:39 -0700 (PDT) Message-ID: <12de813f-cffa-4231-95a4-5b9ee2709123@default> References: <20150615142237.GA3517@acm.fritz.box> <87ioamz8if.fsf@petton.fr> <32013464-2300-46c6-ba46-4a3c36bfee5d@default> <87twu62nnt.fsf@mbork.pl> <87oakdfwim.fsf@uwakimon.sk.tsukuba.ac.jp> <83wpz1lh7c.fsf@gnu.org> <83oakdl7yj.fsf@gnu.org> <83ioall3x5.fsf@gnu.org> <87h9pzxtyi.fsf@mail.linkov.net> <87k2uudoqr.fsf@mail.linkov.net> <87616c94g4.fsf@mail.linkov.net> <87h9pw6922.fsf@mail.linkov.net> <87a8vn75r7.fsf@mail.linkov.net> <0f72b0bd-0170-414c-b926-0b836a973d67@default> <9b42a5bc-48e3-4111-b37d-280867903527@default> 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 1435350917 6338 80.91.229.3 (26 Jun 2015 20:35:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jun 2015 20:35:17 +0000 (UTC) Cc: emacs-devel , Stefan Monnier , Kaushal , "Stephen J. Turnbull" , Juri Linkov , Eli Zaretskii To: bruce.connor.am@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 26 22:35:05 2015 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 1Z8aL2-000279-TB for ged-emacs-devel@m.gmane.org; Fri, 26 Jun 2015 22:35:05 +0200 Original-Received: from localhost ([::1]:33715 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8aL2-0001El-6U for ged-emacs-devel@m.gmane.org; Fri, 26 Jun 2015 16:35:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8aKn-0001EN-4o for emacs-devel@gnu.org; Fri, 26 Jun 2015 16:34:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z8aKl-0005lu-R3 for emacs-devel@gnu.org; Fri, 26 Jun 2015 16:34:49 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:27057) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z8aKf-0005cc-RP; Fri, 26 Jun 2015 16:34:41 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t5QKYdkK016417 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 26 Jun 2015 20:34:40 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t5QKYdlN013567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 Jun 2015 20:34:39 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t5QKYdh7012173; Fri, 26 Jun 2015 20:34:39 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:187581 Archived-At: > > It's not a separate topic if we are now discussing whether to > > indicate char folding in the mode-line etc. >=20 > Whether char-folding is on or off (and how to indicate that) is > orthogonal to which char-folding table the user uses. Not if you assume, as I do, that it can be on for one kind of char folding and off for another. And there can be many kinds. You see char folding as the feature to support with UI indication. I see char foldings (one of which is case folding, BTW). And I'm not sure how they would best be indicated in the UI. > That is, unless you or someone else plans on implementing the > possibility of combining tables and toggling them individually > (which we don't support yet). Let's not assume anything about the possible implementations of char-folding possibilities at this point. (And no, I won't be implementing them.) "(which we don't support yet)" - We don't support *any* character folding yet, in any Emacs release (except for case folding). The point is to not assume there will only be one kind of char folding, so that all we need is a binary mode-line indication that it is turned on. More than one kind of char folding is, yes, what we should aim for, IMO, and what I thought we were aiming for. Multiple predefined equivalence sets, perhaps, and certainly the ability for users to define their own equivalence classes. So yes, I am assuming that is the goal. And in that case it makes little sense to propose mode-line indication now for char folding, I think. It would be either unworkable (too many possibilities) or pretty useless (an all-or-none indicator that says only that *some* folding is currently in effect). Better would be to think, now, about how we might let users know which foldings are in effect - whether via mode-line, an additional line, the prompt, mode-line single-char symbols that provide more info when hovered over or clicked, a key to show a help buffer, or anything else. > Ahn... do you realise that you replied twice to the same email? No; sorry. I received two copies from you (with different recipient lists) and I didn't realize it. I was doing something else at the same time, and I apparently edited two different replies and then sent them both. Mille excuses. > > But it is irrelevant to the > > discussion of whether to indicate char folding in the mode-line. > > How we do char folding doesn't matter in this context. > > What is relevant is that multiple kinds of char folding mean that > > it makes little sense to try to indicate them in the mode-line. > > > > IOW, we should not even think about going down that road, >=20 > So you don't want to implement a simple visual indicator, because > this indicator might become harder to implement in the future when we > *might* have multiple tables that can be independently applied? > (which no one has offered to do yet, btw) You talk in terms of an implementation (tables). I'm talking about a user feature: multiple char foldings, however it might be implemented. And yes, I think that we should, now, assume that we will, one way or another, offer multiple char-folding possibilities. How to indicate the foldings that are currently in effect should be how we think about this, now. We should not opt for a UI that we are pretty sure now will not work for the feature we are aiming for.=20 > > unless someone has a brilliant idea of how to handle a plethora > > of char foldings. >=20 > Well, if we ever even reach that situation: > - If no char-folding tables are in use, the indicator will be off. > - If more than zero char-folding tables are in use, the indicator > will be on. That's not very helpful, IMO. And we *should* "ever even reach that situation". We've been talking about it for a while now. Various implementation possibilities have been suggested, and you have now added one as a start. You know, *case* folding is itself one kind of char folding. Why should we indicate it separately, if, as you seem to think, one size fits all? The answer is that it is important to be able to tell, for any given folding, whether it is on or off. We can do that, I'm sure; we just need to think about it a bit more instead of jumping off the dock into the first dingy we see go by. > I wouldn't call it brilliant (and please let's not go off on a > tangent discussing the (de)merits of this idea), It's not a tangent. All-or-nothing should not be how we indicate char folding to users, IMO. > I'm just saying we don't need to block this feature now What feature? Mode-line indication of char folding? Why not block that for now? Why not discuss how to properly indicate foldings instead? It's not like it's urgent to indicate char folding in the mode line. We don't even indicate case folding in the mode-line! I proposed such case indication years ago (and provided the code). Indicating whether search is currently case-sensitive is as important as indicating other char foldings, no? If we have not found it urgent to do that (and case folding has been a feature for decades) then what's the rush to do it for a not-yet-released, partial implementation of char folding? Why throw something out there now that is inappropriate for the char folding that we've been discussing and aiming toward? > because of the future possibility of multiple independent > char-folding tables. Multiple char foldings, not necessarily tables (plumbing). And yes, that is the feature to work on and discuss at this point, IMO. Not how to indicate the state to users. You made, I assume, a good first step in that direction. That's great. I'm very thankful that we will soon have some additional char folding beyond case folding - believe me. Nothing prevents us from now coming up with a good way to indicate which char foldings are currently in effect.