Many common SOC's MediaTek, Realtek, and Broadcom SOC's quite often used modern audio capable devices analog pins can be software defined either input or output.
IIRC I saw already Bruce Schneider's blog some team proof of concept where they listened using laptop speakers what was spoken in that room. Audio quality wasn't perfect, but it making sense what was spoken was good enough.
"…I saw already Bruce Schneider's blog some team proof of concept where they listened using laptop speakers what was spoken in that room."
Users need to know the electrical features of their H/W and its limits. If a loudspeaker output stage is designed (hardware wired) so that it can never act as an input then no later firmware update can turn the speaker into a microphone.
This is why hardware authentication is becoming more and more important.
Right, it's true that if there is an amplifier stage then it doesn't work. But some devices have had also tiny speakers used for for user interface audio feedback mechanism also used beeping error codes etc. Those SoC can drive that kind load of quite well directly and there is just a tiny speaker coil from IO-pins. That kind of speaker can function lousy microphones. That's what that PoC was all about.
First thing came now from long time ago my former aussie colleagues (mates) in Saudi when we worked there. That when you get out plane and are asked to show passport by the border guards. And they usually ask some the usual questions and then perhaps like
Q: Do you have ever committed a crime or have criminal record?
For heavens sake even though down under they understand jokes, do not try your luck with an answer:
A: Is it still required? :)
Depending the person interviewing and how bad day have had already, they may get you some feedback and give a lesson. I don't know if this is true, but that what those colleagues then told and I think I'm gonna believe and not try joking in that situation.
Right, that ROM BASIC was such a waste for them for years.
Some clone makers quickly found out ways take advantage of that space adding more RAM there. Then bit later it came area where you could even map over 1MB placed memory blocks there with a config.sys loaded driver.
>Why do you think Windows is currently such a mess?
There have been some writings and posts here about Microsoft. Here is one from last spring, from a guy that was long time Windows core developer and moved to Azure group. It's well worth reading, what he writes about challenges they have had and most likely still have if not even worse now.
I have read that, yeah it also shows a lot how things changed.
As per his interview on Dave's Garage, besides being of an age where he really doesn't need to work, at the time he was involved on getting Linux running on XBox on Azure, apparently Microsoft uses idle consoles from XBox Cloud for AI.
It is, but some tools like Turbo C did provide asm generating switch (-S AFAIK) directly you to use and saved you from using debug.com or any better disassembler.
Sure, it wasn't uncommon feature at all, but many fellows I knew had not noticed it before I suggested using it when a colleague or a friend was wondering how he would write that function assembler and try to make it faster.
It tells me more about some people not being curious enough to read documents and explore environment they work than others apparently.
Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time.
Then later it changed bit as vendors did not any more ship any or just some crippled compliers to compile just a new kernel with the base system to curb their language competition. Which made third party compilers had to either provide with complete set their own creating executables or ask buyer also licensing system vendor compiler toolkit which they would not otherwise need. That then caused prospect third party compiler customer add that licensing fee top of offering and compared which option they would buy if any. That was time when developement toolkits started changing. Under MS-DOS there never was compiler shipped with it that was a situation all the time, but with the minis and larger systems more what described here above.
ps. I think you get much too wound up about C-language. For a long time there was no real alternative use to cross environments compatible way developing thing without major rewrite each platform. That what mattered more than anything else then and in some sense also to some these days also. And no language needs to be put on pedestal like you wrote message you already changed or deleted so that I did not get to answer.
> Assembler generating was long time a standard feature of compilers simply because writing the assembler code was easier than directly runnable or linkable object code. And for language designer and compiler programmer it was easier to read verifying correct code generating that way. Why bother writing assembly compiler, linker etc. when you usually already had them in the system that time.
It's easier to directly generate binary object code than assembly. It also makes for a way, way faster compiler. Also, one of the first programs I wrote when developing my compiler was an object file disassembler.
Yes, mostly proprietary third party systems which abtracted complexities away from programmers placing their trust to that often not even sure your language vendor was not belly up or with good luck purchased by someone else who then told you we do not support it any more next year. And left you to deal with that. Not fun, not even close I may add. I know who weren't so lucky and had to gather pieces at least mostly rewriting things again new toolkit.
Software development invests in that written code and you learn to appreciate that when you got a lot of it understanding how large and costly task it would be to rewrite another language. Especially then it was that. Now LLM's, much better IDE's etc help a lot with that. Today standards thinking you do not make fair comparison what it was back then.
>...have you ever tried to write portable C code in K&R C without it being full of #ifdefs?
Yes I have done it, not just tried. It wasn't too bad after all when you knew how to do it. Most of systems dependent were hidden away by ourselves to .h files and some to libraries we did. That time it was common thing to teach even, and if not learn from others code how to do it.
That way we knew we had better chance easier to port it something even remotely close existing kind of platforms and OS's. Investment in written software as too great to ignore.
But, did you lately or when did last time write software without relying those abstractions being hidden away either device vendor language libraries or third parties modules?
While you think of it, let me tell you that this situation where we are now is so much much less diversity with our target systems and plenty of programming languages with multitude of good libraries and ready made modules do not compare at all to what situation was end of 80's. Comparing software development effort today's languages and tools by then doesn't make sense at all. Everything was so much slower and time consuming.
That area where C-language is still relevant is now much narrower, but there still are niches where I understand it fairly well. I also understand that you don't get it but that is not a my problem, it's more of a you problem if that irritates you from my point of viewing this matter.
But whatever written here for before above, I see no value continuing this argument with you any more. If you haven't this far understood what I tried conveying there is no hope with me you will eventually get what I try to explain.
That was one example among many others that I could have chosen from compiled languages, I just happened to chose the very first successful one.
I might also add that I was surprised that you lost an opportunity to advocate for D, which what I was actually hitting for with that remark alongside a smiley.
Some people forget not only is Fortran one of the few languages with first class support for GPU programming, and one of the reasons OpenCL lost, it has all the goodies of modern languages.
I used it as example, as I could have used any other compiled language, including D.
But when Turbo C with assembler (TASM) came out those were just great. And by that asm output generating feature it was often way faster way to write something first in C, translate to asm and go from there do what you wanted with that asm directly. I'm not sure which higher level compilers came with that feature, but once available it was many times just great thing to have for sure.
And file handles stdin, stdout, stderr same file numbers also. There was and still is overlapping features with Microsoft later and current operating systems.
Linked post is quite good and had forgotten completely XEDOS mentioned Byte article.
It did, and also up till 3.0 (thus 2.10 and 2.11) had also SWITCHAR which you could change command options character / to - like in it was in UNIX convention, from CONFIG.SYS definition.
The problem with changing / to - was, that under MS-DOS command line parsing was left completely to a a loaded program, which then would had to know how to find out this change and act accordingly. And if not only MS-DOS std. utilities behaved properly and others not so much. Thus causing confusion which perhaps then lead to dropping that feature 3.0 onwards.
I think it was also before 2.0 or at least what delivered with Apricot PC (UK made PC) 1.25 which I tinkered with few days as we had it on display from Finnish importer ARAIC Rautakirja Oy (Finnish railways VR magazines and other related travel reading importer, also keeper of the R-kiosks). A very nicely built non IBM PC compatible PC with good graphics and then uncommon 3.5" 70kb disk drives before Apple Macintosh made the more popular.
e: Now did it change also path separator from \ to / ?
It may have done it also. I bit later work more with Xenix and can't remember for sure. Starting from 286 versions SvR2.x, 386 SvR3.x up till SCO UNIX SVR4 early 90's and less with MS-DOS besides maintaining couple of TSR's I had written and just checked every MS-DOS release that those still did work.
I think I did have some time early -90's someone did alternative C0.lib which actually when you linked it with your programs it made much easier porting some *nix software to MS-DOS. No need to make modifications command line handler, as that modified startup-library as I think it's or was called, did what was needed.
It was then COMMAND.COM ie. Dos command line did not do that. And there were alternatives like something called 4DOS which I did never use, but those could have done it. Or did they?
I have't used Windows for quite long time. And I do not know if CMD.EXE or PowerShell whatever its name are any better. Maybe someone knowing would like to comment this.
This isn't so much a cmd thing as a fundamental Windows API thing. CreateProcess takes in the entire command line as a single string.
Powershell is a completely different model where native commands run in-process, you can import commands and invoke APIs from arbitrary .NET assemblies, and then the PS runtime handles all argument parsing (and many other things). But it also lets you invoke and interop with arbitrary command-line executables and then those do their own parsing like they always have.
>This isn't so much a cmd thing as a fundamental Windows API thing. CreateProcess takes in the entire command line as a single string.
So is that CreateProcess much different from nix execve() which passes just a pointer to string of executable first followed by pointers to arguments *argv[], and process environment same way *envp[]?
Thus it is the shell which responsibility is to expand all wildcards before passing to that executable arguments nix systems, which do not expand any wildcards itself before passing to executed program.
I'm no Windows programmer so, genuinely what's the difference from point of executed program and just that Windows any shells do not expand wildcards etc. ?
My previous post when I did mention that alternative c0.obj (not lib, sorry) that I for example had about 36 years ago from somewhere was a nifty modified trick which took that plain dumb MS-DOS COMMAND.COM passed string and instead just making it a char *argv[] array first expanded wildcards before your main() got control. It did work very well and saved quite bit of effort when I ported some tools to MS-DOS and I think there was another version of it for OS/2 (1.something) that I used also.
I did not have to add ported software from unix any command line expanding code myself because that alternative startup c0.obj did it for me. Shame I do not remember where I got it and who did it, but it was really good. Now thinking of it perhaps it was from Compu$erve some forum or WSMR-SIMTEL20 archive.
I remember that also Fabrice Bellards lzexe and something spawnsq() (not sure about exact name any more) library also was in use. The latter swapped (saved out file) out running most of MS-DOS program before executing like execve() and freed a lot more memory to run that other program then loading it back when called program was done. I think it used something like 8k memory while resident when other called was running. Which was often enough and no need do any horrible .BAT rewrite tricks to able to accomplish same functionality.
PowerShell has a built-in command parser that all cmdlets share (provided commands; `function` based command scripts; so forth) and it's in a C# library that other .NET-based CLIs can import if they like (though today it's still not that common in writing .NET CLIs to use PowerShell's command parser and not a simpler one or the new-ish System.CommandLine which also doesn't quite resemble PowerShell's built-in one).
no, Windows still leaves that to the program. Usually handled by the msvc runtime for argv/argc, but the base windows API is GetCommandLine, giving you a single string.
Agreed what you wrote. It's great and well written book. I did read the book again last fall after couple decades.
Then few weeks after finishing book I ran into his LinkedIn post (bit OT sure) if what book told was his recollection still accurate in part where book refers his work at DEC Systems Research Center (SRC) at the time. Following is what he replied to me:
"
markoff and hafner did extensive research and the book is accurate in all ways i could know. note that while mitnick has paid his debt to society (jail time), i've never received from him an apologia. my only other written mention of those breakins was here:
Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves.
Those work well also besides shells with Chromium/Chrome/Safari etc. many browsers input fields (address bar and text area). Cisco IOS, Juniper Junos, Netscreen load balancers too etc. IMHO makes jumping around CLI much much convenient and faster than moving hand to reach cursor keys.
My only gripe is that Firefox and its derivatives it doesn't work any more. Long time ago it did work. And I have no idea why feature was dropped some rewrite.
Nothing else is capable of handling the variety of text-related things I want from my text editor.
- I consume HN and Reddit in Emacs. Allows me for example to quickly search through all the links shared in a thread.
- I read Jira and Slack in Emacs - in org-mode. It is far better for finding relevant things, extract them for my notes, etc.
- All my writing done in Emacs. Because I have: spellchecking, thesaurus, etymology and definition lookup, translations, LLM integration, etc. All my notes are in Org (Zettelkasten style).
- All my spaced repetition cards are in Org-mode (they are parts of my notes, I don't need a separate system to manage them). I can generate number of cards to study a topic, from selected notes.
- All my AI sessions are in Emacs. It's amazing that I can send just about any text to an LLM, anytime, anywhere. I can do it in the middle of typing a message, like this very comment.
- I watch YT vids controlling the playback directly. I can pause, rewind, speed-up, mute, extract transcript, etc. - this is indispensable while watching and taking notes.
- my email client is in Emacs (of course, why not)
- my Telegram client is in Emacs. I can easily retrieve a video from any web page and send it directly (without linking the page).
- I can extract any part of my screen and OCR the text out - it pops up in an Emacs buffer.
- I perform all searches from Emacs - I can google, duckduckgo, brave, HN (algolia), wikipedia, etc. I search through my browser history in Emacs.
- I can control my browser tabs, switch between them, find matching lines on the page, jump to links, etc.
- I read and annotate PDFs in Emacs.
- And I haven't even touched anything programming-related (tons of things)
Why, oh why would I ever feel unsatisfied, hoping that there's anything else that can help me do things better? Honestly, there just doesn't exist a piece of software that could help me do even a subset of things I can easily achieve with Emacs. You'd ask me that question in 20 years, if I'm alive and still using a computer - the answer would be - "Yes, what else would I use?"
I'm currently using my custom fork of thanhvg/emacs-reddigg. It isn't ideal, I've been itching to rebuild it into something more robust. Well, one day I may get annoyed enough and just do it.
Nearly 40 years for me. Wow! I’d note that MacOS input fields also have basic Emacs bindings for cursor movement, not just shells and browsers. Works in MacOS Mail, Evernote, etc.
It annoys me so much to have learned that GTK text fields used to have an Emacs editing mode, which they've hidden behind an unaccessible configuration option, and now it's hopelessly broken in modern GTK version.
I spent a day or so hacking around with kanata[0], which is a kernel level keyboard remapping tool, that lets you define[1] keyboard mapping layers in a similar way you might with QMK firmware. When I hit the control or meta/alt/option key, it activates a layer where Emacs editing keys are emulated using the GTK equivalents. For example, C-a and C-e are mapped to home/end, etc. I preserve my macOS CMD-not-control-key muscle memory this way too.
The only problem is, this is not the behavior I want in terminals or in GNU/Emacs itself. I wrote a small python daemon (managed by a systemd user service) which wakes up whenever the active window changes. Based on this info, I send a message to the TCP server that kanata (also managed by a systemd user service) provides for remote control to switch to the appropriate layer.
Yes, emacs keystrokes became kind of cli lingua franca, which apparently many do not know. I don't remember my self ever read about those supported explicitly anywhere, but accidentally I found out long time ago and then whenever I try new systems, programs and whatever I try which keystrokes do work. Quite often at least some work.
It's GNU Readline[0] or similar. It's all over the place, on Linux at least. Being GNU it defaults to emacs, but the vi support is also excellent. The first thing I type in any foreign bash is 'set -o vi'.
Yes it's GNU readline, but note that the very Wikipedia link you gave explains that it's GNU readline that re-used those shortcuts from Emacs, not the other way round.
So it's not wrong to call these "Emacs" shortcuts.
Nope. And I’m probably not a great person to write it. I’m hardly an Emacs power user. I had friends who would do everything in Emacs to the point where I would joke with them that Linux was just their Emacs boot loader. I keep lots of other apps and term windows open. My init.el file is pretty simple. I’m often aware of a vague capability that Emacs has, but I’ll brute-force my way through an editing task with keystrokes and some keyboard macros rather than add a new fancy library, at least until I’ve been forced to do the same thing a couple times per month. That said, I do remember trying to use Emacs on a 300 baud dial-up link. That was painful, though truthfully everything beyond ed would be painful at that speed.
I'm curious... why are people (this thread, but there are several independent others) replying to "Is anyone still using emacs?" ? I don't see that sentence anywhere in the article!
Sure, and I'm not arguing that the answers are uninteresting, but I found it odd that this is being double-quoted several times as if it was taken out of the article.
It's 26 years for me. Emacs is I believe the oldest software I still use. I started on an SGI Irix in 2000. I used it also on HP-UX, Solaris, Windows, MacOS, and of course all varieties of Linux
> Emacs cursor movement keystrokes are quite widely supported elsewhere too which use GNU readline or implement at least subset themselves.
And many keystrokes work on MacOS, too. That was a pleasant surprise when I got a Mac laptop for work.
It's quite difficult to find software older than Emacs in widespread use. Emacs is one of the "original" software, the first GNU software for which the GPL was created. It competes with vi, whose direct lineage has been broken (nvi and vim are reimplementations).
> It's quite difficult to find software older than Emacs in widespread use.
Agredd! Aside from the basic Unix commands (ls, cat, etc), the only substantial program that I use today that I also used in 1991, is emacs.
Well, and perl. I don't write much perl these days, but I have tons of perl scripts accumulated over the decades that I use daily so that counts as using it.
Third oldest for me would be mutt, which is still my primary email client. But I only switched from elm to mutt in.. not sure maybe 1996?
One advantage of vi is that even though emacs is available on all those systems, vi is actually installed on all of those, setting aside windows. If you know rudimentary vi you can walk up to any of those machines and edit a configuration file well enough to work.
vi isn't even in the same neighborhood in this regard. You can and should learn vi (and ed!) in one afternoon even if you never use them. Whereas Emacs isn't something you just learn in an afternoon. (And vim is not the same as vi)
That is a separate discussion from whether you should use ed or vi normally. You learn the "fallback" with the hope of never being forced to used them.
I use Lem. It's an "emacs" but not a clone of GNU Emacs. It's written in Common Lisp, extensible in Common Lisp and it's way more performant than GNU Emacs. Obviously less features and plugins but for my needs (writing Lisp code mostly) it's great.
Dunno, I've been trying it off and on since it was first released in like 2018. I don't theres any particularly noticeable changes from 6 months ago specifically.
I also used Emacs way back in the day but have been Vim/Neovim for the last 5 years or so. But I recently started a new Lisp project so revisited Lem, actually set it up the way I want (with LazyVim-like bindings), and found with my changes and comfort hacking on it (it's all Common Lisp top to bottom so it's easy to change) that it can replace LazyVim for me now. Just using the ncurses front end BTW.
I don't like keyboard-centric text editing. Yes GNU Emacs supports the mouse, but just like Vim the experience is miserable. You can spend a lot of time configuring it, but at some point you're just writing extensions of extensions just to get a basic GUI flow that isn't painful, and no matter what it'll never feel quite "right". The program just wasn't built with the idea of a mouse in mind, and bolting it on really wasn't sufficient.
Add onto that pretty nasty performance issues, internals that aren't exactly well thought-out, and the experience in general having a high background noise of jank, where it's not uncommon for simple things like rainbow parens to randomly break.
I understand why other people like it, but it's really just not for me. I'll stick with Lite-XL.
No. Even most keyboard-centric text editors implement mouse inputs, with only a few exceptions coming to mind, almost none of which anybody uses today, for example ed. In fact, most editors don't even restrict text insertion and deletion to keyboard input, which is what you might be confusing with "text editing", which might be more clearly expanded to "operating a text editor".
The only reason why I was taught vim is that a coworker wanted someone to know it so they can explain why emacs is better. It didn't work and I've transitioned to neovim.
I'm a die-hard vimmer. I use vim-motions everywhere - they permeate my editors/IDEs, browsers, terminal, I use them system wide (e.g. to change volume or control media or my WM). One day I woke up with the realization of the fundamental truth - Emacs simply vims better. Much better than even Neovim. I just had to master Vim and grok some Lisp to arrive to that conclusion.
People fighting Vim vs. Emacs are materially wrong - they focus on superficial (albeit substantial) angle, instead of considering the core ideas behind them. Vim's augmentation of modality is an incredible, beautiful, practical concept. Lisp - yet another grandest idea in all history of computer science. And these ideas are not overlapping. Lisp-powered vimming grants you genuinely joyful experience - surprisingly empowering and enormously liberating.
Emacs' Lisp interpreter is so capable - accurately simulating vim in it is not impossible, while pretty much every other editor/IDE has failed - not a single VSCode plugin, not Sublime, not IntelliJ with IdeaVim have ever fully implemented vim motions to the degree where it doesn't feel foreign, while Evil-mode in Emacs feels like a built-in feature. Until recently, bolting Lisp into Vim seemed impossible, today you can get a pseudo-Lisp engine with Fennel. Even though it unlikely ever feel like Emacs.
If you're sticking to one thing only due to some muscle memory, sure you're not a savage, you're just a bit ignorant.
I suppose that you mean via some third party cloud. I personally sync my Org mode notes via adb when I backup the phone occasionally. I read on the phone using Orgro.
So? Emacs has built-in solar and lunar calendars, has world-clock command, format-time-string accepts ZONE argument. Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones? This can be done in less than 15 minutes. With AI maybe in 20.
You're not dealing with an app you paid for, and your complaint not even an accurate one: Org's timestamp format doesn't encode timezone by default. Emacs absolutely supports the feature you want, you just didn't know about it.
Oh, you can't imagine how I'd like to be proven wrong.
Last time I checked, proper timezone support wasn't there. One could specify single timezone for entire org engine, but not per timestamp. I found some nearly official mailing list thread where participants couldn't settle on a single solution, and so the conclusion was that proper TZ is not coming to org.
> Org's timestamp format doesn't encode timezone by default
> format-time-string accepts ZONE argument
Isn't format-time-string just a visual decoration? Last time I checked, agenda and all other plumbing always treated every timestamp as local (to the TZ configured globally). And so if I recorded that I have a meeting at 1PM London time, my org-agend would show it to me 1PM even if my TZ is set to New York.
> Why don't you build a minor mode that calculates the offsets and shows you stuff in different timezones?
Can you elaborate? My understanding was that I'd need to rewrite entire org in order to support time stamps with mixed time zones embedded in them.
> You're not dealing with an app you paid for
Actually, I'd be willing to pay above the competitor _subscritpion_ price for an org-based organizer with
- proper TZ support
- conflict-free sync between devices
- (cherry on top) touch UI friendly Android client. But honestly, orgzly would do, as long as it supports the above
a) you need to see the timestamp in different timezone(s)
A minor mode with home-zone/visiting-zone vars showing dual times via overlays answers: e.g. "It's 1PM here, what's that in London?" That's the world-clock problem. Useful, easy to solve in ~15 min.
b) anchor an event to a foreign zone permanently - you want to record a fact about an event that is intrinsically tied to a zone
For that, yes, you'd have to either change a bunch of things about Org-mode - every consumer of timestamps (agenda, clock, deadlines, repeaters) would need to become zone-aware.
Pragmatically, you can store the zone without rewriting Org, by piggybacking on a property/tag and a conversion step.
1. Author in foreign zone, but store normalized to one canonical zone (e.g. UTC) in the timestamp, and keep the original zone in a property:
* Meeting
:PROPERTIES:
:TZ: Europe/London
:END:
<2025-06-01 12:00> ; UTC
2. A small minor mode renders the display via overlay in either the stored :TZ: or your current zone, computed with `format-time-string … zone`.
The limitation is that all the timestamps within a single heading can only be of a single timezone.
---
There's yet another alternative - you can codify the TZ on each timestamp as a propertized text. The problem? Text properties don't get persisted, so you'd have to add custom logic that mangles the timestamps in the file on save (essentially breaking them for all dowstream consumers), and then restores them to normal shape with propertized timezone info. I guess this begets another problem - many Org operations reconstruct the timestamp string from a parsed org-element struct.
I guess, I do stand corrected - if the problem you want to solve is "b" - there isn't a straightforward solution to it.
Aren't Org mode dates ISO 8601? ISO 8601 has an optional timezone, is that not supported in Org mode? You could then use format-time-string to configure how it is displayed.
Another possible solution. Often - but not always - a datetime and timezone pair can alternatively be represented as a UNIX timestamp. Depending on the use case there are tons of ways to manipulate UNIX timestamps, and Org mode might support that naively (I'm not sure, try it).
If emacs is not installed on a system, I use sed. In addition to not getting stuck inside it when you don't remember the magic exit incantation, you can immediately reuse the command on a different file. And it doesn't play sounds while you do it. Plus when you're typing the sed command, you can use emacs key bindings to move around!
"If emacs is not installed on a system, I use sed."
Bill Joy (creator of vi) once said that if he sits down on a foreign system, he reaches for ed [1].
To be fair, both emacs and vi have "magic exit incantations", though if you have emacs perhaps you have a menu in GUI mode. If not, C-x C-c is really not any more memorable than :wq! The vi one at least has an obvious mnemonic ("write quit") but either way, you need to know an arbitrary sequence of keystrokes.
NeoVim because it's fun!! So many plugins and colorschemes!
So customizable- these days Claude will just change it for you, no need to learn the APIs if you're just interested in the result. Yes you're AI-slopping your config, but the drawbacks to that are super low (it's a personal editor, not something I'm inflicting on others)
AI slopping my config is what allowed me to learn vim without going through the pain of setting it up. I can ask AI to teach me about some motions or set up some configs for m in lua without ever know lua. This is the biggest impact of AI in my professional life.
Vi is fine. It's superior and to bare ed - The Standard Editor*, when you don't have anything else available. I made much of my living coding vi 7 years in -80's. And I still use vi, when emacs is not there or system has so little memory that emacs is too much. Which is usually with a embedded systems or some old Unix on single mode fixing unbootable system.
Answering to preemptively asked question that doesn't appear in TFA: yup I sure still do.
If anything compared to the 486 days, back when Eight Megabytes And Constantly Swapping was a joke that made sense, my computer now instead of 8 MB or RAM has 32 GB or RAM (so 4096x more RAM, or 2 exp 12 more RAM: something something about transistors doubling every 18 months and all that)...
Who's laughing now? ; )
Seriously though: Emacs with native-compilation, tree-sitter and LSP support (and stuff like Magit and ripgrep integration too) makes it really amazing.
Yeah, emacs is very competitive with "modern" IDEs. Even in JVM languages, which for a long time wasn't true. And I don't know of anything, anywhere that can rival magit.
I've been using it for far less time than you have, began ca. 2011 or 2012 here[0], but over that time it has been my constant benchmark for what an editor should feel like, and every other IDE I've used has fallen short. With LSP especially, in the past 6-7yr I have actually been predominantly using emacs. Part of that was being fortunate enough to no longer have to work on much JVM stuff since ca. 2019, but it's also due largely to large advancements in emacs' capabilities.
EDIT: In particular, this is exactly where I fell down the rabbit hole:
> If you are not familiar with Emacs you SHOULD run the tutorial, which can be accessed in edwin by holding down the control key and typing h, then, releasing the control key, type t. (C-h t)
I don't know if there's anything else on the entire internet I can specifically point to that has had a greater impact on my professional life... strange.
For Firefox I've switched to Glide (Firefox fork?) and configured it to implement Emacs keybindings. There is a config on the project's Github discussions page that I started off of.
> Emacs cursor movement keystrokes are quite widely supported elsewhere too
Yes, even in Codex and Claude Code.
> Those work well also besides shells with Chromium/Chrome/Safari... My only gripe is that Firefox and its derivatives it doesn't work any more
Interesting, my experience is exactly the opposite: I had to finally bite the bullet and migrate to Firefox because Chrome/ium switched to GTK4 which removed key themes support.
(That's OK though, I should've moved off Chrome a long time ago.)
There are so many fad technologies out there, but vim/emacs and unix command line in general are skills you can invest in that stay relevant for 40+ years.
A weird, inscrutable project management tool for the shell written in Perl 4 and Guile Scheme, that the ten people in the world who learned to operate it swear it is the greatest piece of productivity software ever invented.
Well, I've got to admit I've haven't read HN using emacs. Is there such a .el thing avalabnle somewhere? It would be great to read HN as it was with usenet news. Not joking, that would be excellent tools I'd like to have !
Those keybindings work on MacOS for me, but not on Linux (by default).
There is a way to enable Emacs keybindings in all GTK apps on Linux, but it’s quite buggy in practice (many apps define keybindings that override or conflict with these), and I believe the feature is officially deprecated.
Yes. Basic emacs keybindings work pretty much everywhere in macOS. I have run into a couple of apps that don’t behave correctly, but 99% of the time they work.
I have been using VSCode for teaching the last few years, and routinely use a VSCode without plugins for that purpose, and Emacs keybindings work fine in its text area (the code editor itself). If it doesn’t work for you, then apparently something is broken on your computer. Not all keybindings work but the ones listed under Text Editing here certainly works for everyone else:
https://support.apple.com/en-us/102650
I am typing this in a textarea in Chrome, and the basic Emacs navigation commands all work: C-a, C-b, C-e, C-f, C-n and C-p. (The M- equivalents don't, though. You just get some special chars: å, ∫, ´, ƒ, ñ (dead char for the accent), π.)
Chrome Version 149.0.7827.155 (Official Build) (arm64)
Very similar in Visual Studio Code.
(I started using macOS in 2010, I think, and the Emacs-style shortcuts have felt pretty well supported the whole time. I can't promise that applies to Chrome as well though, as I'm not a regular user.)
Yes. For me, on all MacOS versions from Catalina to Sequoia, the basic Emacs keybindings listed here work almost* throughout the operating system:
https://support.apple.com/en-us/102650
I don’t daily drive VSCode but I use it for teaching, and then basic Emacs keybindings like C-n and C-a and C-k work pretty much everywhere, from the command palette to the code editor, without any plugins.
I also don’t use Chrome as my daily driver, but keybindings like C-a/C-e certainly work in both text areas and address field, or I would have remembered it as one of the annoying exceptions. I do regularly use a few Electron apps, which are based on Chrome, and it does work fine there.
*: There are a few apps that deliberately break the Emacs keybindings. Microsoft Office is one of them, since they insist that Ctrl keybindings on Mac should do the same as it does on Windows, which is extremely jarring if you rely on the Emacs keybindings everywhere else.
Weell, it's not completely untyped, but it is runtime type-checked. There's stuff like `(if (integerp foo)` and `(defcustom ... :type '(choice (const tag "abs" abs) 'integer))`
And then there are more ambitious projects like the static analyzer and language server https://github.com/emacs-elsa/Elsa
I haven't tried Elsa yet since it seems to require setting up a package manager like Eask (I don't really understand why I have to install a package manager to run a language server, especially when they support four emacs-specific package managers?) and the docs were very light on whether eglot is supported or just lsp-mode.
I just tried, and my macOS up todateFirefox (still Sonoma few weeks), doesn't work. Nor does Waterfox (Firefox derivativ) that I've been using more lately. Could it be some setting I need to set before it works?
Unless I misunderstood your question, are you simply trying to use emacs bindings in all text areas of the browser like the URL bar, any text fields on webpages, being able to move to the beginning or the end of a line, backspace, etc., go to the next or previous line, all with emacs bindings? That has worked for decades on Mac and it works for me now in all browsers.
Idk, its never stopped working for me for the past 10+ years. And Firefox has additionally always supported ctrl-n and ctrl-p working in the address bar for suggestions while Chrome has never supported this
Bit late to reply, but seems ^A and ^E (jumping line begin and end) at least do work in Firefox.
But for example ^T (letter transpose) do not work on macOS Firefox, which I'm quite accustomed to use also. But ^T works fine same macOS Safari and Chromium.
Firefox apparently has its own input method which do not implement all what macOS supports.
Regarding emacs-style kbds in firefox -- I use vimium to remap most actions, and occasionally resort to an additional global keybinding helper app (e.g. BetterTouchTool on macOS).
I have never used emacs seriously as an editor, however, I couldn't work without magit.
I even manually build emacs 28 so I can re-use the same set of magit configure files.
I started with gosmacs then switched to gnu emacs in 1985ish. So about 40 years. The renaissance of emacs development in the last decade has been very nice to see.
IIRC I saw already Bruce Schneider's blog some team proof of concept where they listened using laptop speakers what was spoken in that room. Audio quality wasn't perfect, but it making sense what was spoken was good enough.
reply