I use a different tool, visidata. It's especially nice when used as a psql pager.
A text editor isn't the right tool for editing tabular data, imo.
As for KaTeX, what I would do is have a preview process running outside of vim that watches for changes in source files and re-renders. That's the Unix way of doing things.
There's many very basic features of vim that VsVim does not have (like... almost all command line commands), basic features which regular vim users use all the time.
You seem to think that people using vim emulation is the norm and using vim itself is the exception and unusual... Which is very much not the case. The opposite is true, with VsVim users being a minority. It's relatively novel among vscode users (most just use a mouse and maybe a small handful of built-in shortcuts), whereas vim itself is quite ubiquitous in the Unix world, with many Linux machines even providing it as the default editor. I know many vim and emacs users (including lots that I work with), and maybe 1 VsVim user (honestly not even sure if they do).
Obviously there's a small handful of things that would require a reboot, but unlike Windows, the vast majority of programs in user space don't require reboots on update.
There's also the fact that restarting Windows to update is a much slower and more disruptive experience than restarting Linux.
Umm, queueing is standard practice particularly when a task is performance intensive and needs limited resources.
Basically any programming language using any kind of asynchronous runtime is using queues in their scheduler, as well.
This is obviously a highly unusual situation, but in general it's actually normal for deserts to experience infrequent episodes of extreme rainfall.
Pushing to master in general is disabled by policy on the forge itself at every place I've worked. That's pretty standard practice. There's no good reason to leave the ability to push to master on.
There's no reason to avoid force pushing a rebased version of your local feature branch to the remote version of your feature branch, since no one else should be touching that branch. I literally do this at least once a day, sometimes more. It's a good practice that empowers you to craft a high-quality set of commits before merging into master. Doing this avoids the countless garbage fix typo commits (and spurious merge commits) that you'd have otherwise, making both reviews easier and giving you a higher-quality, more useful history after merge.
Pretty much everything that can act as a git remote (GitHub, gitlab, etc.) records the activity on a branch and makes it easy to see what the commit sha was before a force push.
But it's a pretty moot point since no one that argues in favor of rebasing is suggesting you use it on shared branches. That's not what it's for. It's for your own feature branches as you work, in which case there is indeed very little risk of any kind of loss.
Uh, it's definitely a bad idea to be concurrently developing on the same branch for a lot of reasons, large org or not. That's widely considered a bad practice and is just a recipe for trouble. My org isn't that huge, and on our team for our repo we have 9 developers working on it including myself. We still do MRs because that's the industry standard best practice and sidesteps a lot of issues.
Like, how do you even do reviews? Patch files?
Ah gotcha.
like to rebase after fetching and before pushing. IMO that's the most sensible way to use it even in teams that generally prefer merge.
What do you mean? Like not pushing at all until you're making the MR? Because if the branch has ever been pushed before and you rebase, you're gonna need to force push the branch to update it.
Personally I'm constantly rebasing (like many times a day) because I maintain a clean commit history as I develop (small changes to things I did previously get commits and are added to the relevant commit as a fixup during interactive rebasing). I also generally keep a draft MR up with my most recent work (pushing at end of day) so that I can have colleagues take a look at any point if I want to validate anything about the direction I'm taking before continuing further (and so CI can produce various artifacts for me).
It's also not obvious to beginners since pull is defaulted to fetch+merge.
Yeah, pull should definitely be --ff-only by default and it's very unfortunate it isn't. Merging on pull is kind of insane behavior that no one actually wants.
That's fair. I definitely think it needs better oversight, if it's to exist at all.
I wasn't trying to fix 5e, merely demonstrate the futility of it.
Vim's command line, i.e, commands starting with
:. The vanishingly few it does support are, again, only the most basic, surface-level commands (and some commands aren't even related to their vim counterparts, like:cwindow, which doesn't open the quick fix list since the extension doesn't support that feature).The last commit to the supported features doc was 5 years ago, so no, it isn't. Seriously, you can't possibly look at that doc and tell me that encompasses even 20% of vim's features. Where's the quick fix list? The location list? The args list? The change list? The jump list? Buffers? Vim-style window management (including vim's tabs)? Tags? Autocommands (no, what it has does not count)? Ftplugins?
ins-completion? The undo tree? Where's:edit,:find,:read [!], and:write !?:cdo,:argdo,:bufdo,:windo?Compared to what vim can do, it is absolutely a joke.