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.devel Subject: Re: Improvement proposals for `completing-read' Date: Sun, 11 Apr 2021 03:51:43 +0300 Message-ID: <759ed5ae-8d58-e73b-244b-08bd86aafb2d@yandex.ru> References: <09b67fc5-f8fd-c48a-8b0b-ad47c88761f1@yandex.ru> <292a9f63-5a41-7b32-66f2-67d06f138a09@yandex.ru> <7d03e917-6a61-23b3-e735-a8e43c3fb65f@daniel-mendler.de> <01ffe85f-6bdb-39a5-b20a-e3c60bea3e2e@yandex.ru> 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="37590"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 To: Daniel Mendler , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 11 02:53:14 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lVOLh-0009g1-Vn for ged-emacs-devel@m.gmane-mx.org; Sun, 11 Apr 2021 02:53:14 +0200 Original-Received: from localhost ([::1]:52140 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lVOLg-0000ci-Uk for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Apr 2021 20:53:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41788) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lVOKL-00008L-Vr for emacs-devel@gnu.org; Sat, 10 Apr 2021 20:51:50 -0400 Original-Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]:33451) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lVOKJ-0003HO-Mt for emacs-devel@gnu.org; Sat, 10 Apr 2021 20:51:49 -0400 Original-Received: by mail-ej1-x632.google.com with SMTP id g5so7737514ejx.0 for ; Sat, 10 Apr 2021 17:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xf/w9RABUE/3+nz0aGz4sVxPDbJMDi1JfMXXvCCQ1hU=; b=qgSSfurQ74c4xXIv1LRQeKzUMkUjHBVU9dLQROcY6usqph33J3LKfieb1pod5zy6Nc Xcs2dJrAvvbq25um06nXf25WmzOKajsyIvVhwMdO85zH8oBZF0jwbzTJTjqMuPkwDmUL bXSdqmItOYHBBYon62hMSaJuO5ULTCmn4+LkQaeTqvbu+4CYG21Iy+TBTVAEFUOk6wp+ PEprmozkFEeT5/+qiA3X6NwywVXh3i1KkyBmaVPNGUNlOS2JtUd3UPpUHsK4CNyrwdmz 1tq5/6VvohSv6aYbgtGf8u7ty+BBC7i/pK4AcR6pA8MoIKtm7zIvhIsKvGvrLFKjIGKU dICQ== 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:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xf/w9RABUE/3+nz0aGz4sVxPDbJMDi1JfMXXvCCQ1hU=; b=Hjy2U0/DpSmW13TYlBeYDRzOITblJ0anlAUvqR7FhJHjoxqpvbcsEce+XYlJzC30oy vjEcLSjkLPNQrdexxbE23RwVVuno9N4pDkLxrY3ipLLLuBIHHnK38WEzmuFu0bb9yEzc zKKhLAKqYBMFBohuDxIEd0pxalktfKUSjf0d4av5Liq/lIgzYME3SN11Xhix5GeylMWF xMIhqTaikM+Uq4WuPix8VerETgBtSUaLZKeKHtRdSNaIDYZ3m+XXvyxuCjQRBvG8zSLq NCoYgzuHj4DA+kXjMNTiJk3rssp9xax++63q0qsEiYPQqPFdD00wjrhXMzZ+z+11vagZ 2W8g== X-Gm-Message-State: AOAM533J0bhKt5iA9JZts2fWVEEPs0ir0ndW3OwkJIMkmlgATeTRCpWS LsfjEwY0k3E6Bk3DP9NkmLs6oIl8ZsM= X-Google-Smtp-Source: ABdhPJzxrRNhwlkvJWvPtOXK8pn/sM64FEPelxH5Yc/xOCTK3vDif9iGkGzWU702a2kxSm0geBrCog== X-Received: by 2002:a17:906:f842:: with SMTP id ks2mr21744782ejb.322.1618102305962; Sat, 10 Apr 2021 17:51:45 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id ho11sm3250830ejc.112.2021.04.10.17.51.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 10 Apr 2021 17:51:45 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::632; envelope-from=raaahh@gmail.com; helo=mail-ej1-x632.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267850 Archived-At: On 10.04.2021 12:18, Daniel Mendler wrote: > On 4/10/21 4:21 AM, Dmitry Gutov wrote: >>> These `consult--async-*` functions can be chained together to produce >>> an async pipeline. The goal here was to have reusable functions which >>> I can glue together to create different async backends. See for >>> example the pipeline for asynchronous commands: >>> https://github.com/minad/consult/blob/3121b34e207222b2db6ac96a655d68c0edf1a449/consult.el#L1505-L1513. >> >> >> I also like that idea. >> >> How are the backtraces in case of error? Whether they can be made >> readable enough, was one of the sticking points in the (quite heated) >> discussion of bug#41531. > > Backtraces are rather opaque. But having such issues on the language > level should not be a road block. I think the proper fix would be to > improve the debugging infrastructure slightly. > > Instead of printing bytecodes - make this more accessible. Either show > some disassembled string or show location information, which should be > attached to the lambdas. Elisp retains all the information due to its > dynamic nature. So all the information is still present, we can print > all objects in a nice way. If you just (load ...) the package, there will be no bytecode in the output. I was more concerned about simply how it reads (whether it's easy enough to diagnose a problem by reading the backtrace). Or at least whether it's not considerably worse than the alternatives. Regarding navigation, though, precise symbol locations are an old Emacs problem. IIRC Alan posted about making some progress on it in the recent months, and lambdas could indeed similarly be annotated with that solution. > Then there were a few other issue with lambdas, I think the interpreter > captures too much in the closures which can leads to large closures, > which is bad for debugability. The bytecode compiler in contrast seems > to perform an analysis. Is this right - please correct me if I am wrong? > I wonder why there is even the actual interpreter left - why is it not > possible to pass everything through bytecode? I guess this is a legacy > issue and also a bootstrapping issue since the bytecode compiler is > written in elisp itself. Speed, probably (all the JS VMs include an interpreter stage, IIRC)? And if we always worked with byte code directly, stuff like edebug, backtrace printer, would need to be repurposed. There are others here better qualified to answer, anyway. > Furthermore I had another issue with lambdas - if you create large > closures, which I am doing with Consult async, which capture the whole > candidates set, then you end up with memory problems if you register > these closures as hooks. The problem is that `add-hook/remove-hook` > compares using `equal` and this uses hash tables internally, which can > get very expensive. See bug#46326, bug#46407 and bug#46414. Perhaps that's another reason not to use hook for this, and instead to attach frontend updater callbacks to the "future" values directly? With lexically scoped callbacks, for example. >> I would probably say that a UI should itself know better when to >> refresh or not, but I'm guessing you have good counter-examples. > > One could update the UI using some timer if an async source is used > (polling). However since I am setting this on top of the > `completing-read' infrastructure I felt it to be better to do it the > other way round, since the table is only queried when the user enters > new input. I guess for fast sources polling will be as good, but for > slow sources, notifying the UI is better. Perhaps we're just talking about the same thing, differently. What I meant, the source should invoke the callback when it gets new data, and the callback should store the result somewhere, and it can notify the UI about the possibility of refreshing (the frontend implements the callback, so it knows whether and how to do it). But whether to refresh right away, or wait, debounce, or simply discard the output, should be the frontend's choice. >>>> No hurry at all. Sometimes, though, a big feature like that can >>>> inform the whole design from the outset. >>> >>> Yes, sure. When planning to do a big overhaul you are certainly >>> right. But currently I am more focused on fixing a few smaller pain >>> points with the API, like retaining text properties and so on. >> >> Sounds good. I just wanted to add some context for completeness, in >> case the work turns into the direction of the "next completing-read". > > Yes, it seems the discussion already went a bit in that direction. I > agree that it is good to keep all these points in the head if one > designs a new `completing-read'. However from my work on Consult I am > actually not that unhappy with `completing-read' as is. With the handful > of small proposals I made in my original mail the state will be improved > where I had issues. If you look at my `consult--read` wrapper, it has to > do some special enhancements (preview, narrowing, async, ...), but I > think one can work reasonably well with the `completing-read' API. For > now I prefer to work with what exists than throwing everything out. At > least the Consult/Embark package show that one can implement more > advanced completion features based on top of the existing > infrastructure, with only a small amount of advices/hacks. I've read it briefly, thanks. Sounds like you have what is needed to propose an "async" extension to the standard completion tables API? ;-) (No pressure.)