[HN Gopher] How I am deeply integrating Emacs
___________________________________________________________________
How I am deeply integrating Emacs
Author : signa11
Score : 199 points
Date : 2025-11-06 07:09 UTC (15 hours ago)
(HTM) web link (joshblais.com)
(TXT) w3m dump (joshblais.com)
| scandox wrote:
| > This is how world class athletes, musicians, artists, writers,
| and of course programmers take what is in their mind and
| translate it into reality.
|
| > It is the ultimate sharpening of the axe before chopping the
| tree[1]
|
| But if part of our axe sharpening is listening to music, reading
| email, catching up with your feeds and so on then perhaps we need
| to take a step back and ask if we're just invading our working
| thought-space with boondoggles.
|
| [1] "Give me six hours to chop down a tree and I will spend the
| first four sharpening the axe." - apparently Abraham Lincoln.
| rusk wrote:
| A good carpenter takes time to maintain and procure their
| tools. They still have a nice phone and might listen to music
| on their headphones while they're working. A chef must keep
| their kitchen clean and well organised. Stocked with
| appropriate and some obscure tools. She must season her
| saucepan, sharpen her knives.
| giraffe_lady wrote:
| My first career was as a cook and I would always sit and
| sharpen my knives after the last service of the week. It was
| kind of a cool time to reflect on the previous cycle and
| mentally prepare for the next. There's really nothing
| comparable in programming and I say this as someone who has
| spent hundreds of hours yak shaving emacs.
| skydhash wrote:
| We do various tasks with computers. And it's not always in a
| linear fashion. What's important is reducing friction. The
| latter can manifest in various way, like having to battle with
| a GUI just to play some music, yet another GUI for email, and
| another one for your feeds. Emacs stuff can be pretty stable
| and you have the same interface for everything.
| sim04ful wrote:
| The more I learn about emacs the more I feel we took the wrong
| fork on road in terms of the desktop metaphor decades ago.
| nine_k wrote:
| Emacs is great for people who are fine tinkering with their
| tools, and adjusting them to their needs and tastes. Emacs
| improves my quality of life quite a bit.
|
| A lot of people hate that, they want a tool that has all
| relevant to their tasks front and center, all irrelevant
| invisible or nonexistent, and zero options to tinker with. It
| should just work, and preferably never change.
|
| A middle ground are the browsers that just work out of the box,
| but can be heavily customized by extensions. MS Office is
| another example.
| omnicognate wrote:
| > A lot of people hate that
|
| It seems a curious attitude for a developer, though. My
| curiosity about how things work and the joy I get when I make
| a computer do the specific thing I want it to do for me are
| the reasons I program for a living.
| fhd2 wrote:
| Completely agree. At the same time, I'd wager a good chunk
| of developers isn't really in it for a love of computers
| and tinkering. Not a bad thing per se, just my observation.
| Karrot_Kream wrote:
| Life is full of decision points. It is very understandable
| to use your decision budget on things that matter, like
| your projects or your job or your money, than things that
| don't like an editor config. Over my decades of emacs use
| I've had periods of crazy tinkering and conversely years of
| doing nothing.
| bodge5000 wrote:
| I fit into this category so I might be able to explain. I'd
| like to learn emacs and build my perfect config for my WM
| and so on, but on top of that theres a long list of other
| stuff I want to do and build and learn. My time is finite
| and with all the other demands of life, my energy even
| moreso, so naturally I have to make sacrifices.
| omnicognate wrote:
| That doesn't sound like you "hate that", more like you're
| making a time management choice. I'd challenge it, as I
| find time spent on creating a good developmemnt
| environment pays off very well in overall productivity
| terms, up to a point, but it's your choice to make. Emacs
| certainly isnt for everyone, even among those that enjoy
| tinkering.
| ssivark wrote:
| > _[...] people hate that [...]_
|
| But that's just culture, and quite easily moldable. Lots of
| people would also rather gamble watch smut all day, but we
| decided that it's not the best way to go about life... so we
| set up a system (school) to manage their learning process,
| and shepherds them for well over a decade, and then involves
| them in the economy and in society. Likewise we have cultural
| mechanisms which try to ensure that people learn essential
| skills related to nutrition, mobility, relationships, etc.
|
| A lot of this has been eroding in recent years under the
| banner of _convenience_ , and will likely have pernicious
| consequences in the coming decades. I posit that letting the
| insidious patterns broadly drive our approach to computing is
| similarly dangerous.
| jcynix wrote:
| > A lot of people hate that, they want a tool that has all
| relevant to their tasks front and center [...]
|
| A lot of people don't even know how to use their tools
| properly. I remember when I was teaching a number of Perl
| courses to programmers, they where joking about me using
| emacs while they where using vi or vim.
|
| But while I watched them while they did their exercises, I
| constantly heard the "bing" sound when the cursor hit the end
| of the line. Why? Because they pressed the cursor key and
| waited for the cursor to travel to the end of the line, then
| chynged to insert mode to append stuff.
|
| Even I, a humble emacs user, knew that there was a vi command
| to jump to the end of the line and append.
| nine_k wrote:
| I'm not talking about hyper-flexible tools like Emacs or
| Perl. I mean tools that do one thing, and do it well, with
| zero tweaking needed, or even allowed. A hammer, a hacksaw,
| a copy machine, a vending machine, software like age, or
| like notepad.exe. They can be learned end to end in a
| rather short time, and if you pick a hacksaw in a different
| workshop, it's almost guaranteed to work exactly the same
| as yours.
|
| Somehow in the same vein, some people prefer to write in C
| and tell the machine what exactly it must do, on a very low
| level, instead of picking an abstraction-rich language like
| Typescript or C++ or, well, a Lisp, where you typically
| operate in abstractions which you need to tweak to express
| your solution elegantly and correctly, but not very
| directly.
| tmtvl wrote:
| > _a vending machine_
|
| It gave me orange. I wanted lemon-lime. Another one
| swallowed my coins.
|
| But to be pragmatic, many tasks need more than one thing
| to be done (I think most of us compose our e-mail in a
| program which sends said e-mail out as well, for
| example), so the inflexible tools can be insufficiently
| convenient at times.
|
| Also, consider the humble scissors. They do one thing and
| do it well unless they're the wrong handedness. Try using
| a right-handed pair with your left hand, it's terribly
| unwieldy.
| skydhash wrote:
| > they want a tool that has all relevant to their tasks front
| and center, all irrelevant invisible or nonexistent
|
| That is Emacs. You just have to drag the relevant up first
| and push down the irrelevant.
|
| The thing is in Emacs, most utilities don't want to presume
| how you would want some feature. Even if they do have
| defaults, they are suggestions at most. Instead of getting a
| tools that you have to learn and conform too, you get the
| template/idea/inital_version of a tool, and you make it your
| own
|
| And there's the whole idea of integrating stuff instead of
| isolated utilities.
| slowmovintarget wrote:
| Polite tools that assume competence are such a pleasure to
| use.
| joshuablais wrote:
| Some people want to just "do work" and not build a toolchest
| over the years. I think if I find myself doing something
| once, I will probably be doing it again, therefore the
| environment can help me greatly with achieving that goal in
| far less time. There is a diminishing return for some tasks,
| but some things I have written in emacs save me minutes of
| time each time they are run daily.
| raverbashing wrote:
| The more I learn about emacs the more I'm happy I never joined
| the cult
|
| Don't waste my time with 70s "ergonomics" (if it can even be
| called that)
|
| The comparisons with art seem almost to the point of offense to
| me. You're not building art, you're just building another yet
| plugin for emacs to do what other people do in maybe 5% less
| efficient ways but won't spend 2 days automating it
| skydhash wrote:
| Emacs don't have plugins. Emacs only have a small C core
| (kernel) that handles very low level details. Everything else
| is lisp code split into packages (libraries and utilities).
| And being a lisp means you can alter and redefine any symbol
| you want.
|
| The thing is that, there's enough packages built-in and by
| third-party, you never really write your own. My whole config
| is pretty much setting options and linking packages together.
| dwringer wrote:
| There are a lot of caveats but in general the "spend 2 days"
| thing is a lot less true now IMHO thanks to LLM's that can
| write mostly correct elisp from basic specifications. YMMV of
| course. I have found this can also open up to being a lot
| more than "maybe 5% more efficient" for niche applications.
| It's the closest environment I've used to where the friction
| between "I wish my editor could do <x>" and actually having
| the feature almost disappears.
| fhd2 wrote:
| For me, the power of Emacs is mainly that I can do everything
| with the keyboard, which is not only much faster, but also - to
| me - much more enjoyable than going through visual menus with
| the mouse.
|
| For someone not good with the keyboard, it's probably a
| nightmare. I suppose it's good for power users and terrible for
| casual users, and I don't know if there's any way to really
| build one user interface that works equally well for both, it's
| usually a compromise.
|
| The next best thing I love about Emacs is that I can do
| anything conceivable with code. This one is an even larger gap
| between power users and casual users.
|
| I think tools like that are just fated to only attract a select
| few.
| timonoko wrote:
| You can do _everything_ with mouse (or touchscreen). Lets
| start with these: (xterm-mouse-mode 1)
| (global-set-key (kbd "<mouse-5>") 'scroll-up-command)
| (global-set-key (kbd "<mouse-4>") 'scroll-down-command)
| (global-set-key (kbd "<wheel-up>") 'scroll-up-command)
| (global-set-key (kbd "<wheel-down>") 'scroll-down-command)
| piokoch wrote:
| Believe or not, you can go 100% keyboard-only even on
| Windows. I had a friend, Win server admin (big Microsoft
| fun), who wasn't using mouse at all.
| Aromasin wrote:
| You _can_ but that doesn 't neccesarily mean you _should_.
|
| I tried it for a while, after seeing my Eve Online friend
| skipping through tasks at a rate of knots without any mouse
| movement. My god the amount of tab pressing I had to do to
| get anything done was crippling. I might have to jump
| through 15 times to get to something that would take me
| less than a second to click.
| cluckindan wrote:
| Which is why most programs support alt-hotkeys.
| Karrot_Kream wrote:
| When I got into emacs 20+ years ago the "use only the
| keyboard" thing was a huge point of pride and to this day I
| don't understand why. Who cares? I use emacs because I can
| code the entire environment.
|
| Fundamentally the mouse is just a form of modal editing.
| Emacs supports this in spades of course, and god-mode is my
| modal input minor mode of choice, but clicking to jump to a
| position on screen can often be a lot faster than I search or
| avy-jump commands, say nothing about how much gentler on the
| wrist it is. Then you can customize the menus and toolbar
| icons so you can be 1-2 clicks away from something that would
| otherwise require a chorded keypress or worse, an M-x
| command.
|
| Then you have the biggest benefit of using the mouse:
| scrolling around reading code or text while having a drink or
| snack in the other hand. These days I use a trackball in my
| left hand. Regardless, the keyboard vs mouse thing always
| struck me as one of the many dumb flamewars that tech people
| engage in.
| fhd2 wrote:
| > Regardless, the keyboard vs mouse thing always struck me
| as one of the many dumb flamewars that tech people engage
| in.
|
| Certainly. I wouldn't argue that text editing speed is a
| relevant bottleneck in software development, actually. To
| me it's enjoyable and that's a big factor in my
| productivity, but that's just me.
|
| My point was mainly that the keyboard (efficient use is
| difficult to learn) vs mouse (arguably easier to learn) is
| just one example of why the current desktop metaphor won
| over something I'd say is designed for heavy keyboard use
| (even if usable without it). The "code the entire
| environment" thing you mention is another example. Not sure
| I expressed that point all that well, rereading my comment
| it almost looks as if I'm trying to start a flame war :D
| robenkleene wrote:
| > My point was mainly that the keyboard (efficient use is
| difficult to learn) vs mouse (arguably easier to learn)
| is just one example of why the current desktop metaphor
| won over something I'd say is designed for heavy keyboard
| use (even if usable without it).
|
| This comparison of the mouse and keyboard seems to have
| programmer tunnel vision. Anything involving layout,
| graphs, media editing (audio, video, image), 3D modeling,
| and drawing I think we can all agree are better served by
| the mouse (in tandem with the keyboard). It's really the
| mouse and keyboard together that's made the computer such
| a successful creative medium. Programming seems to me
| like a bit of anomaly in that it's one of the few
| creative tasks that doesn't benefit greatly from a mouse.
| jbstack wrote:
| I think this largely misses the point. It isn't about which
| out of keyboard vs mouse is objectively better or faster.
| It's about subjective comfort. If a system "feels" nicer to
| use then I'll feel more motivated while using it which
| means I'll use it more and be more productive, and that's a
| sufficiently good reason to prefer one over the other. For
| me, that means using the keyboard and not the mouse.
| stronglikedan wrote:
| > Who cares?
|
| People with RSI from constantly reaching for a mouse.
| dustfinger wrote:
| I have been coding for so long now that I can't have my
| keyboard any higher than my lap. I code with it resting
| directly on my legs. A mouse is right out. Any higher,
| and my hands turn to clubs.
|
| I love emacs because I can do everything with the
| keyboard. It is faster and a lot easier on your body long
| term. My advice, start young. Keep your keyboard directly
| on your lap and use a ortholinear plank keyboard so your
| fingers don't have as far to travel. I was skeptical at
| first, but I will never go back.
| cpfohl wrote:
| Ah, like my eMacs pinky and thumb? ;)
|
| I literally went to an orthopedic specialist recently for
| overuse of the left alt key causing me pretty notable
| pain in my thumb.
| PessimalDecimal wrote:
| An ergonomic keyboard can help. I like the Kinesis
| Advantage but it's expensive for a keyboard.
| skydhash wrote:
| As the sibling comment put it, that's when I look into
| ergonomics accessories.
|
| My primary mouse is a trackball one, because I have pain
| in my arm (elbow and shoulder) when I use a regular one
| on a desk.
|
| I will maybe get a split keyboard in the future. But I
| did get a mechanical one because of key travel. And I
| touch type, so I spend less time on the keyboard itself.
| BeetleB wrote:
| Alternate between using the left and right Alt keys. The
| ergonomist's rule of thumb (no pun intended) is to use
| both halves of the keyboard. So if pressing Alt-x, use
| the right Alt button, etc.
|
| I had RSI issues early in my career and this advice alone
| _really_ helped. Never got the Emacs pinky /thumb. I
| recently switched to a MacOS and _that_ is giving me
| thumb issues with the overuse of the Meta button. I now
| consciously have to force myself to use a different
| finger when pressing Meta.
|
| Always remember: You have five fingers - no need to keep
| using the same one/two fingers to press Ctrl or Alt. It
| will take time getting your brain used to using other
| fingers for this purpose.
|
| Oh, and yes: Definitely got lots of ergonomic pains due
| to mouse use. In fact, I changed my career from "regular"
| engineering to SW engineering partially to avoid having
| to use a mouse (e.g. CAD SW). And every ergonomist you'll
| meet will tell you "Memorize keyboard shortcuts and avoid
| the mouse as much as possible."
| stonemetal12 wrote:
| Ah yes, stop Repetitive Stress Injury by reducing
| variation and increasing repetitive motions.
| joshuablais wrote:
| This is the thing people forget about emacs - it is
| primarily a lisp environment, entirely programmable.
| Something one can make their very own. Nothing else comes
| quite as close, even if the keyboard ergonomics (at least
| for me) do help to sell it. You can change the workspace to
| better the workflow in real time, that's the biggest
| selling feature.
| fellowniusmonk wrote:
| And this is why, even though it is a better OS
| environment my grandmother will never use it.
|
| And because emacs is under socialized and under adopted
| the emacs user will still have to use notion or outlook
| or whatever corporate security requires.
| Karrot_Kream wrote:
| I'm not going to argue that emacs if "for everyone" and
| there's plenty in my own life that I'm happy to accept
| defaults in. But that said, it's not that hard to glue
| emacs onto existing tools if needed. If you're in a
| situation where you can only send emails on a locked down
| email client you can still script the client through
| emacs and some glue code. On MacOS, Apple script does
| wonders and for Windows there's AutoHotKey. Linux
| obviously is infinitely malleable.
| BeetleB wrote:
| Use what works for you.
|
| My few cents:
|
| Pretty much every ergonomist will tell you that mouse use
| causes more ergonomic pains than keyboard use. They
| literally tell you to memorize as many keyboard shortcuts
| as possible.
|
| > but clicking to jump to a position on screen can often be
| a lot faster than I search
|
| It _can_ be, but is it the norm? I have a distinct memory -
| over 15 years ago - of reading a blog post that recommended
| isearch to move the cursor and realizing how right it was.
| I suppose not everyone agrees.
|
| > say nothing about how much gentler on the wrist it is
|
| A bad mouse is as bad as bad posture on the keyboard. You
| only realize this once you're in pain. Not everyone reaches
| the point of pain.
|
| > say nothing about how much gentler on the wrist it is
|
| You should _not_ be moving your wrist! Move your whole arm.
| Once again, one realizes this only when you 're in pain.
| Not everyone reaches the point of pain.
|
| > Then you can customize the menus and toolbar icons so you
| can be 1-2 clicks away from something that would otherwise
| require a chorded keypress or worse, an M-x command.
|
| The same argument works for keyboard. If you're going the
| route of _customizing_ the menu for particular commands,
| you can also customize the keyboard to minimize the
| keystrokes for those commands (e.g. via hydra).
| Karrot_Kream wrote:
| > Pretty much every ergonomist will tell you that mouse
| use causes more ergonomic pains than keyboard use. They
| literally tell you to memorize as many keyboard shortcuts
| as possible.
|
| Right but that's because their advice is tailored around
| the "average" computer usage, which is lots of mousing to
| click around in buried menus and hunting and pecking on
| the keyboard. RSI is just what it says: Repetitive Stress
| Injury. The best palliative for RSI is to stop
| repetitively stressing the same tendons and ligaments. So
| that means breaking up your keyboarding with some
| mousing. Alternating which finger and which hand you use.
| Getting up and stretching and taking breaks. Maybe using
| some dictation in lieu of using an input device.
|
| If you're writing text, your mousing is mostly going to
| be scrolling, unlike doing something like CAD or design
| or illustration. In that context, the context of using
| emacs, mousing is fine.
|
| And realistically, for my own RSI, exercise was the real
| solution. Rock climbing increased the blood flow to my
| wrists significantly. That's probably the only _real_
| solution to RSI.
| mediumsmart wrote:
| this blog post?
|
| https://sites.google.com/site/steveyegge2/effective-emacs
|
| _Get in the habit of using Ctrl-r (isearch-backward) and
| Ctrl-s (isearch-forward) for moving around in the
| document. Whenever you need to jump the cursor backward
| or forward more than about 5 lines, and you can see the
| target location, you should be using i-search._
|
| _To do it effectively, you don 't necessarily need to
| search for the exact word where you want to put the
| cursor. Let your eye defocus slightly and take in the
| whole paragraph or region around the target point, and
| choose a word that looks reasonably unique or easy to
| type. Then i-search for it to navigate to it. You may
| need to hit Ctrl-r or Ctrl-s repeatedly if your anchor
| word turns out not to be unique. But Emacs will highlight
| all the matches, so if there are more than a couple of
| them, Ctrl-g out of the search and choose another anchor
| word._
|
| _It 's difficult to overemphasize how powerful this
| technique is, once you've mastered it. Mastering it
| simply requires that you do it repeatedly until your
| fingers do it "automatically". Emacs eventually becomes
| like an extension of your body, and you'll be performing
| hundreds of different keystrokes and mini-techniques like
| this one without thinking about them. It's comparable to
| the hundreds of subtle techniques you acquire for driving
| a car well._
| lenkite wrote:
| Using the mouse too much gives you RSI syndrome. Frankly,
| using Vim (or neovim nowadays) over Emacs is even better
| for preventing that...
| robenkleene wrote:
| There's a ton of comments here saying the keyboard is more
| ergonomic than the mouse, I've never heard that before and
| it feels wrong on its face (it's called _repetitive_ strain
| injury, using multiple forms of input should helpful).
|
| But generally, please if you believe this provide _some
| kind of source_.
| Karrot_Kream wrote:
| It's one of the oldest forms of "programmer identity" out
| there, one of those shibboleths that people who
| culturally identify as a hacker express that's
| independent of its factuality. A bit of a precursor to
| social media which elevates in group shibboleths over
| data as a matter of course. Programmers were the first to
| invent and use social media after all.
| skeezyjefferson wrote:
| > The next best thing I love about Emacs is that I can do
| anything conceivable with code.
|
| you already could though, no? emacs didnt allow you to
| execute lisp for the first time
| taeric wrote:
| It is more than just that it uses lisp. I do like that, and
| I think it is the correct choice. But it is more that even
| something as basic "move cursor down" is not tied directly
| to a specific key. And the help system will literally take
| you to the source for any command, if you ask it to. (Takes
| some setup for this to work down to the c source, but it is
| there.)
|
| Is a bit like having a problem with "ls" and wondering if
| you could fix it by scanning the source real quick. In
| emacs, that is often just a keystroke away. In most
| systems, good luck.
| positron26 wrote:
| Emacs took a wrong fork in its own metaphor. At length, being
| able to take code and libraries between production and the
| editor would be a game changer. While Elisp has design features
| that make sense, in the tradeoffs, I think it lost to every
| other lisp with a general purpose programming ecosystem.
|
| I have a hope for the Common Lisp based Lem. All we need is to
| coordinate enough signal for potential users to feel it's the
| right time for their actions. Go star Lem
| https://github.com/lem-project/lem
|
| I feel the same way about org mode. Nice. Can I use it on a
| team? Get real. I'd like more embedded data functionality in
| markdown. It's not XML, and that's good. Org is just weird.
| AFAIK it's still trying to figure out inline data embedding, so
| the embedding isn't even that strong. Doing something like
| exporting with a CSS class around a specific word probably uses
| some awkward literal syntax instead.
|
| There are consequences to the monastic culture around Emacs.
| It's really good at holding itself in place. If you don't buy
| that tradeoff, you need to keep shopping.
| ekjhgkejhgk wrote:
| Stallman was right.
| k_bx wrote:
| I actually discovered that emacs is great as it is out of the
| box (except for creating annoying backup files with ~ at the
| end). I use it instead of nano and vim.
| joshuablais wrote:
| I entirely agree - we could have had a completely unified
| computing environment, and we got... apps.
| fellowniusmonk wrote:
| Emacs is 100% nearly perfect, the only thing holding back emacs
| is emacs.
|
| I still can't believe we have IRC for grandma (slack) but not
| emacs for grandma.
|
| People get tied up in the program-ability of it but it's UI and
| the concept of jettising both the desktop and tty paradigms.
| hsbauauvhabzb wrote:
| I like eMacs but I feel the whole workflow is wrong. Buffers are
| a stacked tiled window manager inside your window manager. Your
| browser is a tabbed window manager, and many other applications
| are also window managers. I wish any sub buffer of any
| application was for all intents and purposes a dedicated window,
| so the WM can take care of the rest. Maybe it's an adjustment
| that I could make in my workflow, but a global solution would
| have been nice. Too late now I guess though.
| douglee650 wrote:
| Doesn't emacs slow down on really long files? I mean like 8,000
| lines
| hsbauauvhabzb wrote:
| No, but that's not really relevant, my point is more that all
| buffers should be windows across all applications.
|
| Emacs for me gets slow when syntax highlighting is on and I
| navigate to a very long line, text-mode does not have
| highlighting or the slowness. Most emacs slowness is caused
| by bad plugins, which if you report may be fixed by
| developers.
| precompute wrote:
| Not these days. Native Compilation made emacs a faster and
| there have been a lot of other changes. In fundamental-mode,
| emacs can handle really large files. When opening files
| literally, it's even faster. I have this 104k line org-mode
| file and it's reasonably responsive. Reverting it takes a
| while, but the UI does not hang while the buffer is being
| formatted according to the mode.
|
| I use a mid tier laptop CPU (6C12T). Emacs is snappy.
| Compared to what it's like now, it was glacial in 2019.
| hsbauauvhabzb wrote:
| I'll bite, wtf is your org file?
| precompute wrote:
| It's three months of text I need to refile.
| internet_points wrote:
| My "main" org file is 21k lines, it's no problem at all. My
| laptop is from 2017 or something.
|
| I do sometimes work on files that are 300k lines (don't ask),
| and while it's mostly fine, once in a while I'll try to use
| some less common operation that's not very optimized and have
| to abort it (e.g. don't try to magit-blame that file). But
| stuff like searching, scrolling, editing, syntax highlighting
| are all fast.
|
| If I have to open files >100M I sometimes open them in
| `fundamental-mode`, which turns off syntax highlighting.
|
| For truly large files (gigabytes), there is the `vlf` (Very
| Large File) package, which doesn't load it all into memory at
| once, but still lets you search, scroll and even M-x occur
| (sort of like grep, but more integrated and editable).
|
| Note that this is on Emacs 31 (there have been some _major_
| perf improvements in the last three or so releases, and more
| is coming with the new garbage collector)
|
| In earlier days there were issues with very long lines; these
| have partly been mitigated in later releases; on the one hand
| by faster internals, but also a new builtin package `so-long`
| that can notice very long lines, default 10k bytes, where
| Emacs probably should give up syntax highlighting etc. to
| remain snappy.
| douglee650 wrote:
| I finally made the switch to vim when I was working on a
| really large frontend template that consisted of the same
| massive repeated block where a small portion of each was
| different based on a condition.
|
| There was a lot of search and replace, and emacs started
| dogging it really hard on like the 10th condition block.
| kirubakaran wrote:
| You can configure Emacs to open each buffer in a new frame --
| ie "window" and manage them with your window manager
| jbstack wrote:
| Exactly. I share the view that it doesn't make sense to
| effectively have two window managers running (one in my WM
| and one in Emacs) with different philosophies and shortcuts.
| But, and in a more general sense this is the great thing
| about Emacs, if you don't like its default behaviour you just
| change it.
| rootnod3 wrote:
| EXWM + Qutebrowser can work like that. The individual tabs of
| Qutebrowser become Emacs buffers.
| myaccountonhn wrote:
| I've used the no-tabs extension also for firefox when I used
| sway to integrate firefox into the WM. You can modify the
| userchrome to hide the tab bar completely. It worked really
| nicely, and should also work with exwm.
| omnicognate wrote:
| Re EXWM and:
|
| > Emacs is single threaded, therefore if anything in the system
| hangs, the whole system hangs
|
| For development work I haven't found this to be an issue.
| Generally when coding I use very few X apps - pretty much just a
| web browser and maybe occasionally a PDF preview or docs browser.
| I don't think I've ever had a problem with the single-threaded
| behaviour blocking window management there. (And as an aside,
| while proper threading would be nice for things that actually
| should be concurrent - such as EXWM's duties as a window manager
| - I _massively_ prefer emacs ' synchronous processing of input
| over the JetBrains horror of pressing a key combination and then
| having to wait for some asynchronous UI behaviour to occur, with
| different outcomes depending on whether the next keypress occurs
| before or after the UI behaviour the first one triggered.)
|
| For other, more GUI-focused activities I just run a separate
| (wayland) session.
| hsbauauvhabzb wrote:
| I don't imagine I'd want to use my general emacs as my window
| manager, I imagine the sanest way would be to run two instances
| of emacs.
| joshuablais wrote:
| I do have a wandering eye for EXWM, it probably would require
| my skill with emacs to increase and an optimization of my
| config so as to defer heavy tasks etc. If you have any
| suggestions on how to get there, I am all ears! The more I use
| emacs, the more I want to make my entire computer emacs.
| stebalien wrote:
| You likely don't need to optimize anything; Emacs has seen
| some pretty significant optimizations recently (native Emacs
| Lisp compilation, tree-sitter modes, better handling of long
| lines, etc.) so performance is rarely the issue.
|
| However, you do need to avoid call-process (spawning blocking
| processes) as much as possible. Also, my experience with
| TRAMP has been pretty awful due to the fix for
| https://debbugs.gnu.org/cgi/bugreport.cgi?bug=12145
| (literally: TRAMP blocks all of Emacs while waiting on a
| network connection).
| dustfinger wrote:
| I live in EXWM. I absolutely love it as a coding environment.
| EXWM + helm + projectile. I mainly use v-term for cli, but I
| have always been interested in learning eshell, just never got
| around to it. I have been thread-locked on occasion, and when
| that happens it is frustrating. I can sometimes manage to
| switch to another session to kill processes and avoid restart,
| but not always. Still, I wouldn't leave EXWM. Maybe in my
| retirement I will end my career by helping to make emacs + EXWM
| multi threaded. I am guessing that is a daunting project, but
| it sure would be fulfilling.
| stebalien wrote:
| If you want to try eshell, try combining it with EAT (eat-
| eshell-mode).
|
| > Maybe in my retirement I will end my career by helping to
| make emacs + EXWM multi threaded. I am guessing that is a
| daunting project, but it sure would be fulfilling.
|
| This isn't fixable with threads, unfortunately. The issue is
| that:
|
| 1. Emacs e.g., launches a process with call-process. This
| blocks EVERYTHING (including other threads). 2. That process
| wants to map the window but EXWM can't respond to this
| request because Emacs is blocked. 3. The call to call-process
| never returns because the process can't create its window.
|
| You'd have to fix Emacs to not block everything in cases like
| this, but that has been tried before:
| https://mail.gnu.org/archive/html/emacs-
| devel/2023-06/msg007...
|
| At this point, I think the right answer is to write a minimal
| out-of-process window manager (e.g., a wayland compositor).
|
| 1. During normal operation, it would behave like EXWM and ask
| Emacs how to manage windows, etc. 2. In special cases (TBD),
| it would behave autonomously, acting like a standard floating
| window manager until Emacs becomes responsive again.
| globular-toast wrote:
| The bit about enabling org capture from "outside" Emacs is really
| interesting. It's been so important for me to have a system that
| enables me to make notes, todos etc. with extremely low friction.
| At any time, without my hands leaving the keyboard, I can take a
| note that is either directly attached to what I'm currently
| working on, arbitrarily file it somewhere if I know where it
| should go, or just let it go into the general inbox (the other
| part of the system is actually getting to those things in the
| inbox at some point). Up until this point I have had to be "in"
| Emacs, though, which accounts for most of my time, but not all.
| shevy-java wrote:
| This may sound strange, but I actually think we need just ... one
| editor.
|
| Now, this is not a "we need to favour vim over emacs". I think
| this is a stupid war, the vim versus emacs war.
|
| What I mean is ... basically most editors do almost the same
| exact thing. They look at some buffer for a file and help the
| user modify this. There is a finite number of operations
| possible. Why do people keep on re-implementing basic things
| here? Why can it not be solved once and for all and then everyone
| uses that implementation?
|
| We really should have that; and then people can decide ON THEIR
| OWN what kind of editor they want to use. Many years ago I
| started with crimson editor as my main editor on windows. I have
| since then hopped to many other editors. My favourite one was
| oldschool bluefish in gtk2. I am not saying it was perfect, but I
| found it much easier to go on my poor brain than e. g.
| remembering all vim shortcuts. But, it would need xorg + gtk2, so
| if that is not available, then I can not edit things - that's
| bad. That was (and still is) also one reason why I use e. g.
| nano. But this in turn requires ncurses and I hate ncurses with a
| passion (nano is great though, I can recommend it for quick ad-
| hoc editing; for larger things it is not quite as good, but if
| you have to just change some value in a config file, nano is
| really great).
|
| Even then I used only like 20% of what bluefish offered (the
| newer bluefish releases are also nowhere near as good as the old
| releases, also because GTK really sucks nowadays). I'd like to
| cherry-pick on my editor and declare what I want it to be,
| without needing to implement everything on my own. Why can't we
| transition into this? Why do we need to reimplement everything
| almost from scratch? That just makes no sense to me.
|
| We live in the age where AI autogenerates code (which they
| heavily drew from stealing people's code). Why can't AI
| autogenerate the best, most perfect editor/IDE?
| Antibabelic wrote:
| Step 1. The most perfect editor with all the features is
| created. We've done it. Everyone can tailor it perfectly to
| their workflow.
|
| Step 2. People complain that it's bloated, that they don't want
| 99% of the optional features in the editor, and that the
| codebase is a nightmare to maintain.
|
| Step 3. A thousand more editors are created.
| martinflack wrote:
| Bluefish has had a release in October 2025 and the development
| page talks about gtk-3. Are you sure you've kept up to date
| with it? If you like it, stick with it.
| voidUpdate wrote:
| I keep hearing about emacs and how awesome it is, is there a good
| resource for a complete beginner who is familiar with programming
| but not necessarily editors like vim or emacs, just to get
| started?
| skydhash wrote:
| The book "Mastering Emacs" is nice. But both programs have
| tutorials builtin and extensive documentation. There's also
| various youtube walkthrough videos for features.
| sonnig wrote:
| I strongly recommend the book "Mastering Emacs" by Mickey P.
| You will need some patience as well, I recommend going slow and
| steady for a week at least using the book, with a
| vanilla/standard Emacs install.
|
| It took me about 2 weeks to get productive at first (this was
| in 2018), and now I use Emacs every day for a wide variety of
| tasks (programming and notes, mostly).
| ngc6677 wrote:
| A good way to get straight in, is to download `emacs`, open it,
| and follow the built in "Emacs Tutorial" (click the link on the
| first page that is shown). It brings a new user through the
| concepts of the editor, how to move around, do some of the most
| usual actions, and get familiar with its vocabulary.
|
| At first, it is also a good practice not to install any
| package, and use the built-in capabilities (`magit` and `org-
| mode` are now part of the default installation) for a while,
| the time to discover what comes with the "factory defaults".
|
| Also, for some inspirations, watching videos from `System
| Crafters, Howard Abrams, Emacs Rocks` to see how some people
| use it.
|
| It can take a while to get used to everything, or to install
| packages and customize it to what other editors comes with by
| default, but the reward is worth.
| MarsIronPI wrote:
| Also be sure to use "C-h k" (describe-key), "C-h f"
| (describe-function) and "C-h v" (describe-variable)
| liberally. Emacs' self-documenting nature makes it
| significantly easier to understand what certain actions do
| and how certain options work.
|
| > `magit` and `org-mode` are now part of the default
| installation)
|
| Org is, but magit is not.
| signa11 wrote:
| i would heartily recommend micky-petersen's : Mastering Emacs
| (https://www.masteringemacs.org/about)
| magical_spell wrote:
| https://www2.lib.uchicago.edu/keith/emacs/
| asicsp wrote:
| There's a wiki page with links to plenty of resources:
| https://www.emacswiki.org/emacs/SiteMap
| slu wrote:
| The "Mastering Emacs" is great. But, you don't need it to get
| started, instead check https://www.masteringemacs.org/reading-
| guide
| zelphirkalt wrote:
| If you feel overwhelmed in trying out Emacs, always remember,
| you don't have to switch cold-turkey. You can keep working with
| your previous editor and use Emacs in your spare time. Or go
| 50-50. Or any other method that keeps the initial time of not
| being quite as productive from being a significant downside.
| Once you get the hang of it, you can still try it out for work
| and recognize small issues in the workflow, which you can then
| try to find fixes for in your spare time or spare time
| projects.
|
| Personally, I am using Emacs for everything related to plain
| text files. I have benefited at previous jobs massively from
| already having solved some issues on my own time.
| voidUpdate wrote:
| I currently use nano for a lot of my plain text or markdown
| editing inside my terminal, and VSCode or Visual Studio for a
| lot of my IDE needs. I just keep hearing good things about
| how emacs can be a useful and cohesive system so I'm
| interesting in giving it a try haha
| adlpz wrote:
| A question for the heavy Emacs users:
|
| What's your take on opinionated distros like Doom Emacs or
| Spacemacs?
|
| I've been doing my daily journaling and task management on Emacs
| for while now, using Doom Emacs. Rationale was that it'd be
| mostly pre-configured to a sane standard and that, for actual
| text editing, I'm a long time vim enjoyer, so evil mode is great
| there.
|
| However I always feel that when I go beyond the _safe borders_ of
| the preconfigured, leader-key-accessible realm, I 'm quite lost.
| I don't have good intuitions on how to interact with more raw
| parts of the system.
|
| And I do want to venture further, so I'm feeling I need to get
| re-started with one of the recommended tutorials/books.
|
| Should I start fresh Emacs install instead?
|
| PS: I've coded in a bunch of lisps in the past and I have already
| done a bit of customization on top of Doom, so I sort of know my
| way around, but I'm just not comfortable I guess.
| Karrot_Kream wrote:
| Whatever works for you works. If you want to use your editor
| for a goal, using the guardrails of Doom is fine. I use a
| vanilla setup as my base but I've been using emacs since before
| distributions. If you want to tinker or otherwise learn emacs
| more deeply, feel free to start from a vanilla config.
| Ferret7446 wrote:
| Don't use them. A personal config is highly personal, and a
| distro force someone else's preferences onto you. Even things
| like how exactly your config is organized.
|
| But ultimately it's all about tradeoffs and what works for you.
| You don't necessarily need to go beyond your distro, but if you
| want to or need to, then that's a good sign to try it
| tmtvl wrote:
| My petty opinion is that distributions which disable the menu
| bar are bad, distributions which use an edgelord dark theme are
| bad, and distributions which do both are terrible. Where Doom
| in particular is concerned I dislike the fact that it starts
| with Vi keybindings by default (I quite disfavour modal
| editing, there's a reason I switched away from Vim after 5
| years) and that it changes the 's' binding so I can't even rely
| on my muscle memory.
|
| I've tried both Spacemacs and Doom (and others like Witchmacs
| and Bedrock) and now I'm just using my own 800 line init.el
| (which does include comments and whitespace so the actual LOC
| will be lower) and 110 line custom.el (if you set the custom
| file to a different file than your init then using customize to
| change settings won't mess things up if you manually edit your
| init).
|
| If you really like Doom you can try reading its code base, if
| it's just too much then maybe it would be better to try setting
| up your own configuration from scratch.
| jbstack wrote:
| I think some of these are unfair criticisms, because they are
| things that can be trivially changed. E.g. disabling evil
| mode or changing the theme are one-line modifications in the
| Doom config. After all, any opinionated Emacs distro has to
| make _some_ choices otherwise there would be little point in
| anyone using one.
|
| For me the issues with Doom are (a) the complexity as a whole
| that it introduces, and (b) so many things are already
| installed/configured that you end up using them without any
| real "under the hood" understanding which is so essential for
| customisation.
| jbstack wrote:
| They have their place. I started out with Doom and it
| definitely helped to streamline the beginner phase where
| vanilla would have felt overwhelming. But, as with you, I soon
| became frustrated when I wanted to move beyond its default
| configuration.
|
| I've since switched to Vanilla and I've been using ChatGPT to
| gradually explain and help me integrate the Doom features that
| I like, so that I end up with a similar base that I actually
| understand and which I can deviate from where I want to.
| gtpedrosa wrote:
| I'm in the same boat and curious if other more experienced
| users have any resources to point to. My anedoctal data point
| is that after starting with doom emacs and having problems to
| set it up on another machine i fund out all i needed was a very
| small configuration file to accomplish my orgmode/agenda usage
| needs. So all it took was an issue and a clear vision of the
| goal to find a way through. Maybe it is a healthy approach to
| keep the complexity manageable to your usage
| jwrallie wrote:
| I went from Emacs to Vim to Vscode and back to Emacs with Doom,
| but I still use pretty much all of them. Vscode has copilot,
| Emacs has org mode, vim is great for light editing.
|
| Vim is the magic that lets me use all of those for what I want
| without having to change muscle memory, and Doom just happens
| to aligns with my needs perfectly on that regard.
|
| I think anyone trying to master Emacs within the lines of this
| article will be trying to bend it to their particular needs and
| likely will be annoyed at any opinionated configuration.
|
| The answer to your question will depend if you want to add
| community extensions beyond what Doom integrates or if you want
| to personalize Emacs by yourself. The latter will work just
| fine with leader keys as long as you map them, all Elisp should
| be still available in pretty much the same way. The former will
| probably be much harder.
| joshuablais wrote:
| I personally use Doom because there are a lot of out of the box
| optimizations, some don't like how hlissner has brought nix
| ideas of declarative package management into the mix, but I am
| a nix user so it makes sense. I also am an evil (heretic) user
| - Doom is configured from the get go as a gateway from
| vim/neovim into emacs, and it does that job very well.
|
| I would say use both. You can run multiple emacs
| configurations, and you could have your vanilla config which
| you slowly build as well as Doom/spacemacs where you can see
| what is possible.
| zelphirkalt wrote:
| I have tried Doom Emacs in a Debian VM on Windows host, because
| that was the opportunity to install a new Emacs thing for me
| (to code while playing a game). There Doom Emacs was not
| stable. Sometimes it just crashed and one time I even lost a
| whole function I wrote, because somehow it doesn't do the same
| backup file thing Emacs usually does. The keybindings were
| nice, but the stability requirement I have overrules it. So I
| am back to standard Emacs and currently using evil mode.
| kamaal wrote:
| >>I've been doing my daily journaling and task management on
| Emacs for while now
|
| Trust me, move to Google Docs.
|
| This is simply a whole larger and easier universe compared to
| anything Org-mode will ever evolve to be. Its also backed up
| online, pictures are embedded in the document itself. And
| several other features come out of the box. You also don't have
| spend years learning to use it, and can get productive from
| minute 1.
| stebalien wrote:
| IMO, they're a great way to get started without having to
| invest too much time up-front. On the other hand, that was 10
| years ago and it's a LOT easier to throw together a usable
| config nowadays; with LSP + built-in tree-sitter modes, you no
| longer need 3 packages per language plus a bunch of
| configuration glue.
| craftkiller wrote:
| > What's your take on opinionated distros like Doom Emacs or
| Spacemacs?
|
| If you use vanilla emacs without customization, you are going
| to have a very basic text editor experience. That is fine if
| you understand that, and understand that you'll need to start
| adding your own customizations (like enabling eglot for LSP,
| and company-mode for code completions, etc) in order to get to
| an experience closer to what you'd get out of the box in an IDE
| like vscode.
|
| Some people might see vanilla emacs, assume emacs is just a
| plain text editor, and go back to their fancy IDEs. For them,
| distros like doom/space would be good for avoiding that initial
| shock/disappointment.
|
| Another great use for doom/space is to see what is possible.
| Figure out what bits you like, and then figure out how to
| enable them in your own vanilla-based config. Essentially
| window-shopping for your own emacs config.
|
| But in the end, I'd recommend you eventually get to the state I
| am in: I started with a completely vanilla emacs and then
| slowly added the bits that I wanted. That way I have only what
| I want, and nothing that I don't want. I don't get surprised by
| unexpected features. My breakages are fewer because I use so
| few packages. My load times are great because I am not loading
| a bunch of stuff I don't use. I understand everything that is
| enabled in my config.
|
| You also might want to check out emacs-solo. It's a config that
| is built based entirely on built-in packages rather than 3rd
| party packages. I still use some 3rd-party packages like
| company-mode but it is good to see just how far you can go with
| the built-in stuff (for example, you probably don't need
| projectile, you can use the built-in project.el, and you
| probably don't need lsp-mode, you can use the built-in eglot):
| https://github.com/LionyxML/emacs-solo
| Mackser wrote:
| Are there any good videos showcasing a productive Emacs setup
| like this and how it's used for everyday tasks?
| darshanime wrote:
| not exactly what you seek, but i like the emacs rocks clips:
| https://emacsrocks.com/
| internet_points wrote:
| they're nice and short, but note that the latest one is 8
| years old ;-)
|
| (though https://www.youtube.com/@emacsrocks has newer stuff
| by the same person, seems like game dev in clojure and emacs)
| kevstev wrote:
| https://systemcrafters.net/emacs-from-scratch/
|
| This was my aha! moment where I actually watched someone
| install and use packages and was like oooh yes, this is both
| nice and will actually be very helpful. And I have been using
| emacs since 1998! I find most package pages tell you a lot
| about the how, but very little about the why on you would want
| to use them.
| beanjuiceII wrote:
| so why is he using nix then when there is emacs
| devinprater wrote:
| I love Emacs. My first intro to it was on the Braille Plus Mobile
| Manager back in like 2008 or so. That was a beautiful device that
| ran Linux and was developed for the blind. There's been nothing
| exactly like it since. The BT Speak is a poor ematation that runs
| on a Raspberry Pi 4 and is sluggish because Linux accessibility
| is hard and not optomized for such low-power devices.
|
| Anyway, I began learning Emacs commands in the Emacs tutorial on
| that Braille Plus, , and they made sense to me. Unfortunately,
| Emacspeak only really works well on Linux and Mac, not Windows
| where all the blind people are. Speechd-el only works on Linux,
| since it uses Speech-dispatcher. I got Speechd-el talking on
| Termux for Android last night though, although it was rather
| laggy between key press and speech. Emacspeak development has
| paused, though, and Speechd-el seemingly hasn't been updated in
| half a year. Emacs itself has a lot going on for a normal screen
| reader to interpret which is why Emacs-specific speech interfaces
| are so useful.
|
| A few examples:
|
| * On Windows, with Windows Terminal and NVDA screen reader, arrow
| keys read where the cursor is, but C-n and C-p, C-f and C-b, all
| that, NVDA doesn't say anything. This is with the -nw command
| line option because the GUI is inaccessible. * Now, if I do M-x,
| it does say "minibuf help, M-x, Windows Powershell Terminal".
| From there, I can do list-package and RET and use arrow keys to
| go through packages, but N and P don't speak even though I know
| they move between packages. So it seems like the echo area works.
| * Programs like the calendar, though, really doesn't speak well
| with a screen reader. It just read the line, not the focused
| date. Using left and right jst say "1 2 3 4 5" etc. So custom
| interfaces don't work well. I shudder to think how it'd read
| Helm.
|
| Lol maybe I can get AI to make a good speech server for Emacspeak
| for Windows.
| pfortuny wrote:
| I am amazed by you, and humbled too. Thanks for sharing your
| experience!
| hu3 wrote:
| Amazing.
|
| I really want to make my web apps as accessible as possible for
| the blind.
|
| Could you tell me what are the worst and best practices in this
| regard?
|
| Any article you recommend?
|
| And how could I test accessibility of my web apps, for the
| blind? Perhaps try to navigate it with screen reader and
| keyboard only?
| tinkelenberg wrote:
| I'm exploring a similar implementation and am honestly torn
| between NixOS and a more monolithic experience like Debian or
| OpenBSD.
|
| As much as I love the idea of declarative builds, I'm struggling
| to justify the investment of learning and maintaining Nix for an
| individual setup. I've dabbled with it and mostly encountered
| footguns.
|
| Whatever makes a nice, clean slab is what I'm after.
| nikoomilana wrote:
| I've greatly benefited from investing just a few hours then
| utilizing LLMs. I was very unfamiliar to a lot of the syntax
| from the nix language, so I spent most of my time getting an
| overview. It was less than 8 hours total. Another thing that
| helps a lot is to browse other people's codes on Github.
| YuukiRey wrote:
| > I have seen what people are capable of doing when their tools
| get out of the way, and they are free to just create. This is how
| world class athletes, musicians, artists, writers, and of course
| programmers take what is in their mind and translate it into
| reality.
|
| I think this is a fallacy. If you approach the question of how
| these people achieve the things they do with a bias towards
| tooling then you'll come to the conclusion that it plays a big
| role in their success.
|
| In reality, many of these folks start with a very strong drive to
| achieve something and then the rest sort of follows. If you want
| to be a world class musician, start practicing an instrument.
| Ideally fall in love with music. The rigorous and meticulous
| practice routine comes later.
|
| In other words: you can have the world's best tooling that gets
| out of the way, but you're still as unmotivated to do anything as
| before.
|
| I think it's a cool idea and it sounds like a fun and creative
| endeavor. I don't want to talk it down. But I also wouldn't want
| folks to get the, in my opinion, misguided impression that
| "tooling -> success" is the correct order.
| j4102_ wrote:
| Agreed. You can have all the best tools and you still aren't
| guaranteed "success"
| taeric wrote:
| I'd go further. Some of the world's best tooling is only usable
| by the world's best users. Examples abound on this. The best
| drivers are in vehicles that I would almost certainly crash.
| Our best pilots are in planes that I literally don't understand
| the controls on. (That is true for the cars, too, oddly.)
|
| A really good guitar is easy to miss notes on. Precisely
| because good guitarists don't typically miss.
|
| Now, I think you could reword a little bit. The best performers
| know their tools very well. So well, that they often "just
| disappear" for them. This does require some level of quality in
| the tool. But requires a ton of effort from the performer, too.
| amatecha wrote:
| I think of it a bit differently: if the tool is getting in the
| way, this will hamper the effectiveness and raise the barrier
| for skilled individuals to do their best. Yeah, the absolute
| top-tier max-talent people can do well regardless, but if the
| tools are better quality and more "out of the way", this allows
| a greater pool of people to do their absolute best, with less
| friction.
| dwohnitmok wrote:
| > if the tools are better quality and more "out of the way",
| this allows a greater pool of people to do their absolute
| best, with less friction.
|
| I think YuukiRey's point is that this is not true. The
| bottleneck for people to do their absolute best is almost
| never tool-induced friction, until you've already built a
| strong pre-existing skillbase. Overwhelmingly it's
| motivation, interest, time, energy, etc.
|
| In theory tools can help with this. In practice usually the
| pursuit of tooling ends up being a distraction. This is how
| you end up with the (overly derogatory) idea of GAS, "Gear
| Acquisition Syndrome." The equivalent of this for digital
| things is e.g. the writer who spends money and time trying to
| find the perfect text editor paired with the perfect keyboard
| paired with the perfect monitor etc, instead of just writing.
| There are of course exceptions where tooling is really the
| main unlocking feature, but those are far and few between.
|
| In fact what I get from YuukiRey is the opposite of this:
|
| > Yeah, the absolute top-tier max-talent people can do well
| regardless
|
| Rather it's that the best tooling only really makes sense for
| top-tier people, because for almost everyone else the tooling
| is not the bottleneck.
| WesleyLivesay wrote:
| Seems particularly funny in an article about Emacs, a piece of
| software that lets you get in situations where some portion of
| your "just create" time becomes "managing my custom emacs,
| please don't break".
| tinkelenberg wrote:
| One way to look it is to approach it as a creative practice.
| A good part of any practice is devoted to developing
| technique.
|
| Some are just fine with a standardized but unoptimized tool
| while others are fascinated by building their own high-flying
| TUI. The journey is the destination. If all you create is a
| config file, it still counts.
| robenkleene wrote:
| I think this is a bit of an oversimplification, I see art and
| technology as more like a dance where it's unclear who's
| leading who.
|
| E.g., quick high-level examples: Photograph invented led to
| Impressionism, Andy Warhol's entire oeuvre. Today one of the
| most talked about artists is Beeple (technology-forward in
| distribution medium, tooling, and even practice techniques
| [e.g., "dailies"]).
|
| Music is probably where this is the most profound, take the
| trajectories of Miles Davis and the Beatles, both started their
| career with a fledgling recording industry, ended it record in
| sophisticated studios using instruments and studio techniques
| that didn't exist a mere 5-10 years earlier.
|
| In electronic music this is even more pronounced, e.g., Native
| Instrument's Massive synth facilitating dubstep is a nice clean
| example, but if you've followed electronic music overall the
| connection is obvious. E.g., what dates most pre-2000s era
| music is that today musicians use DAWs whereas before it was
| less powerful hardware devices that had a more specific sound
| (and other arrangement and composition limitations).
|
| This actually feeds into one of the points you made: Being
| successful at art (or anything really) has a lot to do with how
| excited and motivated you are to pursue it. It's easier to be
| excited if you feel like you're exploring new territory, ripe
| with untapped potential, and that's historically often been
| unlocked by technology. Whereas if you keep comparing your
| solos to John Coltrane when you're learning the saxophone,
| that's going to be demoralizing and you'll feel like you'll
| never get there so why bother trying. There's also diminishing
| returns, e.g., that music territory has been so thoroughly
| explored now, so the ROI on developing that specific skill
| (playing jazz at that level) has been reduced, because so much
| of that artistic space has already been explored.
|
| If you tie that all back to the art itself, I'd assume today
| that we already have saxophone soloist who are more technically
| skilled than John Coltrane, e.g., the music theory is better
| understood, and we've had decades of iteration to improve
| practice techniques (there are tons of books and studies on
| this subject now). But you can't replicate the sheer excitement
| that those musicians must have felt as they unlocked new music
| possibilities by iterating on music theory (a form of
| technology), and recording as a new medium to share and learn
| from.
|
| To be clear, most of what you've said I'd agree with, but I'd
| add more nuance like: Leverage technology to make the act of
| creation as exciting for you as possible, but the main goal of
| the excitement is to keep yourself practicing and improving.
| And also look for untapped potential (e.g., a specific example
| that's relevant today, I think GPU-based rendering is still
| under-explored today Beeple has been able to leverage this in
| his art, but I think the big barrier of entry [probably
| ~$10,000+ for hardware/software over the course of a career]
| means there's untapped potential there.
|
| E.g., Daft Punk on well-tread territory due to the
| accessibility of technology
| https://pitchfork.com/features/lists-and-guides/9277-the-
| yea...:
|
| > Technology has made music accessible in a philosophically
| interesting way, which is great. But on the other hand, when
| everybody has the ability to make magic, it's like there's no
| more magic--if the audience can just do it themselves, why are
| they going to bother?
| bachmeier wrote:
| > If you approach the question of how these people achieve the
| things they do with a bias towards tooling then you'll come to
| the conclusion that it plays a big role in their success.
|
| I think the point of the author in your quoted text is that you
| want to avoid the tools getting in your way. If you're a
| writer, you become successful by writing good stuff. That's
| harder to do if your OS crashes and you have to click through a
| bunch of menus while you're writing. That's the reason so many
| bloggers adopted markdown 10-15 years ago - writing in plain
| text meant the tools got out of their way. It's not about the
| tools making you more productive, it's about using tools that
| don't make you less productive.
| theonemind wrote:
| You made me think of this quote: "If you want to build a ship,
| don't drum up the men to gather wood, divide the work, and give
| orders. Instead, teach them to yearn for the vast and endless
| sea." - Antoine de Saint-Exupery
| pphysch wrote:
| "if you want to build 100 ships, refer to the former"
| dima55 wrote:
| Maybe it's a fallacy and maybe it isn't. But I often hear
| people say "I don't use tool X because it doesn't actually
| increase my productivity". X is emacs or debuggers or profilers
| or Linux or version control or code comments or whatever. And
| after observing such people work over time I decided that most
| of them are just trying to justify their laziness. YMMV.
| supersrdjan wrote:
| Indeed. When you have superior skill, inferior tooling can be a
| constraint. But a superior tool will not compensate for
| inferior skill.
| supersrdjan wrote:
| The most seamless capture-from-anywhere workflow I struck upon is
| to have a shortcut on my phone's home screen. When tapped, it
| takes my dictation, transcribes it, and saves it to an inbox.org
| file with an org-syntax timestamp, synced to my main computer.
|
| Basically the notes have the same format that org-mode uses to
| save notes placed in the logbook. But you can also make them as
| individual TODO headings or whatever. It's all plain text anyway.
|
| I try to empty the inbox.org every morning, I typically have
| 20-30 entries to go through. Some things matter and are revised
| and refiled appropriately. The rest gets dumped into a
| chronological log file for just in case.
|
| edit: btw, it would be cool if I also made a version that would
| append the content of the phone's clipboard to the transcription,
| so that I can also catch links and/or bits of text. Or maybe even
| multimedia, thought I am not sure how I would accomplish that.
| FredPret wrote:
| Awesome - are you on an Android?
|
| I tried to do something similar on my iPhone, but couldn't get
| a reliable (or any) way to get an rsync script running.
|
| I ended up with pen and paper though, which is best for me all
| things considered.
| dunb wrote:
| This isn't rsync, but you can integrate a-Shell[0] with iOS
| Shortcuts. You would need to make the syncing happen in the
| script instead of in the background though. I use a Python
| script to create aliases for my email this way, so I don't
| have to turn on wildcard addressing to my inbox.
|
| [0] https://github.com/holzschu/a-shell
| supersrdjan wrote:
| Iphone, yes. I keep the file on dropbox so that is what keeps
| it synced.
|
| Shortcut: https://www.icloud.com/shortcuts/a8a0076cc03f4e699d
| 8ca34bd3d...
| anotherpaulg wrote:
| I've relied heavily on seamless capture for a couple of
| decades, ala Getting Things Done.
|
| My solution is a twilio text number that automatically inserts
| any texts it receives into the top of my todo.md file.
| Previously todo.org, until about a year ago.
|
| iOS has ubiquitous support to quickly share to SMS from
| any/everywhere. It's easy to send a text to this contact from a
| Home Screen shortcut, but also also from the share sheet in
| most every app.
| louistsi wrote:
| I'd be very curious to know more about the shortcut you
| describe. This workflow would work incredibly well for me. I
| already have my notes synced via syncthing, and capture with
| Orgzly Revived, but auto-transcribed captures would be a
| gamechanger.
| supersrdjan wrote:
| It's an iphone shortcut. Here it is: https://www.icloud.com/s
| hortcuts/a8a0076cc03f4e699d8ca34bd3d...
|
| I keep the inbox.org on dropbox, that keeps it synced.
|
| The shortcut is called "longdictate" because previously I had
| a version that didnt require me to press stop after finishing
| my thought. Instead it was set to stop recording when I
| stopped talking. But it misfired too frequently, cutting me
| off, so I added the button.
|
| I imagine there must be something similar to iphone shortcuts
| on Android?
| skeezyjefferson wrote:
| emacs, great if you dont mind coding it all yourself, in which
| case you could have coded an application directly for what you
| need, instead of it being a plugin to a text editor. but I guess
| its cool to use, so theres that intangible piece of nubbins to
| hold onto at least
| jimbokun wrote:
| If the application you are writing is text based, Emacs is a
| great environment to write it in.
| vatsachak wrote:
| Why would I use emacs instead of Helix editor for any language
| other than Lean or Agda?
| rml wrote:
| This is a very good feature/workflow based intro
|
| As the years go by one realizes that even these "features" like
| Org, Dired, etc are just illusions in some sense. They're just
| Elisp code someone else wrote and put a name on. You can take or
| leave them or write your own code that changes/advises/customizes
| them.
|
| It's all up to you. You don't need a blessed "plugin"
| architecture, some PM at IntelliJ's permission etc
|
| At some point one realizes the "visual shell" nature of Emacs.
| Every single piece of text on screen can be programmed to "mean
| something" (see also: "recognizers" from human interface
| research) and have actions taken on it either by the editor
| itself, or external processes / scripts you call with a command.
| If it's common enough, make a key binding. It's your house, do
| what you want
|
| Depending on how you set up your environment, you may never have
| to look at text again that you do not have this level of power
| over. You are no longer at the mercy of "application developers"
|
| I've been using it since 2005. Guess how many of 2005's popular
| editors even still exist
|
| My recommendation to anyone trying to actually learn is start
| with the full vanilla config, weird default keybindings, etc, go
| through the built in tutorials, and only add things to your
| config that you write and understand yourself. Understand it in
| its own terms. The plethora of packages, etc have "cool features"
| but impede learning by adding mountains of complex dependencies
| that are opaque to the beginner and cause confusion IMO
| pjmlp wrote:
| I used it between 1995 and 2006 as replacement for not having
| proper IDEs on the UNIX systems I had to work on.
|
| With that requirement going away, I left Emacs behind.
| cmrdporcupine wrote:
| Re: author's comments about exwm
|
| imho exwm is imho fundamentally flawed, _especially_ when running
| emacs or doing emacs stuff inside it. You end up in a battle over
| keybindings, etc.
|
| I think a better model would be a window manager in a separate
| process that your emacs elisp processes can communicate with over
| IPC.
| kleiba wrote:
| OT: long time Emacs user, but my new employer insists on everyone
| using PhpStorm. And don't get me wrong, that's really a great
| IDE. I still miss Emacs, though.
___________________________________________________________________
(page generated 2025-11-06 23:01 UTC)