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: Sat, 11 Mar 2023 09:58:11 +0100 Message-ID: <87fsabslcj.fsf@gnu.org> References: <875yb8nvvk.fsf@gnu.org> <87y1o486wo.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="23858"; 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 Sat Mar 11 10:12:51 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 1pavHX-00060j-74 for geh-help-gnu-emacs@m.gmane-mx.org; Sat, 11 Mar 2023 10:12:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pavH0-0006Sk-0Q; Sat, 11 Mar 2023 04:12:18 -0500 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 1pavGz-0006Sc-B8 for help-gnu-emacs@gnu.org; Sat, 11 Mar 2023 04:12:17 -0500 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 1pavGy-0000eB-R1; Sat, 11 Mar 2023 04:12:16 -0500 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=vTeqlV4B6hbkowkHt/32WgM+vBFQ7SAXbXY12v3MvR4=; b=Tr/82pFWCHOAQ/ +aWsa4uvMIwU+xUtYy1AJseE48QWbVrRzkNyH2EBTAtjDa1gd4ef24YaO4U4Qt6oQo0A3xSoCTMEi ins/LFgV6AdK4bkA4Hbf2UpGFMBIprN6CO2EW1Le4DYcSj4Z7a9XuZCQawUCOsQmGFZO0Xs7RQPpT 3sCw9Yp9EZmZ/BXtZLENgQJyf9KGWyF4sbbGjfXQAFkIFPHncHK/L/mQLYRQATwWyK9evPCI8/g5U JWArMswXZRejx7C1vgG34wPtqmLtZ8fPXlCvODnx1oVdJBeS7tUZPlxT1H6JV8VY+TRXr6HG9Cofc 9WfXyeeGcTUzfJBomJdg==; Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pavGy-0007ns-KQ; Sat, 11 Mar 2023 04:12:16 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailauth.nyi.internal (Postfix) with ESMTP id 0191A27C0054; Sat, 11 Mar 2023 04:12:15 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 11 Mar 2023 04:12:16 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdduledguddviecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpehffgfhvfevufffjgfkgggtsehttdertddtredtnecuhfhrohhmpefvrghs shhilhhoucfjohhrnhcuoehtshguhhesghhnuhdrohhrgheqnecuggftrfgrthhtvghrnh epudejtdehuddvleffjeekteegvdehleehvdeufefhueekkeekhedvgfeggeffvefgnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepthhhohhrnh domhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqkeeijeefkeejkeegqdeifeeh vdelkedqthhsughhpeepghhnuhdrohhrghesfhgrshhtmhgrihhlrdhfmh X-ME-Proxy: Feedback-ID: ib2b94485:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 11 Mar 2023 04:12:15 -0500 (EST) In-reply-to: <87y1o486wo.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:142984 Archived-At: Michael Heerdegen writes: Hi Michael, >> However, when I do C-x b (switch-to-buffer), no matter what, recent >> files are not provided as completion candidates. But edebug >> convinces me that my function th/read-buffer-or-recentf is called. >> It just seems that the same completing-read call behaves differently >> when called directly and when being called by switch-to-buffer. Why >> is that and what can I do against it? > > Seems this happens because `read-buffer-to-switch' sets > `minibuffer-completion-table'. Ah, that's it! This code works: --8<---------------cut here---------------start------------->8--- (defun th/read-buffer-or-recentf (prompt &optional def require-match predicate) (let ((completion-table (completion-table-in-turn #'internal-complete-buffer (completion-table-dynamic (lambda (s) recentf-list))))) (minibuffer-with-setup-hook (:append (lambda () (setq-local minibuffer-completion-table completion-table))) (when-let ((result (completing-read prompt completion-table predicate require-match nil 'buffer-name-history def))) (cond ((get-buffer result) result) ((file-exists-p result) (buffer-name (find-file-noselect result))) (t result)))))) (setq read-buffer-function #'th/read-buffer-or-recentf) --8<---------------cut here---------------end--------------->8--- But why is that needed? I had expected that when I give a completion table to completing-read, it would be used... 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? Bye, Tassilo