Re: Friendlier dired experience [CODE INCLUDED]

[Boruch Baum <boruch_baum@gmx.com>]

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