The prevalence of this "personal vibecoded app" spirit makes me start to wonder if an "App" is the right level of abstraction for packaging capabilities. Perhaps we need something more "granular".
> Would instead of the RL step a constrained decoding say via something like xgrammar fix syntax generation issue ?
It can, but you have to consider two things here:
a) constrained decoding ensures adherence to syntax, not semantics. Say you're editing a field in an enum in rust. You can write syntactically correct rust code that doesn't address the new field further in the code (say in a switch). You'd get correctly syntactic code, but the compiler will scream at you. RL works on both.
b) if your goal is to further train the model, so it works on many tasks, RL helps with exploring new paths and training the model further. Constrained grammars help with inference, but the model doesn't "learn" anything. With RL you can also have many reward functions at the same time. Say one that rewards good syntax, one that rewards "closing" all the functions so tree-sitter doesn't complain, and one that rewards 0 errors from the compiler. The model gets to train on all 3 at the same time.
The other one is that constrained decoding only works on CFGs (simpler grammars like JSON schemas) since only these ones can produce automatas which can be used for constrained decoding. Programming languages like Python and C++ aren't CFGs so it doesn't work.
Also constrained decoding generally worsens model quality since the model would be generating off-policy. So RL helps push corrected syntax back on-policy.
Not a stranger but strangers
I was returning home from an event early evening. Being absorbed in my thoughts. I got both my front tires free spinning without traction in a ditch.
Although this was in Nigeria, we have this certain camaraderie through hardship, it was still extremely surprising seeing a group of 6 men come out of nowhere, having nothing to do with each other aside being passerbys join hands, exerting sweaty effort to get my car out a ditch by 8pm.
Reminds me of when my wife would drop her loaded-for-touring motorcycle in a parking lot. People would crawl out of the woodwork to run over and help her pick it up.
I’ve dropped mine on rare occasions, and nary a soul even looked my direction. :-) (But thankfully I’m a grown boy who can pick it up myself.)
I high-centered my car on a drift coming out of the Taco Bell drive thru - not a minute passed before ten or so people appeared out of nowhere and pushed me over and out.
Literally, the moment before there hadn’t been anything around but me and that Taco Bell.
We had a blizzard that dumped 3 feet of snow in a weekend, my car got stuck, and about 6 people came out of their warm cozy houses to help push it. On a separate occasion, years later someone driving by stopped their car to help when they saw me stuck on the side of the road.
We grew up very poor, and I can't count the number of times someone helped us through a difficult situation - there are plenty of times we were on our own and there wasn't any help, but also times when someone noticed and helped. The help was always so appreciated- it lessened the suffering considerably compared to the times when we were on our own with whatever problem.
The main issue I'm facing with realtime responses (speech output) is how to separate non-diegetic outputs (e.g thinking, structured outputs) from outputs meant to be heard by the end user.
A simple way is to split the model’s output stream before TTS.
Reasoning/structured tokens go into one bucket, actual user-facing text into another. Only the second bucket is synthesized. Most thinking out loud issues come from feeding the whole stream directly into audio.
There is no TTS here. It's a native audio output model which outputs audio tokens directly. (At least, that's how the other real-time models work. Maybe I've misunderstood the Qwen-Omni architecture.)
True, but even with native audio-token models you still need to split the model’s output channels. Reasoning/internal tokens shouldn't go into the audio stream only user-facing content should be emitted as audio. The principle is the same, whether the last step is TTS or audio token generation.
There's an assumption there that the audio stream contains an equivalent of the <think>/</think> tokens. Every reason to think it should, but without seeing the tokeniser config it's a bit of a guess.
09h is keyboard interrupt, the utter basic interface [1] that only gives you scancodes and that's it, 16h is the extended interface [2] that you need to deal with if you want to read/set shift and other special keys [3].
All art is a combination of objective and subjective aspects.
The objective improvements from css here include: shorter lines are easier to read (per multiple legibility studies), the styling distinguishes navigation and secondary site elements from the main content (without css you get a half screen of navigation links), and the visual importance of in-page anchor links is reduced.
It is way more readable with CSS, I don't know what you're all on about.
The font is bigger, the lines are shorter, the navigation doesn't take half the page. The only thing worse would be the contrast but it's not that bad.
I don't know about most people but to me seeing bits of my desktop on the sides of the window I care about feels like visual noise. I like to have all my apps maximized but maybe is that just me ?
How having bit of your desktop showing on the sides any different than whatever background image or color a particular website decides to show on each side of the text?
I prefer having a quiet single color background and being able to dictate how wide is the text I am reading than being limited by the website owner's choice. But that is also maybe just me.
I was tired of inspiration sites like Dribbble full of polished mockups that aren't practical. Or awwward like sites that don't represent the mundanity of most websites.
So, I spent a while building a tool that captures website design snippets. It's now a collection of 4,363 designs from 544 different domains.
For every design, it extracts:
The exact fonts used on the page (so far 561 unique font families I've found)
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.
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.
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).
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.
> 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.
> 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
> 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.
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.
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."
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.
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.
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.
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.
To be fair to corporate, Emacs has a pretty terrible security model.
There's no reason a program like Emacs couldn't exist which had something like capabilities baked in, but as it is, every package has access to anything it wants.
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.
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.
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.
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.
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.
Right, but not all, which is what makes unplugging your mouse from Windows painful. On Linux, I often forget to plug my mouse in and only notice when I want to play a game or something.
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.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
Emacs changes big O. It is not about changing constant factor. If you need N commands with M features then you can implement and combine them in emacs in O(N+M), to get O(N*M) custom commands.
For example, if you need “Search” feature then you can use it everywhere. It can help find you a file in Dired buffer. It can help you find a git chunk in magit. It can help you find todo item in Org mode, etc. It like having a separate `uniq` command instead of implementing it for each shell command (`sort -u` vs. `sort | uniq`). Another example, having `repeat <N> <cmd>` to repeat `<cmd>` command `<N>` times in zsh vs. implementing `<cmd> —repeat <N>` for each command.
The difference is linear vs. quadratic. If you need to do 1000 actions that can be decomposed into 100 commands with 10 features each then in emacs then you need to know and understand ~100 things vs. 1000 in less customizable environments.
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.
reply