Re: Friendlier dired experience [CODE INCLUDED]

[Arthur Miller]

Boruch Baum <boruch_baum@gmx.com> writes:

> On 2020-11-05 13:54, Arthur Miller wrote:
>> How do you do bookmarks? I just bookmarked a folder with your shortcut
>> C-c b a; and the bookmark does not show in bookmarks list.
>
> diredc-bookmark-* doesn't share the generic emacs bookmark list.
It means you are reinventing the infrastructure that is already in place
and debugged. Also all other Emacs eco system would need to be rewritten
to work with your package, such as Helm (or other completers).

> The
> consideration was not mix directory locations with locations within
> files.
Is saveplace not good enough? :-) Sorry.


>> furthermore, when I use C-c b j; it seems to show some byte code, you
>> can see it in the attached screenshot.
>
> I can't reproduce that. Your screenshot seems to indicate you were using
> helm-something; is that correct? If so: 1) what helm set-up and command
> (I don't use helm); 2) what happens when you don't use helm; 3) what
> were you bookmarking.
I use Helm as a completer, I have just used your shortcut: C-c b j, I
don't know what you are doing undercover, so I don't know how Helm got
called in this case.

>> Another quick impression: opening new frame in the bacgkround is not
>> really the best feel. It didn't got neither raised nor focused.
>
> Oops. Fixed, but before I push the commit, I have a question: As a
> generic setting, should I have the dired frame start out maximized or
> with some other specific orientation?
I don't like it in new frame at all, but that is your package and your
judgement.

Personally I don't like the predefined workflow because it is not
always the case it is the best thing to do. Sometimes I prefer two
panes, sometimes I don't. It is maybe better to create some "configuration
restore" mechanism, maybe based on the new tab mode as mentioned in my
previous mail. Just let us serialize the state of windows to the disk
and re-open it on demand. Thus I could create my own layout inclusive
with buffers and save it as "workspace" to be used with diredc. Thus
two-pane workspace could be "bookmarked" with some specific locations
on hard drive. Three-pane workspace could be bookmarked for some other
use-case etc.

>                                     At issue is that I'm not a GUI
> emacs user, so all my development and testing has been done for emacs
> -nw. I've just now tested the code with GUI emacs and reproduced the
> issue, but I see that neither my default GUI emacs frame nor my initial
> diredc frame start maximized and I have no idea what a normal GUI user's
> expectation is.
No idea either; I think it is very subjective. You should probably start
testing with GUI Emacs if you plan to make diredc a general file manager
based on Dired.

>> Also my original frame got resized and centered on the screen, and
>> diredc took place of the original frame (but in background and not focused).
>
> That I'm not reproducing, but the pending commit may fix it anyway. You
> know, the change is trivial, so you might want to just manually make the
> change. Line 2201 goes from:
>         (make-frame-command)
> to
>         (select-frame (make-frame-command))
> I'm just being stingy on commits and also sneak in whatever other frame
> config is necessary / desirable, (eg. maximize).
>
>> The dual pane wasn't so resilient; at least not to Gnus (nothing is
>> :-)).
>
> *I'm* certainly not resilient to gnus. Never ever have I gotten it to
> work.
>
>> After switching to Gnus and back I was left with a single window.
>
> Question #1: How did you 'switch' back and forth? Did you use S-F11?
> What other method(s)?
C-x C-b (bound to helm-buffers-list) then I picked diredc buffer from
the list. S-F11 just switches between two different frames: one opened
by diredc and the original one I had before starting diredc.

> You mean diredc-recover? I'll presume yes.

> Once diredc is started, it respects a user's desire if it thinks the
> user insists on a custom window configuration for the diredc frame. The
> way to restore the default is to use diredc-recover (I suppose you could
> also perform diredc-quit followed by diredc again, but that's so 20th
> century).
Yes; sorry, I forgott the name in the moment when I was writing the
response. S-F11 does not seem to do it's thing, but diredc-recover seems
to do it. If you say it is the only way, than it works as intended :-).

>> Documentation says they are useful dired values - but in which way are they
>> useful? Do I really need to export a shortcut to a README file if I am 
>> already
>> using Emacs? Am I supposed to open current file from the shell in new
>> Eamcs instance
>
> No, of course not.
>
>> or what was the intended workflow?
>
> You want to perform some generic set of shell operations relating to one
> or both directories displayed. The possibilities and opportunities
> really are endless, but for starters: You may find yourself comparing
> two directories and want to tar three files from one and five files from
> another into a single tar at a third location (not as unusual as it may
> sound at first). You mark the files in each dired buffer, open a shell,
> and use the $t1 and $t2 shell variables on your tar command line. As a
> second theoretical, maybe you want to perform a paste (unix command-line
> paste, not MSwin concept) of files from two directories - select them
> and use $f1 $f2. etc. etc. and so forth.
Why would you drop into shell for that? Do it from dired directly :-).

Ok, might be useful for some scenario. I don't have something in mind
atm, but there can be some probably.