emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: RE: dired-x: Add autoload cookie to dired-omit-mode?
Date: Sat, 29 Aug 2020 10:42:50 -0700 (PDT)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]