dired-x: Add autoload cookie to dired-omit-mode?

dired-x: Add autoload cookie to dired-omit-mode?

[T.V Raman]

Given how long dired-x has been in emacs, could we add relevant
autoload cookies to dired-omit-mode?
-- 
♉Id: kg:/m/0285kf1  🦮♉

--
♉Id: kg:/m/0285kf1  🦮♉

Re: dired-x: Add autoload cookie to dired-omit-mode?

[Stefan Kangas]

"T.V Raman" <raman@google.com> writes:

> Given how long dired-x has been in emacs, could we add relevant
> autoload cookies to dired-omit-mode?

The discussion in Bug#21981[1] indicates that we would rather move any
relevant functionality into Dired, and I concur.  Why not do it one
piece at a time, starting with 'dired-omit-mode'?

Footnotes:
[1]  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21981

Re: dired-x: Add autoload cookie to dired-omit-mode?

[T.V Raman]

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

Stefan Kangas <stefankangas@gmail.com> writes:


that would work for me too:-)> "T.V Raman" <raman@google.com> writes:
>
>> Given how long dired-x has been in emacs, could we add relevant
>> autoload cookies to dired-omit-mode?
>
> The discussion in Bug#21981[1] indicates that we would rather move any
> relevant functionality into Dired, and I concur.  Why not do it one
> piece at a time, starting with 'dired-omit-mode'?
>
> Footnotes:
> [1]  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21981
>

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

Re: dired-x: Add autoload cookie to dired-omit-mode?

[Stefan Kangas]

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

"T.V Raman" <raman@google.com> writes:

> that would work for me too:-)

While we await volunteers to help with that, I see no reason not to add
such an autoload cookie if it helps users.

Any objections to the attached patch?

[-- Attachment #2: 0001-lisp-dired-x.el-dired-omit-mode-Add-autoload-cookie.patch --]
[-- Type: text/x-diff, Size: 669 bytes --]

From 650c50adc9b47d7d2811bd39f8f2a5ab9d9fd83b Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
Date: Sat, 29 Aug 2020 20:18:19 +0200
Subject: [PATCH] * lisp/dired-x.el (dired-omit-mode): Add autoload cookie.

---
 lisp/dired-x.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/dired-x.el b/lisp/dired-x.el
index 873d586ca1..05c5a70422 100644
--- a/lisp/dired-x.el
+++ b/lisp/dired-x.el
@@ -137,6 +137,7 @@ dired-omit-case-fold-p
       (file-name-case-insensitive-p dir)
     dired-omit-case-fold))
 
+;;;###autoload
 (define-minor-mode dired-omit-mode
   "Toggle omission of uninteresting files in Dired (Dired-Omit mode).
 
-- 
2.28.0

Re: dired-x: Add autoload cookie to dired-omit-mode?

[T.V Raman]

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

Yes, adding this line does not interfere with any of the other things we
want to do 
-- 
7©4Id: kg:/m/0285kf1  •0Ü87©4

RE: dired-x: Add autoload cookie to dired-omit-mode?

[Drew Adams]

> I see no reason not to add such an autoload cookie if
> it helps users.  Any objections to the attached patch?

None from me, FWIW.

Re: dired-x: Add autoload cookie to dired-omit-mode?

[Stefan Kangas]

Stefan Kangas <stefankangas@gmail.com> writes:

> Any objections to the attached patch?

Now pushed to master as commit 04578c1063.

Best regards,
Stefan Kangas

RE: dired-x: Add autoload cookie to dired-omit-mode?

[Drew Adams]

> > Given how long dired-x has been in emacs, could we add relevant
> > autoload cookies to dired-omit-mode?
> 
> The discussion in Bug#21981[1] indicates that we would rather move any
> relevant functionality into Dired, and I concur.  Why not do it one
> piece at a time, starting with 'dired-omit-mode'?

FWIW:

OP's request in that bug thread is simply to add
(require 'dired-x) to dired.el, "so users will no
longer need to set up a dired-load-hook to use
dired-x."

That's simple, and it makes sense.  It's a far cry
from it was hijacked to.  The request was ignored,
just replaced by an intention to do something else.

I said this in that thread:

 "If you're not going to add all of the features then
  keep dired-x.el, for now - and until you do add all
  of its features."

  I was in favor of moving dired-x.el to dired.el
  until you started talking about removing features."

I'm in favor of having `dired.el' load both
`dired-x.el' and `dired-aux.el'.  I'm not in favor
of our trying to guess which parts are most useful
for most users.

People use Dired quite differently, and many/most
are pretty unaware of all that it offers.  That's
happened partly because of its separation into
these 3 files, which are kept quite isolated.

We don't do that so much with other features (Org,
Customize).  In general, we load or autoload
additional features for the same general feature
seamlessly.

Most (but not all) commands in `dired-aux.el' get
autoloaded.  But that library improves Dired in
other ways, and unless you use one of its commands
you don't get those improvements.

Actually, it's not even as clear-cut as that.
Helper `dired-query' autoloads `dired-aux.el'.
And `dired.el' defines `dired-unmark-all-files',
one of the most useful commands there is.  And
that command uses `dired-query'.

So _IF_ you happen to know about and use that
`dired.el' command (bound to `M-DEL') then you'll
end up loading `dired-aux.el'.  This is the kind
of odd coupling that can result from trying to
add _some_ stuff to `dired.el' from the other files.

But in general, for the Dired family users pretty
much need to explicitly require the other family
members.

`dired.el' just does (featurep 'dired-x), for
example.  That means that _IF_ you happen to have
loaded Dired-X _THEN_ the `dired.el' code takes
advantage of it.  And you won't have loaded it if
you have no idea about it.

This is, I imagine, mostly for hysterical raisins.
We find these comments for `dired-initial-position'
and `dired-find-buffer-nocreate', which use
(featurep 'dired-x) instead of (require 'dired-x):

 ;; FIXME document whatever dired-x is doing.

 ;; FIXME add a doc-string, and document dired-x
 ;; extensions.

Still not done.  `dired-x.el' and `dired-aux.el'
are really the poor, unmentioned relatives of the
Dired family.

`dired-clean-up-after-deletion', which also just
uses (featurep 'dired-x), at least mentions it in
the doc string:

 "If `dired-x' is loaded and `dired-clean-up-buffers-too'
  is non-nil, kill any buffers visiting those files,
  prompting for confirmation.  To disable the confirmation,
  see `dired-clean-confirm-killing-deleted-buffers'."

The only other occurrence of "dired-x" in `dired.el'
is this comment, which is a bit out of the blue but
is added after the `dired.el' `dired-mark-' commands:

 ;; dired-x.el has a dired-mark-sexp interactive
 ;; command: mark files for which PREDICATE returns
 ;; non-nil.

The closest `dired.el' comes to accepting its poor
relatives is in function `dired-dnd-handle-local-file',
which does (require 'dired-aux).  That's the only
occurrence of "dired-aux" in `dired.el'.  (The
dired-dnd stuff was added in 22.1.)

I vote for integrating `dired-x.el' and `dired-aux.el'
with `dired.el' in the normal way, i.e., what we've
done for other features.  There's no reason to make
it difficult to know about or make use of the whole
family.

We even have a separate Info manual for Dired-X.
Contrast xrefs to the Org manual in the Emacs manual
with the single xref to the Dired-X manual there.
And there's no manual coverage for `dired-aux.el'
features.

See also this emacs-devel thread:

https://lists.gnu.org/archive/html/emacs-devel/2011-03/msg00628.html