From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: dired-x: Add autoload cookie to dired-omit-mode? Date: Sat, 29 Aug 2020 10:42:50 -0700 (PDT) Message-ID: <86c01b3e-4361-4d8b-9cd9-6f68ae5b06e4@default> References: <24394.24718.599025.309500@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6255"; mail-complaints-to="usenet@ciao.gmane.io" To: Stefan Kangas , "T.V Raman" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Aug 29 19:43:31 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kC4t0-0001WR-0k for ged-emacs-devel@m.gmane-mx.org; Sat, 29 Aug 2020 19:43:30 +0200 Original-Received: from localhost ([::1]:34750 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kC4sz-0007yJ-3X for ged-emacs-devel@m.gmane-mx.org; Sat, 29 Aug 2020 13:43:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40774) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kC4sU-0007YX-TB for emacs-devel@gnu.org; Sat, 29 Aug 2020 13:42:58 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:49864) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kC4sS-0006xm-9v for emacs-devel@gnu.org; Sat, 29 Aug 2020 13:42:58 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 07THZ5bY047076; Sat, 29 Aug 2020 17:42:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=yt/UemmQR+Jl4gEyY3dAgNxpuXaQJfeZglf2SbGrtI8=; b=ulwjpVHT8trJ0g7B3eRLOGxXV3fbkIAfP4WO4dIhOXctMKYk68DZsLwScWyN10OEciia olIX7o2Dnjnju9+tohOoqeIwu++CRYFXYeC6OlGpzNHZC5P17nVq4qpguRdQAiDyvgnL cC9xEd9lysu5/jmJmWCtOH/FN4+TFMqVM+zP4HVLgMufQYwLRgzGaY/ZftZ2t8zt/7ec 5f/c/sGoqx14PEZnLgGhavY4t9XMMQntZtXPqyKKxAWSBNkd6VQSnhfchKXJJU1r8iqa 9ccuqCI4wp2SjraKkmKECaCoJ1rT6YVE6U7BXRXJlWfKNkJcJ/svAjCXUmntFX/NC1DC dg== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 337eyks99m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 29 Aug 2020 17:42:52 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 07THeos0020822; Sat, 29 Aug 2020 17:42:52 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3020.oracle.com with ESMTP id 337ebh8jca-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 29 Aug 2020 17:42:52 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 07THgp5Q001705; Sat, 29 Aug 2020 17:42:51 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5044.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9728 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008290143 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9728 signatures=668679 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 priorityscore=1501 phishscore=0 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0 bulkscore=0 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008290142 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/29 13:42:55 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.959, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:254393 Archived-At: > > Given how long dired-x has been in emacs, could we add relevant > > autoload cookies to dired-omit-mode? >=20 > 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