You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If 't' is included in the arguments of dired-get-filename then dired-subtree-insert works when the cursor is on '.' or '..'. Without the 't', it errors out.
The call to dired-get-filename is correct elsewhere.
The text was updated successfully, but these errors were encountered:
Is that a desirable behaviour? Maybe testing if a nil wasn't returned would be better. Is there a practical use-case for inserting a subtree for .? If you think there is I don't object much, but to me I don't see it.
I actually use a filter to hide . and .. in dired, never used them in the last 5 or so years I wrote dired-filter.
Thanks for the response. Actually, I'm may not need this code change, but making the change anyway wouldn't hurt anything, and would avoid the risk more issue reports from people like me.
My original idea was to use dired-subtree-toggle to toggle .. , which doesn't work with the current version of dired-subtree-insert. However, after I changed dired-subtree-insert to make this possible, and then used my .. displaying dired for a couple days, I decided that I didn't love it.
On line 489 of dired-subtree.el, the code:
(let* ((dir-name (dired-get-filename nil))
should be:
(let* ((dir-name (dired-get-filename nil t))
If 't' is included in the arguments of
dired-get-filename
thendired-subtree-insert
works when the cursor is on '.' or '..'. Without the 't', it errors out.The call to
dired-get-filename
is correct elsewhere.The text was updated successfully, but these errors were encountered: