bug#52400: [PATCH] Don't generate separate autoload file for htmlfontify.el

bug#52400: [PATCH] Don't generate separate autoload file for htmlfontify.el

[Stefan Kangas]

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

Severity: wishlist

Is there any need for generating a separate file htmlfontify-loaddefs.el
file given that it only contains three definitions?  Or should we just
get rid of it as in the attached?

[-- Attachment #2: 0001-Don-t-generate-separate-autoload-file-for-htmlfontif.patch --]
[-- Type: text/x-diff, Size: 1879 bytes --]

From d7436b28a2a9324deffacd7fe2db5a9b9ae628a5 Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefan@marxist.se>
Date: Fri, 10 Dec 2021 02:47:35 +0100
Subject: [PATCH] Don't generate separate autoload file for htmlfontify

* lisp/hfy-cmap.el: Update file local to no longer put htmlfontify
autoloads in htmlfontify-loaddefs.el.
* lisp/htmlfontify.el (htmlfontify-loaddefs): Don't require.
* test/lisp/htmlfontify-tests.el (htmlfontify-autoload): Delete
test.
---
 lisp/hfy-cmap.el               | 4 ----
 lisp/htmlfontify.el            | 2 --
 test/lisp/htmlfontify-tests.el | 9 ---------
 3 files changed, 15 deletions(-)

diff --git a/lisp/hfy-cmap.el b/lisp/hfy-cmap.el
index b7de65f5b7..bd4eafc5d2 100644
--- a/lisp/hfy-cmap.el
+++ b/lisp/hfy-cmap.el
@@ -859,8 +859,4 @@ hfy-fallback-color-values
 
 (provide 'hfy-cmap)
 
-;; Local Variables:
-;; generated-autoload-file: "htmlfontify-loaddefs.el"
-;; End:
-
 ;;; hfy-cmap.el ends here
diff --git a/lisp/htmlfontify.el b/lisp/htmlfontify.el
index 8dc4cce323..3b72e5e6b1 100644
--- a/lisp/htmlfontify.el
+++ b/lisp/htmlfontify.el
@@ -81,8 +81,6 @@
 (eval-when-compile (require 'cl-lib))
 (require 'cus-edit)
 
-(require 'htmlfontify-loaddefs)
-
 (defconst htmlfontify-version 0.21)
 
 (defconst hfy-meta-tags
diff --git a/test/lisp/htmlfontify-tests.el b/test/lisp/htmlfontify-tests.el
index 15798319a1..698c6b498e 100644
--- a/test/lisp/htmlfontify-tests.el
+++ b/test/lisp/htmlfontify-tests.el
@@ -21,15 +21,6 @@
 (require 'ert)
 (require 'htmlfontify)
 
-(ert-deftest htmlfontify-autoload ()
-  "Tests to see whether reftex-auc has been autoloaded"
-  (should
-   (fboundp 'htmlfontify-load-rgb-file))
-  (should
-   (autoloadp
-    (symbol-function
-     'htmlfontify-load-rgb-file))))
-
 (ert-deftest htmlfontify-bug25468 ()
   "Tests that htmlfontify can be loaded even if no shell is
 available (Bug#25468)."
-- 
2.30.2

bug#52400: [PATCH] Don't generate separate autoload file for htmlfontify.el

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 9 Dec 2021 18:07:24 -0800
> 
> Is there any need for generating a separate file htmlfontify-loaddefs.el
> file given that it only contains three definitions?  Or should we just
> get rid of it as in the attached?

I wouldn't touch these issues with a 3-mile pole.  They are fragile,
and once they work, having an extra file with 3 definitions is a price
I take every day.  It just isn't worth the effort to awaken these
sleeping dogs.

bug#52400: [PATCH] Don't generate separate autoload file for htmlfontify.el

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> I wouldn't touch these issues with a 3-mile pole.  They are fragile,
> and once they work, having an extra file with 3 definitions is a price
> I take every day.  It just isn't worth the effort to awaken these
> sleeping dogs.

What are the risks in a case like this?  It seems to me that they are
low, in the sense that if we run into any problems we can just revert it
and live happily ever after.  What am I missing?

The main benefit for me is just a general reduction of complexity, but
admittedly it is small.

bug#52400: [PATCH] Don't generate separate autoload file for htmlfontify.el

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 10 Dec 2021 13:32:51 +0000
> Cc: 52400@debbugs.gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I wouldn't touch these issues with a 3-mile pole.  They are fragile,
> > and once they work, having an extra file with 3 definitions is a price
> > I take every day.  It just isn't worth the effort to awaken these
> > sleeping dogs.
> 
> What are the risks in a case like this?

That the build breaks.  Two possible variants of breakage:

  . the autoloads aren't updated when they should be
  . the rule for updating the autoloads is executedevery time you say
    "make", even if there was no change anywhere in Emacs

> It seems to me that they are low, in the sense that if we run into
> any problems we can just revert it and live happily ever after.

I say why take the risks, however low, if the problem is not serious
enough?

> The main benefit for me is just a general reduction of complexity, but
> admittedly it is small.

Exactly.

bug#52400: [PATCH] Don't generate separate autoload file for htmlfontify.el

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> That the build breaks.  Two possible variants of breakage:
>
>   . the autoloads aren't updated when they should be
>   . the rule for updating the autoloads is executedevery time you say
>     "make", even if there was no change anywhere in Emacs

FWIW, I didn't see any of those issues in my testing.

> I say why take the risks, however low, if the problem is not serious
> enough?

Cruft inevitably adds to cognitive load.  A lot of it adds more, little
adds little.  We have a lot of it, IMO, so every little bit helps.

The problem is that if it exists, you will sometimes happen to look at
it and think "hmm, why is this file here".  I think this is the second
(or third?) time I stumble upon this particular file.

bug#52400: [PATCH] Don't generate separate autoload file for htmlfontify.el

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 10 Dec 2021 15:22:12 +0000
> Cc: 52400@debbugs.gnu.org
> 
> > I say why take the risks, however low, if the problem is not serious
> > enough?
> 
> Cruft inevitably adds to cognitive load.

But it isn't cruft.  You tend to declare something "cruft" too easily.

> We have a lot of it, IMO, so every little bit helps.

No, we don't.  Please don't consider cruft anything that you think is
not right; there's more than one way to skin a fish.  People who
worked on Emacs before us weren't exactly incompetent, you know.

> The problem is that if it exists, you will sometimes happen to look at
> it and think "hmm, why is this file here".  I think this is the second
> (or third?) time I stumble upon this particular file.

Just get used to it being there, I say.  It doesn't do any harm,
although you seem to think it does.

We have enough real problems to deal with.

bug#52400: [PATCH] Don't generate separate autoload file for htmlfontify.el

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> But it isn't cruft.  You tend to declare something "cruft" too easily.

This file is the result of an old optimization (some autoloads) that
were subsequently cleaned up.  (The non-optimized version would have
been to just require hfy-cmap.el.)  However, the clean-up didn't go far
enough, and thus we ended up with a file that I think can be accurately
described as cruft.

> No, we don't.  Please don't consider cruft anything that you think is
> not right; there's more than one way to skin a fish.  People who
> worked on Emacs before us weren't exactly incompetent, you know.

I don't think saying that some things have outgrown their usefulness or
could be done better reflects negatively on previous authors.

> Just get used to it being there, I say.  It doesn't do any harm,
> although you seem to think it does.

The "harm" here is exactly having to get used to it.  IOW, you may argue
that this is a very minor cleanup, but on the other hand the cost of
doing nothing is also non-zero.  Hackers will have to look at this for
another couple of decades, or until someone else thinks to install a
patch like the one I wrote.

However, since you seem to feel strongly about it, I won't insist.

bug#52400: [PATCH] Don't generate separate autoload file for htmlfontify.el

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> This file is the result of an old optimization (some autoloads) that
> were subsequently cleaned up.  (The non-optimized version would have
> been to just require hfy-cmap.el.)  However, the clean-up didn't go far
> enough, and thus we ended up with a file that I think can be accurately
> described as cruft.

I think that's the correct analysis here, so I've pushed Stefan's patch
to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no