Friendlier dired experience [CODE INCLUDED]

Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

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

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-11-03 13:45]:
> 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.

I would test it.

For some reason I cannot M-x package-install-from-buffer

Error:
package-read-from-string: Can’t read whole string

-- 
There are 43 messages yet in my incoming mailbox.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-03 13:54, Jean Louis wrote:
> * Boruch Baum <boruch_baum@gmx.com> [2020-11-03 13:45]:
> > 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.
>
> I would test it.
>
> For some reason I cannot M-x package-install-from-buffer

Thanks. The instructions say to evaluate the buffer. Does that work?

> Error:
> package-read-from-string: Can’t read whole string

I can't reproduce this in emacs 26.1, but I do get the error in
emacs-snapshot. I don't have emacs 27, which may be what most users in
the field will be using. What version were you using?

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

Re: Friendlier dired experience [CODE INCLUDED]

[Joost Kremers]

On Tue, Nov 03 2020, Boruch Baum wrote:
> On 2020-11-03 13:54, Jean Louis wrote:
>> Error:
>> package-read-from-string: Can’t read whole string
>
> I can't reproduce this in emacs 26.1, but I do get the error in
> emacs-snapshot. I don't have emacs 27, which may be what most users in
> the field will be using. What version were you using?

It barfs at the "Package-Requires" header, because it doesn't stop reading at
EOL. It works fine if you add an empty line (possibly commented, but otherwise
empty) right after "Package-Requires".

(Note: `M-x toggle-debug-on-error` comes in handy in such cases. :-) )

-- 
Joost Kremers
Life has its moments

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-03 12:32, Joost Kremers wrote:
> It barfs at the "Package-Requires" header,
> ...

Got it, but thanks!

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

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-11-03 14:15]:
> On 2020-11-03 13:54, Jean Louis wrote:
> > * Boruch Baum <boruch_baum@gmx.com> [2020-11-03 13:45]:
> > > 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.
> >
> > I would test it.
> >
> > For some reason I cannot M-x package-install-from-buffer
> 
> Thanks. The instructions say to evaluate the buffer. Does that work?

It works, but it does not give me safety feeling.

It broke my console, I could not see nothing any more, could not
escape from Emacs. On X it is creating new frame.

- test it on console
- test it in EXWM

> > Error:
> > package-read-from-string: Can’t read whole string
> 
> I can't reproduce this in emacs 26.1, but I do get the error in
> emacs-snapshot. I don't have emacs 27, which may be what most users in
> the field will be using. What version were you using?

Like latest git from yesterday maybe. Sorry for that.


-- 
There are 43 messages yet in my incoming mailbox.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-03 19:07, Jean Louis wrote:
> It works, but it does not give me safety feeling.

I don't understand the comment. Are you saying that the package could /
should do something differently? Also, if you have an account on github,
you give feedback there or open issues there. Or you can just email me,
but dealing with a organized forge environment like github / gitlab
helps keep things organized.

> It broke my console.

Whoa. I use console emacs, and never encountered such a problem, so
that's serious. Can you please give details? I've been using this
package for months, and it's the product of accumulated piecemeal work
over years - all on console emacs. Please send me details to reproduce.

> I could not see nothing any more, could not escape from Emacs.

Please try to send details to reproduce.

> On X it is creating new frame.

That's the expected behavior - to have a dedicated emacs frame for two
dired panels and their associated temporary buffers (ie. shell buffers
and a quick-view buffer).

> - test it on console

My favorite.

> - test it in EXWM

Interesting. I've never used EXWM, so I'm interested in how that went.

> > I can't reproduce this in emacs 26.1, but I do get the error in
> > emacs-snapshot. I don't have emacs 27, which may be what most users in
> > the field will be using. What version were you using?
>
> Like latest git from yesterday maybe. Sorry for that.

Don't be. I want user feedback. You reported an error that I had missed
and I corrected it.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-11-03 20:13]:
> On 2020-11-03 19:07, Jean Louis wrote:
> > It works, but it does not give me safety feeling.
> 
> I don't understand the comment.

It never happened that I cannot install package from buffer or
file. At first sight it looks good inside. Maybe it is bug in Emacs or
maybe some wrong formatting in the package what I doubt.

Then I am, maybe wrongly, assuming that package was not tested if it
can be installed in that way. And then I am of course careful with
such package, I do not know what it brings on me. I hope you get
idea.

Neither M-x package-install-file works neither M-x
package-install-from-buffer

> Are you saying that the package could / should do something
> differently? Also, if you have an account on github, you give
> feedback there or open issues there.

Package may have good features for something and is not bad to discuss
here.

Sorry that I find personally Github appalling. I do report sometimes
bugs there and I interact by email or with website by using
LibreJS. I hope there is nothing wrong with email. Would Github not
have non-free Javascript, maybe I would vouch for it. There are so
many free software hosting providers like OS Trisquel, the fully free
OS endorsed by FSF, they offer hosting:
https://devel.trisquel.info/groups/trisquel 

> Or you can just email me, but dealing with a organized forge
> environment like github / gitlab helps keep things organized.

Gitlab is by principle different. Trisquel offers something like
Gitlab.

> > It broke my console.
> 
> Whoa. I use console emacs, and never encountered such a problem, so
> that's serious. Can you please give details?

I cannot give much of details. As it was not possible to do anything
unde XTerm (not real console).

Video is here:
https://gnu.support/images/tmp/2020-11-03-21:57:51.ogv

Of course it may be due to my settings. And I have used emacsclient. 

> I've been using this package for months, and it's the product of
> accumulated piecemeal work over years - all on console emacs. Please
> send me details to reproduce.

Now is maybe time that somebody tries it out. People use programs in
different manners, different outcomes are the result.

> Please try to send details to reproduce.
> 
> > On X it is creating new frame.
> 
> That's the expected behavior - to have a dedicated emacs frame for two
> dired panels and their associated temporary buffers (ie. shell buffers
> and a quick-view buffer).

As I did not need two frames so it is not pleasant. The classic dired
frame appears in front of diredc frame. Maybe on your side is
different. That is how is on my side. I am orderding diredc and I get
classic dired. What if I am in EXWM then maybe I would not even see
what happened.

> > - test it in EXWM
> 
> Interesting. I've never used EXWM, so I'm interested in how that
> went.

I just say to you to test it. If this would work better I would test
myself. 

Sometimes I do diredc and happens nothing. It just switches frames. No
fancy stuff.

Maybe I would need to restart Emacs to see it again, I cannot know. It
does not give me good feeling when M-x diredc does not work for second
or fifth or ninth time.

o - opens new frame but not file that I selected, very unexpected
behavior for me

Trash management I prefer being handled by expected built-in Emacs
behavior. I did not try yours.

shells - you may add common shells on
OpenBSD/FreeBSD/NetBSD/Minix/Dragonfly BSD systems.

{C-h m} did not give me any explanation of diredc-mode-map, for me
very unexpected, I was thinking it would be automatic.

getfacl - I do not have as command on my system Hyperbola
GNU/Linux-libre and I do not know what it is, so I cannot use "get
more file info"

C-c b a - to add bookmark, isn't it just same number of key strokes as
C-x r m ?

' - is good feature to launch shell quickly, I may adopt that. But I
get this:

export d1="~/Programming/emacs-lisp/others/" d2="" f1="~/Programming/emacs-lisp/others/diredc.el" f2="" t1="(/home/data1/protected/Programming/emacs-lisp/others/diredc.el)" t2="nil"

sh-4.4$ sh-4.4$ sh-4.4$

if that is expected, I do not know. It did not choose my shell from
/etc/passwd - it went straight into sh

C-x o - when switching from window to window is currently confusing me
as buffer disappears and I then see instead of opened file again the
diredc listing, then if I had shell on left side, I kill it, my right
side becomes some other buffer! Too many unexpected things happening.

diredc-mode - disabled in all buffers, but colors remain and is not
really disabled, it comes back. Then I see line movements in both
windows, left and right. I have global-hl-line-mode turned on. I can
see in other window the highlighted line but not on same line, imagine
how I feel, like on drugs.

normal dired does not work after diredc, error: let*: Wrong type
argument: consp,
"/home/data1/protected/Programming/emacs-lisp/others/"

q - does not work any more, Use \[diredc-exit] for diredc-exit, or M-x quit-window for the emacs primitive.

Let me restart...

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-03 22:31, Jean Louis wrote:
> * Boruch Baum <boruch_baum@gmx.com> [2020-11-03 20:13]:
> > On 2020-11-03 19:07, Jean Louis wrote:
> > > It works, but it does not give me safety feeling.
> >
> > I don't understand the comment.
>
> It never happened that I cannot install package from buffer or
> file. At first sight it looks good inside. Maybe it is bug in Emacs or
> maybe some wrong formatting in the package what I doubt.

Oh, that. Like Joost Kremers mentioned earlier today, and like I posted
earlier, that issue is solved by adding a single blank line to the
header. Here's what I wrote earlier:

--8<--cut here-(start)------------------------------------------- >8
;; Package-Requires: ((emacs "26.1"))
;;   (emacs "24.1") for: split-window-right, window-normalize-frame

Should be:

;; Package-Requires: ((emacs "26.1"))
;;
;;   (emacs "24.1") for: split-window-right, window-normalize-frame
--8<--cut here-(end)--------------------------------------------- >8

Once you make that change, you can install the package in the way you
are accustomed. That change was uploaded to github hours ago, when I
posted the original fix.

> Sorry that I find personally Github appalling.
> ...
> I hope there is nothing wrong with email.

Any way you prefer.

> Would Github not have non-free Javascript, maybe I would vouch for it.

You can use github without javascript, directly from emacs, to report
issues. The packages for that are: magit and forge. Maybe also ghub?

> > > It broke my console.
> >
> > Whoa. I use console emacs, and never encountered such a problem, so
> > that's serious. Can you please give details?
>
> I cannot give much of details. As it was not possible to do anything
> unde XTerm (not real console).
>
> Video is here:
> https://gnu.support/images/tmp/2020-11-03-21:57:51.ogv

I've downloaded an played the video several times at slow speed, but
can't figure out what keys you're pressing and what is going on.

1] There exists a debian package called 'screenkey' which you can use in
   conjunction with screencasts. Any time you press a key, the program
   display that key as part of your screencast. Other similar packages
   probably exist for other operating systems.

2] Can you describe the steps you took before your 'console broke'?

3] Your video shows you recovered. How did you do that?

4] I'm not familiar with EXWM. Is that the starting point of the video?

> And I have used emacsclient.

Shouldn't be an issue. I always use emacsclient, and tested the package
from both a standalone emacs and a server/client instance.

> > > On X it is creating new frame.
> >
> > That's the expected behavior - to have a dedicated emacs frame for two
> > dired panels and their associated temporary buffers (ie. shell buffers
> > and a quick-view buffer).
>
> As I did not need two frames so it is not pleasant. The classic dired
> frame appears in front of diredc frame.

I didn't see that in your video. Your video shows a buffer labeled
*scratch* in a frame labeled F6.

> Trash management I prefer being handled by expected built-in Emacs
> behavior. I did not try yours.

Mine does many more things than the built-in. See the documentation.

> getfacl - I do not have as command on my system Hyperbola
> GNU/Linux-libre and I do not know what it is, so I cannot use "get
> more file info"

You can change the list for metadata commands available on your system
(it's a defcustom: diredc-show-more-file-info-list). Let me know details
and I can figure out how to include them. What do you get when you
perform "M-: system-type"?

> C-c b a - to add bookmark, isn't it just same number of key strokes as
> C-x r m ?

Yes. The differences include the persistence of the bookmark over emacs
sessions and the ability to use the defcustom interface to manage the
bookmark list.

> ' - is good feature to launch shell quickly, I may adopt that. But I
> get this:
>
> export d1="~/Programming/emacs-lisp/others/" d2="" f1="~/Programming/emacs-lisp/others/diredc.el" f2="" t1="(/home/data1/protected/Programming/emacs-lisp/others/diredc.el)" t2="nil"

Yes. It is expected. It is giving you several useful dired-related data
in shell variables. See the documentation.

> if that is expected, I do not know. It did not choose my shell from
> /etc/passwd - it went straight into sh

It uses the default as set in defcustom variable `diredc-shell-default'.

> C-x o - when switching from window to window is currently confusing me

You didn't read any of the documentation, did you? The navigation
between buffers is using <TAB>. That said, C-x o should work fine. I
can't reproduce a problem with it. Please send more details.

> as buffer disappears and I then see instead of opened file again the
> diredc listing, then if I had shell on left side, I kill it, my right
> side becomes some other buffer! Too many unexpected things happening.

And I don't understand. Probably good idea for another screencast, if
you want. Consider using the screenkey program or similar so viewers can
see what it is you're doing.

> diredc-mode - disabled in all buffers, but colors remain and is not
> really disabled, it comes back.

Then you probably didn't turn it off or exit it. I would need some more
details in order to reproduce your scenario.

> Then I see line movements in both windows, left and right.

That means you have two windows showing the same dired or diredc buffer.

> I have global-hl-line-mode turned on. I can see in other window the
> highlighted line but not on same line

Not on same line as what? POINT?

> normal dired does not work after diredc, error: let*: Wrong type
> argument: consp,
> "/home/data1/protected/Programming/emacs-lisp/others/"

Again, without details I don't know where to start. In this case, can
you provide a backtrace?

> q - does not work any more, Use \[diredc-exit] for diredc-exit, or M-x quit-window for the emacs primitive.

Yes. That is expected behavior. On the one hand, we want to prevent
people from making a mess if what they are trying to do is exit diredc;
on the other hand, we want to give them the option of performing
quit-window and making a mess if they insist. diredc-exit performs an
elegant and complete clean-up, while quit-window just closes a window
and leave behind the buffer to come back to haunt you. What is a bug is
that the actual keybinding wasn't being displayed. I just now pushed a
commit to fix that. You can make the change manually by altering line
2077 from:

  (message "Use \\[diredc-exit] for diredc-exit, or M-x quit-window for the emacs primitive."))

to

  (message "Use %s for diredc-exit, or M-x quit-window for the emacs primitive."
    (key-description (where-is-internal 'diredc-exit diredc-mode-map t))))


Keep in mind that one of your options is "M-x diredc-recover", which
restores your buffer and window configuration if you unintentionally or
intention mess it up.

So. A lot of feedback, which is good. If you can provide more details for
the items of trouble you're reporting, I can try to address them.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-11-04 00:13]:
> > Video is here:
> > https://gnu.support/images/tmp/2020-11-03-21:57:51.ogv
> 
> I've downloaded an played the video several times at slow speed, but
> can't figure out what keys you're pressing and what is going on.

I could not do anything, C-g, C-x k, nothing. So I just closed
XTerm. I did not recover in XTerm, I went to X frame of Emacs.

> 4] I'm not familiar with EXWM. Is that the starting point of the
> video?

No, I did not use Emacs X Window Manager that time.

> I didn't see that in your video. Your video shows a buffer labeled
> *scratch* in a frame labeled F6.

Yes, it looks like something happened that dired output was inserted
into *scratch*

> > getfacl - I do not have as command on my system Hyperbola
> > GNU/Linux-libre and I do not know what it is, so I cannot use "get
> > more file info"
> 
> You can change the list for metadata commands available on your system
> (it's a defcustom: diredc-show-more-file-info-list). Let me know details
> and I can figure out how to include them. What do you get when you
> perform "M-: system-type"?

gnu/linux

> Yes. The differences include the persistence of the bookmark over emacs
> sessions and the ability to use the defcustom interface to manage the
> bookmark list.

But bookmarks anyway persist. I think I am asked to save it.

> It uses the default as set in defcustom variable
> `diredc-shell-default'.

While this may appear fine to many, and may not work on other OS-es, I
do expect that my preferred shell in /etc/passwd is read by whatever
other terminals and Emacs as well if I do not put any special
customization. This way I get:

- that I have chosen preferred shell in /etc/passwd or by using chsh

- that Emacs chooses eventually other shell in its terminals or M-x
  shell

- that new packages chooses other shell

Maybe preferred shell is "first shell" but I consider /etc/passwd some
basic information about user as it is readable by programs. It should
be used.

> > C-x o - when switching from window to window is currently confusing me
> 
> You didn't read any of the documentation, did you? The navigation
> between buffers is using <TAB>. That said, C-x o should work fine. I
> can't reproduce a problem with it. Please send more details.

I was reading documentation and went through it. Some keys I have
tried myself like C-x o.

> > diredc-mode - disabled in all buffers, but colors remain and is not
> > really disabled, it comes back.
> 
> Then you probably didn't turn it off or exit it. I would need some more
> details in order to reproduce your scenario.

I am very fast in Dired and handling thousands of files, like today
maybe 5500 files for websites. The one good function in diredc is
opening of shell in the window. So I will try to duplicate it on my
side. Beside that I will not need the package.

I see you get surprised when I tell you how it comes up on my side. I
know Midnight Commander and I have used it and still using it from
time to time. Diredc did not give me feeling of mc.

> > normal dired does not work after diredc, error: let*: Wrong type
> > argument: consp,
> > "/home/data1/protected/Programming/emacs-lisp/others/"
> 
> Again, without details I don't know where to start. In this case, can
> you provide a backtrace?

I choose to skip for now, maybe in some weeks I will try again if that
package get updates.


-- 
There are 44 messages yet in my incoming mailbox.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-04 11:10, Jean Louis wrote:
> * Boruch Baum <boruch_baum@gmx.com> [2020-11-04 00:13]:
> > > Video is here:
> > > https://gnu.support/images/tmp/2020-11-03-21:57:51.ogv
> >
> > I've downloaded an played the video several times at slow speed, but
> > can't figure out what keys you're pressing and what is going on.
>
> I could not do anything, C-g, C-x k, nothing. So I just closed
> XTerm. I did not recover in XTerm, I went to X frame of Emacs.

But you were using emacsclient, correct? If so, then closing an Xterm
won't kill the server (that's kind-of one of the main points of using
the server/client setup).

> > 4] I'm not familiar with EXWM. Is that the starting point of the
> > video?
>
> No, I did not use Emacs X Window Manager that time.

Then what was the window environment displayed at the beginning of the
video? You just said above that you went back to the X frame of emacs,
so you were in some kind of X window manager...

> > I didn't see that in your video. Your video shows a buffer labeled
> > *scratch* in a frame labeled F6.
>
> Yes, it looks like something happened that dired output was inserted
> into *scratch*

So many wild and crazy un-reproducible symptoms...

If you want to try again, let's start by seeing what happens when you
run M-x diredc-recover and diredc-quit as your FIRST steps. Then start
diredc.

> ...

> I choose to skip for now, maybe in some weeks I will try again if that
> package get updates.

OK, then. I'll consider your point about picking up a default shell from
/etc/passwd. I don't like depending upon that file being readable to
just any user, but the possibility could be taken into account.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-11-04 11:54]:
> But you were using emacsclient, correct? If so, then closing an Xterm
> won't kill the server (that's kind-of one of the main points of using
> the server/client setup).

Yes, it did not close server. But it blocked any usage on XTerm.

> Then what was the window environment displayed at the beginning of the
> video? You just said above that you went back to the X frame of emacs,
> so you were in some kind of X window manager...

That is IceWM.

> OK, then. I'll consider your point about picking up a default shell from
> /etc/passwd. I don't like depending upon that file being readable to
> just any user, but the possibility could be taken into account.

It is traditionally called /etc/passwd but does not contain any
passwords. It is basic information of users you know it. It can
contain even "room number" or website, email, phone, anything.

I do not think Emacs looks into /etc/passwd but then again if you are
opening the shell you should look into what was set in Emacs as
default.

OK let me try again.

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

Hello Boruch,

This time I started with Emacs without doing my usual stuff.

I did not check it, only I think you are invoking bash that does not
read my .bashrc while M-x shell, does read it. So I got different
prompt instead of my prompt.

You would need to review those compiler warnings as for example
{M-x diredc-mode-map RET} is mentioned there and cannot be found.

First thing I usually do is looing into are keybindings explained with
the {C-h m} and of course I can look into the source. My review is
from viewpoint of users, not from my personal view point.

https://gnu.support/images/2020/11/2020-11-04/2020-11-04-13:01:29.ogv

{M-x diredc RET} worked well as I used only TAB as you can see, nothing
much. I would not like using it for operations as it is not
refined.

Apparently {M-x diredc-recover} (recover what?!) removed all diredc
buffers and I finished video. Then I moved to left workspace and found
one dangling diredc buffer, so I killed it. It did not remove
everything.

My notation with curly brackets { } is handy to be activated by using
M-x RET within GNU Hyperbole package.

During writing of this email I have invoked {M-x diredc RET} again and
I could see this email frame going to front and diredc buffer
appearing below the frame buffer. For me that is not handy, as if I
wish or need something, I need it in front of me, not behind papers.

Colors are not visible and do not help me. What is directory and what
is not I get with the {C-h v RET dired-listing-switches RET} being
set to: -gohl --group-directories-first so I can ee directories anyway
in some colors, being listed first. On BSD systems this does not work.

My settings is with: (windmove-default-keybindings 'super) so I am
anyway switching way easier then just {C-x o} in dired buffer, I click
Super key and arrow to which direction I wish to move. I got surprised
that Dired does not use TAB key for at least something useful. Like
you have made it to switch to other window, or to maybe switch both
windows.

I can say it is +1 for TAB switching and quick shell opening. This
gives me ideas for key bindings.

For those other features... nothing to say yet.

Jean

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

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. 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. Then you perform C-x 3 to make it look to you
like you might be in diredc (you aren't). 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.

The usage instructions for diredc are pretty short, so try reading them.
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.

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).

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. A design goal of the package is to avoid
accumulating more than two dired buffers, and to keep an orderly dired
configuration. There should never be a need to call dired itself
directly; When you want to use dired, perform S-<F11> to enter diredc.
The default keybinding '/' will take you anywhere (and will push the
location on the panel's history stack so you can quick navigate back).
"C-u /" pops up a history list for the selected pane and, well I'm just
re-writing the documentation now, aren't I...

When I make it through the video, I'll continue and respond to the rest
of your e-mail.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Joost Kremers]

On Wed, Nov 04 2020, Boruch Baum wrote:
> The usage instructions for diredc are pretty short, so try reading them.
> 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.

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.

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. If it's the latter, perhaps a name that doesn't include `dired`
would make sense?

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...

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), so take my comments
with a big bag of salt.

> 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...)



-- 
Joost Kremers
Life has its moments

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Monnier]

> An autoload cookie on `diredc` might solve that.

Indeed.

> (At least, I assume that
> installing a package from a buffer will install the autoload cookies in it...)

It does,


        Stefan

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Joost Kremers <joostkremers@fastmail.fm> [2020-11-04 18:39]:
> 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), so take my comments
> with a big bag of salt.

While not on subject:

Interesting for me to hear that. But I can understand it. Before I
always used Midnight Commander for file management and still use it on
systems without Emacs. Under graphics I sometimes use Rox file manager
and others from desktop like Caja, etc. And also shell. But when it
comes to quick entering into directories, reviewing images, I have to
invoke package sxiv and various others to be very fast. Sometimes I
have to choose images and send quickly to other people. I think for 15
years I did not use Dired and for 5 years I cannot without it.

Very hand options `dired-dwim-target' renames or copies marked files
into other window.

Within {M-x shell} I am often using `ed' editor to handle
configurations including on remote servers. This may sound strange but
is sometimes faster option to change few lines then invoking Emacs
through Tramp to edit the file.

I like to hear various experiences, thanks.

Jean

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

Re: Friendlier dired experience [CODE INCLUDED]

[Eli Zaretskii]

> Date: Wed, 4 Nov 2020 03:54:25 -0500
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: Emacs-Devel List <emacs-devel@gnu.org>
> 
> I'll consider your point about picking up a default shell from
> /etc/passwd.

Please don't, at least not literally: that's not portable enough for
use to use it.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-03 13:54, Jean Louis wrote:
> For some reason I cannot M-x package-install-from-buffer
>
> Error:
> package-read-from-string: Can’t read whole string

Fixed. The lines

;; Package-Requires: ((emacs "26.1"))
;;   (emacs "24.1") for: split-window-right, window-normalize-frame

Should be:

;; Package-Requires: ((emacs "26.1"))
;;
;;   (emacs "24.1") for: split-window-right, window-normalize-frame


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

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Kangas]

Boruch Baum <boruch_baum@gmx.com> writes:

> 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.

One item that stands out (to me) from the feature list is:

    * Trash management

    per xfreedesktop standard
    restore trashed files to their original locations
    empty the trash, along with its administrative overhead
    view trash summary information

Perhaps something like this would be useful to add directly to dired.el
and/or files.el?  I'm not sure what is currently missing (and I don't
use a trash folder myself), so I cannot say.

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-11-03 18:34]:
> Boruch Baum <boruch_baum@gmx.com> writes:
> 
> > 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.
> 
> One item that stands out (to me) from the feature list is:
> 
>     * Trash management
> 
>     per xfreedesktop standard
>     restore trashed files to their original locations
>     empty the trash, along with its administrative overhead
>     view trash summary information
> 
> Perhaps something like this would be useful to add directly to dired.el
> and/or files.el?  I'm not sure what is currently missing (and I don't
> use a trash folder myself), so I cannot say.

I use trash folder as to prevent some mistakes when deleting
stuff. This package should support the built-in features and not
deviate, though I do not know if it deviates in relation to trashing.

Inspect veriable delete-by-moving-to-trash

move-file-to-trash is an interactive compiled Lisp function in
‘files.el’.

(move-file-to-trash FILENAME)

  Probably introduced at or before Emacs version 23.2.

Move the file (or directory) named FILENAME to the trash.
When ‘delete-by-moving-to-trash’ is non-nil, this function is
called by ‘delete-file’ and ‘delete-directory’ instead of
deleting files outright.

If the function ‘system-move-file-to-trash’ is defined, call it
 with FILENAME as an argument.
Otherwise, if ‘trash-directory’ is non-nil, move FILENAME to that
 directory.
Otherwise, trash FILENAME using the freedesktop.org conventions,
 like the GNOME, KDE and XFCE desktop environments.  Emacs moves
 files only to "home trash", ignoring per-volume trashcans.

-- 
There are 43 messages yet in my incoming mailbox.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-03 19:10, Jean Louis wrote:
> I use trash folder as to prevent some mistakes when deleting
> stuff. This package should support the built-in features and not
> deviate, though I do not know if it deviates in relation to trashing.

It's designed not to deviate. You can look at the source code to see
that it handles all cases.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Michael Albinus]

Boruch Baum <boruch_baum@gmx.com> writes:

Hi Boruch,

>> I use trash folder as to prevent some mistakes when deleting
>> stuff. This package should support the built-in features and not
>> deviate, though I do not know if it deviates in relation to trashing.
>
> It's designed not to deviate. You can look at the source code to see
> that it handles all cases.

Since recently, remote files are trashed to the local trash can. Are you
able to restore them, if the trash can is derived from XDG spec?

Test with recent master branch.

Best regards, Michael.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-03 18:59, Michael Albinus wrote:
> Since recently, remote files are trashed to the local trash can. Are you
> able to restore them, if the trash can is derived from XDG spec?

Oooh. Nice point. I never tested the software with tramp / smb / ssh.
What the software does is respect the XDG metadata stored in the
trash/info directory and performs a file move to the location identified
by that metadata. The software is agnostic to the location, so if emacs
requires any extra processing to reach the "remote", I don't know if the
operation would succeed. It's reasonable to expect the file move to be
handled at a 'level below' the dired function call and so succeed, but I
don't know.

> Test with recent master branch.

I'm not set up for that just now. Can you try and report back?

Also, since you mentioned the 'master branch'... I'm not a regular
lurker on this mailing list, so this may already have been discussed...
Is emacs planning on renaming its 'master branch' to something less
evocative of some 'master race'? You may have caught wind of the trend
to nudge society world-wide to a bit more sensitivity to historic
atrocities world-wide. Even github has recently gotten on-board and no
longer sets default branches to 'master branch'; they use 'main branch'
now. If it hasn't been discussed yet, let me know and I'll start a
dedicated thread with appropriate subject line.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-11-03 22:11]:
> Also, since you mentioned the 'master branch'... I'm not a regular
> lurker on this mailing list, so this may already have been discussed...
> Is emacs planning on renaming its 'master branch' to something less
> evocative of some 'master race'? You may have caught wind of the trend
> to nudge society world-wide to a bit more sensitivity to historic
> atrocities world-wide. Even github has recently gotten on-board and no
> longer sets default branches to 'master branch'; they use 'main branch'
> now. If it hasn't been discussed yet, let me know and I'll start a
> dedicated thread with appropriate subject line.

Where I am now in East Africa, it is difficult to find person who read
more than 3 books. My friend who lives here temporarily, she finished
literature in Uganda and she read 3 books in total. And she is fine
with me telling you this. There is nothing wrong with the word master
as it is not used in the context that those less educated people would
assume.

The Wordnet dictionary does not even mention the context you mentioned
here.

The word main is synonym to master. It accommodates those less
educated people and their sensitivies.

In that context it is not noun, rather adjective "master branch"

* Overview of noun master

The noun master has 10 senses (first 6 from tagged texts)
1. (8) maestro, master -- (an artist of consummate skill; "a master of the violin"; "one of the old masters")
2. (5) overlord, master, lord -- (a person who has general authority over others)
3. (1) victor, master, superior -- (a combatant who is able to defeat rivals)
4. (1) master -- (directs the work of others)
5. (1) headmaster, schoolmaster, master -- (presiding officer of a school)
6. (1) master, master copy, original -- (an original creation (i.e., an audio recording) from which copies can be made)
7. master, captain, sea captain, skipper -- (an officer who is licensed to command a merchant ship)
8. master -- (someone who holds a master's degree from academic institution)
9. master, professional -- (an authority qualified to teach apprentices)
10. passkey, passe-partout, master key, master -- (key that secures entrance everywhere)


So this is the proper context for "master branch".

* Overview of adj master

The adj master has 1 sense (no senses from tagged texts)
1. chief, main, primary, principal, master -- (most important element;
"the chief aim of living"; "the main doors were of solid glass"; "the
principal rivers of America"; "the principal example"; "policemen were
primary targets"; "the master bedroom"; "a master switch")

Less educated people will not know what is noun, adjective, verb, what
is present time, history and so on, they will ANYWAY mix everything
together.

* Overview of adj main

The adj main has 3 senses (first 1 from tagged texts)
1. (33) chief, main, primary, principal, master -- (most important element; "the chief aim of living"; "the main doors were of solid glass"; "the principal rivers of America"; "the principal example"; "policemen were primary targets"; "the master bedroom"; "a master switch")
2. independent, main -- ((of a clause) capable of standing syntactically alone as a complete sentence; "the main (or independent) clause in a complex sentence has at least a subject and a verb")
3. main -- (of force; of the greatest possible intensity; "by main strength")

Re: Friendlier dired experience [CODE INCLUDED]

[Pankaj Jangid]

Jean Louis <bugs@gnu.support> writes:

> * Boruch Baum <boruch_baum@gmx.com> [2020-11-03 22:11]:
>> Also, since you mentioned the 'master branch'... I'm not a regular
>> lurker on this mailing list, so this may already have been discussed...
>> Is emacs planning on renaming its 'master branch' to something less
>> evocative of some 'master race'? You may have caught wind of the trend
>> to nudge society world-wide to a bit more sensitivity to historic
>> atrocities world-wide. Even github has recently gotten on-board and no
>> longer sets default branches to 'master branch'; they use 'main branch'
>> now. If it hasn't been discussed yet, let me know and I'll start a
>> dedicated thread with appropriate subject line.
>
> Where I am now in East Africa, it is difficult to find person who read
> more than 3 books. My friend who lives here temporarily, she finished
> literature in Uganda and she read 3 books in total. And she is fine
> with me telling you this. There is nothing wrong with the word master
> as it is not used in the context that those less educated people would
> assume.
>
> The Wordnet dictionary does not even mention the context you mentioned
> here.
>
> The word main is synonym to master. It accommodates those less
> educated people and their sensitivies.
>
> In that context it is not noun, rather adjective "master branch"
>
> * Overview of noun master
>
> The noun master has 10 senses (first 6 from tagged texts)
> 1. (8) maestro, master -- (an artist of consummate skill; "a master of the violin"; "one of the old masters")
> 2. (5) overlord, master, lord -- (a person who has general authority over others)
> 3. (1) victor, master, superior -- (a combatant who is able to defeat rivals)
> 4. (1) master -- (directs the work of others)
> 5. (1) headmaster, schoolmaster, master -- (presiding officer of a school)
> 6. (1) master, master copy, original -- (an original creation (i.e., an audio recording) from which copies can be made)
> 7. master, captain, sea captain, skipper -- (an officer who is licensed to command a merchant ship)
> 8. master -- (someone who holds a master's degree from academic institution)
> 9. master, professional -- (an authority qualified to teach apprentices)
> 10. passkey, passe-partout, master key, master -- (key that secures entrance everywhere)
>
>
> So this is the proper context for "master branch".
>
> * Overview of adj master
>
> The adj master has 1 sense (no senses from tagged texts)
> 1. chief, main, primary, principal, master -- (most important element;
> "the chief aim of living"; "the main doors were of solid glass"; "the
> principal rivers of America"; "the principal example"; "policemen were
> primary targets"; "the master bedroom"; "a master switch")
>
> Less educated people will not know what is noun, adjective, verb, what
> is present time, history and so on, they will ANYWAY mix everything
> together.
>
> * Overview of adj main
>
> The adj main has 3 senses (first 1 from tagged texts)
> 1. (33) chief, main, primary, principal, master -- (most important
> element; "the chief aim of living"; "the main doors were of solid
> glass"; "the principal rivers of America"; "the principal example";
> "policemen were primary targets"; "the master bedroom"; "a master
> switch")
> 2. independent, main -- ((of a clause) capable of standing
> syntactically alone as a complete sentence; "the main (or independent)
> clause in a complex sentence has at least a subject and a verb")
> 3. main -- (of force; of the greatest possible intensity; "by main strength")

Loved this.... (+1000)

Re: Friendlier dired experience [CODE INCLUDED]

[Michael Albinus]

Boruch Baum <boruch_baum@gmx.com> writes:

Hi Boruch,

>> Since recently, remote files are trashed to the local trash can. Are you
>> able to restore them, if the trash can is derived from XDG spec?
>
> Oooh. Nice point. I never tested the software with tramp / smb / ssh.
> What the software does is respect the XDG metadata stored in the
> trash/info directory and performs a file move to the location identified
> by that metadata. The software is agnostic to the location, so if emacs
> requires any extra processing to reach the "remote", I don't know if the
> operation would succeed. It's reasonable to expect the file move to be
> handled at a 'level below' the dired function call and so succeed, but I
> don't know.
>
>> Test with recent master branch.
>
> I'm not set up for that just now. Can you try and report back?

When I'm working in a remote buffer, "diredc-trash-info" does not
work. This is because you call shell-command, which runs the command on
the remote host.

When I have trashed a file, say "/ssh:ford:/tmp/xxx", it appears as
"/home/albinus/.local/share/Trash/files/xxx", in the local trash can.
"/home/albinus/.local/share/Trash/info/xxx.trashinfo" contains the line

Path=/ssh%3aford%3a/tmp/xxx

as expected. However, "M-x diredc-trash-restore" returns with the error

dired-rename-file: Renaming: No such file or directory, /home/albinus/.local/share/Trash/files/xxx, /ssh%3aford%3a/tmp/xxx

I believe you must unhexlify the path in the .trashinfo. This is not
only because of Tramp. A local file "/tmp/file with space", trashed via
"M-x move-file-to-trash", has the entry

Path=/tmp/file%20with%20space

Calling "M-x diredc-trash-restore" restores it to "/tmp/file%20with%20space".

Best regards, Michael.

Re: Friendlier dired experience [CODE INCLUDED]

[Yuri Khan]

On Thu, 5 Nov 2020 at 03:02, Michael Albinus <michael.albinus@gmx.de> wrote:

> When I'm working in a remote buffer, "diredc-trash-info" does not
> work. This is because you call shell-command, which runs the command on
> the remote host.
>
> When I have trashed a file, say "/ssh:ford:/tmp/xxx", it appears as
> "/home/albinus/.local/share/Trash/files/xxx", in the local trash can.
> "/home/albinus/.local/share/Trash/info/xxx.trashinfo" contains the line
>
> Path=/ssh%3aford%3a/tmp/xxx
>
> as expected.

What do other file managers do when trashing a file from a network
file system into the home trash? The spec is unclear on the intended
path format in this case, although it mentions that trashing over the
network is possible.

It is unfortunate if Emacs puts remote file names in Tramp syntax but
all other file managers use, e.g., URL syntax.

Re: Friendlier dired experience [CODE INCLUDED]

[Michael Albinus]

Yuri Khan <yuri.v.khan@gmail.com> writes:

Hi Yuri,

>> When I have trashed a file, say "/ssh:ford:/tmp/xxx", it appears as
>> "/home/albinus/.local/share/Trash/files/xxx", in the local trash can.
>> "/home/albinus/.local/share/Trash/info/xxx.trashinfo" contains the line
>>
>> Path=/ssh%3aford%3a/tmp/xxx
>>
>> as expected.
>
> What do other file managers do when trashing a file from a network
> file system into the home trash? The spec is unclear on the intended
> path format in this case, although it mentions that trashing over the
> network is possible.

Locally, I have nautilus. It doesn't offer to trash remote files.

> It is unfortunate if Emacs puts remote file names in Tramp syntax but
> all other file managers use, e.g., URL syntax.

This could be changed in move-file-to-trash. Since trashing remote files
to the local trash is a pretty new feature of the master branch, we
don't need to think about backward compatibility.

Best regards, Michael.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-04 20:57, Michael Albinus wrote:
> When I'm working in a remote buffer, "diredc-trash-info" does not
> work. This is because you call shell-command, which runs the command on
> the remote host.
>
> When I have trashed a file, say "/ssh:ford:/tmp/xxx", it appears as
> "/home/albinus/.local/share/Trash/files/xxx", in the local trash can.
> "/home/albinus/.local/share/Trash/info/xxx.trashinfo" contains the line
>
> Path=/ssh%3aford%3a/tmp/xxx
>
> as expected. However, "M-x diredc-trash-restore" returns with the error
>
> dired-rename-file: Renaming: No such file or directory, /home/albinus/.local/share/Trash/files/xxx, /ssh%3aford%3a/tmp/xxx
>
> I believe you must unhexlify the path in the .trashinfo. This is not
> only because of Tramp. A local file "/tmp/file with space", trashed via
> "M-x move-file-to-trash", has the entry
>
> Path=/tmp/file%20with%20space
>
> Calling "M-x diredc-trash-restore" restores it to "/tmp/file%20with%20space".

I was surprised that this turned out so difficult for me to do. The very
simple case for 8-bit ascii was easily handled by unhexlifying, but that
simple case got me thinking about unicode file names. Sure enough, the
trash meta-data for such file names are also hex encoded, but the
standard elisp commands I could find wouldn't handle them. Have I
overlooked something? The following code snippet performs two alternate
techniques (url-unhex-string, stolen-from-emacs-w3m-url-decode-string)
first for a simple case of a file name with an embedded space, and then
on a unicode file name. Only the function shamelessly stolen from the
emacs-w3m package worked for both cases. Tell me I've overlooked
something, please.

(cl-flet
  ((stolen-from-emacs-w3m-url-decode-string (str &optional coding regexp)
     (or regexp (setq regexp "%\\(?:\\([0-9a-f][0-9a-f]\\)\\|0d%0a\\)"))
     (let ((start 0)
         (case-fold-search t))
       (with-temp-buffer
         (set-buffer-multibyte nil)
         (while (string-match regexp str start)
         (insert (substring str start (match-beginning 0))
         	(if (match-beginning 1)
         	    (string-to-number (match-string 1 str) 16)
         	  ?\n))
         (setq start (match-end 0)))
         (insert (substring str start))
         (decode-coding-string
          (buffer-string)
          (or (if (listp coding)
                (with-coding-priority coding
                  (car (detect-coding-region (point-min) (point-max))))
              coding)
              'iso-8859-1))))))
 (dolist (str '("hello%20world"
                "%d7%a9%d7%9c%d7%95%d7%9d%20%d7%a2%d7%95%d7%9c%d7%9d"))
   (insert (format "\n\nurl-unhex: %s\nw3m-url-decode: %s"
     (url-unhex-string str)
     (stolen-from-emacs-w3m-url-decode-string str)))))

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

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

On handling file names, I recommend this read:

Search for:

Programs assume bad filenames won’t happen

on:

https://dwheeler.com/essays/fixing-unix-linux-filenames.html

Some programs may make filenames in automatic manner, there is pretty
much freedom in filenames. For every program handling file names there
shall be a test with all possible situations.

Re: Friendlier dired experience [CODE INCLUDED]

[Eli Zaretskii]

> Date: Thu, 5 Nov 2020 03:54:40 -0500
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>, Jean Louis <bugs@gnu.support>,
>  Emacs-Devel List <emacs-devel@gnu.org>
> 
> > I believe you must unhexlify the path in the .trashinfo. This is not
> > only because of Tramp. A local file "/tmp/file with space", trashed via
> > "M-x move-file-to-trash", has the entry
> >
> > Path=/tmp/file%20with%20space
> >
> > Calling "M-x diredc-trash-restore" restores it to "/tmp/file%20with%20space".
> 
> I was surprised that this turned out so difficult for me to do. The very
> simple case for 8-bit ascii was easily handled by unhexlifying, but that
> simple case got me thinking about unicode file names. Sure enough, the
> trash meta-data for such file names are also hex encoded, but the
> standard elisp commands I could find wouldn't handle them. Have I
> overlooked something? The following code snippet performs two alternate
> techniques (url-unhex-string, stolen-from-emacs-w3m-url-decode-string)
> first for a simple case of a file name with an embedded space, and then
> on a unicode file name. Only the function shamelessly stolen from the
> emacs-w3m package worked for both cases. Tell me I've overlooked
> something, please.

I'm not sure I understand exactly what you are trying to do, so what I
suggest below may not make sense.  But if I did understand, then the
dance with temporary buffer shouldn't be required; the below should
work (and does work with your 2 examples, assuming your file names are
encoded in UTF-8):

  (decode-coding-string
     (url-unhex-string STRING)
     (or file-name-coding-system
         (default-value 'file-name-coding-system)))

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Kangas]

Boruch Baum <boruch_baum@gmx.com> writes:

> On 2020-11-03 19:10, Jean Louis wrote:
>> I use trash folder as to prevent some mistakes when deleting
>> stuff. This package should support the built-in features and not
>> deviate, though I do not know if it deviates in relation to trashing.
>
> It's designed not to deviate. You can look at the source code to see
> that it handles all cases.

But it seems to extend the functionality, right?

I don't know, but I don't think Emacs can currently:

 - restore trashed files to their original locations
 - empty the trash
 - view trash summary information

The only command I can find here is `move-file-to-trash'.

So why not add that stuff directly to Emacs?  It seems to me that it
would be useful.  Say we use the prefix `trash' to get: `trash-empty',
`trash-view-summary', `trash-restore' or something along those lines.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-04 11:28, Stefan Kangas wrote:
> But it seems to extend the functionality, right?

Yep, that's the point of the entire package.

> So why not add that stuff directly to Emacs?

Isn't that what I offered here[1]?

> It seems to me that it would be useful. Say we use the prefix `trash'
> to get: `trash-empty', `trash-view-summary', `trash-restore' or
> something along those lines.

It's GPL3 FOSS. You can do pretty-much with it what you want.

[1] https://lists.gnu.org/archive/html/emacs-devel/2020-11/msg00046.html

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

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Kangas]

Boruch Baum <boruch_baum@gmx.com> writes:

>> So why not add that stuff directly to Emacs?
>
> Isn't that what I offered here[1]?

If that's what you meant, then that is very good.  I'm sorry if I
didn't fully understand your intention.

>> It seems to me that it would be useful. Say we use the prefix `trash'
>> to get: `trash-empty', `trash-view-summary', `trash-restore' or
>> something along those lines.
>
> It's GPL3 FOSS. You can do pretty-much with it what you want.

Indeed.  As soon as it goes into GNU ELPA, anyone could in principle
merge the functionality into Emacs.

But I had hoped that you would be interested in writing the patches to
do this.  You seem well placed to do it, since you are likely to have
studied this recently and know the domain.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-05 07:00, Stefan Kangas wrote:
> Indeed.  As soon as it goes into GNU ELPA, anyone could in principle
> merge the functionality into Emacs.
>
> But I had hoped that you would be interested in writing the patches to
> do this.  You seem well placed to do it, since you are likely to have
> studied this recently and know the domain.

At this point it's all theoretical. The ELPA+merge idea was Stefan
Monnier's, but he admitted that he didn't have a notion what parts
should be merged and that he doesn't even use dired, so there doesn't
yet seem to be any beginning of a plan or roadmap or even agreed-upon
wish-list or actual user-base (though the package has started a lot of
discussion on this list, none of it had been expressions of enthusiasm
for actually using it). Outside the list, I've only otherwise mentioned
it on the emacs-w3m list, and the only positive feed-back I've received
is about eight people 'starring' the repository on github. I've no idea
how many people tried it and rejected it, or liked it but didn't 'star'
it.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Monnier]

> 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

AFAICT, this is a mix of:

- extensions to dired-mode itself (along the lines of what is done also
  in dired-x, and indeed partly building on dired-x).
- a layer on top of dired that provides a UI similar to that of
  midnight-commander (i.e. two dired buffers displayed on side-by-side
  windows and treated as "a unit").

I'm curious how the second aspect compares to other midnight-commander
clones in Emacs like the old `mc.el` and `sunrise-commander.el`.

How 'bout we add it to GNU ELPA and then we work on integrating some of
the code into Dired (i.e. the part that makes sense within Dired
itself)?


        Stefan

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-04 13:07, Stefan Monnier wrote:
> How 'bout we add it to GNU ELPA and then we work on integrating some of
> the code into Dired

I'm fine with integrating parts of it into dired, but I wouldn't want it
done in a way that breaks the stand-alone package. In other words, the
feature super-set (updated) copy from the github upstream should always
continue to work.

>  (i.e. the part that makes sense within Dired itself)?

What part do you have in mind?

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

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Monnier]

>> How 'bout we add it to GNU ELPA and then we work on integrating some of
>> the code into Dired
> I'm fine with integrating parts of it into dired, but I wouldn't want it
> done in a way that breaks the stand-alone package. In other words, the
> feature super-set (updated) copy from the github upstream should always
> continue to work.

Of course.  This said, in many/most cases, integration requires changes
which end up having some impact on the actual user-visible
functionality.  Whether they're considered as "breaking" or not is often
a question of point of view.

>>  (i.e. the part that makes sense within Dired itself)?
> What part do you have in mind?

I don't have any in mind: I use neither Dired nor anything like
midnight-commander (I do my file-management with zsh, and I don't even
do that within Emacs), so I'm not the best person to make such calls.

But clearly, some parts of diredc.el don't make sense within Dired
because they're specific to the dual-pane setup, whereas Dired is
a single-buffer mode, meant to be independent from window layout.


        Stefan

Re: Friendlier dired experience [CODE INCLUDED]

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> How 'bout we add it to GNU ELPA and then we work on integrating some of
>>> the code into Dired
>> I'm fine with integrating parts of it into dired, but I wouldn't want it
>> done in a way that breaks the stand-alone package. In other words, the
>> feature super-set (updated) copy from the github upstream should always
>> continue to work.
>
> Of course.  This said, in many/most cases, integration requires changes
> which end up having some impact on the actual user-visible
> functionality.  Whether they're considered as "breaking" or not is often
> a question of point of view.
>
>>>  (i.e. the part that makes sense within Dired itself)?
>> What part do you have in mind?
>
> I don't have any in mind: I use neither Dired nor anything like
> midnight-commander (I do my file-management with zsh, and I don't even
> do that within Emacs), so I'm not the best person to make such calls.
>
> But clearly, some parts of diredc.el don't make sense within Dired
> because they're specific to the dual-pane setup, whereas Dired is
> a single-buffer mode, meant to be independent from window layout.
>
>
>         Stefan
I use Emacs for almost all interaction with the computer, and I do
manage my files with Helm + Dired, so I am always interested to see
something new.

I have skimmed through diredc (readme + code) but I haven't tried it.
As far as I see, the only part I see worth putting directly in dired
is maybe as you pointed out trash management. I don't use Sunrise nor
any other `comander' Ranger clone; it is just not needed. I don't use
trash folder either for that matter, but I can see there is not much of
trash handling offered via Emacs, so maybe some users would prefer to
have such functionality.

Unfortunately for some features, as I read the diredc code; I would
probably be annoyed if they were in dired. Particularly if dired asked
yes/no if I really wish to bookmark a place and if I wish to start
diredc. If user bothered to press a 4-letter combination, then I think 
we can be sure the user wish to create that bookmark; it is really
unnecessary to ask if I am really sure :-). Just my opinion.

Extra colours for chmod: we have it already in Dired+, it looks like a
rainbow, really not very user friendly to give them each different
colour (sorry Drew).

History handling: can it not be handled by recentf/winner modes already?
I am not particulary against custom history handling, but recentf
already does it and winner has undo/redo stack maybe they can be reused?

Ther is a thing I would like to have in Dired, but I haven't got time
myself to look at it: utilisation of new Tab thing. Since tabs seem
to act more like workspaces I would like to see them serialized and
bookmarked so we could use them with Dired. However diredc seems to do
it's own thing instead of reusing the functionality of tabs.

Other functionality I would like to see is some from dired-hacks: toggle
and filters.

For me Helm does the most; dired is needed just sometimes, so it is nice
if we can keep it lightweight. That said it does not mean that Emacs (or
Elpa) can't include a file manager, I would just prefer to keep it
separate from Dired.

Just my opinion as a daily user of Emacs for file managment. I hope
that Boruch does not take it as personal critique, I don't mean it as
such. These are just my subjective opinions, so take them as such.  It
is nice you experiment and play with Dired and file management.

Best regards
/a

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-05 09:05, Arthur Miller wrote:
> I hope that Boruch does not take it as personal critique

Not at all. It was a good read; here's some feedback.

> I don't use Sunrise

My memory from looking at it years ago was that it was non-functioning
abandon-ware.

> Unfortunately for some features, as I read the diredc code; I would
> probably be annoyed if they were in dired. Particularly if dired asked
> yes/no if I really wish to bookmark a place and if I wish to start
> diredc. If user bothered to press a 4-letter combination, then I think
> we can be sure the user wish to create that bookmark; it is really
> unnecessary to ask if I am really sure :-). Just my opinion.

You read that snippet of code incorrectly. No such prompt.

> History handling: can it not be handled by recentf/winner modes already?

I've been a long-time happy user of winner, and found the answer to be
no. Winner operates on all windows of a frame, not just the current
dired buffer. Thus, if you had in your window configuration history
temporary quick-shell buffer-windows or quick-file-view buffer-windows,
they would pop in and out if you were using winner-undo to navigate
sequentially in your dired history. Also, does winner-mode have a
quick-jump to a specific history element?

> I am not particulary against custom history handling, but recentf
> already does it and winner has undo/redo stack maybe they can be reused?

When I had tried recentf years ago, I was disappointed that its only
interface was the ncurses menu. Is that still the case? In any event,
a recentf menu will include ALL recently visited items, so that list
will be a mixture of emacs files and dired buffers and who knows what
else; a user would need to visually filter out the path-names ending
with a file from those ending with a directory ...

> Other functionality I would like to see is some from dired-hacks: toggle
> and filters.

What do you mean by "toggles and filters"?

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

Re: Friendlier dired experience [CODE INCLUDED]

[Arthur Miller]

[-- Attachment #1: diredc-bookmark.png --]
[-- Type: image/png, Size: 35513 bytes --]

[-- Attachment #2: Type: text/plain, Size: 5049 bytes --]


Boruch Baum <boruch_baum@gmx.com> writes:

> On 2020-11-05 09:05, Arthur Miller wrote:
>> I hope that Boruch does not take it as personal critique
>
> Not at all. It was a good read; here's some feedback.
>
>> I don't use Sunrise
>
> My memory from looking at it years ago was that it was non-functioning
> abandon-ware.
No idea if it is abandon-ware; I don't use it; I used some year ago and it
was quite competent.

Looking at github, it seems like last commit was ~6 month ago:

https://github.com/sunrise-commander/sunrise-commander

>> Unfortunately for some features, as I read the diredc code; I would
>> probably be annoyed if they were in dired. Particularly if dired asked
>> yes/no if I really wish to bookmark a place and if I wish to start
>> diredc. If user bothered to press a 4-letter combination, then I think
>> we can be sure the user wish to create that bookmark; it is really
>> unnecessary to ask if I am really sure :-). Just my opinion.
>
> You read that snippet of code incorrectly. No such prompt.
Ok, sure I was just skimming and saw those yes/no questions. I have
downloaded and tested it now and her are few questions:

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. furthermore, when I use C-c b j; it seems to show some byte
code, you can see it in the attached screenshot.
Another quick impression: opening new frame in the bacgkround is not
really the best feel. It didn't got neither raised nor focused.

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).

The dual pane wasn't so resilient; at least not to Gnus (nothing is
:-)). After switching to Gnus and back I was left with a single window.
I am not sure if I understand the docs correctly: is it supposed to
restore window layout and buffers automatically or do I need to take an
action? It didn't happened automatically so I tried diredc-restore. I
was than ask a question to choose between starting a new or choosing two
panes or something else. I choose two-pane, but I wasn't left with same
buffers after it executed.

After I switched to the mail to continue writing it again switched to
just one window. When I switched back it was still just one window. I
then tried running again diredc (C-x 5 d); it just moved my cursor back
to old frame. Running again diredc moved cursor back to second frame but
it never switched back to dual pane nor to original buffers I had in
diredc. I am sure I am using it wrong, but I don't see in the
accompanying docs how to switch between buffers and go back to dual-pane
and original buffers.

In connection to this, looking at those predefined variables; I am not
sure I find it really useful; you can see below what diredc exported
when I run it for the first time:

export d1="~/repos/emacs-related/emacs-diredc/" d2="" f1="~/repos/emacs-related/emacs-diredc/README.md" f2="" t1="(/home/arthur/repos/emacs-related/emacs-diredc/README.md)" t2="nil"

sh-5.0$ sh-5.0$ sh-5.0$ 

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, or what was the intended workflow?

Sorry if I am obnoxious; these are just questions I was left with after
tryimg it.

Something positive:

I like your C-c C-k and '; I'll steal it for my own hack of term-toggle,
thanks! :-). I have eshell on F2 and term on F1, but ' was really nice;
I think I'll use it instead of F2.

>> History handling: can it not be handled by recentf/winner modes already?
>
> I've been a long-time happy user of winner, and found the answer to be
> no. Winner operates on all windows of a frame, not just the current
> dired buffer. Thus, if you had in your window configuration history
> temporary quick-shell buffer-windows or quick-file-view buffer-windows,
> they would pop in and out if you were using winner-undo to navigate
> sequentially in your dired history. Also, does winner-mode have a
> quick-jump to a specific history element?
>
>> I am not particulary against custom history handling, but recentf
>> already does it and winner has undo/redo stack maybe they can be reused?
>
> When I had tried recentf years ago, I was disappointed that its only
> interface was the ncurses menu. Is that still the case? In any event,
> a recentf menu will include ALL recently visited items, so that list
> will be a mixture of emacs files and dired buffers and who knows what
> else; a user would need to visually filter out the path-names ending
> with a file from those ending with a directory ...
We have Helm + fuzzy search to filter those out ...

>> Other functionality I would like to see is some from dired-hacks: toggle
>> and filters.
>
> What do you mean by "toggles and filters"?
https://github.com/Fuco1/dired-hacks#dired-subtree
https://github.com/Fuco1/dired-hacks#dired-filter

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-11-05 15:55]:

> 
> Boruch Baum <boruch_baum@gmx.com> writes:
> 
> > On 2020-11-05 09:05, Arthur Miller wrote:
> >> I hope that Boruch does not take it as personal critique
> >
> > Not at all. It was a good read; here's some feedback.
> >
> >> I don't use Sunrise
> >
> > My memory from looking at it years ago was that it was non-functioning
> > abandon-ware.
> No idea if it is abandon-ware; I don't use it; I used some year ago and it
> was quite competent.

Sunrise commander uses mnay built-in Emacs functions. Except of cl
deprecated library there are no compiler warnings. All features of
Sunrise Command immitate well Midnight Commander. Function keys are
well set for mc key bindings. M-y and M-u go back and forward in
history. It has good file name and marked file names expansions in
eshell or term how is expected for users of Midnight Commander. There
are good extensions as well. It is useful for users switching from
`mc' to Emacs somehow, or those who are used to type of proprietary
Norton Commander from non-free operating systems. It is already
history.

Well written software is not abandon ware for sole reason that does
not have many recent commits, in fact it could speak for the quality
of software.

I like that Emacs stuff is displayed on Emacs Wiki rather than
scattered all around Internet on non-free Github. Here it is:

https://www.emacswiki.org/emacs/Sunrise_Commander

> Looking at github, it seems like last commit was ~6 month ago:
> 
> https://github.com/sunrise-commander/sunrise-commander

Better one in 6 months than 50 in one week. Files are most important
for users and file manager extensions shall be very reliable.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

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. The
consideration was not mix directory locations with locations within
files. I know that emacs bookmarks works on directories and opens a
dired buffer for them, but it made no sense to me mix the two forms

> 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.

> 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? 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.

> 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)?

> I am not sure if I understand the docs correctly: is it supposed to
> restore window layout and buffers automatically

Yes. If you toggle in and out with M-x diredc, bound by default to S-F11.

> or do I need to take an action? It didn't happened automatically so I
> tried diredc-restore.

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

> I was than ask a question to choose between starting a new or choosing
> two panes or something else. I choose two-pane, but I wasn't left with
> same buffers after it executed.

That's strange and I'd like to be able to reproduce it. If you mean that
the result was that one or more of the dired buffers was unexpected,
that should never happen. If your emacs had a total of two dired buffers
open, they would be used. If your emacs had a total of more than two,
then you would have been prompted to choose. What may have happened was
that you had killed a dired buffer. In that case, diredc *would* try to
intelligently select one, either your $HOME or what it thinks is your
current emacs directory.

> After I switched to the mail to continue writing it again switched to
> just one window. When I switched back it was still just one window. I
> then tried running again diredc (C-x 5 d); it just moved my cursor back
> to old frame. Running again diredc moved cursor back to second frame but
> it never switched back to dual pane nor to original buffers I had in
> diredc.

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).

> I am sure I am using it wrong, but I don't see in the accompanying
> docs how to switch between buffers and go back to dual-pane and
> original buffers.

If when you wrote above diredc-restore, you meant diredc-recover, that
IS the correct way to return a window / buffer configuration that had
gotten corrupted. It should always give you a dual pane, and if two
dired buffers exist, they will be used. I'd like to be able to reproduce
your case, but it may just be that you didn't realize that you had
killed a dired buffer, and then didn't perform the recover.

> In connection to this, looking at those predefined variables; I am not
> sure I find it really useful;
> ...
> 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.

> Sorry if I am obnoxious; these are just questions I was left with after
> tryimg it.

You don't. But people often say I sound obnoxious, so maybe I'm the
wrong person to judge.

> >> Other functionality I would like to see is some from dired-hacks: toggle
> >> and filters.
> >
> > What do you mean by "toggles and filters"?
> https://github.com/Fuco1/dired-hacks#dired-subtree
> https://github.com/Fuco1/dired-hacks#dired-filter

I'll take a look. But later.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Monnier]

>> 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. The
> consideration was not mix directory locations with locations within
> files. I know that emacs bookmarks works on directories and opens a
> dired buffer for them, but it made no sense to me mix the two forms

Do you think it could make sense to keep diredc bookmarks in the normal
bookmarks by arranging for the normal "directory bookmarks" to be
"hijacked" by diredc (i.e. not to open a new dired buffer but to open
the dir within diredc) when called from diredc?

You'd still have the downside that the general bookmarks include all the
other non-directory bookmarks, so maybe it's not a good idea anyway.
[ I'm not using bookmarks very much, so my intuition here is poor.  ]


        Stefan

Re: Friendlier dired experience [CODE INCLUDED]

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> 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. The
>> consideration was not mix directory locations with locations within
>> files. I know that emacs bookmarks works on directories and opens a
>> dired buffer for them, but it made no sense to me mix the two forms
>
> Do you think it could make sense to keep diredc bookmarks in the normal
> bookmarks by arranging for the normal "directory bookmarks" to be
> "hijacked" by diredc (i.e. not to open a new dired buffer but to open
> the dir within diredc) when called from diredc?
>
> You'd still have the downside that the general bookmarks include all the
> other non-directory bookmarks, so maybe it's not a good idea anyway.
> [ I'm not using bookmarks very much, so my intuition here is poor.  ]
>
>
>         Stefan
Why would that be a downside?

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Monnier]

>> You'd still have the downside that the general bookmarks include all the
>> other non-directory bookmarks, so maybe it's not a good idea anyway.
>> [ I'm not using bookmarks very much, so my intuition here is poor.  ]
> Why would that be a downside?

That you can have name conflicts between the diredc and other bookmarks,
and that when selecting a diredc bookmark you'd have to see all those
other bookmarks which might make it more timeconsuming to find the
bookmark you're after.

For the first problem, I don't have a good solution.
For the second, I think this actually hints at a need for the generic
bookmark-selection functionality to offer a way to first select a *type*
of bookmark and only then pick a name among the remaining candidates.

[ And of course, in the absence of such generic support in bookmark.el,
  diredc could do it on its own by offer a command which pre-filters
  the list of bookmarks to only include those which refer to
  directories.  ]


        Stefan

Re: Friendlier dired experience [CODE INCLUDED]

[Adam Porter]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> You'd still have the downside that the general bookmarks include all the
>>> other non-directory bookmarks, so maybe it's not a good idea anyway.
>>> [ I'm not using bookmarks very much, so my intuition here is poor.  ]
>> Why would that be a downside?
>
> That you can have name conflicts between the diredc and other bookmarks,
> and that when selecting a diredc bookmark you'd have to see all those
> other bookmarks which might make it more timeconsuming to find the
> bookmark you're after.
>
> For the first problem, I don't have a good solution.
> For the second, I think this actually hints at a need for the generic
> bookmark-selection functionality to offer a way to first select a *type*
> of bookmark and only then pick a name among the remaining candidates.
>
> [ And of course, in the absence of such generic support in bookmark.el,
>   diredc could do it on its own by offer a command which pre-filters
>   the list of bookmarks to only include those which refer to
>   directories.  ]

Some recent work I've done in Burly[0] touches on this.

Because Burly uses its own bookmark handler function, it was easy to
write a command that offers only bookmarks created with Burly by
filtering them on the bookmark records' handler value.[1]

However, when I tried to write a bookmark-listing command to display
only Burly's bookmarks, it wasn't as easy to re-use existing
functionality.  I tried to re-use the list-bookmarks command by binding
bookmarks-alist to a filtered alist, and that worked.

The problem is that re-displaying the bookmarks list (e.g. after
deleting a bookmark) shows the non-filtered bookmarks list.  I then
experimented with using buffer-local function advice in the
list-bookmarks buffer to cause it to use the filtered bookmarks list
when re-displaying, but it didn't seem to work.  And even if it had, it
would have been very hacky, so it didn't seem like a good solution.

An idea I had was for the list-bookmarks command to use an optional
filter function to filter the bookmarks-alist before displaying them, so
the filter could persist after using commands to manipulate
bookmarks.[2] (Note that the global value of bookmarks-alist would
remain unchanged so that saving the bookmarks to disk still saves all
bookmarks, not just the filtered ones.)

Frankly, I wonder if list-bookmarks ought to be rewritten to use,
e.g. tabulated-list-mode instead of its bespoke code.  (Although I'm
guessing that would break much of Drew's Bookmarks+ library...)

0: https://github.com/alphapapa/burly.el
1: https://github.com/alphapapa/burly.el/blob/e2ab1b2526ce84ad7dd17bf37c0079785619bc8e/burly.el#L156
2: https://github.com/alphapapa/burly.el/issues/14#issuecomment-719803053

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Monnier]

> Frankly, I wonder if list-bookmarks ought to be rewritten to use,
> e.g. tabulated-list-mode instead of its bespoke code.  (Although I'm

commit 61e51fee9ca353c1cea4b68ef7225f374fee9839
Author: Stefan Kangas <stefan@marxist.se>
Date:   Sat Oct 17 17:56:44 2020 +0200

    Base bookmark-bmenu-mode on tabulated-list-mode (Bug#39293)


-- Stefan

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

>> Frankly, I wonder if list-bookmarks ought to be rewritten to use,
>> e.g. tabulated-list-mode instead of its bespoke code.  (Although I'm
>> guessing that would break much of Drew's Bookmarks+ library...)
> 
> commit 61e51fee9ca353c1cea4b68ef7225f374fee9839
> Author: Stefan Kangas <stefan@marxist.se>
> Date:   Sat Oct 17 17:56:44 2020 +0200
> 
> Base bookmark-bmenu-mode on tabulated-list-mode (Bug#39293)

Yes, too bad.

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

> However, when I tried to write a bookmark-listing command to display
> only Burly's bookmarks, it wasn't as easy to re-use existing
> functionality.  I tried to re-use the list-bookmarks command by binding
> bookmarks-alist to a filtered alist, and that worked.
> 
> The problem is that re-displaying the bookmarks list (e.g. after
> deleting a bookmark) shows the non-filtered bookmarks list.  I then
> experimented with using buffer-local function advice in the
> list-bookmarks buffer to cause it to use the filtered bookmarks list
> when re-displaying, but it didn't seem to work.  And even if it had, it
> would have been very hacky, so it didn't seem like a good solution.
> 
> An idea I had was for the list-bookmarks command to use an optional
> filter function to filter the bookmarks-alist before displaying them, so
> the filter could persist after using commands to manipulate
> bookmarks.[2] (Note that the global value of bookmarks-alist would
> remain unchanged so that saving the bookmarks to disk still saves all
> bookmarks, not just the filtered ones.)

This all already done, in Bookmark+.

You can filter in any number of ways.  And by
default the filtering (and other state of the
bookmark-list display) persist, until you
change it.

And you can even bookmark the bookmark-list
display state.  Jumping to such a bookmark
restores the display.

> Frankly, I wonder if list-bookmarks ought to be rewritten to use,
> e.g. tabulated-list-mode instead of its bespoke code.

Absolutely not.  Tabulated-List mode is IMO a
rudimentary, fragile, brute hammer.  It takes
over a complete buffer (you can't even add a
heading or a paragraph, outside the table).
It offers little, and prevents much.

Dired, bookmark-list display, and most other
seemingly tabular lists should stay away from it.
Such UIs can be quite sophisticated, offering a
_lot_ more than just tabular display with only
simplistic sorting.  Don't go by what you see
at first sight ("Oh, hey, there's a tabular
list here...").

> (Although I'm guessing that would break much
> of Drew's Bookmarks+ library...)

Yes.  Vanilla Emacs has apparently gone this
route recently, against my requests/advice.
As a result I'll no doubt have to include some
of the previous vanilla bookmark.el code in
Bookmark+.  Alas.  (On n'arrete pas le progres...)

Re: Friendlier dired experience [CODE INCLUDED]

[Arthur Miller]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> You'd still have the downside that the general bookmarks include all the
>>> other non-directory bookmarks, so maybe it's not a good idea anyway.
>>> [ I'm not using bookmarks very much, so my intuition here is poor.  ]
>> Why would that be a downside?
>
> That you can have name conflicts between the diredc and other bookmarks,
I don't know; usually we are asked to give a name for the bookmark so
user can choose a name that does not conflict. Otherwise some generic
enumeration, or prefix/suffix etc could be used; but I don't think it
would be needed if users is anyway giving it a name.

> and that when selecting a diredc bookmark you'd have to see all those
> other bookmarks which might make it more timeconsuming to find the
> bookmark you're after.
That is why we have completers like Helm. I never look at bookmarks. I
use Helm which completes them with a key or two. 
To be honest I don't use bookmarks much either; I have just few places
that would otherwise require me to navigate through path completion.

> For the first problem, I don't have a good solution.
We are asked for the bookmark name, so user choice?

> For the second, I think this actually hints at a need for the generic
> bookmark-selection functionality to offer a way to first select a *type*
> of bookmark and only then pick a name among the remaining candidates.
I think we already have that. Helm for example is one such.

> [ And of course, in the absence of such generic support in bookmark.el,
>   diredc could do it on its own by offer a command which pre-filters
>   the list of bookmarks to only include those which refer to
>   directories.  ]
Drew's Bookmark+ can bookmark pretty much anything. I never really found
use for it because I don't have such advanced needs, but it could
probably be used with diredc. I am affraid I am not the best person to
answer that, it is just my guess.

Pesonally I think that searching is much better than bookmarking since
search is cognitively less demanding (I'm getting old :-)). In principle
I use bookmarks just as a shortcuts for some long paths, and I search
those bookmarks with Helm.  Bookmarks are one way of indexing things
for searching.

For that reason I wouldn't see it as a downside to mix all "kind" of
bookmarks. A fuzzy search in a completion does not care much where data
comes from; for ex in helm-mini I can fuzzy complete recentf list,
bookmarks and list of live buffers all lumped into one source.

It is subjective of course. I understand your consideration and the way
you think as well as Boruch's consideration.

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-11-05 19:20]:
> That is why we have completers like Helm. I never look at bookmarks. I
> use Helm which completes them with a key or two. 
> To be honest I don't use bookmarks much either; I have just few places
> that would otherwise require me to navigate through path completion.

For me bookmarks are very handy to jump to exact place or heading in a
file like Org file that I can export particular Org section and
transfer it into email, rather then find-file and opening file and
searching for a section in text.

Also it is very handy to remember remote paths for Tramp or deep paths
on local file system. While I do use completion outside of Emacs, the
built-in TAB completion within Emacs works also well and maybe with
same number of keys.

It is better bookmarks are together as it is more useful:

- bookmark can bring user to specific file, specific line, in Dired,
  opened as directory, sometimes user wish to just fine the file, but
  not open it.

- bookmark can bring user to open specific file, usually to specific
  place in the file

> > For the second, I think this actually hints at a need for the generic
> > bookmark-selection functionality to offer a way to first select a *type*
> > of bookmark and only then pick a name among the remaining candidates.
> I think we already have that. Helm for example is one such.

Isn't selection of type of a bookmark somehow already automatic?

Bookmarks and completion functions are separate. I always need to
bookmark it and how I choose bookmark later depends of packages I am
using.

Helm is not in GNU ELPA and is huge as a package. That means that on
number of computers when somebody manages many computers on remote
places all over the world that remote package has to be installed,
that takes time. Sometimes VPS is opened just for an hour or day to
provide specific server or for testing. GNU ELPA packages are way
easier to reach then modifying the archive list, downloading huge
sometimes busy list of outside packages and choosing helm and bunch of
other packages.

ivy and counsel are in GNU ELPA and ivy-* and counsel-* functions can
give great insight.

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

> >> You'd still have the downside that the general bookmarks include all the
> >> other non-directory bookmarks, so maybe it's not a good idea anyway.
> >> [ I'm not using bookmarks very much, so my intuition here is poor.  ]
> > Why would that be a downside?
> 
> That you can have name conflicts between the diredc and other bookmarks,
> and that when selecting a diredc bookmark you'd have to see all those
> other bookmarks which might make it more timeconsuming to find the
> bookmark you're after.
> 
> For the first problem, I don't have a good solution.
> For the second, I think this actually hints at a need for the generic
> bookmark-selection functionality to offer a way to first select a *type*
> of bookmark and only then pick a name among the remaining candidates.

This already exists, with Bookmark+.

1. There are jump commands based on types.  For Dired
bookmarks there are these (also C-x j 4 versions, for
other-window):

 C-x j d    Jump to a Dired bookmark.
 C-x j . d  Jump to a Dired bookmark for the `default-directory'.

And for an arbitrary type (what you suggested) there is
 C-x j :    (`bmkp-jump-to-type').  From the doc:

 Jump to a bookmark of a given type.  You are prompted for the type.
 Otherwise, this is the same as `bookmark-jump' - see that, in
 particular, for info about using a prefix argument.

 When prompted for the type, you can use completion against the known
 bookmark types (see `bmkp-types-alist').

 Completion is lax, so you can also enter the name of a bookmark
 `handler' or `file-handler' function, without completion.  Bookmarks
 with that entry value are then the jump candidates.

[All bookmark jump commands are on prefix key `C-x j'.  And
`.' means "this" in bookmark keys.  E.g., `C-x j . f' jumps
to a file bookmark for the current (this) dir, `C-x j t .'
is a prefix key for "this" bookmarks with various tag sets
(e.g. jump to a file in this directory that has some, or all,
of a set of tags you specify, or those matching a regexp).]

2. In the bookmark-list display (`C-x r l'), you can show
only bookmarks of a given type, e.g. only Dired bookmarks.
And you can mark by type or sort by type.  (And you can do
lots of things to/with the marked bookmarks, from search
to nuts. ;-))

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-05 10:05, Stefan Monnier 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. The
> > consideration was not mix directory locations with locations within
> > files. I know that emacs bookmarks works on directories and opens a
> > dired buffer for them, but it made no sense to me mix the two forms
>
> Do you think it could make sense to keep diredc bookmarks in the normal
> bookmarks by arranging for the normal "directory bookmarks" to be
> "hijacked" by diredc

Hmm. I'm looking at the code for bookmarks and the variable
bookmark-alist, and what I see is that directory bookmarks have a NIL
handler, ie. function bookmark-default-handler, which runs function
find-file-noselect, which is directly or indirectly called by
"everyone", including diredc. So, I suppose a way to 'hijack' the
bookmark process would be to advise around function
bookmark-default-handler checking for the current buffer's major-mode,
the state of variable diredc-mode and whether the bookmark is a
directory. The ugly part of the 'hijack' is keeping the code of the
advice in sync with the underlying function.

> (i.e. not to open a new dired buffer but to open the dir within
> diredc)

The diredc interest isn't only in the buffer management; it also needs
to maintain the history stack (it's not a simple push/pop, see there)
for each new navigation.

>  when called from diredc?

What about the case of diredc-mode being enabled, but the current-frame
isn't the diredc frame (ie. the user is not currently using dired)? You
wouldn't want to jump to that frame and open the directory in one of its
windows?

> You'd still have the downside that the general bookmarks include all the
> other non-directory bookmarks, so maybe it's not a good idea anyway.

Your intuition or my intuition doesn't matter. For me the mixing
certainly is a huge down-side, but you've seen from some of the reaction
to your post that people just do things their own way to their own
preference. The filtering feature that Drew mentioned exists in
bookmarks+ sounds good, in that it retains the standard emacs bookmark
code and allows the completion candidates to be filtered.

> [ I'm not using bookmarks very much, so my intuition here is poor.  ]

I use them a lot, but for the past many years only for temporary
place marks.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Monnier]

> Hmm. I'm looking at the code for bookmarks and the variable
> bookmark-alist, and what I see is that directory bookmarks have a NIL
> handler, ie. function bookmark-default-handler, which runs function
> find-file-noselect, which is directly or indirectly called by
> "everyone", including diredc. So, I suppose a way to 'hijack' the
> bookmark process would be to advise around function
> bookmark-default-handler checking for the current buffer's major-mode,
> the state of variable diredc-mode and whether the bookmark is a
> directory.

Sounds about right, yes.

> The ugly part of the 'hijack' is keeping the code of the
> advice in sync with the underlying function.

Your code doesn't need to depend on the code of
`bookmark-default-handler`: It only depends on the name of that
function, on the fact that it is called for the entries in which you're
interested (and on the fact that it is called in exactly the same way as
any other bookmark handler).

So as far as advice go, it should be pretty stable.

> What about the case of diredc-mode being enabled, but the current-frame
> isn't the diredc frame (ie. the user is not currently using dired)? You
> wouldn't want to jump to that frame and open the directory in one of its
> windows?

Your advice gets to decide which behavior you get.


        Stefan

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

> So, I suppose a way to 'hijack' the
> bookmark process would be to advise around function
> bookmark-default-handler checking for the current buffer's major-mode,
> the state of variable diredc-mode and whether the bookmark is a
> directory. The ugly part of the 'hijack' is keeping the code of the
> advice in sync with the underlying function.

Are you looking for a way to have your own
bookmark-handling code do what you want with a
vanilla bookmark for a directory?  Is that it?

Why not instead define your own bookmark handler
for directory bookmarks?  That's what bookmark
handlers are for.

FWIW -

In Bookmark+ Dired buffers have their own bookmark
handler.  Bookmarking a Dired buffer records not
just the directory location but also its `ls'
switches, which files are marked, which subdirs
are inserted, and which (sub)dirs are hidden.
Jumping to a Dired bookmark restores all of that.

IOW, Dired bookmarks are really Dired bookmarks.
They don't just "invoke Dired in a default way on
this directory".  Dired gives you a particular
kind of directory listing.  That's what should be
bookmarkable.

Re: Friendlier dired experience [CODE INCLUDED]

[Adam Porter]

Drew Adams <drew.adams@oracle.com> writes:

> In Bookmark+ Dired buffers have their own bookmark handler.
> Bookmarking a Dired buffer records not just the directory location but
> also its `ls' switches, which files are marked, which subdirs are
> inserted, and which (sub)dirs are hidden.  Jumping to a Dired bookmark
> restores all of that.

Could that handler be upstreamed into Dired, please?  It seems like that
functionality ought to be built-in.

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

> > In Bookmark+ Dired buffers have their own bookmark handler.
> > Bookmarking a Dired buffer records not just the directory location but
> > also its `ls' switches, which files are marked, which subdirs are
> > inserted, and which (sub)dirs are hidden.  Jumping to a Dired bookmark
> > restores all of that.
> 
> Could that handler be upstreamed into Dired, please?  It seems like that
> functionality ought to be built-in.

I've offered Bookmark+ several times to Emacs.
And I've mentioned specific features even more
times.  They could be included or used as food
for thought.

Bookmark+ could replace vanilla bookmark.el
(after incorporating some of its code).
___

My point to you here was that instead of advising
the default handler you can define your own handler.
That's why we have handlers, and why the default
handler is, well, the default (handler).

Re: Friendlier dired experience [CODE INCLUDED]

[Adam Porter]

Drew Adams <drew.adams@oracle.com> writes:

> My point to you here was that instead of advising
> the default handler you can define your own handler.
> That's why we have handlers, and why the default
> handler is, well, the default (handler).

That wasn't me.

>> > In Bookmark+ Dired buffers have their own bookmark handler.
>> > Bookmarking a Dired buffer records not just the directory location but
>> > also its `ls' switches, which files are marked, which subdirs are
>> > inserted, and which (sub)dirs are hidden.  Jumping to a Dired bookmark
>> > restores all of that.
>> 
>> Could that handler be upstreamed into Dired, please?  It seems like that
>> functionality ought to be built-in.
>
> I've offered Bookmark+ several times to Emacs.
> And I've mentioned specific features even more
> times.  They could be included or used as food
> for thought.

To be clear, I'm asking if you would upstream that specific feature, the
enhanced bookmark-make-record function and the bookmark handler for
Dired buffers.  It seems likely that those two functions would be easily
upstreamed without much modification or objection, and all Dired users
would benefit immediately.

Re: Friendlier dired experience [CODE INCLUDED]

[Daniel Martín]

Adam Porter <adam@alphapapa.net> writes:
>
> To be clear, I'm asking if you would upstream that specific feature, the
> enhanced bookmark-make-record function and the bookmark handler for
> Dired buffers.  It seems likely that those two functions would be easily
> upstreamed without much modification or objection, and all Dired users
> would benefit immediately.

I would also find those two bookmark functions very helpful if they were
part of Emacs.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-06 08:28, Drew Adams wrote:
> > So, I suppose a way to 'hijack' the bookmark process would be to
> > advise around function bookmark-default-handler checking for the
> > current buffer's major-mode, the state of variable diredc-mode and
> > whether the bookmark is a directory. The ugly part of the 'hijack'
> > is keeping the code of the advice in sync with the underlying
> > function.
>
> Are you looking for a way to have your own bookmark-handling code do
> what you want with a vanilla bookmark for a directory? Is that it?

Don't pin this on me, Drew. I was just responding to Stefan Monnier's
proposal.

> Why not instead define your own bookmark handler for directory
> bookmarks? That's what bookmark handlers are for.

Because a specific bookmark's handler is hard-coded into the
data-structure when added, so which ever function creates the bookmark,
be it ye olde function bookmark-set or the new kid diredc, that's the
function that defines the handler to be used.

> FWIW -
>
> In Bookmark+ Dired buffers have their own bookmark handler.

That's very sensible and should be what function bookmark-set does
instead of what it does now which is run through a set of conditionals.

> Bookmarking a Dired buffer records not just the directory location
> but also its `ls' switches, which files are marked, which subdirs are
> inserted, and which (sub)dirs are hidden. Jumping to a Dired bookmark
> restores all of that.

That's why I never end up actually ever using your extensions, Drew. I
think they're great and I enjoy reading them, but it always ends up
intimidating me with a sense of overkill.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Arthur Miller]

Boruch Baum <boruch_baum@gmx.com> writes:

> That's why I never end up actually ever using your extensions, Drew. I
> think they're great and I enjoy reading them, but it always ends up
> intimidating me with a sense of overkill.
But if an extension is overkill, how is then creaing entire system
instead not? :-) Sorry, I just can't resist to ask.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-08 13:09, Arthur Miller wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > That's why I never end up actually ever using your extensions, Drew. I
> > think they're great and I enjoy reading them, but it always ends up
> > intimidating me with a sense of overkill.
> But if an extension is overkill, how is then creaing entire system
> instead not? :-) Sorry, I just can't resist to ask.

Fair. The diredc "system" is only a few lines of code, with nothing at
all complicated (compare the data structures and compare the code to the
emacs native bookmards). It does presume a 'segregationist' mind-set
that I clearly have and many on this list don't, ie. it didn't occur to
me that people find it desirable to mix up bookmark types. Even though
I've been an emacs user for over 20 years, I was probably also heavily
influenced by pretty much all other file managers, that do have a
bookmark feature, only for directory places. I expect many people coming
to emacs more recently might also have their expectations likewise
influenced by all those other file managers. Now, if one can argue that
it's *objectively* better to mix bookmarks, then one can clearly reject
the diredc system, but once it becomes a subjective issue of expectation
and personal preference, the diredc system isn't so easy to reject.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Boruch Baum <boruch_baum@gmx.com> [2020-11-08 15:45]:
> On 2020-11-08 13:09, Arthur Miller wrote:
> > Boruch Baum <boruch_baum@gmx.com> writes:
> >
> > > That's why I never end up actually ever using your extensions, Drew. I
> > > think they're great and I enjoy reading them, but it always ends up
> > > intimidating me with a sense of overkill.
> > But if an extension is overkill, how is then creaing entire system
> > instead not? :-) Sorry, I just can't resist to ask.
> 
> Fair. The diredc "system" is only a few lines of code, with nothing at
> all complicated (compare the data structures and compare the code to the
> emacs native bookmards). It does presume a 'segregationist' mind-set
> that I clearly have and many on this list don't, ie. it didn't occur to
> me that people find it desirable to mix up bookmark types.

My personal bookmark indexing system (Hyperscope) has 15892 bookmarks
to various files, PDF, specific pages to PDFs, Dired directories,
files, specific parts of videos for few different aspects of research,
bookmarking things that are opened externally, videos are opened
externally, PDF files could or need not be opened externally, external
file manager can be opened at specific location, etc.

It does not bother me that it is all "together" because one could see
it as such, but I never even have been thinking of it. Cognition comes
from your statements, yes I keep them together. This may give you
different user viewpoint.

I have launchers, or program launchers in that system, tasks and notes
as well all inside of a bookmark, which I call hyperlink and it still
does not bother me. There is even bookmark to bookmark or another
bookmark which can be with different wordings that point out to first
bookmark. Normally such bookmarks to bookmarks are stored in different
set of bookmarks.

Reason why it does not bother me is incremental narrowing completion
and filtering. Within seconds I am at right place.

> Even though I've been an emacs user for over 20 years, I was
> probably also heavily influenced by pretty much all other file
> managers, that do have a bookmark feature, only for directory
> places.

Me too, used many times bookmarks in Midnight Commander. But it was
also often a problem to invoke the key binding as it was in conflict
with Window Managers.

> I expect many people coming to emacs more recently might also have
> their expectations likewise influenced by all those other file
> managers.

Not so many will be coming from Midnight Commander as it is not
replaceable by Emacs.

There is one package I think helm gnome bookmarks or system bookmarks
which is then taking bookmarks from XFCE, Gnome, KDE and displaying in
Emacs. This shall give you idea how to enhance your package. It is
exactly for reason to help people who used other file managers to find
their dear bookmarks.

> Now, if one can argue that it's *objectively* better to mix
> bookmarks, then one can clearly reject the diredc system, but once
> it becomes a subjective issue of expectation and personal
> preference, the diredc system isn't so easy to reject.

From view point of Emacs users and standard bookmark usage it is
somehow better to leave people in their familiar key bindings and add
or enhance Emacs bookmarks with outside package. That is why I am
looking into those handlers Drew mentioned, but still did not find
clear way to go. It is gluing two bookmark systems together. Then I
can make defcustom to decide which types of bookmarks from my system
would be included in the list C-x r b or maybe all (but I have to have
filtering).

From view point of myself, or from view point of other package
developers like you it need not be together. My bookmarking system is
not together and does not display in in list-bookmarks. I can access
my bookmarks with different key bindings. The difference is basically
in function and in keybindings.

If there is good filtering option and search functions, there is no
difference in accessibility.

Only because I do not have functions yet (handlers) to glue to
`list-bookmarks' for now it remains so. But I may glue the list from
Emacs bookmarks into my system and display, filter, access or annotate
it in a different manner. In that sense gluing systems together is
unfullfiled desire.

Comments on Bookmark+: there are new things to learn, for example
non-existent bookmarks for which I did not even now they are
non-existent, "no such buffer now", bookmarkes to sequence or variable
list, function, there are annotations which should be in every
bookmark system. Browsers mostly have it, some of them still don't.

There are functions to export and import bookmarks,
integrate. Thinking of knowledge management that is useful as one want
whole set or groups or tagged bookmarks exported and to give such to
other people. Bookmarks need not be only to location of files,
directories, bookmarks are pointers and hyperlinks to information.

https://en.wikipedia.org/wiki/Hyperlink

In computing, a hyperlink, or simply a link, is a reference to data
that the user can follow by clicking or tapping.[1] A hyperlink points
to a whole document or to a specific element within a
document. Hypertext is text with hyperlinks. The text that is linked
from is called anchor text. A software system that is used for viewing
and creating hypertext is a hypertext system, and to create a
hyperlink is to hyperlink (or simply to link). A user following
hyperlinks is said to navigate or browse the hypertext.

Emacs bookmarks, bookmarks+ or diredc bookmarks or any similar system
fit into that definition of hypertext systems. Merging them together
or having unified search and filtering interface is useful.

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

> > It does presume a 'segregationist' mind-set
> > that I clearly have and many on this list don't,
> > ie. it didn't occur to me that people find it
> > desirable to mix up bookmark types.

1. If there are no specific handlers, so the default
   handler is always used, then there are, generally
   speaking, no bookmark types.  The most-default
   default behavior is to treat all bookmarks the same.

2. Even when there are multiple bookmark types (and
   there are, even in `emacs -Q' - Info bookmarks,
   for instance), nothing _requires_ someone to "mix"
   bookmarks of different types in the same bookmark
   file.

   It's simple to have a bookmark file for Info
   bookmarks, another for EWW bookmarks, another for
   image bookmarks, another for man bookmarks, etc.

IOW, it's not either/or: one hard-coded camp of
"segregationists" vs another one of "integrationists".

Anyone can use bookmarks either way: mix or match.
___

And bookmarks can not only be "hard-code" separated
by type into different bookmark files.  If you use
Bookmark+ then you can mix them in a given bookmark
file but still separate them wrt access, display, etc.

A function can use bookmarks of any specific type, by
using the function that returns only bookmarks of that
type: `bmkp-<type-or-other-condition-name>-alist-only'. 

> > Now, if one can argue that it's *objectively* better to mix
> > bookmarks, then one can clearly reject the diredc system, but once
> > it becomes a subjective issue of expectation and personal
> > preference, the diredc system isn't so easy to reject.

From my point of view, it's objectively better to be
able to mix _or_ keep separate.

And that, in different ways, only one of which
involves physical separation into different files.

Just one opinion.  The real point is that, even with
vanilla Emacs, nothing obliges anyone to mix bookmarks
of different types in the same file.

> That is why I am looking into those handlers Drew
> mentioned, but still did not find clear way to go.
> It is gluing two bookmark systems together. 

If you mean using bookmark handlers, in general,
then no, that has nothing particular to do with me
or Bookmark+.  That's basic to the vanilla-Emacs
design of bookmarks, and it has been so since Day
One.  There's a default behavior, AND you can add
bookmark types with their own behavior.

> Comments on Bookmark+: there are new things to learn, for example
> non-existent bookmarks for which I did not even now they are
> non-existent, "no such buffer now", bookmarkes to sequence or variable
> list, function, there are annotations which should be in every
> bookmark system. Browsers mostly have it, some of them still don't.
> 
> There are functions to export and import bookmarks,
> integrate. Thinking of knowledge management that is useful as one want
> whole set or groups or tagged bookmarks exported and to give such to
> other people. Bookmarks need not be only to location of files,
> directories, bookmarks are pointers and hyperlinks to information.
> 
> https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Hyperlink__;!!GqivP
> Va7Brio!Nb65Jllzho8BuyZWUu8ZyRmcMOVajbyIWqIMGvH8zDbSbrgROMDMgX2pwMSVvVSL$
> 
> In computing, a hyperlink, or simply a link, is a reference to data
> that the user can follow by clicking or tapping.[1] A hyperlink points
> to a whole document or to a specific element within a
> document. Hypertext is text with hyperlinks. The text that is linked
> from is called anchor text. A software system that is used for viewing
> and creating hypertext is a hypertext system, and to create a
> hyperlink is to hyperlink (or simply to link). A user following
> hyperlinks is said to navigate or browse the hypertext.
> 
> Emacs bookmarks, bookmarks+ or diredc bookmarks or any similar system
> fit into that definition of hypertext systems. Merging them together
> or having unified search and filtering interface is useful.

Yes, to all of that.  The main characteristics of
Emacs bookmarks are these, IMO:

 1. They're persistent.
    (They don't have to be, but they can be.)
 2. They can record nearly anything.
 3. The info they store can be used in any way.

In a nutshell, they're little, persistent bits of Lisp data.

on hyperlinks (bookmarks)

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-11-08 19:51]:
> > > It does presume a 'segregationist' mind-set
> > > that I clearly have and many on this list don't,
> > > ie. it didn't occur to me that people find it
> > > desirable to mix up bookmark types.
> 
> 1. If there are no specific handlers, so the default
>    handler is always used, then there are, generally
>    speaking, no bookmark types.  The most-default
>    default behavior is to treat all bookmarks the same.
> 
> 2. Even when there are multiple bookmark types (and
>    there are, even in `emacs -Q' - Info bookmarks,
>    for instance), nothing _requires_ someone to "mix"
>    bookmarks of different types in the same bookmark
>    file.

And if I use database I am using types of bookmarks. Even if
everything is "together" in display it need not be. I could decide to
show only specific type of bookmarks. So they are together but it is
up to me or user to get different display, they are together as
collection in one database table and they can be always separate in
displaying or using them.

> then no, that has nothing particular to do with me
> or Bookmark+.  That's basic to the vanilla-Emacs
> design of bookmarks, and it has been so since Day
> One.  There's a default behavior, AND you can add
> bookmark types with their own behavior.

That I understood. And I am trying to understand from bookmark+ how is
that done.

> > In computing, a hyperlink, or simply a link, is a reference to data
> > that the user can follow by clicking or tapping.[1] A hyperlink points
> > to a whole document or to a specific element within a
> > document. Hypertext is text with hyperlinks. The text that is linked
> > from is called anchor text. A software system that is used for viewing
> > and creating hypertext is a hypertext system, and to create a
> > hyperlink is to hyperlink (or simply to link). A user following
> > hyperlinks is said to navigate or browse the hypertext.
> > 
> > Emacs bookmarks, bookmarks+ or diredc bookmarks or any similar system
> > fit into that definition of hypertext systems. Merging them together
> > or having unified search and filtering interface is useful.
> 
> Yes, to all of that.  The main characteristics of
> Emacs bookmarks are these, IMO:
> 
>  1. They're persistent.
>     (They don't have to be, but they can be.)

Yes, they are. Only they are designed for single users, not for
collaborative sharing.

Bookmark+ has export option. Files can be shared really, but that is
not fast collaborative sharing. There are many things inside for me to
learn and adopt good ideas I missed myself.

In my Hyperscope system that I am preparing, hyperlinks (bookmarks)
are shareable and global. That increases collective IQ. Engelbart:
https://www.dougengelbart.org/content/view/172/130/

Users with access to database can then collaboratively share common
knowledge and references. 

Imagine when we work in local area network, several users translating
files and need references. New reference is added as bookmark and all
other users have reference without updating or sharing files as
reference is simply accessed through common database. It implies that
some files are shared and accessible between users that bookmarks can
access them. While Emacs is one interface to such bookmarks, there can
be various other interfaces.

>  2. They can record nearly anything.

It would be good that every structured software or information
provides clear way of finely grained referencing. Reference:
https://www.dougengelbart.org/content/view/116/#7j

Example from that page shows on the right side references 7j and 7k:

THE BASIC "HYPER" CHARACTERISTICS - where embedded objects called
links can point to any arbitrary object within the document, or within
another document in a specified domain of documents - and the link can
be actuated by a user or an automatic process to "go see what is at
the other end," or "bring the other-end object to this location," or
"execute the process identified at the other end." (These executable
processes may control peripheral devices such as CD ROM, video-disk
players, etc.)  7j

HYPERDOCUMENT "BACK-LINK" CAPABILITY - when reading a hyperdocument
online, a worker can utilize information about links from other
objects within this or other hyperdocuments that point to this
hyperdocument - or to designated objects or passages of interest in
this hyperdocument.  7k

That feature for every paragraph to get specific #name in WWW is I
think not supported not even in Org mode, but it should be, especially
in Org mode. Koutliner from GNU Hyperbole could have improved HTML
export and easily provide the feature with back references.

Many PDF readers do not support specific --goto-page --goto-line
--goto-search options. If they do, they do not have a built in
back-referencing system that user can simply press a key and obtain
the book mark specification, something like <PAGE:12 LINE:32> but they
should have.

Programmers and document creators could improve collective IQ by
providing back referencing features.

Example of obvious lack of such feature is email reference
ID. References are mostly used by software, and there are almost no
functions for humans. I would like to be able, when reading email, to
obtain the back link which I can then store somewhere as bookmark so
that I can come back to that specific email, specific line or marked
text in the email. Emails are very constant documents when on file
system, perfect for bookmarking. But we do not have those features
almost in no email client. For those who use Maildirs we can use
direct jump to specific files on file system and read them as
emails. For those using mboxes I think there are no such referencing
possibilities in email readers.

In Emacs we can get bookmark with {C-x r m RET} for the file at the
point. It is useful and it just needs easy sharing. Emacs works on
multi-user systems but is not designed for multi-users. To share
bookmarks one would need either to copy bookmark files or provide some
web page or transmit one by one. By sharing or having possibility to
share such as through datbase or imaginable shared bookmark feature
then every household or group or company or organization member can
get bookmarks or hyperlinks assigned to his space or could enter into
the collection of bookmarks that other related persons created.

`eww' lacks function to bookmark specific page on specific line. I can
of course add eww bookmark with `w' but that does not reference
specific line or specific search on the page.

If there are no #names it becomes impossible for many browsers to
obtain finely grained reference or back link. For `eww' it would be
relatively easy to do that feature and include it in {C-x r m RET} to
be bookmarked by Emacs system, not eww system.

RE: on hyperlinks (bookmarks)

[Drew Adams]

> > main characteristics of Emacs bookmarks are these, IMO:
> >
> >  1. They're persistent.
> >     (They don't have to be, but they can be.)
> 
> Yes, they are. Only they are designed for single users, not for
> collaborative sharing.

I can't speak to the general topic of collaborative
sharing, but a bookmark file can of course be shared,
just as any other file can be.  And you can access a
bookmark file as a remote file.  And I imagine that a
bookmark file could be accessible from, say, a
repository URL, etc.

Again, I'm no expert on such things - I don't use
them, myself.  But there's nothing special about a
bookmark file, compared to other plain-text files.

I guess I'm saying that I don't think Emacs bookmarks
are particularly "designed for (only) single users".
Unless one thinks that files, in general, are so
designed.
 
> Bookmark+ has export option. Files can be shared really, but that is
> not fast collaborative sharing. There are many things inside for me to
> learn and adopt good ideas I missed myself.

I imagine that multiple users could use the same
bookmark file at the same time.  In that scenario
the same considerations would apply as would apply
to shared use of any other file.

> Imagine when we work in local area network, several users translating
> files and need references. New reference is added as bookmark and all
> other users have reference without updating or sharing files as
> reference is simply accessed through common database. It implies that
> some files are shared and accessible between users that bookmarks can
> access them. While Emacs is one interface to such bookmarks, there can
> be various other interfaces.

Something to consider, perhaps, is that a bookmark
file is separate from the files and other resources
that the bookmarks target.  The latter can certainly
be shared even when the bookmarks need not be.

> `eww' lacks function to bookmark specific page on specific line. I can
> of course add eww bookmark with `w' but that does not reference
> specific line or specific search on the page.

The EWW bookmarks created with Bookmark+ record a
URL, which can include an anchor - e.g., a location
within an HTML page.  Is there really a notion of
"lines" and line numbers in a displayed web page?
If so, if you can record it then it can be added to
what's recorded in an EWW bookmark.

> If there are no #names it becomes impossible for many browsers to
> obtain finely grained reference or back link. For `eww' it would be
> relatively easy to do that feature and include it in {C-x r m RET} to
> be bookmarked by Emacs system, not eww system.

If you're talking about adding support for #name,
that's already present (with Bookmark+).  If you
mean add, in some way, support for addressing a
particular line of a web page, I don't know how
that would be easy to do (but I'm no expert on
such things).

Re: on hyperlinks (bookmarks)

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2020-11-08 22:50]:
> > > main characteristics of Emacs bookmarks are these, IMO:
> > >
> > >  1. They're persistent.
> > >     (They don't have to be, but they can be.)
> > 
> > Yes, they are. Only they are designed for single users, not for
> > collaborative sharing.
> 
> I can't speak to the general topic of collaborative
> sharing, but a bookmark file can of course be shared,
> just as any other file can be.  And you can access a
> bookmark file as a remote file.  And I imagine that a
> bookmark file could be accessible from, say, a
> repository URL, etc.
> 
> Again, I'm no expert on such things - I don't use
> them, myself.  But there's nothing special about a
> bookmark file, compared to other plain-text files.
> 
> I guess I'm saying that I don't think Emacs bookmarks
> are particularly "designed for (only) single users".
> Unless one thinks that files, in general, are so
> designed.

I have not expressed myself correctly.

I wanted to say that Emacs could provide central sharing feautres.

Example could be when there would be a bookmark file to which all
users on same system could write and read from it. That would be
analogous to site-lisp directory.

If I remember well back in time games scores were centrally shared
with other users. I may be wrong. Similar fashion could be used for
various packages to create the collective data or useful information
for a group without thinking how to share those files, transfer, etc.

In other words that leads to database backed systems that were well
designed for collective collaboration.

But if two users can write to same bookmark file that is one solution.

> > `eww' lacks function to bookmark specific page on specific line. I can
> > of course add eww bookmark with `w' but that does not reference
> > specific line or specific search on the page.
> 
> The EWW bookmarks created with Bookmark+ record a
> URL, which can include an anchor - e.g., a location
> within an HTML page.  Is there really a notion of
> "lines" and line numbers in a displayed web page?
> If so, if you can record it then it can be added to
> what's recorded in an EWW bookmark.

That is good, I will research it.

> > If there are no #names it becomes impossible for many browsers to
> > obtain finely grained reference or back link. For `eww' it would be
> > relatively easy to do that feature and include it in {C-x r m RET} to
> > be bookmarked by Emacs system, not eww system.
> 
> If you're talking about adding support for #name,
> that's already present (with Bookmark+).  If you
> mean add, in some way, support for addressing a
> particular line of a web page, I don't know how
> that would be easy to do (but I'm no expert on
> such things).

I think that eww now does support moving to #names but recently, like
maybe some months ago did not. I see it supports here. 

Re: Friendlier dired experience [CODE INCLUDED]

[Arthur Miller]

Boruch Baum <boruch_baum@gmx.com> writes:

> On 2020-11-08 13:09, Arthur Miller wrote:
>> Boruch Baum <boruch_baum@gmx.com> writes:
>>
>> > That's why I never end up actually ever using your extensions, Drew. I
>> > think they're great and I enjoy reading them, but it always ends up
>> > intimidating me with a sense of overkill.
>> But if an extension is overkill, how is then creaing entire system
>> instead not? :-) Sorry, I just can't resist to ask.
>
> Fair. The diredc "system" is only a few lines of code, with nothing at
> all complicated (compare the data structures and compare the code to the
> emacs native bookmards).
Ok, I can buy that simplicity might be a reason; but looking at history,
simplicity usually vanish when things get developed over time, and
usually yet another package will emerge that will prefer simplicity, and
Mary goes round ...

> Now, if one can argue that
> it's *objectively* better 
Can you define what `objectively better' means? I am quite sure we can
argue to lenghts about what better would be, but I am not sure we can
ever define it objectively.

By objectively I believe you mean not subjectively, and I am affraid
that word `better' refers to very subjective matters, which probably
contradicts to word `objective'. That means putting those together in
same expression is probably a misstake, but I would rather leave that to 
philosophy schoolars which I am unfrotunately not one of.

Jokes, aside, I think it is useful to bookmark some special files (like
init file) for example. Furthermore it is also nice to not have to write
another Helm handler for Helm users who would use yoru file manager
(even though it is fairly easy to write a handler for Helm source); i.e
re-use of existing tools. 

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

> > > So, I suppose a way to 'hijack' the bookmark process would be to
> > > advise around function bookmark-default-handler checking for the
> > > current buffer's major-mode, the state of variable diredc-mode and
> > > whether the bookmark is a directory. The ugly part of the 'hijack'
> > > is keeping the code of the advice in sync with the underlying
> > > function.
> >
> > Are you looking for a way to have your own bookmark-handling code do
> > what you want with a vanilla bookmark for a directory? Is that it?
> 
> Don't pin this on me, Drew. I was just responding
> to Stefan Monnier's proposal.

Excuse me?  I'm not pinning anything on anyone.

I was trying to help, by suggesting that a custom
bookmark handler might be an alternative to your
needing to "'hijack' the bookmark process" by
advising `bookmark-default-handler'".

If that suggestion doesn't help, just ignore it.

> > Why not instead define your own bookmark handler for directory
> > bookmarks? That's what bookmark handlers are for.
> 
> Because a specific bookmark's handler is hard-coded into the
> data-structure when added, so which ever function creates the bookmark,
> be it ye olde function bookmark-set or the new kid diredc, that's the
> function that defines the handler to be used.

OK.  So you don't want specific data in the bookmark
itself, right?  You instead want a plain vanilla
bookmark, but you want it to be handled specially,
right?  And I guess you want _all_ plain bookmarks
to be handled in the same special way (since they're
plain, they presumably can't be distinguished by
their data), right?

If so, then another alternative might be to advise
`bookmark-handle-bookmark'.  Not that that would
make much/any difference from advising the default
handler function.

> > FWIW - In Bookmark+ Dired buffers have their
> > own bookmark handler.
> 
> That's very sensible and should be what function bookmark-set does
> instead of what it does now which is run through a set of conditionals.

The only conditionals I see in vanilla `bookmark-set'
have to do with handling the arg `overwrite-or-push'.
I don't see what that has to do with Dired bookmarking.

But it's not very important that I understand you,
especially if my comments aren't welcome.  I mention
that only in case you want to clarify for others.

> > Bookmarking a Dired buffer records not just the directory location
> > but also its `ls' switches, which files are marked, which subdirs are
> > inserted, and which (sub)dirs are hidden. Jumping to a Dired bookmark
> > restores all of that.
> 
> That's why I never end up actually ever using your extensions, Drew. I
> think they're great and I enjoy reading them, but it always ends up
> intimidating me with a sense of overkill.

Sorry.  Luckily, no one's forced to download or use them.

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

My apologies, Drew. Your comments are welcome, and I do consider them. I
guess I wrote undiplomatically or came across wrong.

On 2020-11-08 08:48, Drew Adams wrote:
> Excuse me?  I'm not pinning anything on anyone.
>
> I was trying to help, by suggesting
> ...
> If that suggestion doesn't help, just ignore it.
> ...
> But it's not very important that I understand you,
> especially if my comments aren't welcome.  I mention
> that only in case you want to clarify for others.
> ...
> Sorry.  Luckily, no one's forced to download or use them.

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

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

No problem.  Thanks for the follow-up.  It's easy
to be misunderstood here, and with email in general.

> My apologies, Drew. Your comments are welcome, and I do consider them. I
> guess I wrote undiplomatically or came across wrong.
> 
> > Excuse me?  I'm not pinning anything on anyone.
> > I was trying to help, by suggesting
> > ...
> > If that suggestion doesn't help, just ignore it.
> > ...
> > But it's not very important that I understand you,
> > especially if my comments aren't welcome.  I mention
> > that only in case you want to clarify for others.
> > ...
> > Sorry.  Luckily, no one's forced to download or use them.

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.

Re: Friendlier dired experience [CODE INCLUDED]

[Adam Porter]

Arthur Miller <arthur.miller@live.com> writes:

> 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.

FYI, my new package, Burly, works this way: it bookmarks window/frame
configurations and restores them, including their buffers, by using the
bookmarks library to restore each buffer before restoring the
frame/window configuration.  All that's necessary is for a buffer's
major mode to define a bookmark-make-record-function and a bookmark
handler function (as many major modes already do).

It already works with, e.g. file-backed text buffers, Dired buffers,
magit-status buffers, Help and Info buffers, etc.

https://github.com/alphapapa/burly.el

Re: Friendlier dired experience [CODE INCLUDED]

[Arthur Miller]

Adam Porter <adam@alphapapa.net> writes:

> Arthur Miller <arthur.miller@live.com> writes:
>
>> 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.
>
> FYI, my new package, Burly, works this way: it bookmarks window/frame
> configurations and restores them, including their buffers, by using the
> bookmarks library to restore each buffer before restoring the
> frame/window configuration.  All that's necessary is for a buffer's
> major mode to define a bookmark-make-record-function and a bookmark
> handler function (as many major modes already do).
>
> It already works with, e.g. file-backed text buffers, Dired buffers,
> magit-status buffers, Help and Info buffers, etc.
Super; I'll give it a try some time; thanks!

> https://github.com/alphapapa/burly.el

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Adam Porter <adam@alphapapa.net> [2020-11-05 19:26]:
> Arthur Miller <arthur.miller@live.com> writes:
> 
> > 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.
> 
> FYI, my new package, Burly, works this way: it bookmarks window/frame
> configurations and restores them, including their buffers, by using the
> bookmarks library to restore each buffer before restoring the
> frame/window configuration.  All that's necessary is for a buffer's
> major mode to define a bookmark-make-record-function and a bookmark
> handler function (as many major modes already do).

Very nice. Good in itself, I just cannot switch from Hyperbole to
Burly as Hyperbole has essentially that what you described. Only it
does not save configurations over sessions. I can add various named
window or frame configurations, or not named, I can then go into them
by name quickly or restore everything to where I was.

I do appreciate influx of new Emacs Packages. Yet it would be useful
if programmer would look into what is already available or widely
used.

Check out GNU Hyperbole!

Re: Friendlier dired experience [CODE INCLUDED]

[Adam Porter]

Jean Louis <bugs@gnu.support> writes:

> * Adam Porter <adam@alphapapa.net> [2020-11-05 19:26]:
>> Arthur Miller <arthur.miller@live.com> writes:
>> 
>> > 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.
>> 
>> FYI, my new package, Burly, works this way: it bookmarks window/frame
>> configurations and restores them, including their buffers, by using the
>> bookmarks library to restore each buffer before restoring the
>> frame/window configuration.  All that's necessary is for a buffer's
>> major mode to define a bookmark-make-record-function and a bookmark
>> handler function (as many major modes already do).
>
> Very nice. Good in itself, I just cannot switch from Hyperbole to
> Burly as Hyperbole has essentially that what you described. Only it
> does not save configurations over sessions. I can add various named
> window or frame configurations, or not named, I can then go into them
> by name quickly or restore everything to where I was.
>
> I do appreciate influx of new Emacs Packages. Yet it would be useful
> if programmer would look into what is already available or widely
> used.
>
> Check out GNU Hyperbole!

You may be interested to know that RSW has contributed to Burly and has
expressed interest in adding support for Burly to Hyperbole.

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Adam Porter <adam@alphapapa.net> [2020-11-05 21:57]:
> > Check out GNU Hyperbole!
> 
> You may be interested to know that RSW has contributed to Burly and has
> expressed interest in adding support for Burly to Hyperbole.

Aha, like that, nice to know!

Re: Friendlier dired experience [CODE INCLUDED]

[Arthur Miller]

Jean Louis <bugs@gnu.support> writes:

> I do appreciate influx of new Emacs Packages. Yet it would be useful
> if programmer would look into what is already available or widely
> used.
Indeed. It would be very nice if not everyone was rediscovering warm
water over and over again :-).

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-05 16:29, Arthur Miller wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
>
> > On 2020-11-05 13:54, Arthur Miller wrote:
> >> 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.

Ouch. That's the reason. Diredc is meant to be used frame-based. That's
why it defines a dedicated frame, and that's why there's a dedicated
command to navigate to/from it.

> S-F11 just switches between two different frames: one opened by diredc
> and the original one I had before starting diredc.

That's the point.

> > You mean diredc-recover? I'll presume yes.
> 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 :-).

It's (S-F11) 'thing' is mainly to toggle-frames, so if the diredc frame
itself has gotten messed up then the diredc-recover 'thing' becomes useful.

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

Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum]

On 2020-11-05 13:54, Arthur Miller wrote:
> Boruch Baum <boruch_baum@gmx.com> writes:
> > My memory from looking at it years ago was that it was non-functioning
> > abandon-ware.
> No idea if it is abandon-ware; I don't use it; I used some year ago and it
> was quite competent.
>
> Looking at github, it seems like last commit was ~6 month ago:
>
> https://github.com/sunrise-commander/sunrise-commander

Thanks!

> 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.

That's right. It's a separate diredc-only bookmark list.

> furthermore, when I use C-c b j; it seems to show some byte code, you
> can see it in the attached screenshot.

That *is* weird. I can't reproduce it. Any hints?

> opening new frame in the bacgkround is not really the best feel. It
> didn't got neither raised nor focused.

Fixed.

> 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).

Wait a second. This email sounds familiar. Did I already respond to this?

> The dual pane wasn't so resilient; at least not to Gnus (nothing is
> :-)). After switching to Gnus and back I was left with a single window.
> I am not sure if I understand the docs correctly: is it supposed to
> restore window layout and buffers automatically or do I need to take an
> action? It didn't happened automatically so I tried diredc-restore. I
> was than ask a question to choose between starting a new or choosing two
> panes or something else. I choose two-pane, but I wasn't left with same
> buffers after it executed.
>
> After I switched to the mail to continue writing it again switched to
> just one window. When I switched back it was still just one window. I
> then tried running again diredc (C-x 5 d); it just moved my cursor back
> to old frame. Running again diredc moved cursor back to second frame but
> it never switched back to dual pane nor to original buffers I had in
> diredc. I am sure I am using it wrong, but I don't see in the
> accompanying docs how to switch between buffers and go back to dual-pane
> and original buffers.
>
> In connection to this, looking at those predefined variables; I am not
> sure I find it really useful; you can see below what diredc exported
> when I run it for the first time:
>
> export d1="~/repos/emacs-related/emacs-diredc/" d2="" f1="~/repos/emacs-related/emacs-diredc/README.md" f2="" t1="(/home/arthur/repos/emacs-related/emacs-diredc/README.md)" t2="nil"
>
> sh-5.0$ sh-5.0$ sh-5.0$
>
> 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, or what was the intended workflow?
>
> Sorry if I am obnoxious; these are just questions I was left with after
> tryimg it.
>
> Something positive:
>
> I like your C-c C-k and '; I'll steal it for my own hack of term-toggle,
> thanks! :-). I have eshell on F2 and term on F1, but ' was really nice;
> I think I'll use it instead of F2.
>
> >> History handling: can it not be handled by recentf/winner modes already?
> >
> > I've been a long-time happy user of winner, and found the answer to be
> > no. Winner operates on all windows of a frame, not just the current
> > dired buffer. Thus, if you had in your window configuration history
> > temporary quick-shell buffer-windows or quick-file-view buffer-windows,
> > they would pop in and out if you were using winner-undo to navigate
> > sequentially in your dired history. Also, does winner-mode have a
> > quick-jump to a specific history element?
> >
> >> I am not particulary against custom history handling, but recentf
> >> already does it and winner has undo/redo stack maybe they can be reused?
> >
> > When I had tried recentf years ago, I was disappointed that its only
> > interface was the ncurses menu. Is that still the case? In any event,
> > a recentf menu will include ALL recently visited items, so that list
> > will be a mixture of emacs files and dired buffers and who knows what
> > else; a user would need to visually filter out the path-names ending
> > with a file from those ending with a directory ...
> We have Helm + fuzzy search to filter those out ...
>
> >> Other functionality I would like to see is some from dired-hacks: toggle
> >> and filters.
> >
> > What do you mean by "toggles and filters"?
> https://github.com/Fuco1/dired-hacks#dired-subtree
> https://github.com/Fuco1/dired-hacks#dired-filter


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

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Monnier]

>> I don't use Sunrise
> My memory from looking at it years ago was that it was non-functioning
> abandon-ware.

My question was really about how you designed your system compared
to it.  Your answer indicates you didn't, which implies you've likely
reinvented some of its square wheels (because that's inevitably what we
do when we don't try to learn from past mistakes).

Basically, if you're writing a package that's not meant only for your
own usage, it's worthwhile to take a close look at other similar packages,
including the dead ones (e.g. to learn what to avoid if you don't want
to fall into the same "dead" category, and you also sometimes bump into
some really good idea).

> When I had tried recentf years ago, I was disappointed that its only
> interface was the ncurses menu.

That shouldn't preclude using recentf's infrastructure/data and
providing a different UI on top of it.

> a user would need to visually filter out the path-names ending with
> a file from those ending with a directory ...

Your code could do that filtering, couldn't it?


        Stefan

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* Arthur Miller <arthur.miller@live.com> [2020-11-05 11:22]:
> I have skimmed through diredc (readme + code) but I haven't tried it.
> As far as I see, the only part I see worth putting directly in dired
> is maybe as you pointed out trash management. I don't use Sunrise nor
> any other `comander' Ranger clone; it is just not needed. I don't use
> trash folder either for that matter, but I can see there is not much of
> trash handling offered via Emacs, so maybe some users would prefer to
> have such functionality.

I am using trash functions, and it is very handy especially when
managing some critical files. Some system /etc/configurations may
remain as backup on server, and those are transferred to local Trash
now. It would not be handy to delete large video or image on remote
ssh/scp systems and that such files are transferred to local Trash, it
would consume bandwidth, so I just need to be careful with it.

Emacs trash system can use Freedesktop style trash or directory for
trash. I am using latter set to be ~/tmp/Trash and inside of directory
I have to place .dir-locals.el with following variables:

;;; Directory Local Variables
;;; For more information see (info "(emacs) Directory Variables")

((dired-mode . ((delete-by-moving-to-trash . nil))))

That is easy done by doing {M-x add-dir-local-variable}, then choosing
dired-mode and variable `delete-by-moving-to-trash'. Why? Because if
variable is true then files in trash would not be deleted from Dired,
they would be renamed but not deleted. So deleting truly works only in
my trash directory.

Emacs does support trashing. So far so good.

> For me Helm does the most; dired is needed just sometimes, so it is nice
> if we can keep it lightweight. That said it does not mean that Emacs (or
> Elpa) can't include a file manager, I would just prefer to keep it
> separate from Dired.

I prefer using plain Dired for file management as I am using Emacs on many
computers and VPS-es. I do not know if that is harder or easier, I
have no idea. What I know is that it works well and I am efficient and
fast. It would generally disturb me to load some packages to give me
my familiarity. That is what I avoid. With many computers I would
waste time until I get all packages installed.

When I need some particular option during the session then I do:
{M-x local-set-key RET} then ' then I can set it for shell command
just like diredc proposed it, which is good idea to quickly open
shell. I just need to figure out how to invoke new shell buffer in the
directory where I am located. Package exist for that, but I want to be
fast in setting it up on plain Emacs from `local-set-key'

Diredc should improve shell choice, as Eli said, rather not from
/etc/passwd but at least from Emacs shell handlings.

From docstring for function `shell':

If a file ‘~/.emacs_SHELLNAME’ exists, or ‘~/.emacs.d/init_SHELLNAME.sh’,
it is given as initial input (but this may be lost, due to a timing
error, if the shell discards input when it starts up).

And there is more in the description how Emacs is choosing default
shell. Dash is not even a choice but is main shell on Debian
GNU/Linux.

Again I represent idea that shell list should be taken from
/etc/shells as it is system based list. And if such does not exist
then some default list from diredc, or any package choosing a
shell. 

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

> History handling: can it not be handled by recentf/winner modes already?
> I am not particulary against custom history handling, but recentf
> already does it and winner has undo/redo stack maybe they can be reused?

I don't know just what you or Boruch had in mind wrt
"history handling".  But FWIW, Dired+ lets you open Dired
on just the recent files and dirs or just the recent dirs.

With a numeric prefix arg you can enter the names of
recent files to include or exclude.

The file listing is always in the order of `recentf-list',
which is reverse chronological order of opening or writing
files you access.

Re: Friendlier dired experience [CODE INCLUDED]

[Juri Linkov]

> Ther is a thing I would like to have in Dired, but I haven't got time
> myself to look at it: utilisation of new Tab thing. Since tabs seem
> to act more like workspaces I would like to see them serialized and
> bookmarked so we could use them with Dired. However diredc seems to do
> it's own thing instead of reusing the functionality of tabs.

Tabs are just framesets, so you can type 'C-x r f' in one tab, then
type 'C-x r j' in another tab, and it will restore the tab from register.
If bookmark.el can save framesets from registers, then it will save
bookmarks from tabs as well.

Sv: Friendlier dired experience [CODE INCLUDED]

[arthur miller]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

Cool; I didn't know. Thanks!


________________________________
Från: Juri Linkov <juri@linkov.net>
Skickat: den 8 november 2020 20:46
Till: Arthur Miller <arthur.miller@live.com>
Kopia: Stefan Monnier <monnier@iro.umontreal.ca>; Boruch Baum <boruch_baum@gmx.com>; Emacs-Devel List <emacs-devel@gnu.org>
Ämne: Re: Friendlier dired experience [CODE INCLUDED]

> Ther is a thing I would like to have in Dired, but I haven't got time
> myself to look at it: utilisation of new Tab thing. Since tabs seem
> to act more like workspaces I would like to see them serialized and
> bookmarked so we could use them with Dired. However diredc seems to do
> it's own thing instead of reusing the functionality of tabs.

Tabs are just framesets, so you can type 'C-x r f' in one tab, then
type 'C-x r j' in another tab, and it will restore the tab from register.
If bookmark.el can save framesets from registers, then it will save
bookmarks from tabs as well.

[-- Attachment #2: Type: text/html, Size: 2086 bytes --]

Re: Friendlier dired experience [CODE INCLUDED]

[Mathias Dahl]

[-- Attachment #1: Type: text/plain, Size: 5589 bytes --]

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 <boruch_baum@gmx.com> 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
>
>

[-- Attachment #2: Type: text/html, Size: 6918 bytes --]

Re: Friendlier dired experience [CODE INCLUDED]

[Stefan Monnier]

> 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 don't think this can be done "right" (actually in general even what
diredc provides can't be done reliably without re-launching a new shell)
by make the shell somehow aware of "where we are" (it would require
a much tighter integration between the shell and Emacs than what's
currently available).
I can see two ways to do it:
1- ask the users to setup some kind of "support code" in their shell
   which implements a particular communication protocol with Emacs (and
   provide implementations for the most popular shells).
2- keep all the processing on Emacs's side, i.e. add special notations
   that can be used in the *shell* buffer and that are expanded by Emacs
   before sending them to the shell.
Option 2 is probably the easiest, but it may get tricky to find a good
syntax for it that's lightweight enough and doesn't get too much in the
way of normal use.  I don't think option 2 can work with `M-x term`, OTOH.

> 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.

BTW, I remember thinking that it would be nice/natural to allow
specifying a (file) bookmark name when doing `C-x C-f`, and similarly
`C-x C-d` could allow specifying a (directory) bookmark.

> 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.

I don't know what diredc currently uses, but Emacs has grown the notion
of "Atomic Windows" (see the Info doc, or `display-buffer-in-atom-window`)
which might also be a good fit for diredc (or not: I haven't used it
enough nor know diredc enough to be sure).


        Stefan

RE: Friendlier dired experience [CODE INCLUDED]

[Drew Adams]

> BTW, I remember thinking that it would be nice/natural to allow
> specifying a (file) bookmark name when doing `C-x C-f`, and similarly
> `C-x C-d` could allow specifying a (directory) bookmark.

Good idea.

Not exactly the same thing, but similar: When you use
`C-x C-f' with Icicles you can hit `C-x m' to get
completions for file bookmarks (bookmark names).

This is a separate, on-demand completion that uses a
recursive minibuffer, instead of mixing in (adding)
bookmark-name matches with file-name matches.  So the
behavior is not exactly what you described, but it's
close.

[`C-x C-f' is a "multicommand", which means you can
act on multiple candidates during the same `C-x C-f'.
So you can visit one or more files and/or one or more
file bookmarks.]

Re: Friendlier dired experience [CODE INCLUDED]

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 370 bytes --]

Haven't had the cycles to delve into this complete thread, but I finally
found a working solution for the shell reliably knowing "where" it is
with respect to the working directory by going through the proc
filesystem.

see https://github.com/tvraman/emacspeak/blob/master/lisp/emacspeak-comint.el#L551
-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: Friendlier dired experience [CODE INCLUDED]

[Jean Louis]

* T.V Raman <raman@google.com> [2020-11-10 05:32]:
> Haven't had the cycles to delve into this complete thread, but I finally
> found a working solution for the shell reliably knowing "where" it is
> with respect to the working directory by going through the proc
> filesystem.
> 
> see
> https://github.com/tvraman/emacspeak/blob/master/lisp/emacspeak-comint.el#L551

M-x nshell from	Pascal Bourguignon:
http://informatimago.com/develop/emacs/emacs/pjb-shell.el

Re: Friendlier dired experience [CODE INCLUDED]

[Juri Linkov]

> 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).

What I like in tumme/image-dired is the quick-preview mode for images.
AFACS, diredc supports the same but for all files with the 'C-x q' key.
I think a better key for this feature would be 'C-c C-f' that already
does the same in next-error capable buffers (compilation, grep, occur, ...)

> 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 :)

I have bound TAB in Dired to do the same thing as web browsers do,
i.e. to navigate to the next link/dir.  Before that, I tried to use
TAB to switch windows between Dired buffer, but the problem is that
after developing the habit of switching windows using TAB, trying
to use TAB to switch windows fails in other modes.

> 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?

Maybe this page contains a relevant answer:
https://www.emacswiki.org/emacs/ShellDirtrackByPrompt

> 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.

A long time ago I tried to emulate *Commander keys:

(mapc (lambda (elt)
        (define-key dired-mode-map (car elt)
          `(lambda ()
             (interactive)
             (dired-sort-other (concat dired-listing-switches ,(cadr elt))))))
      '(([(control f3)]       ""     "by name")
        ([(control f4)]       " -X"  "by extension")
        ([(control f5)]       " -t"  "by time")
        ([(control f6)]       " -S"  "by size")
        ([(control shift f3)] " -r"  "by reverse name")
        ([(control shift f4)] " -rX" "by reverse extension")
        ([(control shift f5)] " -rt" "by reverse time")
        ([(control shift f6)] " -rS" "by reverse size")))

but never used this, because after switching to Dired mode many years ago,
I lost all habits accumulated from other commanders, and never missed them
in Dired mode.  For example, the Commander-like keys above are not mnemonic,
whereas most Dired keys are.

> - 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.

This feature might be useful because currently the quickest way to achieve
the same requires destroying the window configuration with C-x 1
then creating a duplicate Dired window with C-x 2.

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