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: Tue, 23 Jul 2024 15:05:32 +0300 Message-ID: <8634o09uur.fsf@gnu.org> References: <875xthfyz3.fsf@localhost> <87a5it6vr6.fsf@localhost> <86r0c5196r.fsf@gnu.org> <877cdx6ryu.fsf@localhost> <86o77914sh.fsf@gnu.org> <874j916qlv.fsf@localhost> <86ikxh13yc.fsf@gnu.org> <87zfqlpfty.fsf@localhost> <86jzhpjt4x.fsf@gnu.org> <87r0bxpecj.fsf@localhost> <86ikx9jrh4.fsf@gnu.org> <87frscjhhm.fsf@localhost> <8634ocjeze.fsf@gnu.org> <87r0buij3j.fsf@localhost> <86frsaihom.fsf@gnu.org> <878qy2igat.fsf@localhost> <86cyndire5.fsf@gnu.org> <87v80wxsxo.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34387"; 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 Tue Jul 23 14:07:08 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 1sWEIN-0008og-T7 for ged-emacs-devel@m.gmane-mx.org; Tue, 23 Jul 2024 14:07:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sWEHS-0004QS-7G; Tue, 23 Jul 2024 08:06:10 -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 1sWEHM-00046B-GO for emacs-devel@gnu.org; Tue, 23 Jul 2024 08:06:04 -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 1sWEHK-0001Ul-80; Tue, 23 Jul 2024 08:06:02 -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=hR9CEBCm6iDNyvLe6Yh0jsdzYVF6fmpp6Y7t8XMSoX4=; b=loAd2HrRaOgc JsSK8617cJe6G7klSA38sHX+7YJR4yJ3OzYVmrQMhidnR/KdoTR984nkMffK9MuJyzD/YxvDYp4qC 5uv0Sgl97Zim7xVUIRsiWG399T2EhR38wo/UnarNlaWGxq1Cte9JoC665vzqVSOobX9jo4Enhhfux XoH6GwWeAyBLWNMxnR1W03Z7RkFtSZ/KIC2TMzFt4H1rm3+hEVBuwbzQvEtCmTREs4zIRrgMD9Opr 90jMiU4+RQTjd9G35a3PAFpTMGLOkA+DtCMvFOK0teK2HqivPuV9i14HgG3dnXIhIgjD7NUQxgZT5 7Xp0W3B48ystZ0iz+WeAQA==; In-Reply-To: <87v80wxsxo.fsf@localhost> (message from Ihor Radchenko on Tue, 23 Jul 2024 11:13:07 +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:321981 Archived-At: > From: Ihor Radchenko > Cc: mardani29@yahoo.es, emacs-devel@gnu.org > Date: Tue, 23 Jul 2024 11:13:07 +0000 > > Eli Zaretskii writes: > > >> How to unmark after you go to a different directory? > > > > The same way you mark them? Or maybe I don't understand what > > difficulties you have in mind. > > Imagine that a user marks two files: > 1. /home/user/1/2/3/4/5/file1 > 2. /home/user/5/4/3/2/1/file2 > > During step (2), dired will display <...>/5/4/3/2/1/ directory. > > Now, imagine that file1 needs to be unmarked. To do it, the user will > have to go up all the way to /home/user and descent down to 1/2/3/4/5 - > very awkward. And even more awkward if the user does not remember the > full path for file1. It isn't any more awkward than the way forward, from /home/user/1/2/3/4/5/file1 to /home/user/5/4/3/2/1/file2. If you want to help such use case, my suggestion is to show the list of selected items in a separate window. > >> 'i' works poorly when the directories contain many files - you get way > >> too long list of files, potentially with duplicate names, that is a > >> nighmare to search through. Even with regexps. > > > > How is this different from a directory that has a lot of files to > > begin with? Searching in an Emacs buffer is hardly a problem. At the > > very least, it's way more convenient than searching a typical GUI > > file-selection dialog, at least IME. > > The most important difference is that "i" may create duplicate file > names, which never happens when there is a single directory. Then, > searching cannot help much to narrow down to the desired file name. > > Also, there will always be more files in multiple directories compared > to single directory (on average). So, users will have to search through > longer file lists. If we insist on digging out problems, however rare and improbable, we will never do anything at all. I don't see how the minor issues you mention justify an idiosyncratic solution specific to Emacs. Have we learned nothing from our long history? Idiosyncratic solutions could be justified when there was no "prior art" because Emacs was a pioneering application, but this is not that case, far from it. > > Selecting files from a Dired-like list is non unusual. Both Emacs > > users and users who come from other GUI applications will feel right > > at home. > > >> As since we cannot use dired as is (AFAIU), > > > > We can't? why not? > > IMHO, dired as it does not provide a good way to _show_ which files are > selected without having to scroll through the whole file listing. I cannot disagree more. You are rejecting a good solution with which Emacs users, both veteran and newbies, are familiar enough, for no good reason. > >> Also, I am not sure if it is that much unusual - I replicated my dired > >> look in the above. With > >> https://github.com/Fuco1/dired-hacks?tab=readme-ov-file#filter-groups, > >> it is how dired UI looks like. Example: > > > > You miss my point. The unusual part is that the selected files are > > shown at the beginning of the buffer instead of being left in their > > original places with an indication that they were selected. > > Sorry, I was not clear. I did not mean that marked files will be removed > from the main file listing. I meant that marked files will be displayed > on top _in addition_ to being marked in the normal listing. This is to > see an overview of all the selected files together, without having to > scroll through all the directory files (marked + unmarked). If you want to show a list of selected files, show them in a separate window, but leave the original Dired-style list of the files intact. > >> > Because it is unusual and idiosyncratic. By contrast, what I describe > >> > exists in many selection dialogs, and so will be familiar. > >> > >> Yes, it is. Idiosyncratic for Emacs. Just like isearch. > >> I really see no reason to _not_ allow flexibility we already have in > >> Emacs and instead trying to mimic the limitations idiosyncatic to > >> Windows/Mac. > > > > What limitations are those? > > No option to use custom `completion-styles'. First, that could be added without changing the UI and UX. And second, how did we get to completion again? this is about selection of multiple files, not about completion. > >> Maybe it is good enough? Especially since we may not want to shadow > >> existing single-letter bindings in dired. > > > > If that is the problem (but I don't see why, since most of those > > bindings are to dired-do-SOMETHING, which are not relevant for > > selecting files) > > I mostly referred to "m" (mark) and "u" (unmark) bindings. They are relevant. Those commands could be bound to non-character keys, at least as an option. Once again, we should first make the overall design decisions, and only after that talk about minor details like key bindings.