From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: Entering emojis Date: Wed, 03 Nov 2021 02:27:36 +0100 Message-ID: <87tugu9gfr.fsf@bernoul.li> References: <87cznths5j.fsf@gnus.org> <874k8vy7wy.fsf@bernoul.li> <87fssfnwep.fsf@gnus.org> 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="14703"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 03 02:30:42 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 1mi56v-0003ex-7K for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Nov 2021 02:30:41 +0100 Original-Received: from localhost ([::1]:58498 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mi56t-0002p6-6x for ged-emacs-devel@m.gmane-mx.org; Tue, 02 Nov 2021 21:30:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mi544-00026r-Qm for emacs-devel@gnu.org; Tue, 02 Nov 2021 21:27:44 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:51654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mi541-00075p-Vu for emacs-devel@gnu.org; Tue, 02 Nov 2021 21:27:44 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id 23834163FC; Wed, 3 Nov 2021 02:27:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:references:in-reply-to:subject:subject :from:from:received:received; s=sel2011a; t=1635902856; bh=1ftZA FyHYeEmDQWELkdBMMEr3DHRJ8JzKp04RDQQB1g=; b=pJg9DjYg8sfyiZC3byirz 6iRRgCw3BoVU5XewgPPmOKZMvuPwWLQhxBvQkcDmWd//QvjgX/t4KoHwWB+KJpN2 XT8epGSA4OPdNeilF+JSv0p3fo43CoBRETlUoRgTbMQPRo780NLXUKqM6Vmgbm3/ U7D5SYRXRmFbU+maXqpSQw= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id Ulw_2XOnwVfp; Wed, 3 Nov 2021 02:27:36 +0100 (CET) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id E451D163D7; Wed, 3 Nov 2021 02:27:36 +0100 (CET) In-Reply-To: <87fssfnwep.fsf@gnus.org> Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:278552 Archived-At: Lars Ingebrigtsen writes: > =F0=9F=98=84 =F0=9F=91=8D=F0=9F=8F=BC Like it a lot! Lately I was actually occasionally wishing this existed. Let's start with the nitpicking: - The section description is in some cases displayed at the bottom. - That's it. It's great to see something added to Emacs that uses Transient. Thanks for that! And for the variable-pitch functionality. Transient has some support for dynamically generating the suffixes of some prefix using the `setup-children' function, see notmuch-transient for an example (https://git.sr.ht/~tarsius/notmuch-transient). the result. You maybe could use that approach too, at least for the top-level prefix commands. I haven't tried using this for sub-prefixes though. In the notmuch case the suffixes are recreated every time but you could of course cache the result. Ah, actually I ran into one more issue. When I used describe-function to jump to transient-define-prefix to compare it to the code you copied from there I got a lot of new completion candidates for various generated suffix commands that are not intended to invoked directly (and whose name begin with "transient:", which is transient's convention for "anonymous" suffixes but weird I admit). Transient actually tries to prevent that using a *supper weird* hack (I would rather not explain in detail), but you bypass when you generate the suffixes. This hack isn't actually necessary anymore starting with Emacs 28, but I haven't implemented the new approach yet, though it should be trivial: I intend to use (put SUFFIX 'modes '(transient-no-mode)) to do the M-x hiding going forward, which reminds me: it might be a good idea to officially support and document some value that indicates that a command should *never* be shown by M-x. Careful readers might be confused by the use of a mode that doesn't actually exist and it would be good if not every package author who wants to do this has to define some "ceci n'est pas une mode" variable and/or function to have a doc-string to explain what is going on. And since I am going a bit off-topic anyway, let's take it all the way with a question that is only related in that it came up in the context of another package that also uses transient: Is there some generic way to turn a function that reads a single value in the minibuffer into one that reads multiple values, similar to what completing-read-multiple does but which isn't limited to a set of known choices. The function I have in mind is read-file-name-multiple (which is supposed to go beyond merely supporting wildcards, supporting input like "foo.txt,~/bin/bar.sh"). Magit actually uses completing-read-multiple for its "--" argument used to limit logs and diffs to one or more files. It can use do that because the set of choices is known and limited to files tracked in the current repository. This other package needs to read multiple files that are scattered all across the file system. =F0=9F=9B=8C time! Signing off. Jonas