Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-11-04 16:18]:
> On 2020-11-04 13:39, Jean Louis wrote:
> > https://gnu.support/images/2020/11/2020-11-04/2020-11-04-13:01:29.ogv
> 
> Hi. I'm really enjoying your video, and will need to watch it a few more
> times before I can get through it without laughing.

Please watch with laughing, you are welcom.

> The key sequences this time indicate that you are doing your best to
> avoid actually using diredc and are working hard to create
> complications for yourself. For example, you launch diredc, but then
> instead of using it you make a direct use of M-x dired.

No, that may be mistake, it was not at all my intention. It was only
to verify if I am on clean Emacs with my configurations and all
packages loaded would it block again on the console. That was main
purpose. I maybe get stuck with completion functions and you maybe see
dired... but not my intention. I did not want to move files, rename or
do anything more than TAB and ' for shell.

> Then you perform C-x 3 to make it look to you like you might be in
> diredc (you aren't).

When I have got one window, I had to split it before trying out if TAB
will work in that one, split window, right? 

> And it continues. I've watched the video a few times but have never
> gotten to the end yet, because I'm laughing too hard.

That is good...

> The usage instructions for diredc are pretty short, so try reading
> them.

I read them all line by line, but not that I wish to invoke it. In
general I can make review of your package and play little with it. Not
that I wish to play with my files. I hope you get the point.

Same with other dired improving packages.

> That's what they're for, and if they're unclear I'll be happy to edit
> them for clarity and simplicity. If you did read them once, it's obvious
> that either they weren't clearly written or you weren't paying
> attention.

Come on, no. By my review you could see that I went through all
commentary in the package. I did not want to use anything.

Instead you put attention on how I don't put attention, you could make
diredc-mod-map actually working.

> The video shows that you eventually figured out that after performing
> M-x package-install-from-buffer, you need to take the extra step of
> loading the library (you didn't want to follow my simpler instructions
> to just evaluate the buffer, but that's cool; emacs is all about
> choices).

Of course I know what you wrote, of course I know how to evaluate
buffers, etc. But you improved the package since I told you last time
that it does not install? Right? So you changed the space and then I
have been testing new improvement to show it is installing. Isn't that
nice? 

> The intention is for the users to perform M-x diredc (it should be bound
> to S-<F11>) to launch it, *and* to use the same command to toggle into
> and out of the diredc frame.

That is clear, I know that. When package-initialize finishes, if you
have some autoload functions, M-x diredc will start the functions and
load whatever.

> A design goal of the package is to avoid accumulating more than two
> dired buffers, and to keep an orderly dired configuration.

I understand this principle. It really pushes into Midnight Commander
direction. Not that I need that. I do not count or put attention how
many buffers I have. Often hundreds and hundreds of buffers.

Usuall I am handling in a week sometimes 5000+ file processing
functions through Emacs, like video processing by using
`dired-do-async-shell-command', preparing thousands of images for
multiple websites within Website Revision System, optimizing images
for the website page speedups, describing images and videos straight
within Emacs to later automatically include such into website
pages. Video processing is tedious so I distribute processing to other
computers in network that in turn process them without my attention or
my computer getting too hot. Like for Dired I am very much familiar
with it. But how many buffers are there, I don't put attention on
it. I remember I was doing that somewhere 1999 when I was surprised
that buffers are opening and I confused myself, I was thinking is it
good or bad and started always killing them or making sure of
it. Today I only do {C-x s} and that is all. 

> There should never be a need to call dired itself directly; When you
> want to use dired, perform S-<F11> to enter diredc.

Main point was not keybindings. But that it does not block in console.

For key bindings make the {C-h m} work first.

Jean