From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Q: Is there a built-in way to read multiple file names? Date: Sun, 07 Jul 2024 20:56:11 +0300 Message-ID: <86ikxh13yc.fsf@gnu.org> References: <875xthfyz3.fsf@localhost> <87a5it6vr6.fsf@localhost> <86r0c5196r.fsf@gnu.org> <877cdx6ryu.fsf@localhost> <86o77914sh.fsf@gnu.org> <874j916qlv.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25432"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mardani29@yahoo.es, emacs-devel@gnu.org To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 07 19:56:47 2024 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 1sQW7z-0006OO-NQ for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Jul 2024 19:56:47 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQW7U-0007GW-AQ; Sun, 07 Jul 2024 13:56:16 -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 1sQW7S-0007EZ-GM for emacs-devel@gnu.org; Sun, 07 Jul 2024 13:56:14 -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 1sQW7R-0004KG-PF; Sun, 07 Jul 2024 13:56:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ucs8tBuWSca2n0TjZZ4eaMgBOUa12YdlijjYtXl4kAU=; b=dbAHwNpA0Lpe 6lbKxyT9iX9mV7AhrGERRljq+2lrapkdSdjBEGVMB8CGJVZ+oXRBkQFZjtGnGPB/5veyOTLJudK4C RqxYyQZYbhhZdMyIN0LlZ1MiLhYabJG+79teFdh7OKUlI7mQ9/t5QNamQEdepwoq/3i8+tkuyysVE oVORd3F4ZOwd5aJz4awJW7tpXhLE4GhHEp917W6L4VBfNwZLEURCqyu5MjCO0PqOSeZwvZklGFACZ r3CeFqJp49kPZxlQq2hBHDPIIiTgtE6MaPk8OuK00REmGAtVOnlNHL1rEVzSBa9F4wI5B1/m0XepL EtysFEEqoJRasuZJeTh6Cw==; In-Reply-To: <874j916qlv.fsf@localhost> (message from Ihor Radchenko on Sun, 07 Jul 2024 17:47:56 +0000) 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:321512 Archived-At: > From: Ihor Radchenko > Cc: mardani29@yahoo.es, emacs-devel@gnu.org > Date: Sun, 07 Jul 2024 17:47:56 +0000 > > Eli Zaretskii writes: > > > We have Ibuffer and Dired (and other similar features), which > > functions that return lists of marked entities. That is what needs > > to be used for multiple selections, not some loop over read-file-name > > and its ilk. > > My concern about dired and similar is that it is not possible to exit > them and go back to the original place as easily as C-g in the > completion prompt. Interactive narrowing is also not as easy as in the > completion. I didn't mean Dired as use it for browsing a directory. I meant a UI for selecting multiple files that reuses Dired, and lets users exit it with "C-c C-c" or somesuch. IOW, my intent was to point out the features to generalize and extend in order to have what you want. (For buffers, I think Ibuffer already offers an almost complete solution.) > >> I wish that *completions* buffer allowed selecting multiple candidates > >> at once when using `completing-read-multiple' or similar commands. > > > > I think completion is the wrong framework for this purpose, because > > the user might want to select files/buffers/whatever whose names don't > > share anything in common. > > IMHO, helm proves that completion framework can be used for very quick > selection. It does it via: > > 1. The notion of "current" candidate from the list that can be navigated > right from the minibuffer (like next/previous-completion in the > *completions*) > 2. minibuffer command to mark/unmark candidates quickly > 3. ability to retain marked candidates even the prompt input changes > > I find it quick and convenient to use, despite being a completion > framework. > > I also do not see why the same cannot be done based on the basis of > completion-list-mode. The display parts might be suitable for selection, but the entire completion machinery behind this makes absolutely no sense for the purpose of selection based on attributes that are not names or collection of strings.