Friend... don't try to "switch". Just use multiple tools at the same time. I personally use all: Neovim (great writing/editing experimence, LSP+Treesitter+fzf allow you to get really far), Emacs (for Magit), VS Code (if Neovim or Emacs breaks I can still edit the code ;)) and WebStorm to run tests using nice and rich UI.
Don't try to limit yourself artficially.
I have almost exactly the same habits when using editors mentioned above. I'm not sure if I've been using Vim (neovim now) or Emacs (+evil) for longer, but both have great reasons to be installed at the same time.
No, I use Emacs keybindings in the rest of the tools. Tried to use vim bindings but they don't seem to do everything correctly or smoothly and it annoys me.
Actually... I use my own keybindings which are more ergonomic twist of Emacs bindings. For example for moving char left I use C-d and to move word left I use C-S-d (control+shift+d). Convenient to press using both hands (using right shift with pinky). Of course Control is swapped with Caps lock.
If your goal was to release some library with a website - you made it, congrats. Looks really nice to my eyes.
However, as a developer, I want to see something else:
1. Example projects created with this library. Challenges, solutions, pains, wins.
2. Video demonstrating how you created simple app with your lib. Reading docs is a too high bar in very crowded JS ecosystem. For example I want to see:
- how tooling works,
- how debugging works,
- how build process works.
- anything else this tool is strong with.
If your goal was to create this library - then, again - you made it. But what next? Best libraries or frameworks are created during work on some real project and they are extracted from the target creation.
Until recently I owned both MacBook Pro 16 M1 Max and iPad Pro 12.9 with magic keyboard. I love MacBook Pro 16 for work either on desk with connected big display or on laptop stand. Occasionally I use it as a notebook flat on the desk, but don't really like it long term, it forces you to look down which is not comfortable. But I HATE MBP16 to use as a LAPtop, it's too big, I can stand it maybe for 30min, max 1h.
So here comes iPad Pro 12.9 - lightweight (maybe not that light including Magic Keyboard), but it's great to use in laptop way, on chair, in bed etc. Great to browse web, scroll through videos and write notes or emails. I liked this form factor so much that I started to figure out how to make it a coding machine. That's problematic of course, so I ended up buying paid terminal App in App Store to connect over ssh/mosh to some server/other machine and use terminal with tmux/nvim etc. Installed nerdfonds, started using TUIs and it was working pretty well. But, I hate terminals for long term real work. I want to use heavy UI debuggers, click around/browse, move etc, my work is not only inserting text. I considered buying Asus Zenbook s13 OLED and install Linux on it to have two devices to use depending on my mood and physical position I wanna have. But, first, Zenbook is on Intel/Ryzen which means heat and fan noise, two, there are high risks my linux setup will require tweaks and care which I'm not interested in.
In summary: I bought base MacBook Air 13 M2 and use it as couch/cafe machine as alternative to MPB 16. So I have 3 Apple devices. Which is... fine?
One more thing about iPad: I think it has the best on the market form factor, see pictures how magic keyboard elevates the iPad device which makes it's floating in the air a bit. I want to have the same for other laptops, because when you type on normal laptop in LAPTOP position, your fingers stand in your eyesight covering bottom part of the screen which is atrocious. AND: computer is in the screen which makes keyboard always cool. The same as in Surface Pro.
The obvious solution is to use nor ORMs or raw SQL generated with various helpers in your language, but to open up DB engine to execute low level bytecode. Think: DB=GPU, SQL=GLSL, what's actually executed -> compiled code.
I disagree it's responsibility of the tool. Program should just reach out for files and some higher order or meta runner should trace what the process does. One of the commenters mentioned `strace`, this is the correct approach, but should be done in well engineered way.
Other way is to run program in symbomlic interpreter and trace what it wants to read in any of the branches.
Why do you suggest this path over documentating the behavior explicitly?
What makes one approach better the other? Is it faster to run a trace? Should a developer trace their own code and auto-generate documentation post-build?
I tried to understand what vim/nvim is all about and why people love it so I've learned it a little bit. I grasped the Zen of VIM, it's actually very comfortable to navigate files and files tree assuming Ctrl is swapped with Caps Lock and you don't use ESC but Ctrl+] or jk/jj. BUT. But. but... VIM was shining when it was designed and created, it doesn't shine that much today, because for working with code you need things like LSP, syntax awareness etc. Thing like VS Code with Emacs cross platform keybindins AND WITH smartSelect is amazing for me.
Go to VSCode, put it into your `keybindings.json`:
go to TS file and press keybinding multiple times to see how it grows/shrinks.
Having Emacs keybindings like C-w, C-y, C-d (I'm using it to move char left), C-S-d (word left, S is shift, I'm using right one) and more I feel like flying through things like selecting block, expression, function, moving in and out etc. I guess Emacs people using paredit feel something similar taken to the next level.
Ideas in VIM are still brilliant, the same goes for Emacs, but they both need to reincarnate in modern skin taking pixel perfect GUIs with proper animations to the extreme. In fully multithreaded and multiprocess environment.
> VIM was shining when it was designed and created, it doesn't shine that much today, because for working with code you need things like LSP, syntax awareness etc.
This is not true at all. Nvim has built-in LSP support now, there's a huge amount of plugins you can use that integrate with LSP and they work great. I even use ChatGPT inside my vim (check out this plugin: https://github.com/dpayne/CodeGPT.nvim). The smart select functionality you mention is trivial to implement and I bet there is a plugin for this (btw, try `dit` to "delete in tag", or `di(` to delete in bracket, etc...).
I will admit that you have to spend a lot of time to configure it to your liking, not everybody wants to and I understand that.
Honestly I feel like (n)vim is going through a renaissance period lately, check out streamers like ThePrimeagen or TjDevries for some great content on how to get started.
You're defending n(vim)+plugins, not naked (n)vim and I agree it can be taken very far and can start to look like Emacs which integrates multiple external processes in single place. Actually anything can be taken anywhere with sufficient time and effort. That's the secret of transmutation. But you won't overcome the fact it uses terminal by default which I find subpar compared to pixel perfect GUIs. Terminal UIs are useful for sure, but I see them as a hidden cry of despair when people are trying to avoid touching modern GUI systems. The strength of vim (vim motions) should be stripped away and be embeddable in any other system as a leaf, not the other way around where (n)vim is in the center and other pieces are plugged into it. I know it's happening and you can use native nvim inside e.g. VSCode which is great.
I know there are tools like GVim etc, but again, they are created with high engineering effort which for some people is simply pleasant to undertake.
Again, I'm not trying to defend or favor any system, I'm actually using at the same time VSCode (for best TS intellisense), WebStorm (for refactors), nvim (for quick browsing and small config file edits) and Emacs (for Magit). My computer is my tool, not single thing inside it.
Sometimes the world can be improved. Most times it's just fine and any suggested external change should probably start from within. There are those who like letters, words, and the sound of keyboard keys. Then there are others who like pretty pictures in big buttons and the click of the mouse.
All this to suggest that perhaps you are the wrong target for text-base interfaces.
But but but... your posts are about you! They're just presented as though it's a problem with the tools. I'm simply holding up a mirror, using a similar language, and suggesting that perhaps you are not the target of the tools you only dabbled with and presumed to then criticize.
Thanks for becoming a mirror (although what happened was you wrote a "mirror" comment of my comment, not me), however I'm really interested in better tools. None of the tools I know fully satisfy me. GUIs are less comfortable and slower than TUIs, of course depending on task you want to accomplish. If comes to thing like Emacs w/ Magit + evil mode which is ~(n)vim and task which is text editing or even maybe code editing - can't really find anything better more versatile and fast.
I'm interested in merging all known ideas (including Smalltalk IDEs) and moving forward.
Perhaps I have higher expectations which I didn't explain anywhere. Hard to tell full story in short text comment.
I think this is important: finish your project in bigger context where your project is a piece needed in higher level picture. Don't finish project just to finish it. This attitude solves problem of motivation, because you naturally finish the project without forcing yourself. Masons don't lay bricks to have bricks laid down, they want to build a house.
Of course it much more complex than that, some people are just not types of makers and "finishing projects" is not their cup of tea.
1) define somewhere in the repo that it's a "compound repo", a "workspace" etc - name is arbitrary, This is our repo "R",
2) for certain paths in the repo, mark those paths as an aliases to other repos identified by a repository URL/path. These our "r" repos.
3) for every git command executed inside repo "R", run appropriate commands in the background for each "r" repo only if repo "r" was affected by changes initiated in repo "R".
4) If you made changes to repo "r" directly and then returned to "R", after "git pull" you should see nothing else than standard git diffs, conflicts etc. You should not run anything like "sync"/"refresh" etc. Only git pull/rebase/merge etc.
5) Commit in repo "R" which is only responsible for bumping repos "r" should be handled by git submodule system transparently for the user of "R". I'm not a git expert to tell what kind of commit should be used here. Any ideas? You should commit seeing diffs of course, not some commits hashes.
5) THAT'S IT.
Everything should work recursively, e.i. you should be able to do 10 layers of "r" repos. Each n-th "r" repo acts as "R" repo for n+1 level repo. Ten fold commit should work like transaction, e.g. if any of layers between 1 and 10 has failing precommit hook - the whole operation should fail.
We could have amazing HTML/CSS performance if we had programmable "HTML to bitmap" caching. But: a) it's not secure if we can render HTML to bitmap and send over network, b) cache invalidation problem - we'd have to invent mechanisms to lock HTML against further changes or track changes and rerun "HTML to bitmap" procedure.
All this is not suitable for web, but for thing like Elector - hell yeah. HTML to bitmap extension would be really welcome. Then you could render UI in WebGL or WebGPU. Adobe Flash had something similar if I recall correctly.
