> The permission model implements a "seat belt" approach, which prevents trusted code from unintentionally changing files or using resources that access has not explicitly been granted to. It does not provide security guarantees in the presence of malicious code. Malicious code can bypass the permission model and execute arbitrary code without the restrictions imposed by the permission model.
Deno's permissions model is actually a very nice feature. But it is not very granular so I think you end up just allowing everything a lot of the time. I also think sandboxing is a responsibility of the OS. And lastly, a lot of use cases do not really benefit from it (e.g. server applications).
I can't find any info about the people behind it. The branding, mentioning "The Hague" and the rest of the landing page seems to try really hard to fool me into believing this is official from the European Union, I wouldn't trust them with anything, just get Libreoffice.
> This could be true, but why ignore the fact that you create a full blown native Mac app, with a single sentence?
I would guess it's for the same reasons that you're ignoring all the fixes necessary to get to an actual "full blown native Mac app". It's rarely a single sentence unless your app does something trivial like printing Hello World.
> Yeah you're kind of a nerd, using it to read nerd things.
I may be, but my girlfriend isn't and she's using it to follow the government and job postings. But you're moving the goalposts, RSS is getting new attention and it doesn't matter who that attention is from. It's happening, you don't have to use it we don't care but let us have our feeds.
Also if you've ever worked in the podcast space you'd know they all release with RSS, so many people are using it without knowing. Maybe even you?
That comparison table is strange and sometimes wrong. Neovim for example detects and updates external file changes by default. And the coherence of the keybindings in Ki is "Great" bit vim/helix:
> As you can see, there's no single logical categorization for these keymaps, they are either lowercase-uppercase, normal-alt, left-right bracket, or outright unexplainable.
Word, End, Back, Change Word and even Change Inner (, etc are very logical to me and I feel like I'm talking to the editor when editing. I get that it doesn't make sense when one has learned another way to do it, but it does make total sense you just have to make an effort to try and understand it.
It's like learning and always driving automatic then calling manual "outright unexplainable". You simply learned another way and are conditioned into believing that's the one true way. It shows the creator comes from VSCode (multi-cursor is a useless feature, just use s/search/replace and get used to macros and a whole new world will open).
Re. incoherence of vim's keybindings, I partially agree.
Most of the times, shift means "bigger", and only in a few places it means "invert".
Examples of "bigger" are all the motions involving words vs. WORDS, where WORDS are a broader interpretation of words; "V" is like "v" but by lines, thus in larger chunks; "C", "D", "Y" do the same as their unshifted counterparts, but extended to the end of line; etc.
Examples of shift meaning "invert" are fewer, and all sound irrational to me:
With x/X and o/O, the shift inverts the direction left/right or above/below, but we don't have for example i/I to insert to the left/right of the cursor, and H is not the opposite of h, J is not the opposite of j, etc.
With n/N, shift inverts next and previous. Why not n/p? I know, I know: p was already taken for paste, but still...
Finally, t/T/f/F are completely mixed up. In my mental model, t/f sound like to/from and I'd rather use them to move forward/backward till (not including) a char, while T/F would be the "bigger" variants which include the destination char.
I think you've touched on it, but I'm going try to take it one step further into explicitness.
Just over a year ago I decided to switch to Neovim. The reason for switching was personal; I was struggling with what I'll call "clutter" in other tools and I wanted a tool that would reinforce, at least lightly, a mode of working that promoted focus on what I was working on, while making it easy to reference other files without loading up my editor with tabs and other visual clutter (buttons/menus) I don't care about most of the time.
I took the advice I seemed to bump into repeatedly: try out vim mode in my current editor before making the plunge.
I really struggled at first. It felt wildly foreign. All the shortcuts were nowhere near to the world I was familiar with.
As I was about to give up, I ran into some advice that was along the lines of "stop trying to memorize shortcuts and start thinking in terms of what you want to achieve" (words and motions in vim-speak).
Your example of [C]hange [I]nner is a great one; that one in particular was life changing. Sure there are some words and motions that do require memorization, but so many others just flow naturally. And once you start thinking in actions, it's easy to see how they can layer on top of each other in really elegant ways.
I'm not even here trying to tout vim-like editors, I'd wager there are many editors that have some semblance of this kind of interaction, but rather to reiterate there's a shift from a PoV of function vs. goal.
Again, I don't think this is "the right way" but rather one of many perspectives that works in context with the phenomenology of me.
I had an experience like this when I switched to a Keyboardio split keyboard. It was impossible to use at first. Then I do some deliberate practice with a typing tutor app and now I love it so much I own multiple.
Is there a good tutorial for some of these advanced text editing features?
In particular I’d like to get platform independent shortcuts / key bindings. I use both windows and MacOS daily, and it throws off my muscle memory for shortcuts like “go to beginning of line”
I still think their point about search and replace still stand though. I make most my edits with regex in neovim nowadays and I feel this is the superior paradigm: You don't even need to get to some specific location in order to edit it. I also almost only use search to move around the file and I can even reuse the searches for substitutions. It makes most vim motions and commands almost useless for me nowadays.
I also feel like macros are a more clunky and error prone way to do what substitutions can do. Almost never use them.
> I was a Neovim macro user until I figured out how insane that was compared to multi-cursor after using Helix.
Multi-cursor was the first plugin I installed when I moved from VSCode to Vim because I was used to hitting Ctrl+d to select all words and then replacing. Does Helix do something different?
1) First I reach for <C-v> for visual block selection if everything is neatly aligned.
2) Next choice is %s/search/replace(/c if I need confirm).
3) Macros, and I love it everytime I get to use them. I just record the movements, copy what I need to copy, paste it where I need to paste it, and it's repeatable for every line or block where the *formatting* matches. And this is the important part, the words don't matter. I still feel like a wizard using them.
As far as I understand multi-cursor option 3 is a no-go without macros if the words don't match. But macros don't care as long as the movements translate to the same edits. How does Helix multi-cursor work that make macros insane?
Sorry for derailing a bit, the search and replace using a query make sense for purly textual (non-syntactic) editing, but if you want to apply consistent syntactic modifications across multiple locations in the same file, you will need both multi-cursor and syntax node selection/navigation/modification.
It's hard to explain unless you actually try Ki, because it is a paradigm shift
Or you could use grn for LSP rename[1] in Neovim and it will rename all references across the project. VSCode and other IDEs have a similar feature, but compared to multi-cursor that's cheating.
I'll give you that using the AST to select the references is an interesting addition to multi-cursor, but I still don't see how they would be useful compared to my current workflow.
That comparison table is misleading because it mixes implementation details with user-facing behavior, and for example Neovim uses inotify or platform-specific filesystem watchers to surface external changes so marking that row as 'no' is incorrect without platform and config qualifiers.
Keybinding coherence is an engineering tradeoff, and if Ki wants consistent behavior it should expose orthogonal primitives like operators and motions plus AST-aware textobjects using Tree-sitter style node names, then provide discoverability tools such as a which-key overlay and explicit node prefixes so power users get composability while newcomers have a fighting chance.
> You can move to the next line in the buffer editor with `k` but to move down to the next line in the file explorer you have to do `ctrl+n`?
I've never used Helix, but this exists in vim too, but it the autocompletion, because in that context hitting k would type k. Makes sense right? I'm guessing hitting k in Helix file explorer has a similar use, maybe searching?
Yes, a slight misunderstanding, I only meant that the fact that K types in insert mode doesn't mean you move to Ctrl+N to replicate its functionality, you should still maintain the same position (K)
Sure, but [n]ext and [p]revious are common in the TUI world and which one makes more sense is debatable. There's decades of history behind the choice and while I prefer j/k I wouldn't call n/p wrong.
Yes, it's an very common mistake, there is also decades of history behind fixing it. But the debate here is not j/k vs [n]ew file/[p]rint file, but about the inconsistency of using one logic in navigating lines of text in an editor vs another in navigating lines of text in a file list
I'm pretty sure next and previous are older than new file and print file both of which have little use in this context. You could also see it as navigating lines of text vs navigating results in a list (ie search in less/vim) if you want to be pedantic. In (Neo)Vim <C-j> in insert mode inserts a new line below the current and <C-k> inserts digraphs. N/P are not necessarily inconsistent.
Indeed, creating a file is of little use in a file viewer, and is [p]age up old enough?
> if you want to be pedantic
I don't, the question is how you justify that in the search for consistency? I don't get the C-j, the issue with consistency is J/K, why do digraphs matter, are they more important than basic navigation?
> creating a file is of little use in a file viewer
I'm not sure the first programs could handle more than one, and (neo)vi(m) just uses :e, for edit. New or existing is irrelevant, it's not Microsoft Word.
> is [p]age up old enough
Is this a real thing? I only know of [f]orward/[b]ack and [d]own/[u]p.
> are they more important than basic navigation
Don't put words in my mouth, but sure in insert mode you're not supposed to navigate, but this discussion is getting off-topic.
reply