Most active commenters
  • iLemming(8)
  • skydhash(6)
  • t_mahmood(4)
  • frumplestlatz(4)
  • kace91(3)

←back to thread

301 points nogajun | 35 comments | | HN request time: 0.356s | source | bottom
1. pronik ◴[] No.45944469[source]
Whoever thinks that VSCode does not have any learning curve or is somehow magically easy, needs to take a reality check, that thing is overwhelming with all its popups, hovers, sidebars etc. beyond all reason when you first run it (and later too). I'm an Emacs user and I don't in any way support the notion it's somehow easy or intuitively workable, it's most definitely not and never has been. I just think that VSCode is not it either, it's just the more popular tool right now.
replies(10): >>45944574 #>>45944635 #>>45944918 #>>45944919 #>>45945423 #>>45945490 #>>45945817 #>>45946773 #>>45955443 #>>46095471 #
2. kace91 ◴[] No.45944574[source]
Every piece of software that’s effectively a professional workbench (IDEs, DAWs, video editing, etc) is going to have some complexity.

I can’t imagine the argument that vscode’s level of complexity is even in the same order of magnitude as vim or eMacs though. A 2 minute tutorial or half an hour or fiddling will get you sorted with vscode, I needed a full ebook for neovim.

replies(1): >>45944682 #
3. skydhash ◴[] No.45944635[source]
VSCode is familiar in its UX. Here is the file tree, here is the editor. oh that's the terminal, or I can complete with tab, and these are extensions that I can install? And that's pretty much the extent of the interaction most people have with it. If it does not come out of the box or prepackaged into an easily extensible extension, they are not using it.
replies(1): >>45949506 #
4. skydhash ◴[] No.45944682[source]
VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.
replies(2): >>45944797 #>>45947002 #
5. kace91 ◴[] No.45944797{3}[source]
What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result.

My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults.

For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).

replies(2): >>45945205 #>>45945650 #
6. ◴[] No.45944918[source]
7. totetsu ◴[] No.45944919[source]
I get so frustrated watching people fuss around in VSCode because they're stuck in it and they've never had the opportunity to see all the intuitive and more workable tools that a.. just part of the basic OS they are using. .. like keeping their console a tab taking up 1/4 the screen and trying to read a stack-trace ..
8. t_mahmood ◴[] No.45945205{4}[source]
Yeah, now see, you need to do that for every programming language, or tool for vscode.

With Lazyvim you get all at once. And you can ignore many plugins if you want,

Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode. And thanks to Lazyvim, you can set it up faster

but Nvim or vim even without plugins can do many things that vscode can not do. So without plugins vscode is just an editor, while Nvim/vim are powerful utilities

replies(2): >>45945735 #>>45945789 #
9. frumplestlatz ◴[] No.45945423[source]
I’ve been using emacs for very many years, and have a configuration that has evolved over a decade.

I was able to pick up VSCode in an hour. It’s not complicated. I’m using it with the Haskell extension and it’s great.

Honestly, I’m tired of Emacs’ performance, bugs, complexity, and poor UI that requires an enormous amount of hacking to make a usable IDE.

VSCode is a breath of fresh air. The only things I’m not using it for are languages that don’t have extensions yet — Cryptol and SAW.

replies(1): >>45948536 #
10. cholantesh ◴[] No.45945490[source]
>that thing is overwhelming with all its popups, hovers, sidebars etc.

I think it's fairly normal if you're coming from heavy IDE use, eg: Eclipse. If you've spent most of your time editing using tmux/[vi|nano|emacs]], maybe that's not the case, but I can't really speak to that as I've never really worked that way.

11. skydhash ◴[] No.45945650{4}[source]
With emacs, you can just use “customize” (for options) and “M-x” (for commands) and never care about anything else. Yes, it’s not as visible as vscode, but it’s very much the same thing.

But once you learn elisp, then you have the power of a full VM at your disposal and not wait for a plugins to exist and hopefully implement your workflow. And adhoc integration (like having ticket number in comments be clickable) is not easily feasible.

replies(1): >>45952344 #
12. skydhash ◴[] No.45945735{5}[source]
There’s a reason almost every good editor (on unix) have the pipe to/from shell feature. With that you have the whole power of the os at your disposal. And in vim, you get the quickfix list for fast navigation according to the output of a grep/build tool.

Someone could make a config to make vim/emacs beginner friendly. But there’s a reason there’s no beginner friendly truck or plane.

13. kace91 ◴[] No.45945789{5}[source]
>Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode.

I’m not arguing against that, I actually moved to neovim and I enjoy it - plus I can now stop worrying that my daily driver will be rug pulled.

I just don’t agree with the idea that neither nvim or eMacs have similar levels of ability to onboard new users. Not when grokking something as simple as closing a tab will get you through a history lesson on the alternate namings of tabs, buffers and windows for example.

replies(1): >>45946030 #
14. pxc ◴[] No.45945817[source]
I'm also a daily Emacs user. I'm no wizard; I've leaned on starter kits like Spacemacs and Doom my whole Emacs life.

Likewise, I find VSCode overstimulating and, for lack of a better word, rude.

I just tried setting up RustRover for a side project at work on Friday. It's my first time using an IDE since I was a Scala developer near the beginning of my professional career. I only had an hour or two to play, but I ended up unable to get a working run configuration, or at least one that showed me anything at all except sometimes when it failed. It was a lot of clicking around.

I'll sort it out next week, I'm sure. But pointy-clicky turned out not to be as ez-pz as I'd hoped it would be.

replies(1): >>45947246 #
15. skydhash ◴[] No.45946030{6}[source]
No one is arguing that. Just that VSCode is also complex too. But it’s just that out of the box, there’s nothing special. Then you add a few tools through plugins and that’s the extent of of workflow customization most people stay at. If you want more, you have to start a whole new project, and the complexity of that is high while the return is not as good as you can have with emacs/vim.

With emacs/vim, getting started is fairly easy (there’s a tutorial). The learning phase is linear, but it’s just practice and using the software. Creating your own tool is very easy as you can jumpstart from where other’s plugins are and add your own stuff. In VSCode, it’s starting from scatch everytime.

16. jrm4 ◴[] No.45946773[source]
Here's the thing (as someone who did Emacs for a year and then gave it up)

The possibility and ease of interoperability with other general program styles is far more important that the idea is given.

Look, there are too many other good tools out there that do things like have a standard file picker, use CUA bindings etc. This is primarily why I left Emacs for non programmy things (and am happier with a hacked zim-wiki, though I imagine obsidian et al might work too)

17. slaymaker1907 ◴[] No.45947002{3}[source]
You absolutely don't need extensions for JS development. It is absolutely NOT notepad level. In my experience with beginners, installing an extension is also incredibly easy compared to getting them to edit some vim/emacs config.
replies(1): >>45947715 #
18. t_mahmood ◴[] No.45947246[source]
IntelliJ shines when you use the command pallet, keyboard shortcuts, and IdeaVIM

Double shift, to bring up the pallet, and start typing. Though it also have a ton of shortcuts, and shortcuts can be assigned for almost every command.

Try this: https://plugins.jetbrains.com/plugin/9792-key-promoter-x/

Whenever you don't use keyboard shortcut for any action, this suggests you the available keyboard shortcut.

replies(1): >>45948300 #
19. iLemming ◴[] No.45947715{4}[source]
> incredibly easy compared to getting them to edit some vim/emacs config

Yet, extending just about any functionality of Emacs for an experienced user is far simpler than in anything else - you can write some expressions in a scratch buffer and change the behavior of any command - built-in or third-party. Not only wouldn't you even have to restart anything - you wouldn't even need to save that code on the file system.

There's a strong correlation between perceived difficulty at the beginning and notable simplicity at later stages. Things that are seemingly harder to grok often open up avenues for clarity later. Conversely, things that seem easy to get into, later often become full of bottlenecks and complexity.

Imagine attempting to replace all the knobs, controls, buttons and switches in an Airbus A380 cockpit with a single touch-based display à la Tesla and claim it's now easier to train new pilots, but you've just made them dependent on a system they don't deeply understand, you've traded 6 months of training for a lifetime of brittle expertise.

I am forever indebted to my younger self for investing some time in understanding the grand ideas behind Vim and Emacs, and never, even once, have I regretted my choices. Rather the opposite - I regret wasting a big chunk of my life chasing popular trends aimed at "intuitive use", "easy start" and "it just works™". I would have never developed the true "hacker's mindset" without them.

Undeniably, there's an immense pedagogical value in tools that make it easy for beginners, but there's also a mental trap there. It's ingrained into human nature - the brain simply doesn't like the grit; it naturally gravitates toward comfort and minimal effort - it just wants to remain lazy. Yet there's a compounding effect of initial investment that pays off later. Sadly, we keep trying to find ways to dumb things down.

20. iLemming ◴[] No.45948300{3}[source]
IntelliJ is an amazing feat of software engineering, there's no denying that. I'm not saying that to make you (or any other WebStorm/Pycharm/etc. user) feel better - I know that from years of dedicated use.

I just want to share my anecdotal, personal story. I used IntelliJ professionally for almost a decade. I learned some advanced and undocumented features. I've collaborated with Jetbrains team members to help improving the features. It felt like I work for them. I still occasionally receive YouTrack notification emails for the bugs I posted circa 2009, that are still not fixed today, btw.

IntelliJ is to blame for why my transition to Emacs took me two years - I carried the fear of investing too much into a new thing. I feared of liking it, and someday not finding some features I was so attached to in IntelliJ. I was scared that I will be intellectually and emotionally "locked in", while I was already vendor locked-in and condemned to be using IntelliJ forever.

I was so wrong - not only have I found everything I needed, and more, I have developed a true hacker's mindset. Honestly, the only regret I still carry today, even after years of Emacs use, is that I did not attempt to learn it sooner. I no longer experience FOMO - I can easily pick up IntelliJ whenever I want again, I just haven't found a real, pragmatic reason to do so. In fact, I do fire it up on occasion, just to get the feel of how things evolving there, to steal some good ideas, etc.

> and IdeaVIM

Gary Bernhardt famously said - "There's no such thing as vim-mode". And to the degree, he was right - pretty much every editor/IDE that tries to integrate Vim features invariable ends up having glaring deficiencies. IdeaVIM is good enough, but only to the point - for an expert vimmer it may feel annoying. VSCode vim experience is similar, and Sublime as well - there's really no good comparison between them to say which one is really "better", they all have a spectrum of weird, quirky behaviors. There's one notable exception - Evil-mode in Emacs is fantastically good - sometimes you even forget that it's not a built-in feature, but a third-party extension, an afterthought.

> shortcuts can be assigned for almost every command

In Emacs, you can bind keys to anything, conversely - everything is a command - every keypress, every mouse click and mouse-scroll. And since Emacs is inherently a modal editor, you can do stuff like binding commands to a double, triple, etc. keypresses. Like for example, when I'm typing fast, to autofix most recent typo I'd just tap comma twice - this is just one example of unbelievably fast way to stay focused.

Most devs, once they find their favorite tool would settle with it and don't even explore other options. "I don't have time for that.", "I don't want to be building my editor", "I am already so good with what I have, why?", they would say. My suggestion is to always stay skeptical of current choices and curious about unknown. It's not the concrete implementations, but rather abstract ideas that may grant some surprising and unexpected benefits.

replies(1): >>45960980 #
21. iLemming ◴[] No.45948536[source]
> requires an enormous amount of hacking to make a usable IDE.

When you're using it for one, specific purpose, like an IDE for specific language(s), then yes, sure, it may feel like that.

Yet Emacs is so much more. It's not an IDE (but it could be); it's not [the best] source control tool; it's not [greatest] note taking app; it's not an [amazing] mail client; it's not [most beautiful] pdf reader; nor a [feature rich] terminal app; etc. Emacs is not even an editor, to be brutally honest. It's not the greatest concrete implementation of any of these things.

What Emacs actually is - it's a concrete implementation of an abstract idea - a Lisp REPL with a baked-in text editor into it. That, for a second, is an absolutely fascinating commodity. Once you grok the essence of that idea, it's really difficult not to see the extreme value of it.

I'm sorry, I just have hard time to believe anyone who says: "used it for many years... yet abandoned it anyway".

It typically means that they've been using it from a narrow, small focused point of view, without ever exploring the possibilities that "true" Lisp REPL can grant them. I just don't see myself ever escaping Emacs, because there's simply no practical, comparable alternatives to it. Comparing VSCode to Emacs is like comparing it to Thunderbird - you didn't like how Emacs handled your emails and now using something else? Congrats, and that's just fine, only it's not fair and proper comparison by any means.

replies(1): >>45952856 #
22. iLemming ◴[] No.45949506[source]
> VSCode is familiar in its UX

That's by design. It must have appealing looks and employ every trick from psychology books to get you to try it and keep using it.

You don't have to be a genius to realize that a for-profit corporation with a $3 trillion market cap, spending millions on building a code editor with no direct licensing model; that they are distributing for "free" is not some kind of unseen goodwill; That shit eventually will generate billions in downstream Azure/services revenue. What is it if not a trivial ROI? It is a "loss leader" in traditional business terms, but a strategic necessity for cloud/services dominance.

VSCode is essentially a Trojan horse for the Microsoft developer services ecosystem - a mental prison that is designed to be easy to get in but hard to escape.

In comparison - vim/emacs have not a single profit motive; their network effect works differently; Yes, there's no entity with trillion dollar market cap to keep the pace with vscode, but no deprecation risks, no corporate pivot that ever is a treat to lock-in your data or your workflow or compatibility with older hardware. Vim & Emacs win by not being a loss leader for anything.

Who can ever predict what happens 5–10–20 years from now? Who can guarantee that some evil CEO wouldn't replace Nadella and secretly start implementing changes in the strategy that would change the essence and the meaning of being a programmer? It is already assumed that every dev has to use GitHub and to know VSCode at least on some basic level today. What if tomorrow your employers would be able to analyze your telemetry data to "measure" your performance? What if the use of anything but VSCode as the code editor would simply be banned?

23. self_awareness ◴[] No.45952344{5}[source]
Your argument is like... "once you learn C++ you have your whole processor at your disposal, you don't need to wait for any software because you can write it yourself."
replies(1): >>45954159 #
24. frumplestlatz ◴[] No.45952856{3}[source]
I have a job to get done, and my job isn’t screwing around with my Emacs configuration.

And honestly, even if that was my job, I wouldn’t want to spend all my time messing around with a fragile, slow, untyped lisp REPL in the first place.

I used Emacs because it helped me get my job done, not because I have any particular affinity for lisp. I truly do not — in fact, I have even less affinity for it now that I’ve wasted so much time making Emacs usable for my purposes.

replies(1): >>45954313 #
25. skydhash ◴[] No.45954159{6}[source]
That just highlights some confusion about Emacs. It’s more akinto Unix and the shell as a whole. That’s why I said VM. If you know perl and have a whole host of utils from a unix box, you can script the workflow you want quite easily, especially if you have access to the cpan libraries.

The same thing can happen with emacs. There’s a lot of low level interfaces (network, process,…) and some high level ones regarding the UI. Then there’s a lot of utils andd whole software built with those. All modifiable quite easily. As another commenter had put it, you don’t even need to save a file. You just write some code, eval it, and you have your new feature. If you’re happy with it, you add it to your config or create a new module (very simple). So elisp covers the whole range from simple configuration to whole software.

26. iLemming ◴[] No.45954313{4}[source]
> I have a job to get done

Yeah, it so totally fair to hear it from a Haskellite, I'm so convinced now... /s

"I have a job to get done, and my job isn't learning category theory, monads, type families, fighting compiler's cryptic messages and pragmas. I don't have any particular affinity for FP. I truly do not - in fact, I have even less affinity for it now that I've wasted so much time making Haskell do basic I/O and fighting the type system for my purposes..."

Even though the take like this maybe viewed as the honest one since Haskell's learning curve is genuinely brutal for practical work, I personally would never say that. I don't use Haskell, but I never regret time I spent trying to conquer it.

You can pretty much assert similar comments as yours about just any tool if you use it without proper understanding of the ideas behind it:

Python: my job isn't screwing around with virtual environments, dependency shit, and pretty useless type hints...

Java: my job ain't wrestling with Spring Boot config files, Maven POMs, and classpath issues...

C++: my job isn't learning the difference between stack/heap allocation, smart pointers, and move semantics...

Rust: my job isn't fighting the borrow checker and lifetime annotations...

Let's be honest, it seems you're mad at Emacs on an emotional level, rather than from educated, pragmatic stance. I admit, over the course of my career path I have felt similarly about different hard-to-learn things, I was like: "I feel like a sucker for not mastering this thing. Other people seem to make it sing. I wasted time and gave up. Now I need to feel like it was the tool's fault, not mine."

Eventually, I learned ways to distill great ideas and borrow them from different tools. I may not use a specific concrete implementation of a given tool daily, yet I find some of the abstract principles behind it appealing.

You have no idea how instrumental Emacs is for my everyday job-to-get-done tasks. It makes me sad to hear you failed to find the same dynamics even after spending a good amount of energy on it. When you're looking for a gray cat in a dark room and there is no cat, you'll spend a lot of time looking. And when you learn that it wasn't about a cat at all, you may end up hating all the cats. Attempting to use Emacs without understanding Lisp is like trying to cook in a dark kitchen. But programmers who dismiss Lisp entirely, are like musicians who refuse to learn music theory because they can play by ear. It's just sad to watch their talent getting lost in unnecessary limitations they've imposed on themselves. It like a talented musician who could understand harmony, composition, structure - but chooses not to. So they plateau. They hit a ceiling where ear alone can't take them further. And devs dismissing Lisp? They might have skills, but they're voluntarily blind to a way of thinking that could deepen their craft.

replies(1): >>45956118 #
27. solumunus ◴[] No.45955443[source]
If you struggle with VS Code you must struggle with everything.
28. frumplestlatz ◴[] No.45956118{5}[source]
Yikes. I’ve spent 40 years in this industry. My work is in formal verification. My comprehension isn’t the problem here.

I wrote a lot of lisp making Emacs work the way I wanted it to. VSCode has been a remarkable improvement. Writing extensions for it has been a breeze. I have zero interest in going back.

replies(1): >>45957112 #
29. iLemming ◴[] No.45957112{6}[source]
> I wrote a lot of lisp making Emacs work

Share the Emacs packages you wrote. I'm saying this unironically - someone might be interested to keep improving them, maybe they'd find some interesting ideas to extract from them. Don't be like some ungrateful jerk who benefited from communal work for years when it suited them and then has nothing to leave but grumpy resentment when they're done.

replies(1): >>45958170 #
30. frumplestlatz ◴[] No.45958170{7}[source]
That's genuinely wild, man.
replies(1): >>45959468 #
31. iLemming ◴[] No.45959468{8}[source]
In what sense? I apologize if I offended you. Just to be clear - don't share your config, experiments, packages or whatever with me specifically - simply consider making them public. Don't let the years of accumulated wisdom (whatever it adds up to) go waste. Emacs is not "a product", it's a "shared enterprise" and collective endeavor. Of course, it's not really "free" - just like everything, it has a price - it requires patience, dedication and time from every participant. You've mentioned using it for years, which means you've contributed to the cause. You've decided to move on - your reasons are your own. I'm not asking you to donate, volunteer, or speak about it either way. Do what you want. But for a moment, perhaps consider this with wonder: how many remarkable things have we humans collectively created that require no payment whatsoever, yet grant us the freedom to do things on our own terms? Projects like Emacs and Vim/Neovim are like free-for-all, unrestricted gardens. And that's why I get vexed seeing stuff like: "used it for years - getting tired of it...", etc. Reflections like that are akin to shitting all over the neck of those imaginary gardens, making them less desirable places for curious newcomers. I'm not telling you to not criticize, please do, but perhaps with consideration - tell it with constructivism. Allow those gardens to grow. They will most likely outlive your pondering - positive or otherwise, and mine and those of many more generations.
32. t_mahmood ◴[] No.45960980{4}[source]
No issues here, except for you being an Emacs user :D

> IntelliJ is to blame for why my transition to Emacs took me two years ...

It was a bit opposite for me, I jumped around so many editors, and, then I fell in love with VIM, spent so many hours to get the config that meets my need, dissed many Emac users. And, now after many years, as I grew, I realized, these are tools, and at the end, it's all on the user who makes it click.

I use both IntelliJ and (n)vim almost side-by-side, every day, when I am on my main desktop, I am on IntelliJ, when I am connecting through ssh, I am on NVIM. I use NVIM, because it's LSP, and treesitter's highlight is really good. But in any other case I am using VIM. I even wrote this reply on VIM.

I could make VIM work like NVIM, sure, but does it worth the trouble, when I can just use LazyVim? nah ...

> Gary Bernhardt famously said - "There's no such thing as vim-mode ...

True, most of the software can't replicate how wonderfully VIM works. I have had my moments with IdeaVIM, and resorted to VIM, but, again, there are things that IntelliJ does so good, and IdeaVIM scratches a vim sized itch. IdeaVIM makes IntelliJ more useful for me.

And, with these tools together, I can get a lot done, where it would be too inconvenient if I was doing it in VIM, or too annoying if I was doing it in IntelliJ without IdeaVIM.

> In Emacs, you can bind keys to anything, conversely ...

Certainly, you can be faster with keyboard, and It is possible to do the same with IntelliJ + IdeaVIM. Additionally, with IntelliJ, I can quickly navigate my database, write queries, or manage Docker containers without going to another terminal or app. Not having to change window/app is extremely helpful for me to stay focused.

And, I have not found any cli based db tool that is as good as IntelliJ's one.

> Most devs, once they find their favorite tool would settle with it and don't even explore other options ...

True, I used to encourage people towards VIM, converted one or two, but at the end, I realized, it's their choice, and some might even have good reasons for their choice.

I can show them the magic, but it's always their decision to pick it up.

replies(1): >>45961307 #
33. iLemming ◴[] No.45961307{5}[source]
> No issues here, except for you being an Emacs user

I am a die-hard vimmer. I just one day woke up and realized that Emacs vims better than Vim. Seriously though - it's not about concrete implementations, it's all about the [abstract] ideas.

I use vim navigation everywhere - in my editor, my browser, my terminal (I use nvim too), my WM, remote sessions. I control my music, video-playback, app switcher - all, using mostly just home row keys. I never need to touch arrow keys and rarely have to reach for the mouse.

Idea of vim navigation is an absolutely brilliant, beautiful, practical model, it speaks to me and I have zero reasons for not using it. What keeps me with Emacs is another immeasurably brilliant idea - the idea of practical notation for lambda calculus, which is known as Lisp. Lisp probably can be crowned as one of the most important ideas in computer science. It's just hard to think of anything more influential than Lisp.

There's a notable shared trait between these two - they both entail tacit knowledge. You're probably well aware of what I'm hinting at. You see, trying to teach someone who never rode a bike is challenging for a similar reason. You may show them countless videos, explain how gyroscopic effect and caster effect keep the bicycle stable, you can draw diagrams and try to inspire them with names of all famous people who loved riding - none of it can explain the simple joy of an ordinary bike ride on a straight line. Until they've tried for themselves, nothing will ever make them feel what they can never unlearn later.

> I use both IntelliJ and (n)vim almost side-by-side

I perfectly pictured my own younger self - I absolutely had maintained the same setup not too many years ago, before diving into Emacs. And then it became three things side-by-side. Eventually, I had to stop this madness and forced myself to use only one. I made a promise that instead of reaching to the familiar and cozy confines and warmth of WebStorm, whenever I had to get something done, I would try to google and find ways to achieve the same things in Emacs. I really wanted to figure it out and make the decision once and for all. My plan was to time-box that experiment for a week, fully expecting that in the end it will replace Vim, but certainly not WS. After a week I decided I liked it and I wanted to keep going. Two months later I realized - I had not had to run WebStorm even once. Five month later I decided not to extend my license for next year, but it was never about the money.

Keep finding new bicycles to ride. Even when you don't feel like it, and especially when it feels kinda scary.

replies(1): >>45965988 #
34. t_mahmood ◴[] No.45965988{6}[source]
Ah, bicycles, something that I love so much. Yes, agreed, someone who never rode will never realize how amazing it is feel the air in your face, the gentle sound of the tire rolling. I miss it so much.

But, when you keep changing your bikes, and start fiddling with the mechanics of it, you forget, what made it worth in the first place! What was the thing that gave you the pure joy.

PS: Using nvim and IntelliJ(Ultimate) side by side is for a personal reason. I have to be away from my main desktop for a really long time. So have to SSH into my desktop using a Surface Pro 3 (Running Linux) to work. It's a really portable setup, and works well as a thin client. And it is an experiment to fully utilize CLI tools, to get my work done.

35. nsonha ◴[] No.46095471[source]
Does not take any coding ability configue it. Out of the box you can search for any setting and even if you edit the json config directly you get autocomplete.