Without meaning any offense to the OP, I think this is a pretty low bar for Emacs eye-candy... Nicolas Rougier's "Nano Emacs" [0], or his previous "Elegant Emacs" [1] are better examples. You can also get pretty far using variable-pitch mode for mixing fonts (for example in org-mode [2]).
The title is "my emacs eye candy", not "my emacs eye candy is the best emacs eye candy", there are definitely better "eye-candy" emacs setups out there than OP's, but it doesn't matter as it's not a competition, OP's emacs is still eye candy, good enough for some people. Thanks for pointing the others though
Especially regarding org mode I am always surprised about how most users use so little typography. Using the same settings for writing and coding seems counterintuitive yet most org modes I see in screenshots look pretty code-editorisch to me, and the styling options you mentioned are pretty much the only ones I know (missing Olivietti mode [1]) Most other note taking apps surpass here…
[1] https://github.com/rnkn/olivetti
I would argue that some typographic changes (eg right amount of white space, line height etc) might lessen the distraction that you get with visual clotting. It appears here, though, that not everyone perceived it that way..
The foremost reason for use of typography in this case should be readability and accessibility and not pretty (which by itself is not a bad thing either)
I like writing in a monospaced font—it helps me focus, and it's what I'm used to. That said, I have found delight in the ability to customize certain modes to use different fonts.
I keep two fonts: a "reader" font and a "normal" font: normal is all fixed-width, while reader has longer characters for e.g. em-dashes and arrows.
I have a custom Iosevka build [1] that I use to make these. (The only difference is the `spacing` option: full-fixed-width is "term", while the reader version is "normal"—confusing, no?) I make Emacs use one or the other with a little config. [2]
As a group, programmers do seem quite attached to monospaced fonts. For my IDE I have actually gone (I think) even further than you: I use a proportional (serif even!) font for all my programming, not just prose writing. It took a bit of getting used to, but now I've come to much prefer it over monospaced fonts.
Inverse for me, I use mono in places people traditionally use proportional fonts - after literal decades of looking at monospaced text (right back to DOS) it's just as easy for me to grok.
I want to switch to one of those Emacs candy looking setup, but it always ends up being a lot less fun once you have it installed and nothing works as you expects, the whole thing looks like grand father software and the UX is beyond bad.
Sure, if you put up with the pain of setting it all up, eventually, you have something that works and that only you can use.
I think it's worth it, if you are a tinkerer and if you look at that kind of software as a "Personal Development Environment" a phrase I first heard in this video[1]. So, yeah the focus is on creating software that is tailored to your requirements. If your requirements are that someone else has to be able to use it, because you do a lot of pair programming, then that's something to consider.
I've tried a lot of editors over the years... Currently I'm using neovim. It's been pretty nice--after some major adjustments. I like altering my configs and changing what's not working for me. Would I use it exclusively? No, but it's a nice tool to have in my toolbox. And with some effort it also can look very pretty.
You can try Doom Emacs if you want a solid starting point. (https://github.com/doomemacs/doomemacs). Emacs is so idiosyncratic compared to a lot of modern stuff people are used to, starting with a base like this may be a little easier than trying to do it from the ground up.
Both are very opinionated frameworks. Basically, they establish a convention for dealing with packages and custom config code, and build from there.
With Spacemacs, the expected default is to use Vim-style editing, with the addition of the Space key (hence the name) to access all of Emacs functionality. It's quite user-friendly and very discoverable. And it's still Emacs, so it offers a lot of customization.
Doom Emacs is a more focused approach, it has a clean set of defaults, and the ability to load lots of optional features. One key difference with Spacemacs is the use of an extra CLI utility to manage things such as package installation and config upgrades. Doom also disables customize-mode, which leads to cleaner configs at the cost of some discoverability.
Personally, I've been using Spacemacs for years, the key shortcuts just make sense to me, and it includes everything I want. I also love the default theme, the documentation is helpful, and the main drawback, long startup times, is minimized because I never exit Emacs.
Let me clarify that Doom Emacs is not "same as Spacemacs, but faster". This is probably one of the biggest misunderstandings about these two Emacs frameworks.
You can end up with a similar feature set using any of the two, and yes, Doom Emacs will probably be a bit faster, but they are not entirely equal. The user experience is different, one easy example is that while using SPC as a leader key is a feature in both, the keymaps are quite different.
My recommendation would be to try them both: they are easy to install, and uninstallation is as simple as removing the Emacs config in your user directory.
The extensibility and customizability of Emacs typically means that bad UX is user error. There is a barrier to entry, but if you don't want to go past that, it's no big deal. I'm not sure that's the editor's fault though.
Where is Xah Lee when you need him?
His critiques of Emacs on this are spot on, imo.
Helps that he backs up his claims (scattered around his site) with data and usability research.
"If emacs just use standard keys for open close save, cut copy paste undo, users will double in 1 year."[0]
Customizability is Emacs' selling point. A higher level of extensibility necessary means a higher learning curve. I'd call it a learning curve rather than "barrier": it's certainly not difficult to make Emacs look good. Most people don't care how Emacs behaves OOTB because they want to customize every aspect of it. You might say it should look or behave better by default, but I'd rather the base stay consistent and simple (it fits the use case better). There are plenty of starter kits/distros that look good OOTB for people who want a better default experience.
I don't think good UX is a universal concept. People have different preferences. On my desktop I don't want click to type. But still many seem to prefer just that.
I want a trackpoint, many are happy with touchpads.
(Of course some implementations can be classified as just bad UX...)
This is not really objective because you also have to take into consideration how intuitive/simple the UX is. Given 100 related actions, clicking through a logically grouped nested menu or multiple pages to do something is going to require more steps but be something anyone can do. Memorizing and using keyboard shortcuts for all those actions will be more efficient, but isn't something someone could immediately do. There is of course an in-between where you can have menus to display available keyboard shortcuts, but some (most?) people will still prefer a GUI/mouse-based approach. There is no one-size-fits-all approach.
Good UX is very subjective though. I mean for me the way Emacs looks by default and how it allows me to customize it the way I see fit is good UX. Others don't see it as good UX.
Can I customize the status bar to include my contextual information with a single line of code in VS Code? Perhaps not. So VS Code has bad UX for my needs. But many consider VS Code to have good UX.
Are our expectations so low now that developers can't be expected to put in a little effort to learn a text editor? Look, I promise I'm not the smartest guy, but I ground out a few weeks of memorizing key bindings like ten years ago, and that was basically it. M-x apropos and Google fill in the rest of the gaps. I truly don't understand why stuff like this seems to be so hard for people. My hunch is that they just don't want to put in the effort. Which is fine! But please just be honest about it.
Yea, I used to maintain a fairly complicated emacs config that I was never quite happy with. Nowadays, I just go with spacemacs. Tired of messing with stuff :)
I went the opposite way. Used Spacemacs to introduce me to Emacs, and then got rid of it once I got the hang of things, and noticed all the extra packages I don't need that were just impacting (the already poor) Emacs performance.
A few years later, I'm still using my config and wouldn't go back. It's what allows me to make Emacs _mine_, after all. It requires a minimal amount of maintenance, mostly whenever I decide to upgrade the packages.
Is base Emacs performance actually poor? I’ve generally found it to be pretty quick and it performs well in environments that other programs totally fail in, eg in a terminal or over X forwarding.
Well, it depends on your system. In my experience, Emacs without native-comp is way snappier on Linux than on Mac and Windows -- and getting native-comp working is also much easier on Linux, which has a big impact. Large numbers of pixels (high-DPI / Retina displays) can increase stuttering and flickering in the GUI version, in which case performance can improve by using `emacs -nw` in a GPU-accelerated terminal (Kitty/Alacritty), or maybe by switching to a different GUI frontend (e.g. the NS Port vs. Mac Port on MacOS, or the X11 vs. PGTK version on Linux).
Similar experience. Not limited to emacs, I used to spend a lot of time to configure my desktop. Nowadays I go with stock XFCE on machines I use occasionally or shared with others and i3 on my main machine. No configurations. In emacs profile I have very few settings to get the indentation required by company style and avoid trailing whitespace / missing newline at the end. That's all.
Your setup sounds exactly like mine. No-config i3 is nice. You might take a look at Regolith Linux, but that's unfortunately built on top of Ubuntu. I run Arch, so this might be useful at some point [0]. I might give it a go on my work laptop.
I always come back to eMacs at least once a year, fall in love with some of the functionality, then rediscover that every package only works for 80% of my use cases and requires extensive configuration, and after spending hours customising it I have a slightly inferior product to any other IDE because a) some things still don’t work and b) nobody works with eMacs, so there is zero interop. Too bad..
I work with Emacs. I also find that magit and org mode are great examples of doing things better than other tools. Biffer management is another thing. I find it to be superior to handling tabs. vterm and shell are also incredibly helpful. vterm for when you need ncurses or self updating output, shell when you do not and want to easily copy paste from output. Vterm can copy paste too but needs a key combination to switch between modes.
There is at least editorconfig for sharing config with other editors a little.
Yeah org mode would be great. But please tell me how you actually make your org mode calendar sync 2-way with your outlook, gmail and Apple calendars.
Because if it doesn’t that feature is completely useless to me. Same with LSP. That works great in every ide, but with eMacs you have to do custom configs and still half the stuff doesn’t actually work.
I adopted two tools early on and have used them for decades: Emacs and LaTeX/TeX. Both are programmable and have an amazing set of available extensions that enhance their use. As a computer scientist it’s easy to spend time tweaking either of these flexible systems. I have to keep in mind that at some point I need to stop sharpening my axe and start chopping wood.
LaTeX takes a lot of study to become expert in it, but there are books that help. Emacs, on the hand, can be learned from the inside through its great help functionality (starting with the easy to remember Ctrl-H).
My emacs setup is pretty much eye candy free. I remove scrollbars and menus because I never use the mouse and mode-line linenumber and % of file is usually fine.
Zone seems like fun, but I would never activate it.
Do not underestimate the usefulness of the context-based menu bar. It will save you an apropos on many occasion, and open your mind to new actions that you missed on the first skim of the package methods.
I would probably be considered an Emacs power user: I have used it for years as my daily driver for professional programming in many languages; I have an extensive custom config; I have published several non-trivial packages.
But I still had no idea that zones existed until today.
> Even better if you make it single pixel wide, something I like from VSCode. This way, it works nicely with rainbow colors in dark mode too.
I could, but on top of my head, this would require using ASCII blocks characters for the 1 pixel vertical lines, which would break your regular copy paste (ex: shift + mouse) if not using vi visual mode (not a big fan personally).
My current solution uses the background color of regular spaces, so you can copy/paste without any issue, and without having to strip characters from your copy paste buffer (like with wl-copy / wl-paste)
> EDIT: applying the grayscale color to the background would be another direction, it also looks nice:
Indeed, and this could also be made more reliable by using the vt52 underline toggle, and using different colors/grayscales for the underline: it wouldn't break the copy/paste, but you would be missing the vertical lines, so it wouldn't be exactly a block :(
Otherwise it'd have to use sixels: you could do nice things like rounded angles, but this would restrict your choices of terminal.
Anyway, lmk if you need any help to setup either. I'm a bit busy rn but I should be able to provide you at least some suggestions on how to do it for your specific usecase, with minimal negative side effects (like breaking copy-paste :)
I’ve turned off nearly everything in my Emacs. Fullscreen, no scrollbars, minimal frame borders, modeline hidden. My only sadness is that you can’t completely reclaim the echo area when it’s not in use. But one thing this has always helped me ensure is that if I want something, I learn how to go there, directly. No scrolling around and rummaging.
I haven't tried it recently, so it's quite possible it's broken but this package has an autohide behavior for the echo area: https://github.com/honmaple/emacs-maple-echoarea You might be able to adapt it.
OP here. The linked tweaks are straight from my config. I can try help work out why it doesn’t look the same for ya. Would need to see your elisp snippets. May be easier to discuss on GitHub. Maybe open an issue on https://github.com/xenodium/dotsies
The other add-ons, changes and additions probably play a role, too.
On a personal note this is one of the things I disliked about emacs, too: its configs are non-deterministic :) You find a nice config somewhere, or do the same changes,... and your emacs still looks and behaves differently.
Sounds like all these starter packs need to use purely functional package managers like straight.el (or the newer elpaca) who has the ability to pin to exact commit hash of the third party packages. Afaik, Doom Emacs does exactly that, and it doesn't have such reproducibility issues?
Theoretically, another source of deviation might be different distros shipping different builds of Emacs using different flags, resulting in things like different graphics backend (like GTK vs pure X11). I am not sure if this is a legitimate concern in practice, but using something like Nix or Guix might eliminate even that.
I've had some success asking it to write me basic elisp functions to perform basic transformations of data or do stuff for window management. It starts hallucinating when I involve 3rd party packages, though.
You have to fill in some gaps (and occasional paranthesis) but it’s pretty darn good at writing elisp for improving your config. I find it’s helpful enough that you can take on medium hanging fruit that you wouldn’t attempt otherwise.
For example, I wrote a minor mode for centering text, an org-export backend for Notion, and some plumbing for chatgpt-shell.
GPT-4 is generally excellent. If you have errors, you can often ask it to fix them. GPT-3.5 is not so good.
I recently asked GPT-4 to write an elisp function that would automatically query GPT using an openai client and insert a docstring written by GPT for any Python function under the point. It worked on the first try!
My approach to my terminal tools is to avoid eye Candy as much as possible. It distracts and complicates without adding value. Eye candy often is not easily portable, and it can break.
I use color very intentionally to mean something. The only time I theme something is if it’s already themeable and I can set the theme to use 3 bit terminal colors so I can drive all themes from one place (my terminal profile).
I have a very similar Nyancat progress bar plugin for IntelliJ that I love. I'm a Cursive guy for Clojure but also always wanted to spend the time learning some emacs
[0]: https://github.com/rougier/nano-emacs
[1]: https://github.com/rougier/elegant-emacs
[2]: https://github.com/minad/org-modern