[HN Gopher] I have reached Vim nirvana
___________________________________________________________________
I have reached Vim nirvana
Author : behnamoh
Score : 268 points
Date : 2022-12-27 06:05 UTC (16 hours ago)
(HTM) web link (www.maxwellrules.com)
(TXT) w3m dump (www.maxwellrules.com)
| joshthecynic wrote:
| [dead]
| jerpint wrote:
| I've tried the jupytext approach and had problems when files get
| out of sync (which inevitably happens). So far, my best
| Jupyter/vim solutions are either to use a jupyter extension that
| enables vim bindings or use jupyter in vscode with vim emulation
| Lapsa wrote:
| [vim-archery fzf.vim vim-gitgutter] is what I need
| mlboss wrote:
| I take the different approach. I use vim binding in all my
| editors and IDEs. Most of them have vim plugins. Jupyter also has
| a vim mode.
| kzrdude wrote:
| It's interesting to see this, I want to know about how others
| work.
|
| But I've found with jupyter that it's most productive for me to
| just use jupyterlab in the browser, it has lots of features and
| for the visualizations that I do I need a good viewer. So vim
| doesn't work, and executing in ipython is like the console, not
| the notebook interface anyway.
|
| I recommend using jupytext too, and then you can keep .py files
| as the canonical notebook files in your repo and code history.
| czx4f4bd wrote:
| I used to do the same, but I've been pleasantly surprised by VS
| Code's support for Jupyter notebooks. VS Code is my main
| editor, so it's really nice having all my familiar keybindings,
| plugins, VSCodeVim, etc. working out of the box.
| perihelions wrote:
| I use different tools, but what I do is insert image outputs
| inline with the calling code, in an Emacs text buffer. (emacs-
| gtk has native support for this). I don't have any explicit
| "notebook cell" logic. What I do is heuristically assume that
| an image object immediately following a code block is its
| corresponding output, and overwrite it on reevaluation. Very
| inexpensive hack that almost always does the right thing.
|
| (Also, the image-invoking functions are just native functions
| in the source language, so I get a lot of orthogonality for
| free. For example, all the eval- and send-expr- style
| keybindings work automagically -- no need to extend the elisp
| language mode to special-case images).
| rjzzleep wrote:
| From my perspective when I had to turn ML models from a "real
| scientist" to something I could use in production, emacs-
| ipython-notebooks[1] was immensely helpful for me, since it
| allowed to connect to the jupyter server and edit and copy
| things from emacs to other code places as if I'm looking at an
| org mode file.
|
| I see the appeal of Jupyter notebooks for someone testing out
| things or experimenting, but it's a bit like a brain dump that
| isn't that trivial to navigate around when a second or third
| person is involved.
|
| [1] https://github.com/millejoh/emacs-ipython-notebook
| ryan-duve wrote:
| I use IPython in a terminal and keep a Firefox tab open in a
| split screen to look at plots. When the IPython script is
| working, I write it out to a Python file. The only times I use
| Jupyter notebooks are:
|
| 1. If there's a _really_ visually intensive workflow, like some
| sort of data exploration step where I need to be generating and
| inspecting multiple plots at the same time over and over.
|
| 2. If my goal is to make an instructional artifact and
| interleaving Python and explanatory HTML is helpful.
| sva_ wrote:
| It sadly doesn't seem like this would support Jupyter Remote,
| which I've been heavily relying on (through vscode+vim) due to
| working on my laptop remotely with very limited hardware.
| greyman wrote:
| I don't know why, but vim never worked for me. I tried several
| times to learn it, but I always forgot the shortcuts... maybe the
| reason is that I used it only a few times per week, to change
| crontab or some config file on server.
| lvncelot wrote:
| It was the same for me, for a long time. I've just used vim for
| commit messages since I was to lazy to change $EDITOR. Then, I
| can't even remember why exactly, I've taken a few weeks to
| actually learn the basics. The first few months were a little
| awkward, since I wasn't as efficient as I was in Sublime Text
| (which I've used at the time), but I also started to miss some
| vim keybindings in other editors. After a while, everything
| clicked and now I have vim keybindings in almost every program
| where it's even remotely possible. (Shoutout to tridactyl[1]).
| I think the most important part is to slog through a couple of
| longer coding sessions, like you said. (Although vimtutor is a
| good start, as well, and a colleague of mine got started using
| vim adventures[2])
|
| [1] https://github.com/tridactyl/tridactyl
|
| [2] https://vim-adventures.com/
| andrepd wrote:
| I was deep into the vim rabbit-hole for about a year and a
| half. Read all the guides, got all the plugins, kitted out my
| vimrc, all that stuff.
|
| Then one day I realised I was _still_ more productive in
| sublime with its simple but powerful keybindings than I was in
| vim. I dropped it and never looked back.
| glotchimo wrote:
| Vim didn't click for the longest time until I deleted VSCode
| and used it for everything. Much like with many other
| concepts/skills, throwing myself in the deep end worked best.
| flohofwoe wrote:
| You could just have installed one of the vim extensions for
| VSCode ;)
|
| (even though it's not 'real vim', it's good enough for using
| both cmdline vim and vscode without the brain having to
| switch in and out of 'vim mode')
| P5fRxh5kUvp2th wrote:
| No vim emulator is "good enough" if you actually know vim,
| although jetbrains is probably the closest due to the
| configurability of it's plugin.
|
| there are almost always quirks, but the biggest issue tends
| to be when bridging the gap between vim and the GUI itself,
| particularly around the modality of vim vs graphical
| autocomplete.
|
| If you're less experienced as a vim user these emulators
| are probably perfectly fine, but as someone who has been
| using vim for something like 20+ years, they _always_ feel
| just off enough that I either just go back to vim or edit
| the way the editor originally intended.
| doix wrote:
| The problem with every fake vim plugin is that the
| underlying editor does not implement tabs the way vim does.
|
| Combine that with the fact that all the UI elements are not
| vim-ified. In vim, since everything is a pane and a buffer,
| you just think "I want to select the panel to the left".
| Regardless of if it's a plugin view or a file or whatever.
|
| In vim emulator's, that's never the case. It's really not
| the same, but better than nothing. The vscode plugin and
| the IntelliJ one are both pretty good compared to previous
| ones that I tried. But the IDEs are just incompatible with
| the vim ideology, in my opinion.
| yakshaving_jgt wrote:
| I'm not sure that's _the_ problem. I think it 's more
| likely one of several, but I'm not sure tabs are all that
| useful a feature in vim -- vim is all about _buffers_.
|
| Not once in the past eight years have I had to use tabs
| for something. The buffer list, yes. The argument list,
| yes. Tabs, no.
| ketzo wrote:
| As someone who always wanted to try Vim out, I thought
| the Vim keybindings plug-in was a total game changer. I
| _only_ use it for moving around in and manipulating the
| text - because that's all it can do - and it's awesome.
| Genuine life change.
|
| Just a little counterpoint basically - I don't think you
| need Vim's entire editor model to get a _lot_ of value
| out of it!
| doix wrote:
| I'm sure it is! But I got used to everything following
| vim logic, so when I use an IDE that doesn't, I miss
| it/get annoyed.
|
| My comment wasn't meant to dissuade anyone from trying
| the vim plugins. I was just trying to explain why someone
| would consider the vim emulation plugins not as good as
| the real thing.
| jrumbut wrote:
| I also seem to run into performance problems using IDEs
| (even on recent, high end hardware) while vim remains
| fast.
|
| If nothing else, the performance characteristics of vim
| are predictable (to me, after all these years) and there
| are various ways to work around any problems that occur
| (disabling plug-ins, etc).
| dpz wrote:
| why swap out of vim mode, add the key bindings to
| everything
| josephd79 wrote:
| this.
| _448 wrote:
| > I tried several times to learn it, but I always forgot the
| shortcuts...
|
| If you keep at it you will develop the muscle memory. I am not
| an expert in Vim, but I use it whenever I want to write some
| code. Once I was given a coding problem to solve. The
| interviewer gave his laptop to me with part of the program
| implement and I had to complete the program. The problem was
| the C++ code was written in Visual Studio on Windows and I had
| not used that setup for a long time. So it was frustrating for
| me and amusing to the interviewer to see when I use to press
| Vim keystrokes while writing the code in VS :)
| tomkarho wrote:
| > So it was frustrating for me and amusing to the interviewer
| to see when I use to press Vim keystrokes while writing the
| code in VS
|
| And this is why I have never been comfortable with vim or the
| idea learning it on that level. Why would I spend time muscle
| memorizing a program that conflicts so much against all other
| editing software and related paradigms? The skills do not
| scale enough to make it worth the effort imo. Sure your vim
| powers skyrocket but any other interface where you have to
| type becomes a nightmare to work with effectively.
|
| Are the advantages of working really really well with one
| tool worth the effort when you lose productivity in every
| other tool (99.9% of them) out there? Maybe if you can live
| constantly in vim but how many of us truly only edit text
| files during our day to day?
| atarv wrote:
| Learning vim has actually made it easier for me to use
| other IDEs and editors. Most of them have plugins that
| provide vim keybindigs for editing.
|
| Many other programs loosely follow vim bindings. For
| example if you enable hotkeys in GMail webclient you can
| use j and k keys to move between emails, press / to search
| just like in vim.
|
| In the comment you replied to the author was in an
| interview situation so they didn't have time to install any
| plugins.
| eimrine wrote:
| > Why would I spend time muscle memorizing a program that
| conflicts so much against all other editing software and
| related paradigms?
|
| Because no other editor is oriented to muscle-memorizing.
|
| > any other interface where you have to type becomes a
| nightmare to work with effectively.
|
| Something tells me that you are talking about some
| interfaces with mouse. It's really a nightmare for mine
| inner vimmer to get my hands out of keyboard in any other
| editing interface or even to look at keyboard for searching
| those Alt-Ctrl-Shift chords.
| lawn wrote:
| Only a few times a week is indeed to little to get used to it.
|
| If you're serious about it, you should use it for everything
| and use it a lot.
| tinco wrote:
| Yeah that's got it reversed. Vim is overkill for editing
| configuration files. You see people use vim for configuration
| files because it's there and they already know how to use it.
|
| If you really want to ease into it then simply enable the (neo)
| vim plugin in vscode, it's pretty good. You'll miss some big
| features but you'll have all the bread and butter features.
| Only risk is that you'll get used to some vscode features as
| well.
| yodsanklai wrote:
| I've been using vim forever. I'm fluent in editing files. But
| what never clicked for me is working with several buffers,
| making lookups across files, using ctags/lsp and so on.
|
| The right setting for me is Vim _within_ an IDE (nowadays
| VSCode) but I 've found it too complicated to try to turn it
| into an IDE. I find it appealing to be able to do all your work
| within tmux/vim, and I know a lot of great coders work that way
| but it's been too much hassle for me.
|
| I also wonder if Vim is a productivity gain at all. I like to
| be able to navigate/edit a file without taking off my hands
| from the home row, and also quickly edit a file when I'm in the
| terminal. But not sure it really makes that much of a
| difference when you know your VSCode/MacOS shortcuts, and I
| suppose that with proper configuration, you can also edit file
| remotely with VSCode and restrict the need for edition within a
| terminal.
| lvncelot wrote:
| > I also wonder if Vim is a productivity gain at all.
|
| The big productivity gain for me doesn't come from faster
| editing due to the shortcuts, per se, but from the golden
| combo of modal editing and macros. Due to how you treat
| similar looking text in vim, macros are much more powerful
| than something like multi-line-cursors, which break down when
| you want to, for instance, delete the first part of 5
| pascalCased variables with different lengths. Luckily, iirc,
| the vim integration in VSCode supports macros, so people who
| want to keep working in VSCode because of the excellent
| ecosystem can still have the best of both worlds.
| worksonmine wrote:
| There are probably people who are very effective in vscode
| and the likes. But my patience is tested anytime I'm helping
| someone or pair programming and I have to watch them navigate
| the code and make their edits.
|
| In my head all I can think of is all the ways it could be
| done faster in vim, so it's absolutely a productivity gain,
| even if it's just a plugin for vscode.
| Hendrikto wrote:
| "Some people are inefficient with X" does not mean X is
| inefficient. They may just be bad at using X.
| yakshaving_jgt wrote:
| Funny, several people commenting on this post are making
| exactly this argument, but at vim's expense.
| worksonmine wrote:
| While I get what you're trying to say there are benefits
| to modal editing that learning all the keybindings in X
| can't replicate. It's difficult to explain and has to be
| experienced to fully understand.
|
| As a quick example what are the vscode equivalents of I
| and A to enter insert mode in the beginning or end of a
| line? These small things quickly add up.
| modernerd wrote:
| These days if someone using VS Code asks me how they
| could be faster, I would be much more inclined to give
| them some tips that work in VS Code than I would be to
| encourage them to learn Vim or install a Vim extension.
|
| Ctrl-a and Ctrl-e do what you say in VS Code (same amount
| of keypresses as "I" and "A", or fewer if you're in
| insert mode in Vim, and you never need think what mode
| you're in).
|
| Ctrl-w gives you visual selection of the word under the
| cursor. Repeat to extend the selection (similar to nvim-
| treesitter's init_selection and node_incremental, but you
| don't have to set up treesitter and bind shortcuts or
| learn how to use visual mode).
|
| I use Neovim and learned to use VS Code without Vim
| extensions (to help/teach others, and out of professional
| curiosity!).
|
| Editor "X" absolutely can replicate features from Vim
| well enough in a lot of cases for the differences not to
| matter too much, because editor X also does some things
| better or faster than Vim. Plus we can fill in many gaps
| that really bother us with extensions. For example, this
| extension for VS Code lets you switch the cursor from the
| start to the end of a selection similar to 'o' in visual
| mode in Vim: https://marketplace.visualstudio.com/items?i
| temName=rioj7.se....
|
| What _does_ seem to be true is that people who use editor
| "X" are sometimes less vulnerable to spending their free
| time learning the features and shortcuts of their editor
| that would make them just a little bit faster. Vim/Emacs
| users tend to do that because for us text manipulation
| and editor hacking are a weird kind of hobby.
|
| But I pair with a lot of senior devs who are _very_ fast
| with VS Code/IntelliJ these days without Vim extensions.
| I have also spent much less time making VS Code
| completely keyboard-driven than I have customising my
| Neovim config to achieve largely the same abilities (only
| with Neovim I also lack a lot of healthy things like
| screenreader support). In VS Code I just needed:
|
| - File Browser (keyboard-driven file nav/creation without
| using the tree view): https://marketplace.visualstudio.co
| m/items?itemName=bodil.fi...
|
| - Edamagit (keyboard-driven git commits): https://marketp
| lace.visualstudio.com/items?itemName=kahole.m...
|
| - [Optionally]: VSCodeVim ( https://marketplace.visualstu
| dio.com/items?itemName=vscodevi... ) or VSCode Neovim ( h
| ttps://marketplace.visualstudio.com/items?itemName=asvetl
| ia... ).
| worksonmine wrote:
| Yeah, I did a search and realized it was the emacs
| bindings but didn't bother editing my comment as most
| people I've worked with don't know them or even stop to
| consider if it's possible. A better example would be o/O,
| c3w, ci) and so on. Even holding Ctrl+[Arrow
| keys/backspace/delete] to move word by word is rare to
| see even if supported everywhere.
|
| Of course (and I mentioned it in my first comment) there
| are people fluent in vscode but it's far from the norm,
| and doesn't have to be. As you say for vim users it's a
| hobby or even lifestyle.
|
| But this thread started with questioning if "vim is a
| productivity gain at all", and I'm confident it is. I use
| it everywhere from window manager to browsers, and where
| it isn't natively supported by plugins/extensions I add
| my own keybindings to get at least movements and scroll.
| gfaregan wrote:
| I'm not sure if it's much of a productivity gain, but the way
| I have it set up it is really easy to navigate quickly and
| precisely through buffers, folds, characters, etc. And it
| always works once I've installed my config files without any
| further messing around.
| LinXitoW wrote:
| To possibly answer your question, think about conveniences
| that every editor gives you: Editing per (UFT8) character,
| instead of code points, or bytes or even bits. Would that
| make you less efficient? I'm sure it would.
|
| Conversely, saying "delete in parens" instead of "move
| forward 5, delete back 10" is also a real gain.
|
| That being said, use what you have. With editing, and
| navigating the same file, Vim or it's emulations are almost
| always better, but most editors offer great cross-file
| features you should also use, like the "shift shift" in
| Intellij IDEs, or "ctrl-p" in vscode.
| EdwardDiego wrote:
| It blows my mind that there's so much devotion to the tool first,
| problems second, which must be mashed into a shape that fits my
| tool.
|
| I don't think I'll ever describe myself reaching <X> nibbana,
| because, well, a hammer is a hammer, an IDE is an IDE, a tool is
| simply a tool, a means to an end.
| osigurdson wrote:
| It is good to have at least a basic understanding of a common
| terminal based editor. Otherwise it is very cumbersome to work
| with files on a remote server / ssh.
| tasuki wrote:
| This person's tools were not working exactly as they wanted.
| Now their tools work as they want and they're excited about
| that and wanted to share.
|
| It's possible I missed something, but I didn't see the author
| being devoted to tools first, nor mashing problems to fit their
| tools.
| doix wrote:
| You use a tool enough and it shapes your way of thinking. It's
| like touch typing, you don't think about the individual keys
| you press. Instead you think about what you're trying to
| say/code and muscle memory takes over.
|
| It's the same with vim. You start thinking "delete that word",
| or change everything until the '(' character. When you start
| thinking that way, changing the way you think becomes
| distracting.
|
| > It blows my mind that there's so much devotion to the tool
| first, problems second, which must be mashed into a shape that
| fits my tool.
|
| I see it more of a question of, do you change the way you think
| to match the tool? Or change the tool to match the way you
| think?
|
| I don't think there's necessarily a right or wrong answer, at
| some point I changed the way I think to match the vim model.
| Now I change things to match the vim model rather than change
| the way I think.
| minusf wrote:
| i can't not explain in words what it's like to use vim for
| 20+ years, esp to someone thinking an editor is "just" a
| tool. my vim config changes with me...
|
| for some the journey is never the goal.
| EdwardDiego wrote:
| I've used Vim since 1993, pretty sure it was 93, might have
| been 92, and it was probably just Vi initially, but then I
| progressed to Vim.
|
| And I still use it.
|
| So yeah, guess I haven't hit 20+ years, but I'm pretty damn
| close, and still not as committed to it as you are.
|
| Length of time using it doesn't correlate to passion.
| [deleted]
| minusf wrote:
| i'm not excluding anyone using it even for a day.
|
| i was trying to make a point that it's a tool with a very
| long history and all the time i "wasted" (and still
| waste) on learning it was well invested, as it's going
| nowhere and i spend 8-9h in it a working day.
|
| i think i've been using only a shell longer than vim.
| xanathar wrote:
| If you started in 1992 you're at 30 years.
| EdwardDiego wrote:
| ... that's what I get for late- night commenting.
|
| (Also, 30 years? Christ I'm old.)
| EdwardDiego wrote:
| > You use a tool enough and it shapes your way of thinking.
|
| Yes, that's true. I can't fathom writing Java in anything
| other than Intellij because it's shaped my thinking to "my
| tool should already know what this symbol is, where it is,
| and what arguments it might take". I guess it's shaped my
| expectations more than my thinking, but I hope you see what I
| mean.
|
| > I see it more of a question of, do you change the way you
| think to match the tool? Or change the tool to match the way
| you think?
|
| Fair question. I guess my response is that one of the lessons
| I've learned the hard way in life is that my way of thinking
| can be wrong.
|
| And while I enjoy a tool you can tweak to your desired
| tolerances, I prefer to use the tool that is most closely
| aligned to the task at hand.
|
| You can get a nice even surface on a piece of timber using a
| chisel very carefully. Or, you can use a plane.
|
| You can cut down a tree with a stone lashed to a branch, or
| you can use an axe with a metal head. Or, a chainsaw.
|
| Changing between any of them requires a revision of how you
| think about the process, but it seems obvious that the cost
| of doing so might be worth it, even if the chainsaw requires
| changing how you think to incorporate concepts like kickback.
| lycopodiopsida wrote:
| It is not clear to me, why people try to make an exception
| of an extremely IDE-centric language/tooling, such as java
| is, to an advantage of IDEs in general.
|
| There are other languages besides java and C#, where
| advantages of IDEA are small to none. For them, you have to
| accept a bloated project-based resource-consuming monster.
| Or you do not and just write rust in vim or emacs. In times
| of LSP and DAP the gap is getting smaller each day. But
| IDEA is not getting faster, and never will.
| EdwardDiego wrote:
| I primarily use IDEA to write Python at my current job.
| I've also used it for Go, JS, PHP on the odd occasion.
|
| > But IDEA is not getting faster
|
| I disagree, there's been several changes made I can think
| of to improve speed
| asdajksah2123 wrote:
| Isn't the whole article about how the author made his tool
| "most closely aligned to the task at hand"? Bonus points,
| since it's a flexible tool that can be aligned to most
| tasks, he is able to bring his specialized knowledge and
| experience of the tool to this specific task at hand as
| well.
|
| It's the best of all worlds!
| pwdisswordfish9 wrote:
| This sounds like a knee-jerk reaction that results from not
| having taken the time to make sure that the criticism lines up
| with the thing being criticised.
|
| > It blows my mind that there's so much devotion to the tool
| first, problems second
|
| The problem is clearly outlined here: "Manipulating raw ipynb
| files is difficult and unergonomic."
|
| OP is not fiddling with his or her editor configuration because
| of any undue focus/deficiency regarding Neovim. The deficiency
| is in the Jupyter notebooks editors. In other words...
|
| Problem: Jupyter sucks; my thoughts are always slowed down by
| having to squeeze them through a low-bandwidth link and the
| ergonomics hurdles that comprise basic text inputs--I want to
| go fast, but with Jupyter, I can't.
|
| Their solution: This.
| EdwardDiego wrote:
| And conveniently, the solution is the editor that the author
| has already invested a lot of time into.
|
| What are the odds?
|
| PS, describing my comment as knee-jerk is unhelpfully
| dismissive. I'm always keen to engage, and always happy to
| acknowledge when I'm wrong. :)
| rhaway84773 wrote:
| The odds ew pretty damn good.
|
| 1. You're talking about an editor that has been popular
| across multiple decades and across many many generations of
| technologies.
|
| 2. The editor they're already using obviously already does
| things in ways they like. That's why they are using it. So
| the odds that their editor will perform the job well for
| them is also pretty high.
| myfavoritedog wrote:
| Conveniently, the solution is the editor that thousands of
| developers have taken time to improve over decades so that
| the author didn't have to start from scratch.
|
| What are the odds that the solution involved a popular,
| mature tool that the developer could leverage?
| pwdisswordfish9 wrote:
| To answer your question:
|
| > What are the odds?
|
| Very good, actually.
|
| You seem (and seemed) to be unaware how dismissive your
| original comment was. In fact that was the entire point of
| the response. To take issue with that response on the
| grounds it itself is "unhelpfully dismissive" involves
| layers of irony.
| xbryanx wrote:
| If you swing a steel head framing hammer for 20 years, and then
| discover the lighter titanium one, I guarantee it will feel
| like nirvana. Tools matter.
| EdwardDiego wrote:
| I don't disagree that using the right tool for the job is
| important. In fact, that's kinda what I was going for - don't
| try to make the problem fit your preferred tool, rather, use
| the right tool.
| anamexis wrote:
| Isn't the weight of a hammer head a key part of what makes it
| effective?
| 0xEFF wrote:
| I was curious how F = mv/t relates. TIL a steel hammer
| reverberates 30% of the energy back into the arm. Titanium
| is only 3%. I imagine it feels a lot better after a day of
| work.
|
| https://www.protoolreviews.com/titanium-hammers-vs-steel/
| pc86 wrote:
| Except this is more like using a hammer for screws because
| you've been swinging a hammer for 20 years and don't feel
| like using a screwdriver.
| mtlmtlmtlmtl wrote:
| That comparison makes no sense. Using a hammer for screws
| doesn't work at all.
| pc86 wrote:
| And using vim for Jupyter notebooks doesn't either.
| That's the point of this entire subthread.
| mtlmtlmtlmtl wrote:
| Did you read the blog post? Clearly vim does work.
|
| Or are you saying the blog post is a hoax?
| jolmg wrote:
| Yesterday, I bought some nuts and wondered if I needed a
| nutcracker. I kinda dislike specialist tools. I prefer
| versatile ones. I found that I could just hold it in my hand
| and hit the nut with the blunt side of a chef's knife, turning
| the nut around and cracking all sides with precision. I could
| reliably extract the eatable inside part completely intact, not
| even split in halves. A specialist nutcracker tool is pointless
| to me now.
| tpoacher wrote:
| That's nuts!!!
| EdwardDiego wrote:
| I typically use a hammer. But as the old saying goes, when
| all you've got is a hammer, everything looks like a nut.
| MonkeyClub wrote:
| I have good news for you :)
|
| > I don't think I'll ever describe myself reaching <X> nibbana,
| because, well, a hammer is a hammer, an IDE is an IDE, a tool
| is simply a tool, a means to an end.
|
| According to the Zen master Dogen:
|
| "Before one studies Zen, mountains are mountains and waters are
| waters; after a first glimpse into the truth of Zen, mountains
| are no longer mountains and waters are no longer waters; after
| enlightenment, mountains are once again mountains and waters
| once again waters."
| diffxx wrote:
| Also relevant, Before enlightenment: chop wood, carry water.
| After enlightenment: chop wood, carry water.
| lukas099 wrote:
| Like a lot of Zen things, this sounds like someone 'trying to
| sound deep'. But I'll try my best to interpret it charitably
| and maybe others can chime in with their interpretations.
|
| It's safe to say most people see mountains as mountains etc.
| When you start practicing Zen, you glimpse into the
| inseparability of things: there is really no defined boundary
| between the 'atoms of the mountain' and the 'atoms of the
| water'. (Also the atoms themselves are mostly empty space
| with a probability distribution of where the 'stuff' 'is').
| Things like 'mountains' are really illusory abstractions that
| humans build on top of the underlying reality of the swirling
| wave patterns of the universe. 'Existence precedes essence',
| as the existentialists say.
|
| Still in this second phase, you notice things like when you
| have a conversation with another, the conversation is not
| really being generated by either brain, it is being generated
| by the system that includes both brains (and nerves, muscles,
| vocal cords, the air between them, eardrums, etc.)
|
| However, after enlightenment, you realize that the underlying
| physics is no more 'real' than the abstractions, as the
| abstractions are what really has an effect on the universe.
| As Zizek might say, the distortion itself is the real. When I
| see a mountain, the way that my brain interprets it as a
| mountain, in effect _makes_ it a mountain, because the symbol
| itself manifests itself in my thoughts and actions.
| lukas099 wrote:
| Note that if you are reading this, you probably shouldn't
| listen to my interpretations of what Dogen, Sartre, or
| Zizek are trying to say. These are my own, very flawed
| interpretations of their words.
| MonkeyClub wrote:
| Lol obviously a good meta point.
|
| I'd also note that Dogen wasn't trying to sound deep -
| perhaps unlike Sartre and Zizek.
| EdwardDiego wrote:
| Maybe contrast that to Chuang Tzu's Dexterous Butcher...
|
| "When I first began
|
| To cut up an oxen
|
| I would see before me
|
| The whole ox
|
| All in one mass.
|
| After three years
|
| I no longer saw this mass.
|
| I saw the distinctions.
|
| "But now, I see nothing
|
| With the eye. My whole being
|
| Apprehends.
|
| My senses are idle. The spirit
|
| Free to work without plan
|
| Follows its own instinct
|
| Guided by natural line,
|
| By the secret opening, the hidden space,
|
| My cleaver finds its own way.
|
| I cut through no joint, chop no bone."
|
| It's not the tool, but the wielder.
| MonkeyClub wrote:
| > It's not the tool, but the wielder.
|
| It's following the tao of the ox. That's why he didn't need
| to sharpen his cleaver for a decade or something, it just
| "naturally" went into the empty spaces, rather than stumble
| against bones and sinews.
|
| (If I remember correctly; my old Burton Watson copy is now
| sadly long lost.)
| asdajksah2123 wrote:
| I find it fascinating that people think that optimizing a tool
| doesn't matter when they will be spending over 50% of their
| actual productive professional time in that tool. At least.
| allarm wrote:
| > tool first, problems second
|
| Because there's a tool and there are (current and future)
| problems that can be solved with this tool. It's an one time
| investment into a tool and it helps to solve multiple future
| problems more efficiently. Especially with vim or rather modal
| editing - this skill can be applied everywhere, including your
| favorite IDE. Though, it may be unrelated to the problem that
| OP was solving.
| EdwardDiego wrote:
| I've used Vim since I first managed to figure out a way to
| get a shell on the heavily controlled school Unix network.
| (Well, it was Vi initially).
|
| It was always my editor of choice when SSHing into a box over
| dodgy dial-up for the very obvious reasons, a few keystrokes
| could be immensely powerful, and they're easy to transmit.
|
| But I've never felt the urge to run Vim bindings in my IDE,
| or my browser. But for working on a file over SSH? Vim all
| the way.
|
| Different tools for different situations.
| AstixAndBelix wrote:
| I mean, in mathematics a lot of problems are solved by
| realizing they can be turned into another tupe of problem that
| we already know how to solve.
|
| If you know a text editor like the back of your hand, why would
| you learn another tool when you can take a different approach
| and be even more effective?
| EdwardDiego wrote:
| How many hours am I going to spend making my text editor work
| with this new problem? How long would it take to learn the
| new tool sufficiently to be reasonably effective?
|
| I always remember a coworker who was determined to use Emacs
| on our Java codebase. He spent three months trying to get
| functionality equivalent to 2010 Eclipse (I was one of the
| IDEA hipsters in the company back then), and failed. Hard.
|
| I always thought that in 3 months,n if he'd applied that
| effort to Eclipse, he'd probably be contributing patches to
| it.
| knewter wrote:
| I have learned a multitude of tools. I have used vim/nvim
| since 2005. Prior to that, visual studio for a few years as
| a .net developer.
|
| I have sought to incorporate vim wherever I could because
| my muscle memory demands it for productivity.
|
| It's not from a lack of learning tools.
| f0e4c2f7 wrote:
| I find that some people really care about the work and that the
| tools are just a means to an end.
|
| Other people love certain tools so much that "the work" is
| actually just an excuse to use their favorite tool in more
| elaborate and challenging ways. Their attitude is something
| like "and now for my next trick..."
|
| The funny part, to me is that I've never been able to see one
| method as producing better results than another. I've seen work
| focused folks produce bad output and I've seen tool focused
| folks get caught up in their tools and never produce anything
| at all.
|
| But I've also seen both types produce masterpieces.
|
| Just different approaches and personalities I think.
| plufz wrote:
| I partly agree that it is a matter of personality, and that
| both can produce good results. But in my experience junior
| devs care more about the tools than seniors.
| stitched2gethr wrote:
| I think a big part of it is just enjoying your time.
|
| We're both driving cross country, following the speed limits.
| We'll both arrive at roughly the same time but maybe I'll
| enjoy my time more if I'm driving a stick shift.
|
| This is in general of course. Me personally, I save tens of
| minutes a year by using vim.
| allarm wrote:
| > I save tens of minutes a year by using vim.
|
| Probably more. It's not only the speed of typing and
| editing that matters, but also the time you spend on
| context switching. When your hands don't leave the home row
| you don't leave the current context.
| manmal wrote:
| Loving one's tools is one way of loving the process -
| arguably the best approach to building great things.
| kovac wrote:
| > It blows my mind that there's so much devotion to the tool
| first, problems second
|
| What made you think that their devotion to the tool indicates
| that they care less about the problem? I wonder what you might
| think about me then in that I have vim integrated with mutt for
| composing emails, git, my password manager, code editor, text
| pager, etc land me in vim. I choose most my apps so that I can
| use vim for text editing. It gives me uniformity. It saves me
| time.
|
| More importantly, I do not get a negative reaction from people
| that use different text editors for different text editing
| tasks looking for buttons to click, shortcuts to press in
| different places.
|
| Especially nowadays, when tech is converging, getting locked
| down, and we are being told what and how to do things by a few
| companies, we must appreciate and encourage diversity of tools
| (except for emacs obviously:) that empower their users. Not be
| dismissive and judge them for using a tool that we don't use.
|
| It's okay for people to master tools they find valuable, and
| use that mastery to do good things even if they're off-road
| tools (by today's standards) such as vim.
| DecemberSnow wrote:
| For PyCharm users, FYI using notebooks within the IDE with
| Intellisense and jupyter server management is available out of
| the box [0].
|
| [0] https://www.jetbrains.com/help/pycharm/jupyter-notebook-
| supp...
| xrayarx wrote:
| BTW nirvana means ,to blow out', like a candle.
| switch007 wrote:
| Google says: " Figurative sense of "perfect bliss" is from
| 1895."
|
| I think the ship has sailed
| illegalmemory wrote:
| That is correct, but general public understanding is a little
| different. Nirvana ( Sanskrit origin ) word to word means : to
| blow out / disappear / extinguish and so on. But to "achieve
| Nirvana" or "Nirvana prapti" generally means to reach a state
| when nothing else matters ( you have disappeared sort of , but
| very very loosely )
| saberience wrote:
| The meaning of words changes and evolves over time. :)
| yakattak wrote:
| I always want to go this far with vim but I can't break just
| using the vim bindings in IDEs like IntelliJ or WebStorm. Is
| there any big reason for me to forsake a full blown IDE for vim?
|
| I still use vim for small stuff but for navigating commercial
| codebases I can't imagine not using a fully fledged IDE.
| code-blooded wrote:
| The advantage of (Neo)vim is that it lets you create a PDE
| (personalized development environment) [1] where you can
| customize every little detail to your liking easily [2] and as
| a result program and navigate at the speed of thought.
|
| It takes some effort and likely 20-30 plugins, but you get to
| learn a lot and IMO become a better programmer as a
| (unintended?) side effect. For me it's part of the continuous
| improvement to understand your tools.
|
| Last but not least it's just so much joy when you can envision
| a certain feature (e.g. I wanted to have a function header
| visible in the first line of editor even when the top of the
| function has scrolled off the screen) and either find a plugin
| or program it yourself. This is exactly the kind of primal joy
| that initially made me pursue the career of software engineer.
|
| [1] The concept of PDE is explained in this video:
| https://youtu.be/QMVIJhC9Veg [2] Easily is relative. IMO each
| little customization is quick, but you'll end up customizing
| hundreds of things over time.
| endorphine wrote:
| > e.g. I wanted to have a function header visible in the
| first line of editor even when the top of the function has
| scrolled off the screen
|
| This sounds super-useful. Do you mind sharing how you
| achieved this?
| lancebeet wrote:
| There are a couple of plugins that do this.
|
| For vim: https://github.com/wellle/context.vim
|
| For neovim (much higher performance in my experience):
| https://github.com/nvim-treesitter/nvim-treesitter-context
|
| I believe there's now also a VS code plugin for the same
| behavior, but I don't know what it's called.
| ndand wrote:
| > I believe there's now also a VS code plugin for the
| same behavior, but I don't know what it's called.
|
| It's called "sticky scroll". It's a relatively new
| feature of VS Code.
| pjot wrote:
| It actually ships with vscode!
|
| https://code.visualstudio.com/updates/v1_70#_editor-
| sticky-s...
| code-blooded wrote:
| Sure thing! https://github.com/nvim-treesitter/nvim-
| treesitter-context is what I use nowadays. It has a little
| clip demonstrating how it works so you'll instantly know if
| you want it or not ;)
| firstSpeaker wrote:
| Do you by any chance have your whole config shared somewhere?
| SuperCuber wrote:
| You didn't ask but here's mine
| https://github.com/SuperCuber/dotfiles/tree/master/nvim
|
| I just finished refactoring and dusting off my config with
| a structure similar to this video
| https://www.youtube.com/watch?v=w7i4amO_zaE
| code-blooded wrote:
| https://github.com/mateuszwieloch/dotfiles/tree/master/.con
| f...
|
| I'm rewriting it to be 100% Lua at the moment. It's 80%
| done and I've just pushed it for you. Take a look at the
| init.lua and ignore init.vim which is going away and is in
| a messy transitional state. The only thing that's missing
| in the Lua config is LSP integration, but that should be
| done by tomorrow as well.
|
| Edit: Just remembered that the Lua version also has no
| plugin manager, but there's plugin-install.fish script that
| just clones plugins into the correct folder, which works
| for now. I'll probably add lazy.nvim plugin manager in the
| upcoming weeks as well ;)
| firstSpeaker wrote:
| Thank you. It is 404, probably the repo is not public?
| code-blooded wrote:
| Whoops! Making it public right away :)
| tipsytoad wrote:
| I jump between neovim and vscode with neovim every few months.
| Neovim can be faster and more scriptable but vscode _just
| works_.
|
| If you start using Neovim know you'll be spending hours
| breaking and updating your config to reach "vimvarna". Let me
| know if you ever get there ;) you can enjoy the journey getting
| close to perfect just for something else to break the next day.
|
| It is crazy to me people try to shoehorn jupyter notebooks and
| debugging into Neovim, if you haven't try the jupyter notebook
| extension in vscode, will make you reevaluate your life choices
| code-blooded wrote:
| Yes it takes quite a lot of effort to get there. Vim motions
| take weeks to become your second nature, and then you'll
| probably spend 20-50hours finding plugins and configuring
| Neovim until you reach the Vimvarna. That's a ton of effort,
| but like I explained in the other post, I found it being both
| fun and making me a better programmer as an unintended side
| effect.
|
| Breakages are rare though especially if you use a plugin
| manager that shows you commits from your current versions of
| plugins (e.g. lazy.nvim [1]) so that you can see if you need
| to update anything.
|
| [1] An example of lazy.nvim plugin update experience:
| https://user-
| images.githubusercontent.com/292349/208301737-6...
| lycopodiopsida wrote:
| IMO, not a big deal if you have fun while doing so. I still
| have to finish elden ring and have already played for 105
| hours. 50 hours for Vimvarna are nothing and a time well
| invested :D
| christophilus wrote:
| My journey was VS to VS Code to Neovim. I can't see myself
| going back. Maybe if I went back to writing C# on Windows, but
| as it is, TypeScript on Linux is just fine with Neovim, and I
| don't find myself missing anything.
|
| When I leave Neovim, everything else seems slow and frustrating
| by comparison. If anything, _that_ is the reason to avoid it.
| It ruins a bunch of subpar editors for you.
| ansc wrote:
| There's a Vim keybinding plugin for Jetbrains products which I
| can highly recommend. I fully agree -- even as a Vim aficionado
| the productivity of these big IDEs is impressive. Without Vim
| keybindings I'd have a harder time justifying it though.
| cocochanel wrote:
| I moved to WebStorm/IntelliJ after many years of working in vim
| and neovim, fully loaded (LSPs, telescope, nvim-dap, coc.nvim,
| 20 other plugins), and I find JetBrains IDEs to be just much
| more intelligent, come in a single well integrated package
| including impeccable git integration, refactoring capabilities,
| and debugging experience (with the last two being particularly
| important and vastly superior to neovim). Vim is just not worth
| it IMO unless it is for fun, I used it mostly because it was
| fast to open, made me feel in control and I enjoyed fiddling
| with and configuring software to my own liking.
| sph wrote:
| Indeed, vim is a great text editor, but a mediocre IDE
| framework (adding Lua on top won't change this fact)
|
| Emacs is a great IDE framework, but a mediocre editor (compared
| to vim keys and modes, and IMO evil only helps somewhat)
|
| One day someone will be blessed by the Buddha himself, and will
| go on to create an Emacs clone running on a Lisp with native
| and default support for a modal editing system. The whole of
| humanity will enter nirvana, ending the infinite cycle of
| reincarnation^Hreinventing the wheel.
| ykonstant wrote:
| I stand behind this message 1000%.
| lawn wrote:
| With extensive use of plugins and configuration (especially LSP
| servers) you can get very close to an IDE experience, and many
| people including me use it to navigate commercial codebases
| just fine.
|
| It depends a bit on what language you use, but people who claim
| (neo)vim is a bad IDE are IMO wrong.
| eric-burel wrote:
| No I've tried a few times and it's not realistic especially
| since VS Code
| animal_spirits wrote:
| The VSCode Neovim plugin works with the Jupyter plugin for VS
| Code. So you can use your favorite editor inside Jupyter inside
| VSCode without having to change windows at all. It's a breeze
| kimukasetsu wrote:
| I have a similar setup with Emacs + Evil + Poly + Quarto Modes.
| Evil for vim keybindings, Poly to read cells as buffers and
| Quarto as a superior alternative to Jupytext [1].
|
| [1] https://quarto.org/
| omrjml wrote:
| This sounds interesting. Would you mind sharing how exactly you
| have this setup?
| synergy20 wrote:
| I'm a vim user and wondering if neovim worth a try these days, so
| far vim does everything I needed.
|
| for jupyter in vim I do think vscode has some edge, it can show
| the output(i.e. graphs) right inside without a browser.
|
| plus jupyterlab has vim mode to get by.
|
| will find sometime to see if these steps can be converted to vim.
| Tmpod wrote:
| If vim is working well for you, I'd say not to chase neovim,
| unless you feel like trying something new. Moving to nvim is
| pretty straightforward, but more and more stuff is expected, in
| a way, to be configured through Lua. That's nice, but it is a
| change from vimscript which you may not want to make.
|
| Neovim has a _lot_ of momentum going and high quality (and fast
| /light) plugins, in part due to Lua, but also due to the ever
| growing integration with modern editing and software
| development tools like TreeSitter and LSPs. It's a really nice
| ecosystem, where you can find pleasant plugin surprises almost
| every week. I really like it, but if you fancy a more stable
| and battle-tested system, vim may still be more appealing. Or
| neovim with just classic vim plugins.
| bastardoperator wrote:
| I bounce between vscode and neovim, I use the
| https://github.com/AstroNvim/AstroNvim config. I prefer nvim
| now.
| deliriumchn wrote:
| I tried to get into vim countless times but every single time I
| fail because I already remember intellij keybinds and feel myself
| helpless without webstorm interface/ide functionality (where
| everything is included by default and works great with
| ts/react/solid).
|
| I respect people who can and love to use it, but its simply not
| for me
| zamalek wrote:
| The biggest advantage of vim is the movements (key bindings),
| and there are plugins for many editors for that, e.g.
| https://github.com/JetBrains/ideavim
| joouha wrote:
| If people are looking for a more JupyterLab like environment for
| the terminal, you could try euporie [1] (I am the author).
|
| It supports vim and emacs style key-bindings, and can display
| rich cell output like images and widgets.
|
| [1] https://github.com/joouha/euporie
| synu wrote:
| Vim enlightenment for me was learning to use it with all the
| default settings. Everywhere I go, it's already set up just the
| way I like it.
| juped wrote:
| Now remove the silly "m" and use generic system vi!
| adlpz wrote:
| This also makes it easier to use the _vim keybinding_ you find
| in many IDEs, as you are not relying on more arcane or
| customized bits of vim itself, but the general concept and
| common idioms.
| exegete wrote:
| I'm at this point. Learned vim in grad school where I was
| ssh'ing into systems all the time. I tried a variety of plugins
| but none of them have stuck for me. Now in industry everyone
| uses VS Code or something like it and I just can't get into it.
| Everything I need to do is on the command line (git, run tests,
| etc). Having been a Linux-enthusiast for quite some time helped
| me with needed command line tools as well (now I'm using a Mac
| at work, which is similar enough where it matters).
| bkirkby wrote:
| I stick with regular vi for a very long time because of this. I
| was a systems consultant way back when and I'd have to work on
| several variants of unix that had a mich-too-long lag time on
| getting vim ports. Iirc, sparc was the unix that took the
| longest in getting a gnu tools pipeline, so once they had vim
| and I could reasonably expect most of my customers could
| install it, I switched.
|
| I now do a pretty standard config (mostly use the vim plugin in
| VSCode since I'm a software dev nowadays).
| osigurdson wrote:
| I do wish the defaults were better however. The following
| changes help a lot.
|
| set tabstop=3 set shiftwidth=0 set autoindent
| rectang wrote:
| I persisted with this approach for a decade. Enlightenment came
| when I let it go.
|
| Even after 10+ years of daily use, I never managed to make
| navigating via hjkl work naturally with my brain -- I need "up"
| to be physically above "down". So I set up key bindings for the
| classic "inverted T" formation, dealt with the secondary
| effects, and I'm much more comfortable.
| https://github.com/rectang/dotfiles/blob/30e0a41714c34416f10...
|
| Dare I say I use vim more like it was intended to be used with
| this new setup, as my right hand remains in place and is not
| constantly flying to the arrow keys and back.
|
| Now I struggle a bit when I have to work on a stock vi, but
| that's a very small part of what I do.
| fowlie wrote:
| Ever since I learned how to use the Miryoku layout, I've been
| using vim with the hjkl navigation-keys shifted one position
| to the right. Those are also my arrow keys on a separate
| layer in the keyboard firmware. And I never looked back, this
| is how it really should be!
| dmix wrote:
| I use hjkl to scroll 90% of the time when using my browser.
| Having it on the middle of the keyboard where your hand rests
| make a lot more sense to me than weirdly angling your hand at
| the bottom right of my MacBook.
| BeFlatXIII wrote:
| I just wish hjkl scrolling worked for those of us who do
| not use QWERTY
| Taywee wrote:
| I used hjkl scrolling for about a decade with Dvorak. In
| fact, I learned to use Vim for the first time on Dvorak.
| The muscle memory makes it work just fine, even when not
| all the keys are on the home row.
| yjftsjthsd-h wrote:
| It, um, _can_ , but you have to kind of not pay attention
| and pretend that the letters are somehow important and
| ignore what your fingers are actually doing on the
| keyboard. At least n=1, my brain was willing to accept
| that j=down and k=up and not worry about the fact that
| they're not even next to each other. That said, if I
| could go back in time I would tell my younger self to
| either use vi/m or non-qwerty, but not both.
| camel_Snake wrote:
| I found this forced me to use vim's natural language more
| rather than relying on hjkl for the majority of my
| navigation, since it was ergonomically uncomfortable and
| I wanted to preserve vim's mnemonics by not rebinding.
| roland35 wrote:
| Totally agree. Although wherever I go, I map "jk" to <ESC>
| since I find that so much easier to enter Normal Mode.
| synergy20 wrote:
| kj for me,thats all i need on servers
| vaylian wrote:
| Let me introduce you to ctrl+c which is the same as <ESC> in
| most cases (notable exception: visual selection mode)
| czx4f4bd wrote:
| Ctrl+C requires taking your fingers off homerow and
| pressing two keys at once, though.
|
| Granted, escape also meets those criteria if you map it to
| the caps lock key, which I do. The jk mapping is still
| useful in the rare occasions I use vim on my phone, though.
| robervin wrote:
| I remap caps lock to ctrl on my OS which does make it a
| little more ergonomic, but I still prefer your method.
| Although, whatever wizard taught me vim and gave me their
| beginner cheat sheet had jj instead of jk.
| cassepipe wrote:
| +1 for remapping Caps Lock to Esc. It is easily done in
| GUI settings in both MacOs and most Linuxes and it is
| quite useful to have it there OS-WIDE. In the rare cases
| I need to Caps Lock it is still available by pressing
| both shift together (there are various Linux options
| around that) I never bothered to have it map to Ctrl on
| holding the key in addition of Escape on pressing but it
| is easily done. There's at least on blog post about that
| if you search HN
| sodapopcan wrote:
| ctrl-c is _not_ the same as escape. ctrl-c doesn 't trigger
| the InsertLeave autocmd or abbreviations. This may not
| matter to everyone but it's worth being aware of.
| fsh wrote:
| ctrl+[ is identical to <ESC> and much easier to reach.
| zhengyi13 wrote:
| In my case, I agree, but when I asked about this key
| combo once elsewhere, a number of folk pointed out that
| this is true for the standard US QWERTY layout, but not
| necessarily so for various EU or other layouts.
| godelski wrote:
| How do you program if you have a hard time accessing
| array elements?
| bitofhope wrote:
| AltGr+8 is reasonable enough that I don't feel like
| learning a new layout.
|
| Ctrl+AltGr+8 is involved enough that I might as well
| press Esc.
|
| A lot of software developers are unaware of the AltGr[1]
| key or even assume US ANSI layout altogether so as a user
| I have been trained not to take keybindings involving
| that layer for granted.
|
| As a real world example of similar issues, there's piece
| of software (I think it was telnet or mosh, but I
| apologize if I misremember) where Ctrl+^ is used as an
| escape sequence. This doesn't work for me, possibly
| because caret is a dead key[2] on my keyboard. For some
| reason, perhaps related to using scancodes instead of key
| codes, Ctrl+6 happens to work in that application.
|
| [1] https://en.wikipedia.org/wiki/AltGr_key [2]
| https://en.wikipedia.org/wiki/Dead_key
| roland35 wrote:
| That's what I love about vimmers. We all have our
| preference on something as simple as what the escape key
| should be :D
| LAC-Tech wrote:
| Good for you - I always get stuck wish LSP. ALE almost works,
| except for the settings it ignores.
| maCDzP wrote:
| Bums me out that the title was isn't "Vimvana".
| martinskou wrote:
| Yes, lost opportunity. Like COVID which should have been named
| KungFlu.
| notpachet wrote:
| Nirvimna, surely...
| [deleted]
| wcrossbow wrote:
| I'm sorry. Now that I know it bum's me too to not have reached
| for the pun :(
| eric-burel wrote:
| All apologies
| ISO-morphism wrote:
| I use a similar setup in Emacs with code-cells.el [1]. VSCode had
| a tendency to choke rendering large _interactive_ graphs in-line,
| so if I was needing to view in a separate process anyways a
| little elisp turns "write last IPython output to a tempfile,
| open, move to workspace N" into a keybind.
|
| Edit: browser-based Jupyter would also fall down here as the
| penalty for a graph being too big is at least a kernel restart.
|
| [1] https://github.com/astoff/code-cells.el
| eric4smith wrote:
| Default Vim is best.
|
| Actually just editing/copy/paste/delete is more than enough for
| 99% of uses cases.
|
| I been using vi since 1982 and vim now. No need for anything
| else.
|
| No plugins. Nothing. Just vim.
| Congeec wrote:
| This can be further extended to show plot images if the author
| decides to render repl outputs in a separate terminal (or a tmux
| pane) instead of a vim window.
| 127 wrote:
| I have learned Vim and tried it out. Still using Vscode. Don't
| understand the appeal. As long as you make some additional
| keyboard shortcuts for movement in Vscode, I really doubt you can
| go much faster with Vim. Plus I'm using about 100 plugins in
| Vscode and all the niche platforms don't have Vim addons for
| them. Domain specific plugins really make Vscode irreplaceable.
| shriek wrote:
| The appeal is it's hackable. Top to bottom. Pretty sure VScode
| is too but you can literally just write functions and get vim
| to do the things you want it to.
| jerpint wrote:
| VScode vim emulation is great!
|
| But when you just want to fire an editor to do a quick change,
| vim is your friend. It's also reliably present on almost any
| server you'll ssh into
| inDigiNeous wrote:
| Big part of the appeal is keeping your hands on the home row
| all the time, without having to reach for the arrow keys. HJKL
| for movement makes all the difference for keeping focus on the
| writing, not having to reach out to the arrow keys when wanting
| to move or communicate motion.
|
| This combined with the excellent text manipulation features
| right there from the keyboard, without leaving to menus, being
| able to just flow with the Vim -keybindings, and in all
| different IDEs and editors that support Vim -support, it's just
| great.
| GaryPalmer wrote:
| It's great for a command line editor. I don't know why anyone
| would use it in a desktop environment though.
| anthomtb wrote:
| Interesting. If you swap VScode and Vim in this post, you come
| up with my reasoning for not using VScode.
|
| (Full disclosure- I never write JavaScript).
| linsomniac wrote:
| Sounds like VSCode is working great for you, no reason to
| change. Especially as, if you ever decide you want to use modal
| editing, there's a VSCode plugin for that.
|
| But, since you mention it, there are a few things that appeal
| about vim. For me, personally, I am quite often working on
| remote systems from the command line. Being able to "vi
| filename" and make some changes and get back to the command
| line is important and VSCode doesn't seem to work for that. I
| know it has remote editing, but navigating over there from Code
| isn't worth it when I can just "vi filename".
|
| A significant part of the appeal is the modal editing, which as
| I mention above is available in Code.
| LinXitoW wrote:
| I think one good analogy to why vim is great is to examine
| other tools everyone already uses.
|
| Imagine instead of pressing backspace to delete a character,
| you would have to delete the individual bits that make up the
| character. A character is just an abstraction of bits, that
| your text editor/IDE takes care of for you so you don't have to
| think about it.
|
| Vim is also an abstraction, making it similarly far more
| convenient than doing everything by hand. Think about it: Is
| "forward 2, backspace 5" or "delete this word" a more natural
| abstraction?
|
| So what's the advantage? Speed, but not typing speed. It's
| about the mental distance between the model in your head of
| what you want to happen (delete everything between the parens)
| and the model your tool understands (go forward some words, go
| forward 1, delete backwards 20). Since speed = distance per
| time, reducing the mental distance increases mental speed.
|
| And that therefore uses less mental energy on translating for
| your tool, and leaves more room for doing hard mental problems,
| like fixing a bug.
| et1337 wrote:
| In my book, it's way better to install one Vim extension in
| whatever your favorite IDE is, than to install Vim with a hodge
| podge of 5 extensions and 300 lines of Vimscript. The keybindings
| are really the unique selling point of Vim, and you can get them
| anywhere.
|
| I actually view this as another advantage of Vim; you don't have
| to learn new keybindings every time you switch editors.
| lanza wrote:
| > The keybindings are really the unique selling point of Vim,
| and you can get them anywhere.
|
| How you know somebody doesn't have a clue what they are talking
| about.
|
| That's like saying "chess is a bunch of nerds playing chess
| with more pieces."
| melony wrote:
| Evil, VsCodeVim, IdeaVim are all faithful reproductions with
| thorough coverage of the typical text editing use cases.
| yakubin wrote:
| Which of them understand what gn and cgn are supposed to
| do?
| azeirah wrote:
| Evil and ideavim both do, haven't tested vscodevim
| bobbylarrybobby wrote:
| Even better, use Neovim's server mode in your IDE, since then
| you're getting "real " vim, not just a plugin that attempts to
| copy it.
| ericpruitt wrote:
| > The keybindings are really the unique selling point of Vim,
| and you can get them anywhere.
|
| This is going to vary heavily from user to user. I'll admit
| it's been some years since I last tried anything new, but I
| never found Vim keybindings that were complete and configurable
| enough to comfortably replace Vim. It's always more like a UI
| uncanny valley in that the keybindings are relatively close,
| but imperfect enough that they interfere with my typical
| workflow.
| parham wrote:
| I would say that's making the assumption that IDE is actually
| bound to the key bindings in a useful way (e.g. file exploring)
|
| I have yet to find an IDE that has integrated well with key
| bindings.
| imbnwa wrote:
| Eh, I've never run into a vim emulator that didn't do something
| I used or the surrounding environment made it a hassle to
| integrate deeper. Vim is the entire runtime that also
| integrates with the Unix command line
| anonporridge wrote:
| Don't forget the browser.
|
| Vimium radically improved my entire web browsing experience. I
| can't live without it anymore.
|
| https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/
|
| https://chrome.google.com/webstore/detail/vimium/dbepggeogba...
| hansvm wrote:
| Qutebrowser is worth a mention too. Google has sufficiently
| neutered extensions that I fell out of the flow pretty often
| with Vimium (e.g., can't work on any of the built-in pages or
| some other Google properties), but having chrome exist at a
| much lower level and building the UI around vim bindings has
| made it a 10x better experience for me in Qutebrowser.
| d0mine wrote:
| There is `--extensions-chrome-urls` command-line flag
| (Chrome shows a scary warning, it works otherwise).
| photonbeam wrote:
| The set of permissions needed is somewhat concerning
| behnamoh wrote:
| I used Vimium for years until I discovered SurfingKey, which
| offers way more features.
| cassepipe wrote:
| And with the Firenvim extension you can run a neovim instance
| in any text area! (Currently typing this inside neovim
| _inside_ my browser)
| fuy wrote:
| Definitely agree. I've been trying to go full-Vim a few times
| over the years, and it's not been very successful. I'm a huge
| fan of Vim keybindings though, and wouldn't use an editor/IDE
| without support for it.
|
| I would say that going 100% Vim is reasonable if you have a
| very stable development stack/environment. You spend a few
| weeks (or months, which is more realistic IMO) setting things
| the way you like and then use the setup for years.
|
| If you work in several different languages, connect to several
| different databases, and also like to play with other tech
| stuff, VS code (and/or JetBrains products) with Vim bindings is
| usually more ergonomic. Both VS code and JB have very nice Vim
| plugins, so you get like 80% of Vim power + a lot of polish and
| modern tooling from VS code/JB.
| ravishi wrote:
| I've started full-vim and eventually settled for exactly
| that. It's been a success. Recently had to work from Windows
| after years on Mac, also using VSCode after years of Intellij
| and it wasn't a big deal because the Vim experience was
| mostly on par between Intellij and VSCode. I still prefer
| Intellij, but the remote coding (over SSH) experience on
| VSCode is just so much better.
| weaksauce wrote:
| there's also neovim extensions for vscode which uses neovim
| as the "server" so to speak that does vim things and then
| updates your vscode. in practice it works very well...
| especially the more recent updates to it. just have to have a
| neovim binary installed somewhere and point the extension to
| it.
| andreyk wrote:
| Personally I like Vim because I do a lot of coding while in an
| SSH session and it's easy to port my setup very quickly. My
| work involves using a workstation with a GPU so I am not able
| to do that at home, and debugging requires me to run things
| from command line a lot to know what to change in the code. No
| doubt I could create a set up with a fancier IDE to do that,
| but at the scale I'm working in (academic code with just 1000s
| of lines of code) there is really no need.
| jdrek1 wrote:
| You could also use VS Code's remote (over SSH) ability.
| ftufek wrote:
| You can do the same with vscode btw. I also work on remote
| gpu workstations and vscode remote with ssh works just fine,
| especially if you use tmux, you can preserve all the history
| and what you were doing.
| inDigiNeous wrote:
| The Vim enlightenment for me, was to let go of Vim. Modern IDEs
| with Vim support: bless you. XCode got finally Vim -keybindings
| also. CLion and other IntelliJ -ides have great Vim support,
| VSCode also.
|
| Sometimes I still use Vim only when editing some old school stuff
| or just simple files though, for my development journals I still
| always use Vim.
| [deleted]
| inductive_magic wrote:
| I just use vim bindings as a jupyter extension. That way we can
| collaborate via `jupyter lab --collaborative` and have plots
| rendering directly under cells. You can hack plot visualization
| into terminals, but at that point something feels off to me.
___________________________________________________________________
(page generated 2022-12-27 23:02 UTC)