In helix that's %d (select-buffer, then delete). The selection-then-action design for helix is showing it's difference to vi, which is action-on-movement.
not really, vim's visual mode always extends selection, while in Helix the base mode selects with your base commands so you can act on the selection, but it doesn't extend to the next one. For example, moving by 2 words only selects the 2nd one, not both like in Visual mode.
(although in this specific case of selecting everything this difference isn't visible)
The details are different, but they're both select-then-act. Admittedly, I've never used Helix, but I don't see how what you've described is a game changer. Surely, at least sometimes, what you want to do is exactly what visual-mode provides: explicitly select a region, using the combined movement of any available operator, and then act on that region.
Surely you understand the difference between sometimes and all the other times? This is a game changer for all those other times. Otherwise helix has a similar extending selection mode like visual
> This is a game changer for all those other times.
Is it though? I honestly don't understand what the big deal is. The original contention was that the benefit was in offering selection-then-action, unlike Vi. And then when it's pointed out that Vim actually offers selection-then-action as well, there is a new assertion that it's the particular WAY that Helix offers selection-then-action that is key.
To my mind, selection-then-action is provided by Vim if you want it. Maybe it's a few extra keystrokes sometimes, because it's not the default mode, as it is in Helix, but the main concept (ability to think in object-then-verb) is available in both, if that's the way you prefer to think.
> I honestly don't understand what the big deal is.
Honestly, you't not even trying to
> To my mind, selection-then-action is provided by Vim if you want it.
Ok, let your mind be content with ignoring the difference that I've just explained. By the way, you can also trivialize vim as "it's just a fewer keystrokes sometimes to do the same as in notepad, what's the big deal?"
Why do you think that? I've been listening to what you say. But again, you haven't exactly proven that operating on the single-most-recent movement (which as I understand it, also defines the selection) is the thing that you want to operate on the most often, rather than the convenience of being able to use the flexibility of multiple movements to define a selection.
Anyway, many people do claim that an editor isn't the most important thing, and that thinking takes a lot more time than the operation itself, and that therefore Notepad would often be sufficient. What those people don't really appreciate is the ability to operate on multiple lines at once, not a single selection, but across vast swathes of the text being edited. When your thinking is done, and needs to be applied to every single line of the file, you'd much rather have Vim than Notepad. But in such a case Helix wouldn't offer much, if any, advantage over Vim.
You seem emotionally attached to this in a way that my skepticism provokes, so we can drop the debate. People should use whatever they prefer; no harm done.
This actual answer according the the author realized after he already liked the name.
He created it intending to be +1 of APL. Accidentally came up with BQN instead of BQM. Sat with that for 1hr, really liked the name, then realized that it should be BQM which he hated, so he stuck with BQN.
That said, it's and incredibly designed language. I honestly have never read any language (especially not designed by a single person) with the level of creative thought as he put into BQN. Some really incredible insights and deep understanding. It's amazing reading his posts / documentation about it. The focus on ergonomics, brand new constructs and the consistency/coherence of how all of his decisions fit together is really impressive.
I'm somewhat sure the author actually mentioned that that was the intention, "Big Question Notation" and basically "apl" + 1. But he realized that it didn't match up
It's just. So gross. Say it. Sudden interruption of slime coming up your throat. Like walking out the door into a spiderweb. Alphabetically I was mistaken but in every way that matters I was right.
Ordinarily I'd make fun of the Germans for giving such an ugly name to a nice concept, but I've always found "comfortable" to be rather unpleasant too (the root "comfort" is fine).
> I didn't understand how this connects to the first paragraph at first, but I think you're saying this playthrough is an analog to someone making such documentation, thus saving DF from such a fate?
(Not OP) Possibly, but one of the repeated themes in Boatmurdered is a number of fortress defenses (some with considerable collateral damage) attached to a variety of scattered and unmarked levers.
Does pulling this lever lower the drawbridge, irrigate the fields, or douse the world in cleansing magma? Only one way to tell!
> For character-based movement, simply press 'z' to enter the column mode.
I did eventually find this in the documentation, under the "regexp selections" section. I think it should be more prominently displayed in other sections, since it's a natural thing to want (at first).
I am enjoying the editor (as a current helix user), and looking forward to trying it more.
In this respect, probably nothing, and they probably all mean Q.
Q is a different language to K, implemented in K. There are more versions of K than Q- kdb+ is the only Q implementation, but there are others like shakti, ngn/k, and kona that implement K.
