The local credit union in Eugene had installed Flock cams at the entrances to all their branches. They took em down after only a few of our community members began protests out front a few branches and emailing with the CU's leadership before our city terminated our contract and removed the cams
I've been asking for little tutorials or implementation plans for things, and demanding that the model not write any code itself. Following the advice of Geoffrey Litt.[1] I find reviewing code written by my coworkers to be difficult when i'm being paid for it, surely i'm not gonna review thousands of lines of auto-generated code and the comprehensive tests required to trust them in my free time...!
So I've been learning kotlin & android development in the evenings and i find this style of thing to be so much more effective as a dev practice than claude code and a better learning practice than following dev.to tutorials. I've been coding for almost 20 years and find most tutorial or documentation stuff either targeted to someone who has hardly programmed at all, or just plain old API docs.
Asking the langlemangler to generate a dev plan, focusing on idiomatic implementation details and design questions rather than lines of code, and to let me fill in the algorithm implementations, it's been nice. I'll use the jetbrains AI autocomplete stuff for little things or ask it to refactor a stinky function but mostly I just follow the implementation plan so that the shape of the whole system is in my head.
Here's an example:
> i have scaffolded out a new project, an implementation of a library i've written multiple times in the last decade in multiple languages, but with a language i haven't written and with new design requirements specified in the documentation. i want you to write up an implementation plan, an in-depth tutorial for implementing the requirements in a Kotlin Multi Platform library.
> i am still learning kotlin but have been programming for 20 years. you don't need to baby me, but don't assume i know best practices and proper idioms for kotlin. make sure to include background context, best practices, idioms, and rationale for the design choices and separation of concerns.
This produced a 3kb markdown file that i've been following while I develop this project.
This is a really great idea going to try this out. I similarly just cannot mentally stand reviewing vibe coding PRs all day, but this sounds genuinely useful.
I recently bodged together a board that would drive FastLED programs parameterized by the control voltages that come off a eurorack, it was really neat and straightforward because you have some really good clock sources to sync to
hardware or software keyboard I don't think I've ever used a binding like that and if I did I would almost immediately bind them to something more reasonable.
the fdroid build of android doesn't have a real linux environment that you can install arbitrary binaries on to. you can switch to a termux-ish proot environment and do x-forwarding or TUI emacs but those are shenanigans
Specifically for org, and specifically for org-roam, it's pretty good, but not good enough. It's not as good as desktop emacs, and it's also somehow not as good as a 1st class android app.
the fdroid build of emacs doesn't really work very well with my org-roam, so i use a termux build,,, well nix-on-droid+emacs-overlay... and it's fine, for capture and recall. but i'm not authoring a lot of text with it. a custom extra-keys in the termux config so that your common emacs keybindings are on screen in a tool bar can get you close to a point-and-click interface... but you don't really have a good "swipe" input or voice input to input text efficiently, it's a character interface, a TUI, which is actually not what you want on a phone, you want a word-based interface. so when i want to do org-mode right now, i pull a unihertz titan 2 out of my pocket. without a sim card, the titan battery lasts for about three days unless i fire up an nix devShell & lsp server on it.
calc-mode is my default android calculator tho.
tbh don't listen to me, though: i've been teaching myself 8vim[1] and building a markdown document graph database in my free time. don't listen to ~any emacs user's opinion with any authority, we all have found our own local minima, our opinions and advice usually aren't so useful to each other
I didn't know about modified-bar-mode, though, that's neat.
> don't listen to ~any emacs user's opinion with any authority
As a vim user, I suppose it’s proper to say “I don’t” :p
Also as a vim user, no one should listen to mine with any authority
—
Jokes aside, 8vim looks pretty slick! I don’t have an android to play around with at the moment but if I remember this I’ll check it out when I do.
Text input on phones for anything beyond prose seems to be a space ripe for innovation - although, as an iPhone user, the amount of anything technical I want to do from my phone approaches zero quickly.
If you swipe left on the shortcut bar ("esc" "/" etc) in the termux keyboard, it switches to a word oriented text input area where you can use predictive text and swipe text. Swipe that area right when done to get back to the modifiers
i find that unless i swipe perfectly, the input is considered in the textbox not the bar, so i can't easily swipe out of it. :( have never really got the hang of it. i wish there was a button to swap in/out, i guess i could do some simple android dev but i'd rather not
The intersection between (the set of people who care about good UX) and (the set of people who would try to use emacs on android) is the empty set. Emacs users' self-flagellation is pretty legendary, and I say this as an emacs user (though I've mostly given up on how janky and slow it is compared to modern editors and only use it for magit these days)
I agree with you on UX but disagree with everything else. If you use native elisp compilation, I find its speed to rival an average editor. Completions can be slow in lsp-mode but still faster than VSCode (and emacs itself ships with eglot, a less full featured alternative to lsp-mode, but may be faster. I haven't used it enough to judge.) This is due to shelling out to LSPs and the fact that not all LSPs are particularly well built.
If you find your emacs to feel jank I highly recommend declaring "emacs bankruptcy" and starting anew with a fresh config. Defaults emacs ships with today are really good.
That said I haven't used emacs on Android yet so I don't know how well, if it all, it works. I also think the UX of emacs tends to bend toward the user's own preferences rather than good UX, and the default UX of emacs is a bit bad.
I've been using emacs for 15 years as my daily editor. One thing that never fails is that when I share the fact that I've switched away, emacs users fall over themselves to tell me I'm wrong.
I assure you that my emacs setup is as optimized as it can be. Native compilation, all that jazz. I've compiled my own. But emacs is ultimately a lost cause unless something drastic changes. The single threaded nature of it means that you need to just live with your editor regularly freezing for a whole second while working in bigger projects using modern tooling. The only way to remedy this is to turn off as many features as possible and accept a worse tooling experience. Shifting the blame for emacs poor internal architecture over on the poor LSPs is silly. Every other editor handles this better than emacs.
For now, I'm using zed and it was really an eye-opener to how fast an editor can be and feel. I replicated a large part of my workflow, basically all the keybindings, and while there are things I miss (projectile and some other things), I can live without them in exchange for not having my editor choke constantly when working on big projects while emacs chugs through json from lsp or something like that.
You may have a very justified reason to switch, including nnot liking one aspect of emacs. But you are presenting it as a general flaw. Which people cannot obviously accept as it’s fine for them and they are not experiencing your issue (and as you know, everyone’s setup and workflow are different)
As for the single threaded nature of it, it doesn’t bother me. Because what should be async already is. The only thing left that is synchronous follows closely the repl model of the terminal. I issue a command and I wait for the result. If the result doesn’t matter or I want part of it as soon as possible, then it can be async and there’s plenty of way you can make it so.
The fundamental issue is Emacs its JSON parser is currently still rather slow (not sure why actually). But in LSP mode it needs to parse the LSP server's many JSON response messages very quickly. The aforementioned booster converts all JSON into ELISP byte code so Emacs can process LSP messages much faster.
I guess, the Emacs project will have to tune their JSON parser in the future.
Right, so what you're really saying is that you are totally fine with your editor being unresponsive and janky during regular editing workflow, working with modern tooling, and that everyone else is just wrong for not feeling the same way.
You do you. I lived with the same copium excuse for years, obviously, but I've moved past that now and into the year 20xx.
I love emacs and truly wish that I felt like I could seriously use it, and in many ways, I feel like it's the ultimate expression of what an editor could be. But it's just suffering from being 40 year old software that hasn't seen significant modernization to meet the demands of today's development workflows.
Modern tooling part one: tried using an LSP with emacs (35+ year user) ... gave up after 3 days, it provided absolutely nothing to my workflow.
Modern tooling part two: via M-x grep (bound to F1) use ag(1) or rg(1) instead of grep to explore my codebase, runs async and finishes more or less before my "emacs pinkie" is ready to touch another key.
Look nobody is forcing you to stay on emacs. But most of us aren't experiencing editor freezing even on big projects. I'm working in a monolith of multiple languages and can get LSP for all the ones we use just fine.
To use your own argument, every other person has a better experience than you. Shifting the blame to the editor is silly ;)
You get the same behavior from any editor, though? Hell, you'd probably get similar behavior if you switched brands of power tools. People are attached to their tools.
That said, it would help if you didn't have hyperbole there. Many of us do not, in fact, have to live with the editor freezing on a regular basis.
> Defaults emacs ships with today are really good.
They're really not. It still defaults to opening a split window, still litters #foo# and foo~ files in the directory of whatever you're editing, and still comes with few language modes supported out of the box, let alone set up to automatically spawn and use LSP servers. Running a macro over a 10,000 line file is still incredibly slow on a 1-year old mac. Many common functions are still bound to chains of two or sometimes three keystrokes with multiple combinations of ctrl-keys and sometimes the mysterious ctrl-u prefix. Rebinding all the defaults is pretty much a given for any emacs power user. It's no wonder RMS ended up with RSI problems, because "emacs pinkie" is still very much a thing.
I miss emacs in a lot of ways, I used it for a good two dozen years starting in the 90's, but there's a reason I use IDEA Ultimate to write code now.
You may have two dozens years of emacs, but I fear you’ve not grasped the philosophy of emacs, if that is the list of complaints.
> split windows.
Why would I want a new window to replace the one I’m in. If I want to look at an info manual, I want it to start in a new window instead of the one that I’m looking it. My understanding is that there are main tasks and secondary tasks. Switching main tasks replace the current windows, starting secondary tasks pop up a new one. And those pops up are usually dismissed by typing q.
> still litters #foo# and foo~ files in the directory of whatever you're editing
Backup files and autosaved files are good. Especially if the edited file is not versioned. It’s the correct choice as some users are not programmers.
> few language modes
How many toolchain are installed on a newly installed OS? And major modes are not only for syntax.
> LSP servers
Eglot is built in and has a good set of default for current servers. But why should Emacs install stuff for me. It does not know how I want to install them.
> macro over a 10,000 lines
macros do run the full set of the commands as it would run in a normal invocation time the amount of repetition. And there are other approaches like an awk script that may be faster for your usecase.
> common functions…bound to chains of two…three keystrokes
Emacs have a lot of commands. And if you used something a lot, you can bind it to a more accessible bindings.
> mysterious ctrl-u prefix
If it’s mysterious after two dozen years, then I wonder if you ever give the manual a glance. It is for providing an argument to the command and it’s commonly used for providing an alternate behavior to the default one. Like ‘g’ is recompile in a compilation buffer and ‘ctrl-u g’ asks for the command to use for the new iteration instead of reusing the old one.
Nothing says "prompt interactively" like Ctrl-U. I mean, it literally stands for "universal argument", which is basically "do this command, but different". Defaulting to "insert four times" because why not? Mysterious :^)
Like I said I used emacs for a quarter century, wrote quite a bit of elisp for doing my job, and I still miss some of those things, but I've made do with perl scripts. I still pop up emacs for quick edits now and again, but I long ago gave up trying to force it into the shape of a full-blown IDE.
Your parent wasn't saying they weren't. He just doesn't want them in the same directory. I've set up my config to dump all these in a dedicated directory.
> but there's a reason I use IDEA Ultimate to write code now.
IDEA is so painfully slow that while I have it paid by my company I cannot force myself to work in it for extended periods of time. And I say it being fully aware of Emacs's speed problems. Also, the limitation on "1 Window - 1 Project" is laughable in IDEA, as well as in VSCode.
IDEA can certainly get slow, but `esc 10000 c-x e` still means I'm hitting abort before it gets even close to done. I use multiple panes/windows in IDEA all the time, and it also supports opening tabs in new windows/frames.
I have just opened a 7k loc JS file in idea and I can observe for at least 2 seconds how syntax fontification and all the hints are applied and rendered. All of it on a macbook M4. It is not acceptable and also the slowest of any editor I've used.
It uses that time to parse the source into an AST and build a search index to provide type-aware symbol search, information for autocomplete and refactoring if you request it, etc. Sure it will be slower than simply highlighting the code and then doing nothing with it...
If you use IDEA as a glorified text editor, you're using less than 1% of what it's capable of. It's a complete waste of computing resources then.
I think the contention is that emacs stalls and stutters running a macro on a medium sized file while IDEA sings. I find IDEA to be slower than emacs as a whole but overall more full-featured and much better out of the box. I'm an emacs fan myself, but think IDEA is a great IDE.
> the limitation on "1 Window - 1 Project" is laughable in IDEA
There's no such limitation in IDEA. If your project consists of separate subprojects stored in subdirectories inside a single large directory, just open that directory in IDEA. Your subdirectories will work/look/feel like different projects, all within the same window, with global symbol search, support for attaching SQL resolution scopes (i.e. attaching different databases to different projects and/or paths within them and having correct autocomplete), etc.
One of the things I work on is such a project built from a dozen separate subprojects, some of them written in Java, one in PHP, one in JS/node, one in TS/React, two in Go, one in Python. Plus the usual stuff like Markdown, HTML, CSS, SQL, etc. It all integrates very nicely within the same window.
If they're stored in completely separate directories, and you want to combine them into a single window for some reason, it's still perfectly possible by attaching them as "modules" inside your project settings. It looks and feels exactly like the first case, even when projects are spread across the system.
> If you find your emacs to feel jank I highly recommend declaring "emacs bankruptcy" and starting anew with a fresh config.
My custom config is the reason to use Emacs. If I declare bankruptcy, I might as well switch editors.
eglot has performance issues. I'm not the only one who's noticed them. There's a whole page out there on config settings you can try to improve eglot's performance.
I’m an Emacs enthusiast and also build iOS apps powered by org markup.
The more I used my apps, the more I wanted their UX optimised for mobile. This often means completely rethinking the Emacs experience when bringing to mobile.
This is most obvious in my latest app [1]. Org markup fully fades as implementation details. Of all my apps, this is the one I personally use the most. Proudly, I also started getting non-Emacs users interested in org [2].
Anyway, that’s all to say that as an Emacs fan, I want the full Emacs experience on desktop, but when on iPhone, I want fully optimised mobile UX. No meta anything there ;)
Emacs is ultimately an REPL environment, but ones where you can bind commands to bindings. And there’s a lot of bindings possible in a keyboard.
A mobile experience can be fine if you want a restricted subset of commands. You can then map them to buttons. But the core emacs experience is the ability to create your own commands and have different bindings.
The closest implementation, IMO, would be a streamdeck like UI, but with a transient or hydra like UX.
Are Emacs users really known for "self-flagellation"? I would have thought that was more vi users. Even if modern vis like vim try to make it slightly less painful, the fact is modal editing is really nonintutive. Certainly the reason why I became an Emacs user nearly 40 years ago when I was using UNIX for the first time, was that the only two real options were vi and Emacs and after playing with vi for a bit I was pretty much "nope, not doing that". Emacs may have a reputation as being arcane, but ultimately it is a modeless editor (yes, you can make it emulate vi and its modes if you really want it to) which means it basically works like any other editor or word processor you'd find on mainstream OSes.
Plain Emacs certainly felt more intuitive at first contact, but Vim felt more intuitive to me once I approached it as a language. What can I say, I’m the target audience of evil mode.
whenever i ssh in to some box and fire up vi[m] to edit some text i realize how reliant i am on both input methods & how cool emacs&evil are for letting my do that to myself...
vim text object motions for edits, my emacs keybindings and libs for movement&buffer management... my normal-mod binding for avy-goto-char and my other evil-leader stuff is muscle memory now...
Modal editing is unintuitive for the same reason why new language you're learning unintuitive. Once you understand the rules, it is much more intuitive than any other editor. This is the reason why I use IdeaVim/VSCodeVim instead of learning "native" shortcuts.
That's not fine at all. A developer who doesn't want to (or can't) distribute through the Play Store will now need to teach their users how to enable developer mode and toggle a hidden setting. This raises the barrier a bit more than the current method of installing outside the Play Store.
Maybe this sounds dark but see also how the net is tightening around phones that allow you to run open firmware after you've bought the hardware for the full and fair price. We're slowly being relegated to crappy hobbyist projects once the last major vendors decide on this as well, and I don't even understand what crime it is I'm being locked out for
We're too small a group for commercial vendors to care. Switching away isn't enough, especially when there's no solidarity, not even among hackers. Anyone who uses Apple phones votes with their wallet for locking down the ability to run software of your choice on hardware of your choice. It's as anti-hacker as you can get but it's fairly popular among the HN audience for some reason
If not even we can agree on this internally, what's a bank going to care about the fifty people in the country that can't use a banking app because they're obstinately using dev tools? What are they gonna do, try to live bankless?
Of course, so long as we can switch away: by all means. But it's not a long-term solution
I think pretty soon I'll carry a "normal" phone in my bag for things like communication and banking/ticketing, but I'll carry a device I actually like in my pocket. It'll be the best of both worlds - content I want to see often and easily in my pocket, and the stuff I don't want to be distracted by will be harder to reach on a whim.
Yes, I think I'll have to do the same. I've been in the market for a new phone but the one I had pretty much settled on removed the option to update the boot verification chain so I'm obviously not buying that. Might as well buy apple then
It seems like a finite solution though. Having a second phone is not something most people will do, so the apps that are relegated to run on such devices will become less popular, less maintained, less and less good
Currently, you can run open software alongside e.g. government verification software. I think it's important to keep that option if somehow possible
you're being downvoted, i suggest folks read up on the whiskey rebellion, the economic depression after the revolutionary war, the economic problems and internal strife caused by policies that Washington and the other federalists enacted to "strengthen the republic" in the years between the war and the constitution being ratified.
