From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Tue, 01 Jun 2021 16:06:56 +0100 Message-ID: <87h7ih8vzj.fsf@gmail.com> References: <87zgwlb4xc.fsf@gmail.com> <617d06ca-27bf-2ae8-26eb-1042123499d3@daniel-mendler.de> <87pmxhb1rs.fsf@gmail.com> <23510125-37b9-e87e-3590-5322f44772ce@daniel-mendler.de> <87y2c5nhsr.fsf@mail.linkov.net> <87h7irss50.fsf@mail.linkov.net> <43d1599e-2ba9-2efb-45c3-76c67d29a69d@daniel-mendler.de> <87tumrgqrb.fsf@gmail.com> <87tumq92pe.fsf@mail.linkov.net> <87lf82g10g.fsf@gmail.com> <87y2c24lww.fsf@mail.linkov.net> <871r9t2lsy.fsf@mail.linkov.net> <22880197-6d05-c821-2c58-328ed3cfc02e@daniel-mendler.de> <87eedruui3.fsf@gmail.com> <8dd915fe-fe67-2a45-67ff-8aaa3e9b9aca@daniel-mendler.de> <878s3zuq47.fsf@gmail.com> <09f2a253-84ba-5cfd-552e-0b89109864a5@daniel-mendler.de> <875yyxaoxp.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23973"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 01 17:31:57 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 1lo6N1-00065E-N7 for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 17:31:55 +0200 Original-Received: from localhost ([::1]:48382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lo6N0-0001Mm-Mc for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 11:31:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40942) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lo68R-0001Kf-Rg for emacs-devel@gnu.org; Tue, 01 Jun 2021 11:16:51 -0400 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:37684) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lo68P-0004Po-SW for emacs-devel@gnu.org; Tue, 01 Jun 2021 11:16:51 -0400 Original-Received: by mail-wr1-x429.google.com with SMTP id q5so14748468wrs.4 for ; Tue, 01 Jun 2021 08:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=MoQ1d82A5niezq3bCzZ2JMgQaE6/HDlVIGhq0/R5EB8=; b=o6VZ5mQQqkOzAbb/U681CDLA6ScgBtw3Gm/Xsefx7F9ZKFFdNWKcygg3BFLjLPGbdr Sp1/yDW+7rX1b1hyrZhkvExOMKzFN7xw14Mw3em/OaU5QzMN4q7ZsTZ/T5i7uxvurp9+ fGzkn19n076Bm/DqUwkS4kqeY+u+0dzDTkONzGISacZDRf+NJrnDJOe/RxsdMMsQr06O PUw2QAXpGvNwhEwo2BtdpJU4KGVsI5BwCne7XQQ6DQfCTt3/jFiZpZoI9nBmDgpZxQoH AaVTelSfplHfRHiEMkdwulJzrViPhQSIxolCTDUTc61F9VhaeL2AgyOlhvYvXgec30vB YgsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=MoQ1d82A5niezq3bCzZ2JMgQaE6/HDlVIGhq0/R5EB8=; b=mt5bBkIQYvKPmxKXcq4q07OTlwfDAuPwZXwp2StXHTR8DYXYcqkYbu7lEDPSBUBVey FRJ3ifpM4xKXu9EkzWO4kTLPHUmizyb1vbaCJv4DNb6RFah38BDcxrP8dJokKEAHon1G qxqrVdzfuBuhukeHELYAa8M2sIljVPH/dkhLWq6GhVHy65okGUH17ES+Fc0eRPcsPkdf bTCM1z+kDeifg6UKq1lBH4LV56ma1Qm9f6R70BdVxAHPx6xRtE79KAeUrshmox1GwoxH /4KA5ruTHjQcHgBV1SMAf7Sy+X5m8JdD/ZDAjhQZweRUnmn9AKA6x3hAxk7lsVIRenzX SbLA== X-Gm-Message-State: AOAM5325uBTKdCZtU9Xk2QXJiZTxjZYUqIrXmKPsXyhqwpyLi3EmMRmN 7PdRhVr5zIjYTUsyqf7pJfpIiB8xCgA= X-Google-Smtp-Source: ABdhPJw/dvg1hWv0c2YamGBUKYWRSYjVlAkpEioYIwkfYTBAGR6i/fZ3rMBapJpD0yGmCAkcNeOr9Q== X-Received: by 2002:adf:ce90:: with SMTP id r16mr21996005wrn.146.1622560018329; Tue, 01 Jun 2021 08:06:58 -0700 (PDT) Original-Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id 89sm4155636wrq.14.2021.06.01.08.06.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jun 2021 08:06:57 -0700 (PDT) In-Reply-To: (Gregory Heytings's message of "Tue, 01 Jun 2021 14:47:43 +0000") Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x429.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:270208 Archived-At: [Just sent you this reply off-list, here it is on-list] Gregory Heytings writes: >> Just because it's in master doesn't mean it's written in stone. > That's most often the case, but let's see whether this one is an > exception. What, really? Lol, then what are all these commits to master doing? :-) > 1. Your code is not modular enough, for example, IMO it would be much > better if the the annotation function and the candidate number/total > number of candidates were (user-configurable) hooks, instead of > hard-coding these operations in the code. Why do you think the code is not modular enough? Previously, it mixed vertical and non-vertical mode with a bunch of ifs, now vertical mode is handled in its own function. Not ideal, but at least more modular to me. Maybe you're conflating the ability to configure a system with the modularity of its implementation in code. > Not everyone wants to see > these numbers, not everyone wants to see annotations even if they are > available, some might want to add annotations to the candidates list > with their own chosen formatting, and so forth. Who do you think doesn't want to see those numbers? You personally? If so, add a patch (I think Daniel is working on this). But keep the numbers on by default in fido-mode + fido-vertical-mode. It's a new feature so we can what we think is the best default. Overlay, to clarify it seems you regard icomplete-vertical-mode as a long-supported feature of Emacs, it's not. It's a new thing for Emacs 28. Your implementation, which I reworked and merged some time ago, was very simple (a good thing!) but also primitive in functionality (when compared to other completers). I was a good proof of concept but it makes sense to rework it. > 2. I don't understand why you used "icomplete-scroll" for the variable > name, and why it is not a defcustom. IMO it should have been > something more explicit like > "icomplete-vertical-scroll-candidate-list". With a hook, this > variable would not be necessary. A hook is a variable, and considerably more complex than a boolean. Why is that better here and how would it solve the problem? If you want to change the variable name, it's vertainly possible, but really your proposal is mouthful of words, IMHO. I don't make stuff customizable unless people request the customization, i.e. I don't add customization knobs gratutiously. But if you really want to make it a defcustom, of course it can be added. As for fido-mode, which is an opinionated completer, it overrides it (as it already does a lot of other defcustoms). > 3. As I feared, the code to scroll the candidates list does not work > correctly alas. I've put lots of efforts to make "icomplete-vertical" > work correctly in virtually every possible case, so I find this very > regrettable. For example, with frame-height =3D 47, 10 candidates are > displayed, yet the candidates list rotates on the 7th candidate > (instead of the 11th one). This is by design. Works like Vertico and many other completers. But are you experimenting with: fido-mode + icomplete-vertical-mode or icomplete-mode + icomplete-vertical-mode ? The former uses scrolling by default, the latter doesn't. It uses rotation, and always "rotates" in the first character. So I am confused when you speak of rotations. > With frame-height =3D 30, 6 candidates are > displayed, and the candidates list rotates on the 6th candidate > (instead of the 7th one). Can't reproduce this, I see it scroll (not rotate) on the third visual candidate. > With frame-height =3D 22, 4 candidates are displayed, and the candidates > list correctly rotates on the 5th candidate. With frame-height =3D 15, > two candidates are displayed, yet the candidates list rotates on the > 4th candidate (instead of the 3th one, and in this case you don't even > see the current candidate anymore). I also can't reproduce these two cases, not with Emacs -Q. Maybe you're using some extra configuration? What? > If I start working on this (again), I would likely change most of your > code into something else, and it would take some time, because it's a > difficult problem. Would you agree with this? First say what you would want to change it to, and why. Jo=C3=A3o