all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Kangas <stefankangas@gmail.com>,
	"T.V Raman" <raman@google.com>,
	emacs-devel@gnu.org
Subject: RE: dired-x: Add autoload cookie to dired-omit-mode?
Date: Sat, 29 Aug 2020 10:42:50 -0700 (PDT)	[thread overview]
Message-ID: <86c01b3e-4361-4d8b-9cd9-6f68ae5b06e4@default> (raw)
In-Reply-To: <CADwFkm=1JhDMOJ1P44S4BGXAzurEpikfg2Ye1GAbVk9v4uP+Wg@mail.gmail.com>

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





      parent reply	other threads:[~2020-08-29 17:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-29 14:05 dired-x: Add autoload cookie to dired-omit-mode? T.V Raman
2020-08-29 14:17 ` Stefan Kangas
2020-08-29 16:34   ` T.V Raman
2020-08-29 18:43     ` Stefan Kangas
2020-08-29 19:22       ` T.V Raman
2020-08-29 20:23       ` Drew Adams
2020-08-31 14:05       ` Stefan Kangas
2020-08-29 17:42   ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86c01b3e-4361-4d8b-9cd9-6f68ae5b06e4@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=raman@google.com \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.