It’s not necessary. Unlike on Windows, Linux users rarely download random packages off the internet. We just use package managers.
It’s not necessary. Unlike on Windows, Linux users rarely download random packages off the internet. We just use package managers.
The software itself may or may not be more secure, but acquiring software is absolutely more secure. There’s so much Windows malware people unwittingly download from the internet. Downloading from a distro’s software repository simply doesn’t have that problem.
I just… Go to sleep. No noise needed.
A synopsis for a great fucking movie.
That’s what the diff
tool is for.
Interactive rebase? There’s no GUI that actually does that well, if at all. And it’s a massive part of my daily workflow.
The CLI is far, far more powerful and has many features that GUIs do not.
It’s also scriptable. For example, I often like to see just the commits I’ve made that diverge from master, along with the files changed in each. This can be accomplished with git log --oneline --stat --name-status origin/master..HEAD
. What’s more, since this is just a CLI command, I can very easily make a keybind in vim to execute the command and stick it’s output into a split window. This lets me use git as a navigation tool as I can then very quickly jump to files that I’ve changed in some recent commit.
This is all using a standard, uniform interface without mucking around with IDE plugin settings (if they even can do such a thing). I have many, many other examples of scripting with it, such as loading side-by-side diffs for all files in the worktree against some particular commit (defaulting to master) in vim in a tabpage-per-file, which I often use to review all of my changes before making a commit.
It can be nice when you successfully do a rebase (after resolving conflicts), but change your mind about the resolution and want to redo it.
Doesn’t come up that much, but it’s been handy once or twice, for me. It’s also just nice security: no matter how I edit commits, I can always go back if I need to.
I’m sure it’s fine for small-scale usage, but overall it’s extremely inflexible and doesn’t really scale well at all. There’s also a lot of very basic functionality that’s straight up missing. For example, there’s no way to have a global epic priority. You can rearrange epics in an epic board, but the ordering of the epics there is not persisted elsewhere. There were many, many other shortcomings we kept running into.
Oh, and after a lot of our tickets had been imported (which itself was a huge undertaking since the auto import tools are complete trash), it started to be very slow. It feels like a very unfinished, unpolished product.
We use Gitlab’s CI/CD features extensively at my current job and it’s very, very nice. That’s what they are actually good at, not project management.
I also wonder if people complaining about Jira are still on Jira Server. Jira Cloud is a much nicer experience. Certainly not perfect, but I’ve yet to see an actual viable alternative (once worked someplace that tried to move all project management to Gitlab… 🤮).
If you do want to go the web route, I’d highly recommend avoiding SPAs and going with https://htmx.org/ instead. Much simpler, less code, entirely driven by your backend, while still giving you the ability to make nice interactive applications.
As a bonus, since you presumably have been working with Python anyway, the author of htmx has a whole book online walking you through building an app using htmx and Flask, a web framework for Python: https://hypermedia.systems/book/contents/
Uh, there are an absolute fuckload of Java libs out there with nothing more than auto-generated garbage Javadocs.
I dunno, plenty of those sound pretty reasonable.
It’s been massively effective and has put them on the defensive in a way no other criticism ever has.
Probably a good thing you got banned for advocating for child abuse.
! is supported
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).
Your experience is out of date.
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.
I’m a senior software engineer with a pretty uncommon skill set. Recruiters are the primary way that companies hire in my industry outside of networking contacts and I get contacted frequently. The job before my current one was through a recruiter.
I very much dislike Microsoft and LinkedIn in general, but not using it all is a huge handicap that isn’t worth taking on.
It’s how recruiters find me, so unfortunately I can’t. I almost never open it, though.
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).
Spoken like someone who knows absolutely nothing about vim/unix.