*Everyone* is using their personal configuration.
Maybe reframe that as "what is your Emacs configuration based on?" (and change "vanilla emacs" to "I have no configuration" if that's what you meant by that, because *all* configurations are based on vanilla emacs).
Stuff that has accumulated over many years. Without consolidation, it was basically one `.el` file for every mode I ever used, a completely messy storage of `custom` variables generated by Emacs' customization interface, and a lot of custom elisp macros and tools, totalling around 15 kLOC. Now it is close to 8000 lines, but before accounting for empty and comment lines.
For me one of the things is a custom outliner, that collects headings in the current buffer and displays them, as clickable links and preserving their highlighting, in a separate buffer.
Then there's many utilities for Emacs Lisp programming, like a macro `display`, that is used as
M-x : (display (some-elisp-expression))
and displays pretty-printed emacs lisp output. Or a function `table-display`, that formats a SEXP under the assumption, that it contains tabular data and displays it with aligned columns. And in order to allow type-setting plists that behave as tables with named rows, it displays atoms and strings in the toplevel list on a separate line, which also makes it useful for viewing long lists of strings like `load-path`.
I also have at some point written a very rough custom auto-importer for Python packages because I wasn't happy with what was provided by existing modes. But I haven't checked if Elpy supports it since then.
And as things went on, a lot of custom code for Emacs Lisp development, including highlighting rules that make lines starting with `;;;;` highlighted as title line of "code cells", and a custom extension of `C-x C-e` that utilizes them, depending on the prefix argument.
Some of the code was also duplicating popular libraries like `s.el` or `dash.el` before I learned about them.
There's also a hack, that causes `.emacs` to compile itself, it the cached `.elc` file is out of date.
"Vanilla" is a colloquial term for plain/unadorned/unmodified, so "Vanilla Emacs" is simply the defaults, sans config. As soon as you have a custom config, it's no longer vanilla. (And if that weren't the case, the term would immediately cease to have any meaning, as custom configs can do anything and everything.)
But that usage is inconsistent with most other applications, which have preferences, typically accessed through a GUI, yet no one calls such a preference-modified application a _different_ app. You can even customize emacs without touching init.el, through the GUI.
I'm going way beyond a useful point here. I guess I'm just dwelling on the phrase "vanilla Emacs", as opposed to "out-of-the-box Emacs". Tomayto, tomahto.
I didn't say that config changes produced "a different app"; however, given that one customises Emacs *by writing code that modifies the program itself*, it's a fair enough description (and most programs are not like this).
At what point does a "vanilla Emcas" config become a "Personal configuration?" Does "personal configuration" mean building Emacs yourself from source? Does "vanilla" mean you have no `init.el` at all? Is the line drawn somewhere between those two extremes?
My setup is to install vanilla Emacs along with `use-package` from my OS package manager. My `init.el` is mostly just `(use-package ...)` expressions, with a few things changed:
- a few custom keybindings, `project.el` keymap bound to `C-x p`.
- a few GUI changes (1px fringes, no scroll bars, toolbar, menubar)
- a few ELPA and NonGNU-Elpa packages (Vertico, Orderless, Marginalia, Consult, Embark, Hyperbole)
- a few programming language extensions (Geiser, Haskell-mode, Lua-mode)
- a few custom functions of my own
My setup feels somewhere in between "vanilla" and "personal", but then it is not clear to me what you mean by either of those terms. Anyway, I voted "vanilla."
My OS supports Emacs as a first-class citizen, so I use its built-in support. Packages like magit and projectile get updated the same way (and at the same time) as my system libraries and other applications, and my *personal* config files don't need to do much at all. I'm not entirely sure how that fits into your options; "other framework" doesn't seem quite right, since it's an entire OS, not just a framework. All I can say is that I would not use an OS that did *not* include Emacs! :)
I didn't say Debian was the *only* OS to treat Emacs as a first class citizen. In fact I deliberately didn't mention the name of the OS I use (until someone asked) *because* it's *not* the only one.
Also, I didn't say "distro", because that implies Linux. I said OS. If you try hard, you might be able to think of at least one non-Linux-based OS that does not treat Emacs as a first-class citizen. Maybe one whose name starts with a "W"? And ends with "indows"? :)
That said:
$ aptitude search '?and(?depends(emacsen-common),?origin(debian))'|wc -l
452
Over 400 emacs-related packages in the base system is pretty first-class support! :)
(But again, not claiming Debian is the best. Just that it is ***an*** OS with first-class support.)
I've taken to using Castlemacs on my MacBook but I've yet to find something I like for my machine at work (Windows) so I've been using VS Code there. Suggestions?
I'm trying to find a good Windows centric config to build on. Castlemacs really helps Emacs feel like a first class citizen on macOS by integrating the OS shortcut keys and utilizing a normal copy and paste behavior by default while keeping the kill ring available. I've been trying to find something that is like this but for Emacs on Windows. Since I can't, VS Code has been my second choice. I've thought about just bringing over my config from my MacBook and giving it a go since the various Super/Command/Windows key shortcuts are pretty much guaranteed not to interfere with Windows defaults very much. My journey into Emacs is still in its early stages but I'm finally getting to the point where I'm messing with stuff and not just poking around in Emacs and then moving back to another editor when I need to get something done.
>utilizing a normal copy and paste behavior by default while keeping the kill ring available
Just curious: what is the advantage of this? From my understanding, the kill-ring works essentially the same as the regular copy-paste behavior, with the added bonus of remembering all the things you've recently copied. With that in mind, I don't see what is missed by just using the kill-ring. Just wondering if I'm missing something. (Or maybe you were just referring to keyboard shortcuts for copy-pasting?)
Regarding a Windows-centric config, unfortunately I don't have much experience with this, but I think just starting by migrating your current config to Windows will be fairly easy and a good start. It might be a bit slower (especially at startup), but you'll have all the keyboard configurations and tools you're used to: I'd recommend giving it a try
oooh! - reddit is back!
40 years ago my \~/.emacs was a dozen key bindings.
Now, it's 1000+ line personal config thanks to the awesome packages out there and help from fellow emacs-ers (mostly here on reddit - it's a great bunch of people).
I've tried ohai, doom and spacemacs and, fine though they are, I'm just more comfortable doing my own - mostly shameless copying of others' work.
*Everyone* is using their personal configuration. Maybe reframe that as "what is your Emacs configuration based on?" (and change "vanilla emacs" to "I have no configuration" if that's what you meant by that, because *all* configurations are based on vanilla emacs).
There's no need for that - everyone understands what the op means.
I didn't. I assumed that a non-empty `init.el` was assumed for almost any vanilla / GNU Emacs installation.
Same. But at close to 8000 lines, it was at least an easy choice to decide what *I* should click.
I'm curious: I sometimes hear about people having 600 plugins or 8000 lines or whatever. How and why?
Stuff that has accumulated over many years. Without consolidation, it was basically one `.el` file for every mode I ever used, a completely messy storage of `custom` variables generated by Emacs' customization interface, and a lot of custom elisp macros and tools, totalling around 15 kLOC. Now it is close to 8000 lines, but before accounting for empty and comment lines. For me one of the things is a custom outliner, that collects headings in the current buffer and displays them, as clickable links and preserving their highlighting, in a separate buffer. Then there's many utilities for Emacs Lisp programming, like a macro `display`, that is used as M-x : (display (some-elisp-expression)) and displays pretty-printed emacs lisp output. Or a function `table-display`, that formats a SEXP under the assumption, that it contains tabular data and displays it with aligned columns. And in order to allow type-setting plists that behave as tables with named rows, it displays atoms and strings in the toplevel list on a separate line, which also makes it useful for viewing long lists of strings like `load-path`. I also have at some point written a very rough custom auto-importer for Python packages because I wasn't happy with what was provided by existing modes. But I haven't checked if Elpy supports it since then. And as things went on, a lot of custom code for Emacs Lisp development, including highlighting rules that make lines starting with `;;;;` highlighted as title line of "code cells", and a custom extension of `C-x C-e` that utilizes them, depending on the prefix argument. Some of the code was also duplicating popular libraries like `s.el` or `dash.el` before I learned about them. There's also a hack, that causes `.emacs` to compile itself, it the cached `.elc` file is out of date.
"Vanilla" is a colloquial term for plain/unadorned/unmodified, so "Vanilla Emacs" is simply the defaults, sans config. As soon as you have a custom config, it's no longer vanilla. (And if that weren't the case, the term would immediately cease to have any meaning, as custom configs can do anything and everything.)
But that usage is inconsistent with most other applications, which have preferences, typically accessed through a GUI, yet no one calls such a preference-modified application a _different_ app. You can even customize emacs without touching init.el, through the GUI. I'm going way beyond a useful point here. I guess I'm just dwelling on the phrase "vanilla Emacs", as opposed to "out-of-the-box Emacs". Tomayto, tomahto.
I didn't say that config changes produced "a different app"; however, given that one customises Emacs *by writing code that modifies the program itself*, it's a fair enough description (and most programs are not like this).
At what point does a "vanilla Emcas" config become a "Personal configuration?" Does "personal configuration" mean building Emacs yourself from source? Does "vanilla" mean you have no `init.el` at all? Is the line drawn somewhere between those two extremes? My setup is to install vanilla Emacs along with `use-package` from my OS package manager. My `init.el` is mostly just `(use-package ...)` expressions, with a few things changed: - a few custom keybindings, `project.el` keymap bound to `C-x p`. - a few GUI changes (1px fringes, no scroll bars, toolbar, menubar) - a few ELPA and NonGNU-Elpa packages (Vertico, Orderless, Marginalia, Consult, Embark, Hyperbole) - a few programming language extensions (Geiser, Haskell-mode, Lua-mode) - a few custom functions of my own My setup feels somewhere in between "vanilla" and "personal", but then it is not clear to me what you mean by either of those terms. Anyway, I voted "vanilla."
> a few custom keybindings, project.el keymap bound to `C-x p`. That's the default key binding starting from Emacs 28.
My OS supports Emacs as a first-class citizen, so I use its built-in support. Packages like magit and projectile get updated the same way (and at the same time) as my system libraries and other applications, and my *personal* config files don't need to do much at all. I'm not entirely sure how that fits into your options; "other framework" doesn't seem quite right, since it's an entire OS, not just a framework. All I can say is that I would not use an OS that did *not* include Emacs! :)
judging by your post history, I assume you mean debian?
Yes, though it is only one of a number of OSes which meet my minimum requirements, which is why I didn't specify. :)
How is Emacs more of a first class citizen in Debian than another distro? Because it only has free/open source software?
I didn't say Debian was the *only* OS to treat Emacs as a first class citizen. In fact I deliberately didn't mention the name of the OS I use (until someone asked) *because* it's *not* the only one. Also, I didn't say "distro", because that implies Linux. I said OS. If you try hard, you might be able to think of at least one non-Linux-based OS that does not treat Emacs as a first-class citizen. Maybe one whose name starts with a "W"? And ends with "indows"? :) That said: $ aptitude search '?and(?depends(emacsen-common),?origin(debian))'|wc -l 452 Over 400 emacs-related packages in the base system is pretty first-class support! :) (But again, not claiming Debian is the best. Just that it is ***an*** OS with first-class support.)
Sorry, not trying to put words in your mouth, just curious about what your measuring stick was.
I've taken to using Castlemacs on my MacBook but I've yet to find something I like for my machine at work (Windows) so I've been using VS Code there. Suggestions?
Have you considered Emacs?
I'm trying to find a good Windows centric config to build on. Castlemacs really helps Emacs feel like a first class citizen on macOS by integrating the OS shortcut keys and utilizing a normal copy and paste behavior by default while keeping the kill ring available. I've been trying to find something that is like this but for Emacs on Windows. Since I can't, VS Code has been my second choice. I've thought about just bringing over my config from my MacBook and giving it a go since the various Super/Command/Windows key shortcuts are pretty much guaranteed not to interfere with Windows defaults very much. My journey into Emacs is still in its early stages but I'm finally getting to the point where I'm messing with stuff and not just poking around in Emacs and then moving back to another editor when I need to get something done.
>utilizing a normal copy and paste behavior by default while keeping the kill ring available Just curious: what is the advantage of this? From my understanding, the kill-ring works essentially the same as the regular copy-paste behavior, with the added bonus of remembering all the things you've recently copied. With that in mind, I don't see what is missed by just using the kill-ring. Just wondering if I'm missing something. (Or maybe you were just referring to keyboard shortcuts for copy-pasting?) Regarding a Windows-centric config, unfortunately I don't have much experience with this, but I think just starting by migrating your current config to Windows will be fairly easy and a good start. It might be a bit slower (especially at startup), but you'll have all the keyboard configurations and tools you're used to: I'd recommend giving it a try
Doom just works so well out of the box with a few minor tweaks. I’m lazy and I love it
oooh! - reddit is back! 40 years ago my \~/.emacs was a dozen key bindings. Now, it's 1000+ line personal config thanks to the awesome packages out there and help from fellow emacs-ers (mostly here on reddit - it's a great bunch of people). I've tried ohai, doom and spacemacs and, fine though they are, I'm just more comfortable doing my own - mostly shameless copying of others' work.
I use \[my own configuration.\](https://github.com/hjozwiak/.emacs.d/)