From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: BIKESHED: completion faces Date: Fri, 8 Nov 2019 16:01:54 +0000 Message-ID: References: <87zhhaxalt.fsf@gmail.com> <83bltpgffr.fsf@gnu.org> <83tv7gg9oz.fsf@gnu.org> <83r22kg8pa.fsf@gnu.org> <20191106205133.njij3ve7qqy7yh3q@Ergus> <83ftizg4nr.fsf@gnu.org> <8336ezg2vm.fsf@gnu.org> <83wocbelu1.fsf@gnu.org> <83imnvegcp.fsf@gnu.org> <83ftizeelw.fsf@gnu.org> <83bltne6oq.fsf@gnu.org> <87lfsrqs63.fsf@gmail.com> <838soqeuzr.fsf@gnu.org> <87ftiyn07t.fsf@gmail.com> <8336eycvpf.fsf@gnu.org> <83pni2bcws.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="264989"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Ergus , Dmitry Gutov , Stefan Monnier , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 08 17:07:18 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iT6n7-0016m7-62 for ged-emacs-devel@m.gmane.org; Fri, 08 Nov 2019 17:07:17 +0100 Original-Received: from localhost ([::1]:56940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iT6n5-0000Od-It for ged-emacs-devel@m.gmane.org; Fri, 08 Nov 2019 11:07:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56872) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iT6iI-00040K-SG for emacs-devel@gnu.org; Fri, 08 Nov 2019 11:02:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iT6iD-0002Fl-HU for emacs-devel@gnu.org; Fri, 08 Nov 2019 11:02:18 -0500 Original-Received: from mail-io1-xd2c.google.com ([2607:f8b0:4864:20::d2c]:40859) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iT6i7-0002Bv-Oe; Fri, 08 Nov 2019 11:02:07 -0500 Original-Received: by mail-io1-xd2c.google.com with SMTP id p6so6878472iod.7; Fri, 08 Nov 2019 08:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mwBqrA8M5+lK5Z769UTvjYbdLq4uvoweb5ZQuH9FUeY=; b=iFqrqzB5LnwnekonKD0C6RBATAaRzWa4hL2EgmxJQXkK94kDyE7fJG0BZ7FDk8d+o8 307cAmWBg3VNGVkrhWir4tJv62/hU4OoVuR/wqJbYGrLooLOFp6ujFM6KzHKCY4TP+Cn SUfOtrU8zeBL3/+9rAfH0Y0h5fv9ev95C2rbKQTuVg4Zm1PfdtuK4cSkSYeNae1Mfr3O mtGJN7rEMfz3BYDFR51LcHSB0oQkP+FARD0epgL8zVCZTjgraP3BI8kSNIdlp3QG6J/P XmQdG6o4lNE0iWu/Ix7tIQKF4VdRdu7UnuKiPSTj9I82Pnhz/fw6NT5GwFPFExfQGCnW VdXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mwBqrA8M5+lK5Z769UTvjYbdLq4uvoweb5ZQuH9FUeY=; b=HpHfBSmqvGnkznINVhJ9jFqY9aQ1laGRlX2Q+mSnbuhPijCn50H/F9qlggAPGQ/GUk JK9ny1QSdpdcQmW4XEKUMxN0b/XFfFtKYEPiWpPXE4nIeqzXYAt6PielnuELZigXpvke dpnhbRjsd3rY36M3FaustpZDlQXgnWfgXRRMl6OOYvCwnfyG7CTjlxg17qELuYS39Vuq /HecG4fQy2RGkUrvrxhlWq7+0iTy0mXs9XaAGEjCFAJrmeGS94r9gOaGfVp2a/6uynzd OUdxSZTSvuJ6rxMKr6UxP65iRtGU2NXYkBPlS7gFspSbOhIyFR5C3cN0Wc3XhVKHpxAi Qo6g== X-Gm-Message-State: APjAAAWeA2bYlYW6wHMwm2Z1uTug+g6YPixBbL5RCn9VsWPh44QmT1zJ CcLoaEC7k9QJ1dDlmlcxi7OwY5D03EUI87RQ9FSc2g== X-Google-Smtp-Source: APXvYqyWmp4f3n9yL0WDCKDWYDUJGQU6FYkAee7VdEL7W+ZywQCgffrmdCM9bpo1HWdpArdNsRSSYezgTJkuU1m6KY8= X-Received: by 2002:a02:7160:: with SMTP id n32mr11833603jaf.120.1573228926539; Fri, 08 Nov 2019 08:02:06 -0800 (PST) In-Reply-To: <83pni2bcws.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d2c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:241986 Archived-At: On Fri, Nov 8, 2019 at 3:34 PM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Fri, 8 Nov 2019 15:09:31 +0000 > > Cc: Ergus , emacs-devel , > > Stefan Monnier , Dmitry Gutov > > > > > > >> fabrobazor > > > > >> ^ ^ ^ > > > > >> `---`---`----- I want these bold by default in the future > > > > >> > > > > >> no change to the 'basic/prefix' completion. > > > > > > > > > > I understand that you want to highlight both f, o, o, and r, but = the > > > > > latter with a different face. If my understanding is incorrect, > > > > > > > > It is incorrect indeed: 'r' is should have the same face as 'a' or = 'b'. > > > > > > Did I say that _only_ r will be highlighted with that face? > > > > I don' think so. I think you can read what you said above. > > > > I confirmed your sentence "if my understanding is incorrect". Because > > I _don't_ intend flex to "highlight" r at all, or 'a' or any other cha= racter > > except 'f', 'o' and ' o'. So these characters ('a','b','r' and 'z' in = this > > example) should, for now, have the same face, 'default'. We can think > > about the value of highlighting other neighboring characters later. > > > > > I'm okay with highlighting a and b as well in this example, provided > > > that typing "faoo" will include "fabrobazor" in the results. > > > > It will indeed include that in the results. But in that your > > example only 4 characters should be highlighted: f, > > a (the first one),o, and o . So no 'b'. > > 'b' comes from what you originally wrote. My example was different from yours. I just wrote 'b' there to exemplify a thing that would not be highlighted when the pattern is "foo" and the candidate is "fabrobazor" > I admit I don't understand why 'b' won't be highlighted: wouldn't > typing "fobo" narrow the list of candidates shown by "foo"? If so, > 'b' should be highlighted like 'a' and 'r', no? When you type "fobo" the 'b' is highlighted .What you seem to propose later doesn't make much sense in flex, because usually there can be many such things that you "could" type to narrow the selection.If 'basic' there is at most one. And in other more complex styles like Drew's regexp styles or Helm's advances stylee, there can probably be many more such things, even characters that are not literally in the candidates. > > > That would mean this face is used inconsistently: in basic and other > > > similar styles it highlights the character(s) that narrow(s) the > > > selection of candidates, while in flex they will highlight the > > > characters already typed by the user. Is that correct? > > > > Yes it is, but "this face" would now be called "completion-emphasis" > > , not "completion-narrower" or "completion-already-typed" or > > "completion-first-difference". That's why the renames are > > important. > > I don't think that names that obfuscate the use of the face is a good I don't think it obfuscates, but it displaces the meaning, yes. Since there can be many styles, which rely on visually highlighting things according to a particular, well, "style", I thought it a good strategy to have face names that don't restrict them from doing so. So, according to your decision, the way to achieve that freedom seems to be, to me, to have more face names like "flex-completion-pattern", "flex-completion-likely-next-char". "forgiving-completion-typo", etc. (the latter is a hypothetical example of a face used in the implementation of a "forgiving" style that allows some typos). I am correct? This affords the "consistency" you want, at the expense of requiring the user to customize a whole new set of faces if he ever switches styles. The upside is that the defaults problem goes away and perhaps face inheritance can hide part of the complexity from the user. So, using the opportunity that the subject is fresh now, would you object that 'flex' starts using a new face, say 'completion-flex-pattern-emphasis' or 'flex-pattern-emphasis' , that inherits from the current 'completions-first-difference' face? Thanks, Jo=C3=A3o