From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Mathias Dahl Newsgroups: gmane.emacs.devel Subject: Re: Friendlier dired experience [CODE INCLUDED] Date: Mon, 9 Nov 2020 23:45:26 +0100 Message-ID: References: <20201103104340.q34kqfita55w2u7h@E15-2016.optimum.net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003e1dc505b3b452aa" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5819"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs-Devel List To: Boruch Baum Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Nov 09 23:47:04 2020 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 1kcFwF-0001JA-BF for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Nov 2020 23:47:03 +0100 Original-Received: from localhost ([::1]:55266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcFwC-0001LK-DN for ged-emacs-devel@m.gmane-mx.org; Mon, 09 Nov 2020 17:47:01 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50742) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcFux-0000qO-Dg for emacs-devel@gnu.org; Mon, 09 Nov 2020 17:45:43 -0500 Original-Received: from mail-vk1-xa34.google.com ([2607:f8b0:4864:20::a34]:47030) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kcFuu-0006z7-SR for emacs-devel@gnu.org; Mon, 09 Nov 2020 17:45:43 -0500 Original-Received: by mail-vk1-xa34.google.com with SMTP id d191so2267175vka.13 for ; Mon, 09 Nov 2020 14:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y08t+wCvkFMo/sbp09/TN7YXWm0TB8fEIGdbWW55Rr8=; b=O0Ymaa/RpX/Ru/vQAnmLK+mhA7EwCWCqO8dg4qh3Ca8l0ukMtWoaNYKv7lp+l5bDx7 IH6b6UsvdHt1t5KapFDTrEZa3A4qRmjRo1FlTR8im/rTxkz5LioiiN/NZORUA8xNc2EG pRaSQJoJWJXrsP+xt1mt+zP5q+qGdl5+kSY5IxQesLmchrooa3xavQa6iTTIM1Ndlgjc 7DV3SSq5v7RivZJL0s5nKclzT1RdSMlXi6prC5E+zoMkfunXXTe2wks3OaBFEeh9oT1n KeRrT/vWVzJogdbOCjJjl6IJskmf0WTM+h+JqFbwJSIPVVV7csMT/n1cXQtmAt3EtDf3 8I0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y08t+wCvkFMo/sbp09/TN7YXWm0TB8fEIGdbWW55Rr8=; b=oqLwWaUZSYEcRrivUV9e6s3PbxOSvbY58KrTfGc3568ei6zSWOClRV+iC1Zv5cOX7A s+P8JuQF6L1z1CoxR66mBHaOlrvK+gmYQdDvlGXXtawlm4YAOvMRCzaEsZWJ6gObEEf4 CoUPW9zQyiC6EL6G8piJ5VITTekpxX8Wv4UJcpAiKXiQhS89P44NTFmKlIzCUL7Xnydn rXhebBiHjWzaFM2uStyzMKILFqXxSReFnb/Jly35h2/Fc/6OXPiGWglaSDiJAD7MH5lk zpHbr6slEgjzGMyEtvWnmFhGG9Lcl84C2CQGaHVuELWla6fD43ouggdl9C/zPc6u77UM EfqQ== X-Gm-Message-State: AOAM531RkQ4QAsP9xITAnTloN0D5/EyQIwpUIaPHjZ6rbgR+FhJGFB5V nna7NnhtgtKwF4GLeZUC4SfIoLLaPT7apvgeFBY= X-Google-Smtp-Source: ABdhPJxqmTMAIKKtog0js73fEisRuVQ4F+mfPQhwZ5w85PWIwyGSXGmcE6Rzbu1ZM/DQB/aP9ot5Y3pgCLe2ikOOj7s= X-Received: by 2002:ac5:cd58:: with SMTP id n24mr6199029vkm.17.1604961938839; Mon, 09 Nov 2020 14:45:38 -0800 (PST) In-Reply-To: <20201103104340.q34kqfita55w2u7h@E15-2016.optimum.net> Received-SPF: pass client-ip=2607:f8b0:4864:20::a34; envelope-from=mathias.dahl@gmail.com; helo=mail-vk1-xa34.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:258958 Archived-At: --0000000000003e1dc505b3b452aa Content-Type: text/plain; charset="UTF-8" Hi, Thanks for sharing this! Since I'm a die-hard Dired fan I wanted to see what's all the fuzz is about and tried this. I did not try it very much but I read most of the commentary and some of the comments in the source code. A general comment is that, should we try to incorporate this into Emacs, I think it would be better to try to incorporate individual features such that they become part of Dired and Emacs in general. The way I see things, this package is... packaging together useful extensions to Dired. I think, by adding the various features, users could quite easily put together the same thing, more or less, without bringing in the whole package itself. I can see how one can end up with a package like this since I did it myself with "Tumme" (now "Image Dired") many years ago (Any Day Now I will have a look at it again and see how it can be enhanced now that we have better/different image handling built-in). And, by the way, I have not looked much at other packages that extend Dired, like dired+. I do use features from dired-x and perhaps dired-aux too. With that said, I have some comments on a couple of the features that I tried. I did not think very long before writing this, so take it for what it is. Tab-key switching Navigating back and forth using the Tab key is convenient. For me, personally, since I already have a dedicated key (f2) for switching to the next window, it's only slightly better because the key is slightly easier to press. I will consider binding Tab in my own Dired setup :) Shell integration I like this idea and I remember having liked this feature when running Norton Commander hundreds of years ago. I like the idea to be able to access different file names from the two Dired buffers using those environment variables. It's a limitation however that the values are only set (right?) when you go from the diredc buffers to the shell again, using the special command. It would be super cool if the shell just "knew", without diredc needing to set those things explicitly. Could Emacs' different shells and terminals have this ability automatically by using some pre-processing of each command invocation, looking for open Dired windows in the same frame? I could see this being very useful as a normal part of Emacs/Dired/Shell/Terminal and even in Comint (different "REPLs" might benefit from being able to pull in file names from Dired buffers open in the same frame). Multiple panel views Did not try this much but is surely useful depending on what you want to see at any given moment. I often use the "s" binding to sort differently, for example, so I see that different viewing modes are nice to have. File quick-preview mode This was nice, especially the "quick view" following along when I change between files in the main diredc buffer. For sure something good to bring in if we wanted. Directory history I liked the parts of this that I tried. I especially liked the "fast" keys to go back and forth in the directory history. I can see that as very useful. Now, depending on what other buffer switching mechanism you are using, this might be very helpful or not more helpful than current setups. Bookmarks Did not try them but like others, I felt it might be better to integrate with the normal bookmark functionality in some way. A command that simply filters out the existing bookmarks that point to directories should not be hard to add to Dired, or simply make part of selecting a directory regardless of where you are in Emacs. Resilient dedicated dual-pane frame I liked this and I used the default keybinding (S-f11). I also felt we could make the same thing or something very similar using Winner, the new tab functionality, or some of the other ways we can work with window configurations. I get that a lot of work has been put into making this, as the author says, resilient, and I don't want to down-play that. Navigate 'up' n parent directories I have bound backspace to dired-up-directory so I have a quite convenient way to quickly step up N directories. Not the exact same thing of course and I can see how this is useful together with the directory history. Things I did not try (much) - Trash management. I feel that the standard behavior is enough for me, by changing a few settings. Some of the features sound like they could be good additions to Emacs in general. - Edit dired buffers. Well, this is not anything new at all, just a useful thing available in diredc ad well as in normal Dired. - Set both panels to same directory. Did not try this much or think about when it is useful but I guess quickly "syncing" the two panes, then being able to drill down, or go back in either of them would be the main use. Yeah, so... In summary, I think it's a nice package with several useful features. I would personally like each feature brought in on its own merits, so to speak, and try to incorporate them into normal Dired and Emacs features, and try to make it as easy as possible to put together a similar package using standard configuration features. Thanks! /Mathias On Tue, Nov 3, 2020 at 11:49 AM Boruch Baum wrote: > I've just published an elisp package that extends and configures > dired-mode with features that many people have come to take for granted > in other programming languages. For the source code and the detailed > description, see: http://github.com/Boruch-Baum/emacs-diredc > > If the project is interested in it, I can assign the copyright. > > -- > hkp://keys.gnupg.net > CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0 > > --0000000000003e1dc505b3b452aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for sharing this!
=
Since I'm a die-hard Dired fan I wanted to see what'= s all the fuzz is about and tried this. I did not try it very much but I re= ad most of the commentary and some of the comments in the source code.=C2= =A0

A general comment is that, should we try to in= corporate this into Emacs, I think it would be better to try to incorporate= individual features such that they become part of Dired and Emacs in gener= al. The way I see things, this package is... packaging together useful exte= nsions to Dired. I think, by adding the various features, users could quite= easily put together the same thing, more or less, without bringing in the = whole package itself.

I can see how one can end up= with a package like this since I did it myself=C2=A0with "Tumme"= (now "Image Dired") many years ago (Any Day Now I will have a lo= ok at it again and see how it can be enhanced now that we have better/diffe= rent image handling built-in).

And, by the way, I = have not looked much at other packages that extend Dired, like dired+. I do= use features from=C2=A0dired-x and perhaps dired-aux too.

With that said, I have some comments on a couple of the features t= hat I tried. I did not think very long before writing this, so take it for = what it is.

Tab-key switching

=
Navigating back and forth using the Tab key is convenient. For me, per= sonally, since I already have a dedicated key (f2) for switching to the nex= t window, it's only slightly better because the key is slightly easier = to press. I will consider binding Tab in my own Dired setup :)
Shell integration

I like this idea an= d I remember having liked this feature when running Norton Commander hundre= ds of years ago. I like the idea to be able to access different file names = from the two Dired buffers using those environment variables. It's a li= mitation however that the values are only set (right?) when you go from the= diredc buffers to the shell again, using the special command. It would be = super cool if the shell just "knew", without diredc needing to se= t those things explicitly. Could Emacs' different shells and terminals = have this ability automatically by using some pre-processing of each comman= d invocation, looking for open Dired windows in the same frame? I could see= this being very useful as a normal part of Emacs/Dired/Shell/Terminal and = even in Comint (different "REPLs" might benefit from being able t= o pull in file names from Dired buffers open in the same frame).
=
Multiple panel views

Did not tr= y this much but is surely useful depending on what you want to see at any g= iven moment. I often use the "s" binding to sort differently, for= example, so I see that different viewing modes are nice to have.

File quick-preview mode

This w= as nice, especially the "quick view" following along when I chang= e between files in the main diredc buffer. For sure something good to bring= in if we wanted.

Directory history

=
I liked the parts of this that I tried. I especially liked the &= quot;fast" keys to go back and forth in the directory history. I can s= ee that as very useful. Now, depending on what other buffer switching mecha= nism you are using, this might be very helpful or not more helpful than cur= rent setups.

Bookmarks

Di= d not try them but like others, I felt it might be better to integrate with= the normal bookmark functionality in some way. A command that simply filte= rs out the existing bookmarks that point to directories should not be hard = to add to Dired, or simply make part of selecting a directory regardless of= where you are in Emacs.

Resilient dedicated dual-= pane frame

I liked this and I used the default= keybinding (S-f11). I also felt we could make the same thing or something = very similar using Winner, the new tab functionality, or some of the other = ways we can work with window configurations. I get that a lot of work has b= een put into making this, as the author says, resilient, and I don't wa= nt to down-play that.

Navigate 'up' n pare= nt directories

I have bound backspace to dired= -up-directory=C2=A0so I have a quite convenient way to quickly step up N di= rectories. Not the exact same thing of course and I can see how this is use= ful together with the directory history.

Things I = did not try (much)

- Trash management. I feel that= the standard behavior is enough for me, by changing a few settings. Some o= f the features sound like they could be good additions to Emacs in general.=

- Edit dired buffers. Well, this is not anything = new at all, just a useful thing available in diredc ad well as in normal Di= red.

- Set both panels to same directory. Did = not try this much or think about when it is useful but I guess quickly &quo= t;syncing" the two panes, then being able to drill down, or go back in= either of them would be the main use.

Yeah, s= o... In summary, I think it's a nice package with several useful featur= es. I would personally like each feature brought in on its own merits, so t= o speak, and try to incorporate them into normal Dired and Emacs features, = and try to make it as easy as possible to put together a similar package us= ing standard configuration features.

Thanks!
=

/Mathias

On Tue, Nov 3, 2020 at 11:49 A= M Boruch Baum <boruch_baum@gmx.co= m> wrote:
I've just published an elisp package that extends and configures
dired-mode with features that many people have come to take for granted
in other programming languages. For the source code and the detailed
description, see: http://github.com/Boruch-Baum/emacs-dire= dc

If the project is interested in it, I can assign the copyright.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1=C2=A0 7286 0036 9E45 1595 8BC0

--0000000000003e1dc505b3b452aa--