Since Steve Purcell loves new technologies and update his setup
frequently, it may be a little harder to follow him for beginners.
That’s actually great. I’m lucky to stick to his setup because pulling
from his git branch gets me updated with the latest cool things in
community.
When I say “on the shoulders of giants”, I’m stressing that you need
set your standard higher. I’m NOT saying the master’s setup is “newbie
friendly”. If it happens to be “friendly”, it’s just the coincidence.
Also, cargo culting everybody to use the Evil mode for Vim bindings in Emacs is also probably bad advice, unless you are teaching emacs to a vim user.
As a beginner, you are better off starting your emacs config from scratch.
Some of the opinions of the author have been stated as facts:-
...every master uses the package smex to remember keybindings
Mickey walks you chapter by chapter, while you build your own emacs configuration as you learn new things.
Once you have worked through that textbook, you will find it a piece of cake to study other people's configurations on github and learn more.
If you are looking for motivation to learn emacs, watch the short 2 minute demo videos on the Youtube Channel @EmacsRocks
The Paul Nordstrom comment is so funny to me. I joined his team in (I think) late 2000 to build the distributed system that moved Amazon from the single (massive) monolithic binary. I was using vi at the time and I could see him physically cringe when he stood over my shoulders watching me move through code. It's like he was in pain.
He told me (a 23-year-old) to pick an editor and learn it well. He said vi was fine but he didn't know it well and couldn't really help me. But if I wanted to learn Emacs he would help me. So, he brought me up to speed. He sat behind me and helped me through the basics. He helped me set up a usable .emacs file. When we would sit at his desk he would tell me what he was doing with Emacs so I could see how a ninja would do things.
23 years later I still use Emacs and I am still learning new things.
It's people like Paul that really make a difference for junior engineers.
He got me about five years later. I had used emacs in college so it was a smoother transition. Still my only editor today. I have failed to pass emacs knowledge on to the next generation so far.
Is it because the vi-type editors are a lot better or VSCode or just the whole IDE thing (not sure if this is still a thing these days)?
Becoming productive with Emacs should take you a couple of weeks. At least that's what it took my dumb 19 year old self back in the day. Mastering emacs? I don't think you should be expected to do such thing.
> At least that's what it took my dumb 19-year-old self back in the day
That's the one thing I miss about being a teen: few enough other options that I'd stick to things to mastery instead of giving up and reverting to the tools I already know once things hit my frustration threshold.
Back in my larval stage I adopted Emacs because it was considerably more “intuitive” than vi and wasn’t a joke like pine. I found it suitable for writing C and xpilots[1] configs out of the box and went from there. It did help that I was mostly in a college CS lab so there were people to ask questions.
The content here is that they’ve:
- Done the built-in tutorial;
- Picked up somebody else’s Emacs and a few packages.
That’s two hours, maybe, if you go slow and have a few beers in the meantime. I wonder what they did for the rest of the year.
I'm not sure I agree with the necessity of mastering Emacs, or specifying a time frame for getting it done as the title of the article implies. I've used Emacs alongside of vi for editing since the 1990s. I'm no expert at using Emacs, but that's never really mattered to me.
On the other hand Emacs is a key part of how I use computers. I read email, use the calendar, and edit text of all kinds. I use outline mode, and now Org mode to help organize and author text. I'm also a long time user of, and occasional author for info mode. I still tend to use vi for quick edits of line oriented text. For everything else I use Emacs.
I'll suggest new users simply use the built-in tutorial to get started with GNU Emacs, and learn the new features as time goes by, and your needs change.
Related:
Master Emacs in one year - https://news.ycombinator.com/item?id=16424934 - Feb 2018 (5 comments)
Master Emacs in one year - https://news.ycombinator.com/item?id=8079083 - July 2014 (116 comments)
The focus on leaning on “giants” and not being creative is a bit too much for my taste.
I kind of get it, but it feels off.
“Those giants are more intelligent than me. They are harder working than me. How can I reach their level as quickly as possible?”
Not by blindly copying everything I imagine, but I could be wrong.
"First, you copy the master. Then, you master the master"
Can't find the source of the quote but it was about the Chinese approach to learning.
To follow the path
Look to the master
Follow the master
Walk with the master
See through the master
Become the master
Yes, you copy it (do what they did). Not take photographs of their work.
Copying the setup of an emacs guru sounds like a great idea to me. Think of it as using a Linux distro instead of building your own Linux from scratch. What turned me off of emacs as my daily driver, after using it from college through the first ten years of my career, was the large number of packages that came highly recommended by the community but which were half-baked or required debugging and subtle adjustments to coexist with other packages.
When the author says:
> Don’t try to be “creative” at this stage.
What he means by that is that if you try to configure emacs yourself, without yet being a master, half of the functionality you try to use will be broken, and you'll spend countless hours reading code and figuring out how to fix your broken setup. This is the traditional way to master emacs: by going back and forth between writing your own modifications and struggling to incorporate other people's code. Tackle every challenge head-on, and solve them one by one to make emacs do what you need. The daily effort to do turns you into an emacs master, like turning the wheel of pain turned the boy Conan into a 1970s bodybuilder.
I don't think that's a wise or attractive route for new emacs users today. Nowadays, everything I could do in emacs I can do with other freely available software as well, and I have to ask myself whether it makes more sense to invest the time figuring out how to do it in emacs, or to install an easier and more polished special-purpose tool. When my workflow revolved entirely around emacs, it made sense to make the extra effort. But over time my workflow fragmented, until the extra effort never made sense, and my emacs setup stopped growing.
Copying the setup of somebody who has already invest the time to get everything working together sounds like a nice compromise.
I doubt it'd take a year. Just remember, `C-h` is your friend, and there's no shame in using Doom / Spacemacs. Even if you're a vim devotee you can switch full-time to linux, thanks to `evil`. Emacs has a much better GUI than vim / gvim and related.
Starting with vim keybinds, you can be very productive in just an afternoon, because `evil` is extremely comprehensive in mimicking vim. After that, you'd want to learn some elisp, and making small functions with the basic `let` and `interactive` forms will get you up to speed. A year is overkill. You can start being productive in emacs in less than a week.
Emacs it's bearable with persp-mode. If you set the global keybind to C-c C-w (as it was with some former buffer manager) you'll find yourself using C-c -C-w b more than C-x b, because it will show you the isolated buffer per "pane" a la Screen/Tmux.
You can use the first pane for editing, the second one for eww, another one for programming, one more for M-x calc (and the GNU info help page) and so on. Much better than cluttering your buffer list.
C-c C-w s to create a new pane, and C-c C-w C to destroy it, and C-c C-w ? in order to get help. That's it.
I second „persp-mode.el“ to be a great early addition to your default setup. I usually do that to separate front end from backend code or source files from remote terminals and/or error logs.
Wherever I can I use default key bindings which actually helps me with remembering. In this case I stuck to „C-x x“ as a prefix key combo.
I would also suggest to first install „which-key.el“ which will make Emacs display a list of possible key bindings from where from the key combo you just typed. This way hitting „C-x x“ will give you a menu displaying all possible persp-mode actions and will become second nature.
I find that with project.el (or projectile) buffer handling per repo works fine without having to separate things into frames. I often have hundreds of buffers open after a while and finding the right one is rarely a problem.
I’ve been using vim for 3-4 years now, and I’m very comfortable in the vim ecosystem. Trying out emacs has been in my mind for a while, but I’m not sure if it’s worth the time investment.
I used (and use) vim for over a decade.
I've used emacs for probably over a year now.
I'm glad I learned modal editing with vim, but with doom emacs there is nothing I miss from vim, except maybe `ctrl-p`, `projectile` isn't as good in certain cases, but it's good enough.
In my opinion emacs is just better for everything, and if you know vim well enough doom will take 10 minutes to learn to use. Those 10 minutes are the install. Most vim commands will _just work_.
I‘ve also been using vim for ~3yrs now, editing small programming projects and all kinds of text in it (like config files). Never had a need for emacs until a couple weeks ago I started working at a project involving a lot of meetings and writing a TeX report. I experienced that emacs, used in the auctex and org modes, is helping me a lot with that because the available commands simplify the workflow (like `reftex-citation`).
Why has trying out emacs been on your mind, if I may ask? If it‘s just for fun, go ahead. If it‘s because you think aspects of your workflow could be optimized, take a look at the several modes emacs has to offer. Otherwise, I would just stay with vim, tbh.
Once you go Emacs, you never go back.
I started on vim. Switched to emacs for a couple years, then switched back.
The biggest issue with emacs for me is ergonomic. It relies way too much on the pinkie finger for everything and it gets really painful when you get RSI in your pinkie. It’s fine if you’re going slow and taking your time with things, but then why learn a complicated editor in the first place if you’re just going to go slow?
Yes, I tried evil mode for a while as well. The problem with that is that it’s, well, evil. An unholy alliance of drastically different paradigms, the setup just becomes way too complicated. You lose the main advantage of emacs modelessness and are back to switching modes like vim, only now you also have all of the emacs key bindings to deal with. Why not just go back to vim and simplify your life? That’s what I did!
Well, if your pinky is such an issue why not bind „C-“ to caps lock instead? I‘ve heard many people doing that and be happy w/o the effort of learning the evil mode framework (which I wouldn’t suggest beginners doing despite many prominent Emacs evangelists using evil).
I still mostly use vim but when I use emacs I prefer plugins like meowmode or godmode which essentially make the modifiers sticky so you dont need to chord.
It's really easy to use a different key for that. Pretty sure the keyboards it was written for had a different layout to today's off the shelf ones.
I have swapped "C-" key with "~". I can type all the "C-key" shortcuts with flat hand and it just feels right(at least to me).
I moved to emacs (with its own keybindings) after using vim for a decade.
Learning something new and very different to what you are used to is always worth the time investment. It doesn't mean you have to necessarily leave vim.
Start with Doom Emacs, you get sensible defaults out of the box and familiar vim bindings, but with all the emacs goodness
You can just use it for note taking and as an outliner (orgmode) and keep using vim for programming.
Alternately, spend a weekend learning VS.Code and get on with doing real work.
(I spent 20+ years with emacs, including writing one of the first popular HTML modes in 1993. We have better tools now!)
"real work" "better tools"
Data point: I do real work in emacs (people pay me money for it). I haven't written any major emacs modes (use-package desired-feature) is it for me. I've looked at vs code (to get personal experience e.g., gitlens is nice though I mostly use magit plus several "feature" packages). Emacs is much better tool for me: I have an order of magnitude more notes than corresponding code (org-mode is life changing), say, 300 lines of notes per 30 lines of code.
I have many of my colleagues use vs code--expectedly, I don't see the "betterness." Ultimately, I don't care what tools do you use as long as the results are acceptable.
Though, I don't understand why someone would use less powerful tools long-term. Given your 20+ years experience, it is interesting to see some specific examples.
Often, I enjoy running emacs (and vim) in a terminal. (And, by the way, as we all know, “VSCode” stands for “Eight Gigabytes And Constantly Swapping.”)
More like 5 minutes. Install the extensions for your programming languages and frameworks of choice (who conveniently embed LSP), learn Cmd+Maj+P to get the global command palette, and start working.
That's funny. I actually come from VSCode. I grew so sick of it that I decided to try Emacs. I hadn't done it because I always saw it as a meme because I always heard jokes about it.
I was horrified for months. How did no one tell me how much better Emacs is over pretty much everything and especially VSCode?
In terms of brilliance, VSCode is a photon or two. Emacs is the Tarantula Nebula.
I use VSCode and Jupyter for writing code, but I always have emacs open for doing edits that would be time-consuming and onerous in VSCode, Jupyter, or my rich database client. I feel caught between the failure of text editors to become rich tools, and the failure of rich tools to become good text editors.
If you spent 20+ years with Emacs, you should probably know to not compare it with VS Code. Emacs is more comparable to Bash than IDEs.
There is something fundamentally wrong with a UI/UX that takes a literal year to master. I can’t think of a better argument against learning emacs than the title of this submission.
In reality, Emacs has the gentlest UI/UX of any Unix tool. Emacs has tutorials built-in, is 100 percent documented and all of the moving bits and pieces are discoverable.
The problem is people don't use it's disoverability or built-in help.
They do a web search that quickly gives bad to poor advice.
Nonsense. Just like with any software you can be perfectly productive in an afternoon but actual mastery takes time. For instance, for Microsoft Excel the title would probably be "Master Excel in two years"
Would you please show me a tool with a better UI/UX that can do all the things that emacs can do?
Orgmode Magit Dired EXWM . . . this rabbit hole is an endless pursuit of higher and higher efficiency.
BTW, the UI/UX is quite customizable with basic elisp fu, using say Helm, Ivy etc.
For code editing, pick your IDE. For mail reading, pick your mail reader. For todo, pick your favorite todo app. They’re all better UI/UX.
I prefer JEdit to Emacs for a programmable editor, but I mostly just use IntelliJ anyway. JEdit carries the philosophy of Emacs, but the UI isn't stuck in the 70s.
I just read the JEdit.org homepage.
I am really intriuged by this comment over there and also your recommendation:
jEdit is a mature programmer's text editor with hundreds (counting the time developing plugins) of person-years of development behind it.
It’s a productivity tool. It also takes months or years to master a professional video editing software like Adobe Premier, or 3D graphics software like Blender. People take time to learn because it’s worth it.
It’s a text editor, mail reader, todo manager, etc. none of those things should take a year to master, even in aggregate.
Yep, exactly. So obviously that is not the case.
I would not imagine mastering VSCode or any Jetbrains suite product to take any less time.
This. Jetbrains is also awesome but you don't just pick it up and msater it in short time.
I agree. But you should learn Emacs anyway, because mastering such a powerful tool, even if it takes a long time - and even if you don't really need it - is FUN!
I did and I regret it.
I guess programming [1] isn’t worth learning, then?
“UI/UX”
"Mastering" emacs (certainly any version of "mastering" it that takes a whole year) requires learning a programming language, elisp. This is because emacs isn't an editor. It's a language and environment for rapiy developing textual user interfaces (TUIs) and "customising" or "configuring" it is programming. To just learn to operate it as a text editor certainly doesn't take a year, but if that's the approach you're going to take I wouldn't recommend emacs. Use VS Code or a JetBrains IDE or whatever instead.
The linked article isn't very good, BTW. If you're interested in actually mastering emacs, the book "Mastering Emacs" [1], whose author comments here regularly, is the place to start.
That certainly wasn't the intention of that sentence.
Re "has no value" - wevs. It has massive value to me and to a community large enough to have continually supplied me with new and useful functionality and resources for 20 years, most of which have been spent using it alongside either Visual Studio (not "Code") or a JetBrains IDE (mostly Rider, some PyCharm). You use whatever tools you like and I'll decide what tools have value to me.
I think a programming language can be viewed as a UI and having a UX: - UI: It's a text based UI that is lazily evaluated (that is, there is always some compilation and/or execution to specifically run for the commands to execute. This UI would fit a certain model of computation, itself being a domain and use-case. - UX: The ergonomics of a programming language, like it's usefulness, accessibility of concepts, its surrounding toolchain, is part of the experience of using this interface to the computer. There is also talk even here on HN about PL features and their utility. That, to me, is a form of user experience.
I say this because I think about a programming language's toolchain as the make-or-break aspect of its utility of a language. Can I interface with it well enough without anxiety or anger? :) But, these "lazily evaluated" tools I think form in an aggregate as a user interface to me.
Yeah, do they really think "learn in one year" is a compliment?
Interesting how they claim it's compatible with vim was an advantage, oh well but aren't you trying to get me away from it? Sure it's a "shorter learning curve" (if they somehow get rid of all the emacsism before getting to that mode and learn nobody has a "meta" key in their computer)
I could learn a lot of more fulfilling things than emacs in a year. Guess I'll just stick with vim and vscode
> There is something fundamentally wrong with a UI/UX that takes a literal year to master.
You can learn basic navigation in about 5 to 10 minutes reading through emac's built in tutorial. Mastering it means finding a configuration that works for you, or writing your own implementation.
I don't use emacs regularly (other than as an info page browser), but I have been using vim for the last 20 years and am still learning new things about it.
I have read plenty of anecdotes on HN about people choosing the wrong platform. In my opinion, Emacs displays characteristics of a wrong platform to invest time in.
I know that Emacs is a very powerful and completely open-source platform, but I have questions about its long-term viability. It's not commonly introduced in CS programs/bootcamps so it'll lead to a declining market share, and its most powerful capabilities require knowledge of LISP, which is not a popular language.
Time and energy spent learning Emacs is also non-transferable as it has a one-of-a kind shortcut/user interface. The student will be locked in to Emacs.
Students should invest time learning VSCode instead. At least it'll be easy to switch to other products.
Do you also give reviews of books you've never read?
What was the last version of Emacs you've used?
This is one of the most FUD-like posts I've read on this site in a long time.
Good question. I admit I am not an expert on emacs. I tried out Emacs a few years ago, left, tried again to get into it but got the version of Emacs on Windows with the broken package manager due to an SSL issue. My recollection was that there was nothing on the site that indicates it was broken, I then found discussions online saying that they weren't going to patch the windows only SSL issue, and that I should use an older release or wait for a new dot release in a few months. It certainly doesn't make a great (second) impression.
I apologize if I got anything wrong. If you have any specific points about what I got wrong, for example, the average age of contributors or usage isn't related to the ecosystem. I am happy to change my mind.
> it has a one-of-a kind shortcut/user interface
The system-wide OS keyboard shortcuts for basic text editing in macOS are the same as emacs. I discovered this accidentally and people wonder why I can navigate basic stuff on the mac so well and my answer is "I used emacs for many years."
Which shortcuts? You have a link to a list? I only know Cmd-left/right to skip words. But anything more fancy?
Ok. Interesting. Where on macOS can I use these for navigating inside text? If I’m inside Textmate, for instance, typing F just… well, types an F. And it would seem to me that that’s the case anywhere on macOS where there is a cursor, no?
Wrong. I’m using it for over 15 years now! And I’ve never ever even just heard about this. And keyboard shortcuts are the first thing I look for in any app. Hence my surprise
> You have a link to a list?
`man readline`
Thanks! I was not aware of that.
GNU readline is also all over the place and has emacs like keybindings.
the best predictor of something's future lifespan is its past lifespan. Emacs has been around for 50 years, the likelihood that it's going to vanish is much smaller than whatever is new on the scene. You can fill an entire graveyard with bootcamp fads.
And being locked into Emacs isn't really an issue because it does everything. It's like saying you're locked into the dotnet ecosystem. I mean, so what?
And an important thing to note is that you may be locked into Emacs, but with every other tool you're locked out. What is there to learn about something like VSCode? You click on the marketplace and install extensions. Emacs might teach you things that aren't transferable (which I'd also question), but at least it's teaching you something.
> It's not commonly introduced in CS programs/bootcamps so it'll lead to a declining market share
Bootcamp a few years ago would have made me an expert in coding in Ruby/RoR under Atom with Ember.js; man, am I ready for those market shares!
> but I have questions about its long-term viability.
Emacs has existed 40 years, do you assume it'll just go away?
I probably shouldn't have used the word viability. It will probqbly survive, but will it getting the latest features and adopting to trends if it has a small market share?
I would bet that emacs has a better chance than vscode of getting the latest features and adopting to trends in 10 years.
For a recent example of adopting to trends, see the amount of time it took for lsp integration to 1) exist in external plugins and then 2) be put into emacs itself after lsp proved to be something that will likely stick around for a bit.
> questions about its long-term viability
I guess people have been having them for the last 47 years now.
You'd do well to start here https://en.wikipedia.org/wiki/Emacs and stop regurgitating half-understood opinions of others.
Emacs with Org-Mode, M-x calc with Gnuplot and literary programming can bash every other IDE alone. Org Mode it's a beast, it has its own book and with Texlive and Auctex combined with Org-Mode for programming can do things far superior to any IDE/Notebook ever. Nothing comes close.
And I say this as an nvi/Unix tools user with TMUX because I have vi keys ingrained in muscle memory, but Emacs with Org Mode+calc+ELlSP+Texlive+Gnuplot is something out of this world.
Why stick to what's popular? A larger ecosystem doesn't mean anything there is actually any better—or at least the better parts aren't guaranteed to be discoverable.
One year is not bad to master a whole OS!
Waste of time. Better off to master JavaScript and extend VS Code / Codium / et. al.
At least the JS knowledge will carry over to something employable.
Well, that‘s a valid opinion and I am not telling anyone what tools to use.
But as a senior I have seen many colleagues moving from one IDE du jour to the next and spending many hours of reconfiguring their tools while I just stuck to using Emacs all these years with a moderate shift of packages. I’ve been programming C, C++, Perl, JavaScript (and its various ECMA incarnations), React components, SQL and even Lua. Nowadays I am doing my terminal sessions from Emacs, too, and enjoy Tramp mode for tracing live bugs. Also, I started writing SQL change sets using org-mode which is really a killer for me now. Emacs is such a versatile programming tool and does not stop amazing me.
VS Code looks so boring in comparison.
Also my colleagues keep on whining about the CPU and memory consumption of their IDE that is quite large for, well, ultimately, text editing.
Writing functions in elisp is much easier than having to write JS for electron-based editors, and the elisp you write will usually work for a long time without being modified. Emacs is geared towards people that use it regularly, and its defaults hardly ever change.
What makes it easier to write in ELisp compared to JS?
Also, other text editors got on the 'real programming language' train too, like Neovim with its support for Lua. There's also Lite XL which is almost fully written in Lua itself. Does ELisp still have a big advantage there?
Sure. Elisp is very well-integrated with the editor itself, because that's what emacs is written in. There are some primitive functions that written in C that everything builds on top of. This makes writing functions an extension of the text editing process itself. This is why it's truly extensible. You don't get penalized for writing your own functions, they exist at the same rank as what emacs ships with.
Writing functions in lua is fine, but nvim and the like still suffer from being just text editors, and most things that interact with the operating system / syscalls or change/traverse the UI require quite a lot of legwork. In Emacs, this is all very easy. Depending on what you need, you can be perfectly satisfied with vim and a couple of plugins. However, after realizing how easy it was to write functions in elisp, I more or less moved all my text / file editing to Emacs, along with most batch functions.
For example, here's a function to insert a formatted date in the current buffer:
(defun timestamp ()
"Insert string for the current time formatted like '2:34 PM' or 1507121460"
(interactive)
(insert (format-time-string "[%02y-%02m-%02d %02H:%02M:%02S] ")))
Chaining functions:
(defun org-id-create-copy ()
"org-id-get-create and then org-id-copy"
(interactive)
(org-id-get-create) (org-id-copy))
(defun org-delete-subtree ()
"Delete the current subtree"
(interactive)
(let ((org-heading-text (nth 4 (org-heading-components))))
(save-restriction
(org-narrow-to-subtree)
(kill-region (point-min) (point-max))
(widen)
(kill-whole-line 1))
(message "Heading deleted : %s" org-heading-text)))
(fset 'throwtext-c
"x\C-w\C-wGp")
(fset 'kindle-clippings-to-org-macro
(save-excursion (kmacro-lambda-form [?d ?d ?$ ?d ?% ?O ?\s-p escape ?d ?s ?b ?O ?* ? escape ?J ?o ?* ?* ? escape ?J ?j ?^ ?d ?w ?d ?w ?l ?v ?e ?~ ?I ?* ?* ?* ? escape ?w ?d ?w ?f ?| ?r return ?d ?w ?d ?w ?V ? ?\; ?c ?o ?n ?v ?e ?r ?t return ?j ?d ?d ?V ?\C-s ?f ?n] 0 "%d")))
(defun org-capture-pdf-c (action)
"Capture the active region of the pdf-view buffer."
(let* ((pdf-buf-name (plist-get org-capture-plist :original-buffer))
(pdf-buf (get-buffer pdf-buf-name)))
(if (buffer-live-p pdf-buf)
(cond
((= action 1)
(with-current-buffer pdf-buf
(buffer-name)))
((= action 2)
(with-current-buffer pdf-buf
(buffer-file-name)))
((= action 3)
(with-current-buffer pdf-buf
(if (pdf-view-active-region-p)
(car (pdf-view-active-region-text))
(ignore-errors
(buffer-substring-no-properties (region-beginning) (region-end))))))
((= action 4)
(with-current-buffer pdf-buf
(number-to-string (pdf-view-current-page)))))
(user-error "Buffer %S not alive." pdf-buf-name))))
(defun comments-skip-c ()
"Skips to the line after the next comment ends"
(interactive)
(search-forward-regexp comment-start-skip)
(while (string-match
comment-start-skip
(buffer-substring (line-beginning-position) (line-end-position)))
(forward-line)))
(defun make-window-larger-c (&optional ratio)
"Makes the current window larger or smaller.
RATIO is the ratio used, default is 0.618.
It switches the width before the height."
(interactive)
(save-excursion
(let\* ((postv (if olivetti-mode
(progn (olivetti-mode -1) t)
nil))
(wwidth (window-width))
(wheight (window-height))
(fwidth (frame-width))
(fheight (frame-height))
(ratio (if ratio ratio 0.618))
(fl/fheight (floor (\* ratio fheight)))
(fl/fwidth (floor (\* ratio fwidth))))
(if (window-full-width-p)
(if (window-full-height-p) (message "Nothing to resize.")
(if (>= wheight fl/fheight)
(if (>= wwidth fl/fwidth)
(message "Nothing to resize.")
(enlarge-window (- fl/fwidth wwidth) t))
(enlarge-window (- fl/fheight wheight))))
(if (>= wwidth fl/fwidth)
(if (>= wheight fl/fheight)
(message "Nothing to resize.")
(enlarge-window (- fl/fheight wheight)))
(enlarge-window (- fl/fwidth wwidth) t)))
(if postv (olivetti-mode 1)))))
(require 'sqlite3)
(defun kill-new-from-global-paste-c ()
(interactive)
(let ((mylist '()))
(let* ((dbh (sqlite3-open "/home/user/.local/share/zeitgeist/activity.sqlite" sqlite-open-readonly))
(stmt (sqlite3-prepare dbh "select * from text order by id desc limit 500")))
(while (= sqlite-row (sqlite3-step stmt))
(cl-destructuring-bind (id text) (sqlite3-fetch stmt)
(setq mylist (nconc mylist (list text)))))
(sqlite3-finalize stmt)
(sqlite3-close dbh))
(kill-new
(let* ((vertico-sort-function nil)
(rlist (completing-read-multiple " " mylist))
(rstr ""))
(while (length> rlist 0)
(setq rstr (concat rstr (pop rlist) "\n")))
rstr))))
I'm going to post it as a reply to my comment, so it's not a mistake that this is here.
I notice my comment being downvoted, and that's fine. I don't really care- but my statement stands; it's a far better use of your time to learn JavaScript and write extensions in VS Code to accomplish what you want. I realize this might get flagged and someone might be offended. I don't have patience today.
My JavaScript advice is multi-fold:
- You'll learn a language that's in active use and development, and the lingua franca of the web.
- You'll learn how extensions are created for VS Code, one of the most popular text editor and the greatest reach for sharing your work if you desire that.
- JavaScript is *fast*, Emacs is slow ; there are many other language problems that, shockingly, JavaScript is just better with.
- Waste less time debugging your text editor; not all of us (especially myself) have time to sink into becoming experts at Emacs. Emacs documentation is a bit esoteric and not that easy to grok, unless you already know ELisp.
- Need an off-the-shelf solution? VS Code most likely has that, and it's probably going to work
- Don't waste your time with dogma. EMacsers get in a tizzy fit over this and that, the right way to do things, to RTFM, etc. It's a community that has almost the same level of toxicity as Linux users.
I am someone who went all-in with Emacs for around 6 months. It is really an interesting piece of software and no one will deny that it can ostensibly do alot. One of the biggest issues I had was writing any form of prose - which made it lag so badly, it was nearly impossible to scroll. The collective solution, after posting on Reddit and searching via Google, was simply to use search - rather than scrolling to find what you're looking for.
I find manipulating buffers in Emacs fairly tedious, and I still believe that the mouse is a great invaluable tool not to be shunned. Some things are just easier and faster to manipulate with a pointer. I don't have a problem reaching for my mouse and returning to the keyboard without looking.
I tried to use it for journalling, and learning the ins-and-outs of Org-mode was fun. I liked org-capture. Then I realized, Obsidian was a better piece of tool. It handles prose just fine, and Markdown is much easier to remember (due to its ubiquitiness) than org-mode. And guess what languages extensions are written in? JavaScript.
Other comments:
> Writing functions in elisp is much easier than having to write JS for electron-based editors, and the elisp you write will usually work for a long time without being modified.
Old JS code still work. JS has a reputation for being backwards compatible and taking a very long time to break any type of ABI. In the case of Electron, you are informed when things break - and you have time to update it. It's not like code changes happen under your feet, and things are breaking all of the time. [0] On top of that, Electron-based applications are almost guaranteed to work similarly on Windows, Mac and Linux. The same can't be said for Emacs, which suffer some fairly extreme performance issues on Windows.
> VS Code looks so boring in comparison.
It's just a tool. I can use themes, and syntax highlighting is great.
> but nvim and the like still suffer from being just text editors
And this is what makes it perfectly suited for its task.
> In Emacs, this is all very easy.
What makes emacs very easy? Every time I see anyone say Emacs is easy - they gush about writing code in ELisp, it's almost dogmatic. It's not about Emacs, it's about *ELisp*. I do believe the majority of Emacsers suffer from the IKEA effect[1] because the learning curve is so high that by the time they're able to build something in ELisp - they're also hit over the head with the Stockholm Syndrome[2].
My preferred solution would be to use an SQLite plugin in VS Code because that allows me to browse and query any code, rather than a fixed string. I don't need to write a new function, or try to manipulate Emacs buffers.
> Alternately, spend a weekend learning VS.Code and get on with doing real work.
Exactly my perspective.
[0] https://www.electronjs.org/docs/latest/breaking-changes
Some may read your comment negatively, but as someone that has bounced off emacs many times, I really appreciate it. It took me days just to figure out how to navigate through files in emacs. I felt really stupid trying to learn it, mainly because of the attitude of its biggest fans. It seems emacs users have a combination of implying you're lazy/unintelligent if you don't grok the tool quickly, as well as greatly underestimating how easy it is to work in VSCode.
There are people in this thread claiming their colleagues will spend "many hours" configuring VSCode to get it to work, or are constantly "churning" through IDEs. I have no idea what they are on about, because emacs users would be the first to tell you how often they are reconfiguring their environment and how difficult of a journey that is, and this is a source of pride for them. I have no problem with owning your tools, but not everyone has the time to do this. I also think senior devs holding onto emacs has actually hurt the popularity of some languages like CommonLisp, where interest in the language is immediately met with the emacs "brick wall" because the only proper IDE available for CL is outrageously expensive. Meanwhile Clojure works great with VSCode and Calva. VSCode has been around nearly a decade and is going incredibly strong, I don't know why people pretend it's a dumpster fire.
And the argument inevitably turns into emacs as a "lifestyle," because it's a text editor, emailer, task manager, etc. But I don't want all my needs to be handled by one tool, and I actually see that as a huge downside. I like being able to swap out one of my tools if I don't like the workflow. So when the argument becomes "You're not using emacs right if you're not using it for everything," I find that really odd. It's weird to me that lispers, which tend to reinforce loose coupling in their coding practices, would tether themselves to such a restrictive ecosystem for really simple everyday tasks.
Also the keyboard only approach just doesn't work for mobile. I'm sure there's someone somewhere using emacs on mobile, but it's just not an option. So making your whole organizational life centered around emacs/org-mode is odd to me because you'll need a separate system for your phone. Obsidian, meanwhile, has a mobile app, and javascript runs everywhere now.
Thanks, it helps to know that someone else has similar sentiments as I do in regards to Emacs. By no means am I saying Emacs is bad software (it's not), but;
> claiming their colleagues will spend "many hours" configuring VSCode to get it to work
It's been my experience that you can simply install VS Code, open a source file and it will suggest extensions to help you get going. Even going so far as to be helpful in installing Python if you open a .py file one time, on a fresh install, for me. I just search for a dark theme I like (Dracula is one of my goto) and a light one (I switch when it suits me) and I'm off.
Meanwhile I'm told it's _SO_ simple and straightforward to set-up treesitter and the language servers.
> javascript runs everywhere now
Indeed. JavaScript is a far easier language to work with - it may have a quirks and gotchas, but it's fairly straightforward despite it not being my first choice in a language.
In my opinion, as of 2023, the best way to learn emacs the right way is through the textbook 'Mastering Emacs' by Mickey Petersen. Trust me, that book is well worth the price tag.
Strongly second this opinion!
Mickey Petersen simply has no equal in explaining Emacs. His book and blog posts are a model of effective teaching, starting from zero. Yet somehow gently ceomprehensive. Hard recommend.
Emacs from scratch is the way to go. Added abstractions are usually not good enough to completely replace fiddling around with vanilla Emacs.
Two videos by Steve Yegge should be enough to convince the most dyed-in-the-wool anti-Emacser to consider re-evaluating their position. (Here is the first: https://www.youtube.com/watch?v=lkIicfzPBys).
My top-tip, FWIW, is learning how to navigate the help system to the point that it drags you into the deepest layers of Emacs' source code.
> smex
The three packages, whichkey, helpful and marginalia are excellent for beginners for quick overviews of what's going on at the surface.
And, yes, Mickey P's work is undoubtedly of great value!