From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.help Subject: Re: My read-buffer-function doesn't work when called by switch-to-buffer Date: Sun, 12 Mar 2023 19:51:33 +0100 Message-ID: <87h6upyenm.fsf@gnu.org> References: <875yb8nvvk.fsf@gnu.org> <87y1o486wo.fsf@web.de> <87fsabslcj.fsf@gnu.org> <874jqq63vn.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2571"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.9.22; emacs 30.0.50 Cc: help-gnu-emacs@gnu.org To: Michael Heerdegen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 12 20:05:21 2023 Return-path: Envelope-to: geh-help-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 1pbR0S-0000Nv-PC for geh-help-gnu-emacs@m.gmane-mx.org; Sun, 12 Mar 2023 20:05:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbR00-0001jd-PA; Sun, 12 Mar 2023 15:04:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbQzz-0001jU-8k for help-gnu-emacs@gnu.org; Sun, 12 Mar 2023 15:04:51 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbQzy-00062C-QA; Sun, 12 Mar 2023 15:04:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-Version:In-reply-to:Date:Subject:To:From: References; bh=oqLIHIuwp0u3lHlbLQ95D8yaHy7Isscq0lmS1R32Mxg=; b=E5RV5Oke0ibexg jcp7LSlYdE5bLpaVIgI+78c4zaPrGsLDGPvxAatrgYvBSaRSOq5J8d8+dSp+AfnTff8V02gNMfWoI +KxecM6k+/YlNpIWlFwaAT5TI5bDD1jU82H1vKvHuCXcmG/YeQcwzEklwgx9zbfZeaedhM77uCNSP bh1Asz+6A53wEk2bO9SzMyLsJ5sDmFHTYZ3lZ60ywGiVkebfZTE5WgnEOM4ApY+DhppJbKtPnsWpC MV8wbhRzp7WQ6eeu2MmRvcT87lKceMD5F5VZnES2ZRkTY0Np72yD2bgoq+KbO//rvKN74ZQ3V7VZ2 362Qa2+yIytcFpfRG3BQ==; Original-Received: from auth1-smtp.messagingengine.com ([66.111.4.227]) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pbQzy-0006lE-Cu; Sun, 12 Mar 2023 15:04:50 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id B6B3F27C0054; Sun, 12 Mar 2023 15:04:49 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 12 Mar 2023 15:04:49 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvddvvddguddukecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehffgfhvfevufffjgfkgggtsehttdertddtredtnecuhfhrohhmpefvrghs shhilhhoucfjohhrnhcuoehtshguhhesghhnuhdrohhrgheqnecuggftrfgrthhtvghrnh epudejtdehuddvleffjeekteegvdehleehvdeufefhueekkeekhedvgfeggeffvefgnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhrnh domhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqkeeijeefkeejkeegqdeifeeh vdelkedqthhsughhpeepghhnuhdrohhrghesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Feedback-ID: ib2b94485:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 12 Mar 2023 15:04:48 -0400 (EDT) In-reply-to: <874jqq63vn.fsf@web.de> X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:143000 Archived-At: Michael Heerdegen writes: Hi Michael, > I think the lesson is that it's better to avoid nested > `completing-read' calls. It is probably not intended to allow to > change the completion table in `read-buffer-function'. Seems so but it nevertheless works extremely well since I strongly stated my wish by appending to minibuffer-with-setup-hook. :-) > Maybe an advice of a higher level function would better fit your > wished-for behavior. Do you have one in mind? >> And a bonus question: I use vertico + marginalia, so the buffers (and >> files in C-x C-f, variables/functions in C-h v/f,...) are nicely >> annotated, e.g., with the buffer's mode or the file's permissions. >> What do I have to do that the recentf candidates also get those >> niceties? Wrap the recentf completion table so that it responds to >> metadata requests? > > Dunno. I don't use these packages. Maybe using :annotation-function > in `completion-extra-properties' also works? How do these packages > achieve this? I haven't checked their implementation but completion-extra-properties is nil and the metadata completion requests also don't return an annotation-function or affixation-function. Nevertheless, all standard completions are annotated. I'll have a look how marginalia does it. Anyway, I've played a bit with responding to metadata requests and it looks like it's not really suited for my goal because it seems to assume that the metadata won't change (e.g., category from buffer to file) during a single completion which is obviously a reasonable assumption. Bye, Tassilo