From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Date: Mon, 16 Aug 2021 06:21:16 +0300 Message-ID: <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30213"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 Cc: mail@daniel-mendler.de, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org To: Lars Ingebrigtsen , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 16 05:22:15 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mFTCY-0007iQ-QI for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Aug 2021 05:22:14 +0200 Original-Received: from localhost ([::1]:59662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFTCX-0002T5-LR for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 15 Aug 2021 23:22:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39038) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFTCM-0002RF-Pq for bug-gnu-emacs@gnu.org; Sun, 15 Aug 2021 23:22:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36520) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mFTCM-0001lA-JB for bug-gnu-emacs@gnu.org; Sun, 15 Aug 2021 23:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mFTCM-0007Qw-GE for bug-gnu-emacs@gnu.org; Sun, 15 Aug 2021 23:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 03:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs Original-Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162908408728524 (code B ref 48841); Mon, 16 Aug 2021 03:22:02 +0000 Original-Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 03:21:27 +0000 Original-Received: from localhost ([127.0.0.1]:48065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTBm-0007Pv-VL for submit@debbugs.gnu.org; Sun, 15 Aug 2021 23:21:27 -0400 Original-Received: from mail-wr1-f51.google.com ([209.85.221.51]:38463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTBj-0007Pc-Us; Sun, 15 Aug 2021 23:21:24 -0400 Original-Received: by mail-wr1-f51.google.com with SMTP id u16so4428362wrn.5; Sun, 15 Aug 2021 20:21:23 -0700 (PDT) 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=/SDdnV/qJpRL1tdLDLIG8DzV4voetJU/pAmP2OsCwmQ=; b=INK893s60seq21i3Dj5Kh+rfJDiOwPaCCk5Nt1TrGFQjLttNjPcyQKwFkedSi0/JMg ZFiWptBDGU+IByd4h1QasfSz6f+mYeFU5EKKnQ0Vxz7cVhQtV7BwN8G0MnhSecJkpmK+ 8lPEBsaRhE+PXj5zlPjj8IHHCsrliEQ97zZeNBZGCopMFfsHf199L0HVcNMu96mb0zKb VV6Cs/FYyM7+XhvSCqY4IQk4u76cYXN1KTPCJqQhD+Y+jXneHJJW2gaLCW8udzkqmtZI nhioPrrSSlcWpO2NqKVgHY/OKuvEFJKVuWa+ClvlGjfCMLTfMdcyXmVVbpv4zXWIOj6I +Pnw== 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=/SDdnV/qJpRL1tdLDLIG8DzV4voetJU/pAmP2OsCwmQ=; b=FvfOUWi83UiAk17HICrLJ0e/yOyEEklfNwN7ztrDR5znOUlKO3x01nD5u71kiwdlbl i5MpjUF3sBkS5b8IWyQTBbtR55G1spk7YBJi6rHpw3aNfddt37SNsKAQK1sd5O6ctee6 Eyb2E3eid0Dzj3bvKmZmoo9rJMIUohkGcxsEpuxzt8s4xmE9ybUJ9idnStg6GdufdpSL IgTgZ9bbCwLEvFGztA81nKsNwbhU5hhmbcPPx6JAz68/CfPRHhiT4XkvpcgIKlmqbqaR 1n+PVo+cDGgggqsagvTjvVPwonRbMjtmKoDQXMbJFnc3A3bO1PdOpU9dD6Z8paVPXjEo 6WVw== X-Gm-Message-State: AOAM530/V20OZR4i60nwdh+3tIhEHQ57/yHb2+gudBKxnAOSpJ6a2xK6 eV8Ug9IJNx0PQpJAWONdxffnRsVDli8= X-Google-Smtp-Source: ABdhPJyYmnt+dnaCSXEoR1/rysVo1gOgb6lV5DwDleVLpb2yhlFNUeLcnSxtUgUrJ9JW8l/NArVtyA== X-Received: by 2002:adf:e9c3:: with SMTP id l3mr16098689wrn.300.1629084078386; Sun, 15 Aug 2021 20:21:18 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id t14sm9177633wmj.2.2021.08.15.20.21.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:21:18 -0700 (PDT) In-Reply-To: <87wnootec0.fsf@gnus.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:211957 Archived-At: On 14.08.2021 15:12, Lars Ingebrigtsen wrote: > It is a destructive change, but we may just declare that completion > functions are allowed to destructively change the inputs in certain very > prescribed ways. I'd rather avoid that, though, if at all possible, > because it may lead to subtle bugs all over the place. That would be a breaking change, but it's a possibility, of course. If we couldn't find a better way to implement this. > Stefan just reminded me (in a different bug report) that we've long > meant to extend the text property machinery with a "namespace" or > "plane" concept. The impetus for this is really the font locking > machinery which wants to manage some text properties that other packages > also want to manage. "Planes" for text properties are just prefixed properties, I guess? That's different from the situation with font-lock. > The idea is that the display machinery would combine all the planes > before displaying, but each package would just manage its own "plane". > If we had something like this, then using this mechanism in the > completion context would make sense -- we could then say that completion > isn't allowed to alter anything except text properties in its private > plane. Yes, if the code makes sure to only use prefixed properties, that would limit the damage. It could still affect repeated (parallel?) uses of the same values in the same piece of code. And even if the effects are usually not serious, are we really okay with evaluating (symbol-name 'car) someday and seeing lots of properties attached to it?