Your dependency on external packages reduce with experience

Very often, people discuss in the emacs-devel mailing list that, why so and so package is not included as a default built-in. Over the years, I have found that, in the beginning, users might get annoyed when they find a missing feature. And they start exploring packages. But with experience, they come to know that there is already an emacsy way of doing the same thing.

I totally agree with you and I asked myself why that is... I think one aspect is because of how most people "learn/research" something: Through the internet and the browser. Most searches will lead to a special package that is doing "this". One example: Search for "edit multiple regions emacs" one of the first things you find is multiple-cursors.el. (nothing against this package I used it for many many years) Occur, macros and string-rectangle are maybe somewhere in the search results. But someone with little knowledge about emacs will think "there is a package because native emacs is probably not capable of it". And I already hear many voices (my voice is somewhere in this storm) you can find everything with `C-h i`. Well yes, but.... I don't think that this is the norm today, to read a specialized manual. Some features are in itself hard to understand or not that well documented. I saw that while switching from yassnippets to tempo. Yas can be used mostly without elisp knowledge and is well documented. Two things that tempo is not. Then there is a historical reason like projectile vs project.el. All in all I think that is a good thing. It is one more layer to make emacs your own piece of software. I had a great time packing emacs full of packages: neotree, eamcs-code-browser, dashboard and what so ever. That was one aspect of emacs that hooked me. Now I am hooked because I really enjoy to do it the emacs way. At the end do whatever you want with emacs and make it your own.

> there is already an emacsy way of doing the same thing Sure, for many problems that hold very true. Problems can be solved in different ways. > why so and so package is not included as a default built-in There is a difference between what is included, and what is used as a default choice, or even enabled. There are lots of packages (or rather say libraries) that are included, but many are, naturally, just optional and not defaults. Not everything is needed by the vast majority, and there are lots of alternative ways of accomplishing things, so not everything can be a default, or enabled. Some defaults in Emacs are there just because Emacs need some value to work with, some are deliberate choices by devs, but does not mean they suit everyone. That is just the nature of things. What is included depends on several parameters, technical (usefulness and quality) and political (FSF copyrights and the license). For that reason, not everything can be included with Emacs, either. Emacs's devs do tend to include even kitchen sink in Emacs if possible, so that Emacs is useful to as many as possible, but few things might be missing. For me, Helm is a must, and I am really in doubt it will ever get included in Emacs.

That's true! Here are two articles with extensive examples of this sentiment: * https://karthinks.com/software/batteries-included-with-emacs/ * https://karthinks.com/software/more-batteries-included-with-emacs/ I had no idea about like 90% of these, I just used whatever Doom came with :P Frankly I'm not sure if I'm in favor of shoving too many things into core Emacs; I guess [this article](http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/) about the "battries-includedness" of Python can be argued for here as well

> But someone with little knowledge about emacs will think "there is a package because native emacs is probably not capable of it". Yes, unfortunately, Emacs could do a better to introduce new users to the waste world of its features :). The manual is excellent; not written as a dry technical text, but the world of Emacs is big, and not everything gets into the manual. Furthermore, very few people actually start by reading the manual, it seems like, and they discover things as they are using Emacs. I myself was awful at discovering stuff in Emacs, and used it for years as a very simple text editor, doing lots of things manually as I would do in some other editors. But social media has changed a lot :). New users have YT, Reddit, blogs and what not, which does help to promote Emacs and its lesser obvious features.

I agree that the how-to documentation is the biggest missing piece and there is no official channel for that. People wander of unofficial channels to get the information. But sometimes that is not up-to-date with the current version of Emacs.

> And I already hear many voices (my voice is somewhere in this storm) you can find everything with C-h i. Well yes, but.... > > I don't think that this is the norm today, to read a specialized manual. Another problem is that sometimes because of weird naming schemes it's hard to find what you want in the manual and documentation unless you know exactly what you're looking for. Search apropos 'ediff kill buffers' vs google 'ediff kill buffers' when trying to find ediff-keep-variants. An emacs cookbook would be helpful though. Going through other peoples configs and seeing what they have is generally pretty useful to find new ways to do things in emacs, so a central repository for those tricks would be nice.

I guess the philosophy of the core developers is to keep Emacs hackable. And not having a default for many things is one way of doing that. If the core devs favour one package than a significant number of contributors would move from other similar packages to the one just selected. That could be counter productive for the overall Emacs ecosystem.

The documentation, in general, would be magnificently improved by more (and better) examples. In the rare cases there are examples provided, they almost never demonstrate basic usage and attempt to be too cute by half. I'm a huge fan of starting with the built-in docs before going to Google, and I've written my own packages before so I'm not a total elisp beginner, but I'll still often find the documentations too economical and arcane from time to time.

And this is exactly why one should search the index. If that doesn't show anything, then a full text search through the manual which is VERY easy as it is a simple matter of holding down C-s. Once you find the relevant node, it might be a good idea to start from the first chapter.

The official documentation often feels not up-to-date with the current version of emacs either. This is especially true when you start looking in the elisp manual. For instance, look at this page: [https://www.gnu.org/software/emacs/manual/html\_node/eintr/defcustom.html](https://www.gnu.org/software/emacs/manual/html_node/eintr/defcustom.html) With such notably helpful gems as: >The custom-set-variables function works somewhat differently than a setq. While I have never learned the differences, I modify the custom-set-variables expressions in my .emacs file by hand: I make the changes in what appears to me to be a reasonable manner and have not had any problems. Others prefer to use the Customization command and let Emacs do the work for them. And >I myself use customize for hardly anything. Mostly, I write expressions myself. There are plenty of ways to do something in emacs, but one of the benefits of packages is that someone has already found the thing you wanted to do, put a wrapper on it that's easy to remember and easy to invoke, and has already had to contemplate the weird edge cases so you don't have to. On occasion, I'll revert to a built-in way of doing things, but honestly, finding files (for instance) is so much better with helm or consult that it's bordering on foolish to use the built-in emacs system. But even when I do revert to the built-in method, it's usually because I learned enough from using a package to figure out what it is I even want to ask emacs FOR.

Yes, I totally agree. I use 'i' and 's' a lot. Also, with Helm & co installed, it is even easier to jump to a node in any info page that has a menu, like the main manual page. I can press 'm' and just type a letter or few to complete between all the choices; it is really easy. It just that it took me a while to get there :). I think what scares people off from the manual is that they either are not aware of it, or don't know how to use info and Emacs built-in info reader, and maybe don't even know how to lookup help for the info. It does not help that info reader somewhat uncommon shortcuts, for example, 'l' and 'r' for back & forth, or '[' & ']' to navigate nodes. There are of course web and PDF versions for those who prefer more traditional reading media, but reading it locally in Emacs info reader has advantages.

I agree. One way to accelerate this process is to just straight-up read the manual.

I have the opposite experience also - my .emacs file has grown with many more "require" statements as I discover new packages.

Reaching for Evil immediately instead of learning Emacs text editing/navigation capabilities too.

You sound like a good candidate to contribute improvements. Look forward to seeing them.

This exactly. I take a couple of days every year to re-read the current manual and always find a couple of things I didn't know about -- after 30 years of daily emacs usage. I'd be remiss not to mention that Mickey's book and articles are nearly required reading these days. It's an impressive body of work that augments the manual nicely.

[deleted]

I think it's probably like a bell curve or something. It grows for a while and then it goes back down. I started on Emacs in 2003. Nowadays I don't use package.el at all; I just have a handful of packages dumped directly into my dotfiles git repo.

It's quite unfortunate that that personal opinion got inserted in the manual. Quite misleading as well.

That's also the year I started using emacs. A lot of my require statements are associated with different language modes, which I've picked up over the years.

Some things are undocumented though, like `tempo.el` which u/0lMon references. The package's comment documentation could also use more examples.

> Quite misleading as well. Particularly since the documentation for those functions does a reasonably good job explaining just what the difference is. `custom-set-variables` is not meant to be a user-facing function for configuration, one should be using `customize-set-variable`.

It is also useful to look through one's included Emacs Lisp libraries that come with Emacs, as some of them are completely undocumented outside of header comments and docstrings.

It also tends to grow if you start using Emacs for more things. It'll shrink if you only use it for programming, but if you start using it for [file management](https://www.gnu.org/software/emacs/manual/html_node/emacs/Dired.html), [email](https://github.com/emacs-tw/awesome-emacs#mail), [NNTP](https://www.gnus.org/), [music](https://www.gnu.org/software/emms/), [torrenting](https://github.com/holomorph/transmission), [ebooks](https://depp.brause.cc/nov.el/) & [library](https://github.com/chenyanming/calibredb.el), etc, then individual sections might shrink as your understanding grows and you refine them, but more will be added as new use-cases are covered (up to a point where all your computing is covered and only refinements remain).

Same. There are definitely some packages that I used but they didn't stick so I removed them, but it's not some long term trend of reduction in the least. I expect overall the trend has been to more packages configured over my 28 years of Emacs. I'm not sure I can think of any that I've abandoned for default packages. I *intend* to drop projectile for project some time soon, but I hardly see that as meaningful, it just happens to be a default package, not anything taking me closer to some vanilla state.

A lot of languages have been added to core emacs since then!

the first three things on your list are all built-in, ironically enough.

That is probably true because most Emacs users are programmers or some kind of IT person. I'm a writer, not a programmer. I've been using Emacs for many years. I can follow instructions and perform simple configurations, sometimes even hack a function by pattern recognition and a lot of trial and error. But, mostly, I'm using packages that do that for me, and I don't expect that to change.

Oh definitely, I was thinking more of "your config will grow" than your dependence on external packages specifically.

What you say there is incorrect. *Nothing* is said in the doc string of `custom-set-variables` about it being in any way not intended as a "user-facing function". Not in Emacs 20 through Emacs 28 (the latest release). And that text is identical since Emacs 22. (And nearly identical before that, except that the only optional arg before that was `NOW`.) And nothing is said there even about users not being intended to use optional args `NOW`, `REQUEST`, and `COMMENT`. (`NOW` has been there forever, and `REQUEST` and `COMMENT` were added in Emacs 22.) As for its doc in the Elisp manual (node [Applying Customizations](https://www.gnu.org/software/emacs/manual/html_node/elisp/Applying-Customizations.html)): For Emacs 24 till the present (28), the text is the same. And it mentions internal-only use only for the optional args, *not for the function* itself: > The `NOW`, `REQUEST`, and `COMMENT` entries are for internal use only, and may be omitted. (There's nothing at all about `custom-set-variables` in the Elisp manual prior to Emacs 24.) And IMHO, the manual should not even say that. It's entirely reasonable for users to use the function with any or all of those optional arguments. Emacs maintenance has (IMHO) increasingly been infected by a mania of gratuitously calling things "internal". Gratuitously here means **no need**. (Don't believe me? What's the need to claim those args are "internal"?) What *would have been reasonable* would have been to let readers know, in the **Emacs** manual, that there are *commands* they can use to customize options (and faces), and they *need* not invoke `custom-set-variables` from Lisp code just to customize options. (The only place the Emacs manual mentions `customize-set-variable` is in the sections about `display-buffer`.) IOW, yes, `customize-set-variable` is a good command, and you can also use it from Lisp. You need not use `custom-set-variables`, but you can, if you like (note the plural in the name). And no, it's not silly or dangerous or unwise for users to use any of the optional args to `custom-set-variables`. (And beyond all of that, `M-x customize-option` (aka `customize-set-variable`) is the best way to go, in general.)

I have definitely considered contributing back improvements to documentation but the process of doing so wasn't particularly clear to me. It's definitely something I'd be interested in doing but getting started contributing to emacs is a bit intimidating.

> Nothing is said in the doc string of custom-set-variables about it being in any way not intended as a "user-facing function". The main reason I have to not recommend `custom-set-variables` is that the default blob generated by Customize/Custom contains comments that suggest that it may be problematic to have multiple such invocations. (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(custom-enabled-themes '(wombat))) (custom-set-faces ;; custom-set-faces was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. ) > ;; If there is more than one, they won't work right. Whereas `customize-set-variable` can be used ad nauseam in a manner which permits configuration modularity. It is possible that the generated comments are no longer correct, in which case they should be removed. If however they are correct, then I consider that `custom-set-variables` should be avoided. > Particularly since the documentation for those functions does a reasonably good job explaining just what the difference is. This was in reference to the following: >>> The custom-set-variables function works somewhat differently than a setq. While I have never learned the differences, Calling the appropriate `:set` function when present is a rather significant and important difference.

This looks like a fair enough guide: https://www.fosskers.ca/en/blog/contributing-to-emacs Documentation is a good way to get your feet wet with the process.

If it weren't for evil I would have never made the switch from vim. It made it possible to quickly replicate the setup I wanted, which reduced the amount I had to learn all at once. Now, years later, I'm thinking about removing evil, but it was an important part of switching to emacs for me.

That comment is in a user's init file (or preferably `custom-file`) because a user might not be a lisper. A user might not understand where that code and comment come from, or whether or why s?he might not want to edit that code. Both `customize-set-variable` and `custom-set-variables` work by side effect. Doing either of them more than once *for the same variable* can have as final effect something a nonlisper might not expect. The point of that comment is that users, especially those not comfortable with Lisp, probably shouldn't fiddle with such generated text. Which is true. It's just as true of `customize-set-variable` as it is of `custom-set-variables` -- it's just that only a `custom-set-variables` expression is generated (by either) and inserted in a user's init file. (IMHO, the default behavior should *not* put generated text in a user's init file. That just invites trouble, no matter how much is added as a comment to tell users not to fiddle with the generated code. A separate `custom-file` should be made the default behavior. But that's another struggle...) There's nothing special about `custom-set-variables` wrt `:set` either -- the same thing applies for `customize-set-variable`. The point is to distinguish their behavior from that of `setq`. It's *not at all* that `custom-set-variables` (or `customize-set-variable`) should be avoided. Neither of them writes to your init file (or your `custom-file`) -- they each just set option values. But if you save customizations (using Customize or `custom*` functions) then a `custom-set-variables` expression gets written to your file. The point really is not to *mix Lisp code you write* that sets option values *with Lisp code that's generated* and that you load.

That's fair. My point is that I feel that emacs text editing capabilities are highly underestimated.

I'd seen others, but not this particular guide. Will check it out.

> That comment is in a user's init file (or preferably custom-file) because a user might not be a lisper. A user might not understand where that code and comment come from, or whether or why s?he might not want to edit that code. I used customize-themes' menu to generate it with no other settings. > Both customize-set-variable and custom-set-variables work by side effect. Doing either of them more than once for the same variable can have as final effect something a nonlisper might not expect. Indeed. But it is misleading to say they won't work right if they're working exactly as one would instead expect them to work after reading their documentation. To me the comment rather suggests that there'd be legitimate breakage in customization behavior if one were to use multiple such `custom-set-variables` calls. > There's nothing special about custom-set-variables wrt :set either -- the same thing applies for customize-set-variable. I presumed as much. It isn't stated in its description, but it *is* the primary entrypoint to the customization system for many so necessarily it has to do it right.

At the user level I think this is pretty true! At the Lisp level there are legitimate gaps that seem (as someone not on the mailing list) to be getting addressed incrementally, but I still find myself reaching for 3rd-party stuff all the time. * dash.el was almost mandatory a few years ago for 3rd-party package authors doing list processing, but seq.el covers most of the key points now. * pcase is mostly a replacement for dash's destructuring, but alist/plist destructuring is still way better in dash so I keep it around * s.el is still more convenient than the builtins for getting capture groups out of regex matches. * filesystem traversals and path manipulation via f.el are still nicer than the builtins * as a competent Elisp programmer I still have no idea how the hell I should be using generalised variables ¯\\\_(ツ)\_/¯

This. Often what keeps me from using apropos and the built-in manual functionality is that I usually have *no clue* what Emacs has decided to call a thing, and that usually differs significantly enough about my idea on what to call a thing that I probably won't find it without consulting a search engine. See the perrenial confusion about yank vs paste and window vs frame, which honestly is a pattern you can find present in a ton of places in Emacs. That's not to say that "well Emacs needs to change all the archaic wording to my preferences", but the manual needs to better concede this huge language barrier in some way IMO. A small 'translation' section could help, for example.

>but alist/plist destructuring is still way better in dash so I keep it around Take a look at `let-alist` if you haven't yet! [http://endlessparentheses.com/new-on-elpa-and-in-emacs-25-1-let-alist.html](http://endlessparentheses.com/new-on-elpa-and-in-emacs-25-1-let-alist.html)

I have seen that, thanks! I actually default to plists rather than alists, since they're isomorphic with cl keyword args. If emacs came with a let-plist macro that would wack another mole. :)

I don't remember the autotype manual much but tempo is mentioned there. IIRC, tempo's commentary does link to a package as an example.

The default blob says not to have multiple instances of it not because it is dangerous to have so but because the blob may override previous setting. At least, that's what I would think. I have been using that function for over a year for setting user options and I have zero problems.

That would be reasonable to expect, but I remain wary and likely would until either I or someone else looks over the code. But considering my current use works and the macros I wrote to help it also work, I'm not particularly inclined to. You've been using multiple instances of it?

I don't know. I don't think any lisp form is truly dangerous as long as it doesn't touch a file. Custom is entirely specific to Emacs (tho it can execute arbitrary lisp written by the user option author). Yes, I use multiple instances of it. I cannot be bothered to check whether an option has a setter so I have a billion custom-set-variables forms in my init.el. I would use the customise interface, since unlike most people I think it is a pretty good UI, but it simply writes whatever that is in memory to the file so you end up losing out on updated default values so hand written custom-set-variables forms it is.

Sounds a lot like me. I'm into my fourth year using emacs (or third, depending, as I started using Spacemacs for the first year), and am beginning to think about maybe switching to evil-less emacs...eventually. May I ask how many years it's been for you?

> I don't know. I don't think any lisp form is truly dangerous as long as it doesn't touch a file. Custom is entirely specific to Emacs (tho it can execute arbitrary lisp written by the user option author). Well yeah, ultimately all that'd happen is having to close Emacs, reopen it with `-q` if it's warranted, and removing the offending parts that could be causing problems (assuming some problems have been noticed). > Yes, I use multiple instances of it. I cannot be bothered to check whether an option has a setter so I have a billion custom-set-variables forms in my init.el. Similarly for me, just with `customize-set-variable` instead, being implemented via a macro I made to have `setq`-like usage similarly to `setq-local`/`setq-default` (my code is most similar to setq-default, as setq-local's is more complicated). > I would use the customise interface, since unlike most people I think it is a pretty good UI, but it simply writes whatever that is in memory to the file so you end up losing out on updated default values so hand written custom-set-variables forms it is. It is a nice UI, albeit with limited versatility & selectiveness as you say.

I think saying customise has limited versatility is a bit too harsh on the UI framework. If you have had a poor experience setting an option in customise, then the problem most likely is with the :type thingy for the option, not necessarily because of customise. I had one instance where the UI was to blame and that was then the type was an alist with the keys being characters; with that hint you would expect customise to use letters to print the characters but no it simply printed the number! I should send a patch to fix this but I'm not too eager to dig into the UI code...

> I think saying customise has limited versatility is a bit too harsh on the UI framework. If you have had a poor experience setting an option in customise, then the problem most likely is with the :type thingy for the option, not necessarily because of customise. True, the phrasing was less than ideal, but I didn't feel like making a wall of text that wouldn't quite be right either. I've actually written code using the customize system to provide a proper menu, and it is fairly versatile although it does have some limits (which could be extended further if I felt like actually extending the customize system). The selectiveness part is more closely the part I was commiserating with.

Somewhere around 5 years. I've been thinking about dropping evil and trying meow (I still like that modal editing), but I'm so used to all the vim ways that evil lets me have...

I don't think anyone reads that particular manual which is the problem. Either you read the Emacs manual or the Elisp manual. While in theory if you are a beginner to programming+Elisp you would read that Intro to Elisp manual, I don't think anyone does, hence it being in a sorry state. The actual Emacs/Elisp manual is generally very good.

Well the way you are "supposed" to do it is read the entire manual first, not search for this or that functionality like the internet. So you would have a rough idea what it's called and where in the manual it is. Just like you are "supposed" to read all of the manuals for all of the appliances in your house. No one does that of course, which is why people burn down their house from never cleaning their dryer lint and what have you.

It sounds like you haven't reached a high enough experience level yet. I mean, you shouldn't be "requiring" most packages at all, the packages should be autoloading.

> See the perrenial confusion about yank vs paste and window vs frame `apropos` specifically checks for common synonyms like `paste` maps it to `yank`. > That's not to say that "well Emacs needs to change all the archaic wording to my preferences", but the manual needs to better concede this huge language barrier in some way IMO. A small 'translation' section could help, for example. The tutorial, `C-h t` does explain windows and frames.

You can definitely do an awful lot more with Emacs of today compared to (X)Emacs of 2003 or even 2013.

I firmly believe that a plurality of Emacs users are "not technical" in the sense that they're not IT people. That's why I generally advocate using the customize interface as you can get a lot done with that alone.

>That's not to say that "well Emacs needs to change all the archaic wording to my preferences", but the manual needs to better concede this huge language barrier in some way IMO. A small 'translation' section could help, for example. And its called the Glossary.

Maybe the following articles are interesting for you: > They used a manual someone had written which showed how to extend Emacs, but didn't say it was a programming. So the secretaries, who believed they couldn't do programming, weren't scared off. They read the manual, discovered they could do useful things and they learned to program. [Source](https://www.gnu.org/gnu/rms-lisp.en.html) -- Or something about the maintainer of [Helm](https://github.com/emacs-helm/helm) > Tell us a little about yourself and your family, where you live, etc. > > I'm 55 years old, French, and I've been a mountain guide in the Alps since 1984. For 20 years I guided people climbing the greatest summits and walls of the Alps, as well as canyoning and via feratta each summer, while working in the winter as a ski instructor and guiding people climbing icefalls. I'm now living in the south of France with my family, guiding people only rock climbs. I started programming 12 years ago (in 2006) when I discovered how useful a computer is when you know how to use it! I learned by reading books and other people's source code. [Source](https://sachachua.com/blog/2018/09/interview-with-thierry-volpiatto/)

Fair statement about autoloading. It's an old habit because I've been coding long before package.el, and I like to be explicit about what extensions are being used to setup emacs on multiple machines. But recently I have started using the use-package ensure feature which is quite useful in this regard.

> sometimes that is not up-to-date with the current version That is the curse of the (future) generation(s)! Not just for Emacs users, but for anything in general. Information on the Internet never dies! People are unaware that some information is old, and are following obsoleted advices and learning things the wrong way due to this. In later years, I have seen this in other communities as well. It goes other ways around too, some "old ways" that might be still perfectly valid and maybe better than new ones are "forgotten" of fallen out of fashion for no good reason. For example, most notorious is insisting on using "header-only" libraries in C and C++ communities (in my opinionated opinion :)).

Are there uses where one is mandated over the other? I would like to actually make an alias called 'setc' to use instead of venerable 'setq' in my init file, which should I alias? (defalias 'setc 'customize-set-???) (put 'setc 'byte-optimizer 'byte-compile-inline-expand) In which cases should I use this instead of setq; can I generalize and use it in all cases? Can you two guys summarize your findings to a n00b like me, who is generally not using customize at all? If I would like to replace the sea of setq:s in my init file, which one should be used, and when is it mandatory or at least better to use customize-set-* instead of plain setq?

I think it gets read more than you think. I was reading that bit of the manual because I was trying to figure out if there was a way to remove customizations in a more standard way than just stomping around and deleting things in your init or customization file. Search engines return results to this file. If you happen to be looking for info on customization, this is where you wind up, and it is wildly unhelpful. But in general, I find the emacs manual to be of middling quality. The documentation on cl-loop is halfway decent, but fails to provide examples for fairly complex constructs, so there's a lot of guess and test. I had a problem that I couldn't figure out and I ended up asking for clarification here, and the explanation that I got from people here was absolutely necessary to understanding how cl-loop works, but wasn't in the manual in any meaningful fashion. I find for non-trivial bits of emacs, this is common.

By trying to pick easy examples, I have picked examples that are *too* easy. I didn't mean to imply that Emacs didn't do a good job of explaining yank vs paste or frame vs window specifically - those were just immediately obvious examples of the phenomenon. It's in other places where "what do you call this thing" rears its head.

Fair counterpoint. I'll try to remember to look at the glossary the next time I need something and see if that makes things any easier.

If you want that then alias `customize-set-option`. It sets only one option. You can use it in all cases to set an *option* value, and that's always preferable to using `setq` to do that. (It's of course not appropriate for setting a non-option variable.) See [this answer](https://emacs.stackexchange.com/a/106) to the question: *Advantages of setting variables with setq instead of custom.el?*.

I know I can become a lisp programmer if I want to. I don't ;)

Thank you for the answer and the link. That was informative read. Unfortunately I am now even more confused and not sure if I wl do the switch. But if I do it would be to customize-set-variables since I am not into setting things one at a time. I think we need a better solution than customize.

(I guess you mean `custom-set-variables`.)

[Info+](https://www.emacswiki.org/emacs/InfoPlus) can help you discover and get to [glossary](https://www.emacswiki.org/emacs/InfoPlus#GlossaryEnhancements) definitions. [`info+.el`](https://www.emacswiki.org/emacs/download/info%2b.el)

Thanks for the additional advice. Sounds to me that Info+ ought to be a stock package based on all the useful things I'm seeing that it does.

I guess that too :)

I actually learned how to put my settings under `use-package` which I find handy. Sometimes I still use the customize interface because some things are just too hard otherwise. But every once in a while I go through my `custom.el` and move some of the settings to `use-package` just for the sake of having everything in one place. I am not a programmer (and don't wanna become one), but I am an invested user! Also: love your website!

Yeah that's a good way to learn, too. Customize is a fine place to start, and use-package is a good place to end up.

Addendum to my other comment: info+ is unfortunately *not* a simple package install away. It requires jumping through far too many hoops to get it installed as a proper package (namely, in requiring *a whole separate package manager* to be installed). I'm not particularly keen on just downloading something like this and plopping it into my `.emacs.d` outside of the package system - that's just asking for things to get old and stale. Yeah, this is how you used to do it back in the day, but now it's 2022 and the package system has been in Emacs for a decade; I'm disappointed that there's seemingly resistance to using it. So unfortunately I'm going to just leave info+ unused and just try to explore better with the base info package.

>I firmly believe that a plurality of Emacs users are "not technical" in the sense that they're not IT people. Given the code quality of a fair amount of the MELPA packages, I tend to agree with you. Formatting, code organization, code style, tests, linting - people ignore best developing practices.

The reason, why I prefer dash/s/f, builtins (whether it's a elisp thing or CL one) often suffer from inconsistency and redundancy. The formers, designed with FP(mostly Clojure) in mind, are just more pleasant to work with.

That's not really what I was referring to when I said that though.

> [info+] requires jumping through **far too many hoops to get it installed** as a proper package (namely, in **requiring a whole separate package manager to be installed**). Huh? [`info+.el`](https://www.emacswiki.org/emacs/download/info%2b.el) is a **single lisp file**. Just save it to a directory that's in your `load-path` and put this in your init file : `(require 'info+)`. How hard is that? No separate package manager. No package manager needed at all. Just the easiest and oldest and most flexible way to load an Elisp file. > I'm going to just leave info+ unused Feel free.

I didn't say it was hard. That's just something I'd strongly prefer *not* to do: > I'm not particularly keen on just downloading something like this and plopping it into my `.emacs.d` outside of the package system - that's just asking for things to get old and stale It's about making sure that I don't run into a scenario where I've downloaded a random standalone library, forgotten I've done it, and then experience breakage down the line during Emacs upgrades, especially for a package like this that ends up advising a lot of functions because of the inherent nature of the package. I want to be able to `M-x package-list-packages`, hit a few buttons, and have it be able to update without needing to faff about with having to manually download and replace the thing. I will grant that `load`ing an Emacs Lisp file is fairly flexible and in some regards an easier method, but it can potentially cause friction in a way that bothers me. I want it to be a package so that it can be properly compartmentalized, tracked, and upgraded without much fuss. Your comment comes off in a very condescending way, as if you think I'm too lazy or dumb to "just" download the library as a standalone thing. I trust you didn't really mean to portray it as that.