Read the built in documentation.

Properly package that code (sounds like you’re most of the way there) and let your package manager handle it.

In terms of what?

Po Lu a week ago: less cl-lib please. Po Lu a couple days ago: What do you mean touchscreen.el shouldn’t be loaded by default?

lol Not that I think it’s a big deal (sorry for using you as an example, Po. I respect the work you’re doing, but I’m calling it as I see it). It does highlight how unproductive this type of bikeshedding is, though. That email chain is beyond novel length now and it’s still going. Almost makes me hope the “reply-to” button on the site stays broken.

[The Elpaca installer] has a version-number variable that it sets. […] The solution is to replace [the installer with] the new code in elpaca’s docs

This is correct. For anyone troubleshooting Elpaca, there is a Wiki which covers this warning.

When you initialized your new Emacs instance, it installed elpaca from MELPA

This is incorrect. The installer directly clones Elpaca. Elpaca is not hosted on any ELPA. Doing so would require an installer package to be installed by another package manager. I don’t offer support for users running multiple package managers because it creates confusion about which package manager is responsible for which package, load-path entry, etc. MELPA rejected a similar proposal for straight.el as well:

https://github.com/melpa/melpa/issues/4939

cc: /u/liesdestroyer

I have never done anything in lisp before

Emacs has a built-in emacs lisp tutorial. That would be a good starting place.

struggle to understand how single quotes signify a function or what ever

Not exactly sure what you mean by that. Again, I recommend the manual, but you can think of quoting as a way to tell the interpreter “don’t evaluate this”.

e.g.

(prin1 (+ 1 1)) ; (+ 1 1) is evaluated, prints 2
(prin1 '(+ 1 1)) ; prints the literal list (+ 1 1)

There is also backquoting, which I recommend reading up on, too. The syntax and rules are simple, but powerful.

Is this even “viable”, or advisable?

Try it out. At worst you’ll learn something. Fretting about whether or not to give it a shot is a waste of time. I’m sure you can find previous problems and solutions in a lisp.

Should i be looking at common lisp instead?

Do a few problems in elisp, a few in Common Lisp.

Or would you say that’s a pretty dumb idea and i should rather learn it in a different way?

The only foolish idea is to spend time debating about whether or not to try learning something. No one can make that call for you. Try it and see if you like it.

Think of all the thoughts you can think while not thinking!

It’s unclear what your talking about. Add some detail.

My conclusion has been that for some users it creates more problems than it solves, as they can wind up with a new layer of things they don’t understand, and one which further obfuscates the systems they didn’t understand to start with.

There are many questions about use-package because new users are encouraged to copy/paste configurations from package READMEs and other configurations. If you take use-package out of the equation, you’ll be left with questions about the underlying elisp. It doesn’t matter what was used if the crux of the question is “I copied this thing I didn’t read about and now I don’t know how it works. Explain it to me?”

Your life story wasn’t in the way until you put it there.

Agreed here.

Judicious use of `eval-after-load’ is all you need and a lot less wtf.

Until you realize that eval-after-load is just a superfluous abstraction itself (a forgivable “noob” move) and transcend to manually managing load history and friends. /s

But, if we’re using use-package to also manage installing the packages for us (:ensure t), then why shouldn’t it know about the autoloads already and automagically imply a :defer t by default?

Package installation and activation are two seperate concerns. :ensure ensures the package is isntalled if it isn’t already. Users might want to ensure a package is installed and prefer it to be immediately required.

So, by default, we have to remember to either add :defer t or we have to remember that setting our own hooks, bindings, or commands will create autoloads for us.

I feel like you’re misunderstanding what autoloads do. Hooks do not autoload anything. The :commands use-package keyword does autolaod commands. This is useful when a package author has not provided the autoload cookie in the package for a command, or when you wish to forgo loading all of the autoloads.

I know that you can configure use-package to behave as though :defer t is set by default, but that’s just broken for packages that don’t have any autoloads.

How is it broken? There are other ways to load a package. Namely, require.

It feels like maybe use-package is doing too many things.

It only does what you tell it to do via user options and declarations.`

but that kind of sucks because there’s no reason to load magit before I actually want to use it for anything. So, what we can do instead is to implement the project.el integration ourselves

Or (use-package project :ensure nil :defer t :config (require magit)) There are multiple ways to set this sort of thing up and use-package (which should have been named use-feature) can be used to configure built-in features.

Either I’m a little dim or the tooling here is hard to use correctly.

Third option: You haven’t taken the time to digest the use-package manual and/or expand the macro to see what it’s doing. It’s a DSL. You have to learn it to use it effectively.

Am I the only one?

You must be. Otherwise someone would’ve written “use-package alternatives”, which has an almost searchable ring to it.

Ultimately, organization comes down to the user. Tools like use-package make it easier, but they do not guarantee it.

RGB lit crap wasn’t the norm in the 90s. Especially keyboards.

RGB underglow… 90s vibe

Were you alive in the 90s?

Pointless. Not entertaining or informative.

Two days ago: https://www.reddit.com/r/emacs/comments/17k6pu4/m_aka_mx_evalexpression_does_nothing_upon_hitting/

What have you tried/searched for?

(add-variable-watcher 'autosave-toggle
                      #'(lambda (_ value _ _)
                          (if value (autosave-setup) (autosave-teardown))))

Don’t add an anonymous function. It will make it harder to remove. Better yet, implement this as a minor-mode.

(defvar autosave-delay-interval 1
  "The amount of time to wait before autosaving after a change has occurred.")
(defvar autosave-exclude-buffer-list
  '("COMMIT_EDITMSG" "treemacs-persist")
  "List of buffers to exclude from autosaving")
(defvar autosave-immediate-save-functions-list
  '(switch-to-buffer other-window windmove-up windmove-down windmove-left windmove-right next-buffer previous-buffer)
  "A list of functions which trigger an immediate save")
(defvar autosave-immediate-save-hooks-list
  '(mouse-leave-buffer-hook focus-out-hook)
  "A list of hooks which trigger an immediate save")

These should be user options defined via defcustom

(defmacro advice-add-list (advice-list how function)
  "Add list of advice to given function using the how parameter"
  `(dolist (advice ,advice-list)
     (advice-add advice ,how ,function)))
(defmacro advice-remove-list (advice-list function)
  "Remove list of advice from given function using the how parameter"
  `(dolist (advice ,advice-list)
     (advice-remove advice ,function)))
(defmacro add-hooks (hook-list function)
  "Add list of hooks to given function"
  `(dolist (hook ,hook-list)
    (add-hook hook ,function)))
(defmacro remove-hooks (hook-list function)
  "Remove list of hooks from given function"
  `(dolist (hook ,hook-list)
    (remove-hook hook ,function)))

These should be functions instead of macros. They should also be prefixed with your package’s “namespace”.

You don’t have anything to guard against a bad response from the server. e.g.

(unless (equal url-http-response-status 200)
  (error "Server responded with status: %S" url-http-response-status))

To position point at the end of the headers:

(goto-char url-http-end-of-headers)

This:

(setq result (cons (cons ...) result))

Is more clearly expressed as:

(push (cons ...) result)

Better yet, you could map over the elements you’re interested in and accumulate the results via mapcar or cl-loop. That would obviate the need for the “results” variable.

You could probably shorten things by using the dom-elements function to directly search for the href’s you’re interested in in combination with dom-parent to get at the parent elements.

Overall your function gets a 65 out of 130 ERU (elisp rating units).

Customize display-buffer-alist to your liking. There is an Emacs manual section devoted to it as well as several online tutorials.

Auctex requires a :pre-build step which involves generating elisp files. If that step fails, certain parts will break. There are several ways to configure the build as well. See the various issues on the bug tracker for more info. e.g,

https://github.com/progfolio/elpaca/issues/191

Long story short, they’re not being compiled. The message is just output every time. There is a thread on emacs-devel or emacs-bug archive which offers a more detailed explanation if you search there.