Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On Wed, 04 Nov 2020 16:32:19 +0100, Joost Kremers wrote:
> Perhaps your presentation is confusing. When I read your original message and
> the README.md, I got the impression that diredc is an extension of dired, 
> which
> implies that you can do everything you're used to in dired in the same way 
> it's
> done in dired, and that diredc adds new functionality.
>
> However, the way you describe it now it sounds more like diredc is 
> essentially a
> different file manager that just happens to use dired under the hood. In that
> case, it would help to present it that way, so that a user knows they have to
> forget their dired habits.

I see your point, but I can't bring myself to go so far as to describe it as
"a different file manager that just happens to use dired under the hood".
Mostly, the habits that I see needing to be suspended are more 'emacs habits
around using dired' than those of using dired itself'. For example, in
Jean-Louis's case, he fell back on his habits of calling dired directly and
of managing windows and buffers externally to diredc. So I think your
initial impression was correct that "you can do everything you're used to
*in* [my emphasis added] dired in the same way it's done in dired". Clearly,
if people are getting confused, clarification is called for. Can you point
to any 'dired' habit that the package asks be changed?

> If it's the former, it might be a good idea to consider whether you need
> an extra command, or whether calling `M-x dired` would automatically
> activate the extra functionality.

I don't want to deny the user from any specific case in which they want to
intentionally call dired. Maybe they intentionally want a third dired buffer
for some reason, like a three-way directory sync?

> If it's the latter, perhaps a name that doesn't include `dired` would make
> sense?

Once a keybinding exists, then the command name isn't so important, is it? I
chose S-F11 as the because it seemed available, but that could be changed.

> Of course it's possible that you think of diredc one way, while someone else
> sees it another way. Doesn't make things easier, of course...

Honestly, I *was* expecting some push-back from developers related to that,
but what I was expecting was insistence that dired was never meant to be a
"file manager", but rather strictly a "file editor" and that I was trying to
make it something it wasn't designed to be.

> Mind you, I hardly ever use dired (I occasionally do some bulk renaming with 
> it,
> but otherwise I do most of my file managing in a shell)

Then you're exactly the audience I'm targeting: emacs users who find
themselves always leaving emacs in order to perform file management
operations that they could at least as easily perform within emacs if only
dired were a bit more convenient.

> > 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).
>
> An autoload cookie on `diredc` might solve that. (At least, I assume that
> installing a package from a buffer will install the autoload cookies in it...)

Thanks (also to Stefan Monnier). I just pushed the commit, adding the
following lines:

--8<--cut here-(start)------------------------------------------- >8
;;;###autoload (global-set-key (kbd "S-<f11>") 'diredc)
;;;###autoload
--8<--cut here-(end)--------------------------------------------- >8

Anyone having problems recently using magit/forge? I'm finding it
impossible to perform operations. magit/forge is suddenly no longer
recognizing my auth tokens and respecting my sshagent settings...

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