From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: BIKESHED: completion faces Date: Tue, 5 Nov 2019 01:25:29 +0200 Message-ID: References: <4c5631d4-9dfd-04c6-c573-b83c67fcc2fa@yandex.ru> <87pni7p83l.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="244417"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 Cc: Stefan Monnier , emacs-devel@gnu.org To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 05 00:25:44 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 1iRljE-0011TX-Jj for ged-emacs-devel@m.gmane.org; Tue, 05 Nov 2019 00:25:44 +0100 Original-Received: from localhost ([::1]:39552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iRljD-0003kK-E2 for ged-emacs-devel@m.gmane.org; Mon, 04 Nov 2019 18:25:43 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46693) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iRlj6-0003kD-Io for emacs-devel@gnu.org; Mon, 04 Nov 2019 18:25:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iRlj5-0001I6-1R for emacs-devel@gnu.org; Mon, 04 Nov 2019 18:25:36 -0500 Original-Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:43747) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iRlj4-0001Dd-PN for emacs-devel@gnu.org; Mon, 04 Nov 2019 18:25:34 -0500 Original-Received: by mail-wr1-x42c.google.com with SMTP id n1so19096108wra.10 for ; Mon, 04 Nov 2019 15:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Uz5yK9oqQBjUP7x2q5A1zY5QEeedhc46LYSJz1GoYNo=; b=D9g1z56bxA0otHRvDEm43hb4V558xHkMCMX864sqtgvpYeJeUCUbeqUQz9jO8hfaWW HEmF6ghFNbfvHzS05S640g7AybLsLLpdrZXKoYGyWReoc+hDStEOKeXgzN2f+u43+2vn PKm29W2etmPG4yuk1roNdRPxNet5sa5t0hQ8dEIuXDliysH0CYs6LGIQm5DMAZYLhoVU Yy0fXbvih4K1M0/6XupO4Gy4rdoluotUIFYvLcz04LPEizq4C/pUo/tIucp7UGFdqR61 D8/hGw6johUQ3T9LnCK2OIYnZwINZu589Emy2OaTM8TXbKDKb8CQE9kSFjG5f8LibCwh okiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Uz5yK9oqQBjUP7x2q5A1zY5QEeedhc46LYSJz1GoYNo=; b=lRRfIMPV2bIoNRtZnmDC3i1gRziWk5Mt7QM9STZDlFXjJH823ouEaR7sM5wSbGgxK3 CecIUyRx1SgCtP0GWAiUE0D32XGCWjO3omOq9XLuZKz0lGApIxTbYNaQrkBD9togYZ7j 15EH9ofZUXqINuThhJtIxM2aUdrfDvAXHH8bIrk9TLcUytTMhLwRdpa5uTU9X2qN2fvz N/2R5muAXAsVXuNDREdSgYGVh7pgus7+i38H16Szg6owXouLaF54Jm0WA/6tga6V70Ou eYDCQCkUket0AEvBBT/5muehQ8AZ9IWZ5X0nF3LsCEUjr0YYE4W9qgi7q1lpekcm6MIs iHZQ== X-Gm-Message-State: APjAAAXnPWpG/1l7I8xdLhcNFVWtZLnxltcJFpBe9m32k33V49E8i4vc yg2Lf/v+sUnPRIijBVnOtVOECwcPJgE= X-Google-Smtp-Source: APXvYqwXIiZRxOuXKrnBasWDcCiMye/eyNLpZddBbaAotytxOsWUL5mA0I86d435YYHAdIoFD6VPvg== X-Received: by 2002:a5d:570a:: with SMTP id a10mr14700126wrv.107.1572909932273; Mon, 04 Nov 2019 15:25:32 -0800 (PST) Original-Received: from [192.168.0.5] ([212.50.117.215]) by smtp.googlemail.com with ESMTPSA id 65sm28379624wrs.9.2019.11.04.15.25.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 15:25:31 -0800 (PST) In-Reply-To: <87pni7p83l.fsf@gmail.com> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42c 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:241796 Archived-At: On 05.11.2019 0:52, João Távora wrote: > I don't agree with this reasoning at all. First I think we agree Emacs > would profit (in influx from users) from defaults that make it behave > less like 90's Emacs and more like other younger editors. However we > also know that we can't just change the defaults without bothering > users already relying on those defaults. We agree, yes. Although I'm more in favor of changing the defaults, as soon as the kinks are worked out (e.g. flex is a bit slow when prefix is 1-2 chars). > So the next best thing is to add new functionality with a minimum of > customization necessary. So, IMO, it's nonsensical to ask users to > customize the matching style to 'flex' AND also ask them customize a > face so that that more-than-familiar matching strategy reveals its > familiarity. I disagree that it's a significant problem, though. Enabling 'flex' is one line. Customizing the face is just another line. > This is better: I think this would lead you to my idea of a new > `completion-relevant` face, which we would set to bold or something very > prominent. For the 'prefix' the relevant part is the "next character" > and for the 'flex' style is whatever has matched. > completions-first-difference could then be made an alias of that new > face. Hmm, I don't like this changing of terms, sorry. This way, the same highlighting would be applied to two fairly different things. > 3. Completion styles decide which parts which faces to apply and when. > Prefix uses both like it does now. Flex should probably only use > 'completion-relevant'. With my proposal, the positions of the new face can be unambiguously determined by the current markings. So its application doesn't need to be implemented in completion styles. It can be done in one place: the code rendering the *Completions* buffer.