[HN Gopher] Helix: a post-modern modal text editor
___________________________________________________________________
Helix: a post-modern modal text editor
Author : bpierre
Score : 354 points
Date : 2021-06-01 17:48 UTC (5 hours ago)
(HTM) web link (helix-editor.com)
(TXT) w3m dump (helix-editor.com)
| rhabarba wrote:
| Looks like a confusing mix between BRIEF (which I like) and micro
| (which I like).
|
| However, I'm afraid that there is no niche to be filled by yet
| another text editor.
|
| (Also, even though I'm an Emacs and Acme user, the assumption
| that VimScript is bad for the battery is... weird. Mind to
| elaborate?)
| yur3i__ wrote:
| >an acme user
|
| Now there's a rare breed
| rhabarba wrote:
| Please do not hunt us for our teeth!
| lefrenchy wrote:
| I think that's more directed at Electron than VimScript.
| cestith wrote:
| I take slight issue with the joke around "postmodern". Modernism
| and postmodernism are actual things. Modern means a new way to do
| something without much influence from the older ways. Postmodern
| means looking at multiple ways something has been done over time
| then extracting and combining a sets of the good ways from any
| time and tradition into a new, workable whole.
|
| Saying something is postmodern because it came out after
| something modern cheapens the word.
|
| What I really want from another Vim replacement is why it's
| better than neovim, not jokes about usurping Vim at the expense
| of the English language. I think that's presumptuous at best and
| I don't find it very funny to claim to be better because it's
| newer.
| wodenokoto wrote:
| Do you have sources to back up those definitions? The Oxford
| dictionary on my iPhone don't really agree with your assessment
| and Wikipedia considers postmodern a specific period in time
| (mid to late 19 hundreds)
| zeendo wrote:
| | I don't find it very funny to claim
|
| Sorry, trying to make sure I understand. Am I to read this as
| saying you do find it somewhat funny but not very funny?
| throwamon wrote:
| It's a joke. Such is the nature of jokes: not taking it
| seriously.
| coldtea wrote:
| > _Saying something is postmodern because it came out after
| something modern cheapens the word._
|
| Well,
|
| (a) it's meant as a joke.
|
| (b) it's not such a great word for us to care about
| "cheapening" it. It's not like "postmodern" is a word loaded
| with valor, like "freedom" or "justice" or some such for
| example.
|
| (c) Actually neither modernism nor postmodernism mean what you
| wrote as they are canonically defined. Modernism is a specific
| early to mid 20th century movement in arts, design, literature
| and so on, and postmodernism is another one (mid to late 20th
| century, the term started from architectural critique and moved
| to philosophy and aesthetic discourse to general use), with a
| quite specific context and history.
| gaoshan wrote:
| This was my observation before actually reading the post... a
| reaction to the title. If you visit the actual site you will see
| that the author points out that the use of "post-modern" is
| intended to be a joke (which I quite like, lol): From an art
| perspective "postmodern" would be something that challenged the
| concept of modernism. That would be work based on idealism and
| reason vs that based on scepticism and suspicion of reason. Since
| that doesn't really apply to this editor perhaps this editor is
| simply a modern editor?
| beepbooptheory wrote:
| just a nit-pick but I would push back on the notion that the
| only thing that came to challenge modernity was neo-Idealism,
| neo-Rationality. I have never seen any one really define post-
| modernism that way, and in fact such things are just as
| challenged by postmodernity! Postmodernity is first and
| foremost a loose collection of tendencies post-WWII. I also
| agree its cute that its a little joke.
|
| maybe something that makes/or would make it a true PoMo editor
| is an effort in juxtaposing modern vscode-IDE stuff onto an
| older terminal aesthetic
| dicroce wrote:
| Does Helix run on windows too?
| m1cl wrote:
| How can I use LSP?
| flakiness wrote:
| This seems something I can love, will give it a shot.
|
| I switched from Emacs to VSCode but occasionally misses the
| editor-in-the-terminal-without-project-setup. I use vim when I'm
| forced by, say git, but I can barely copy-n-pate and undo, and I
| have no desire to learn the decades old tool. It's too anti-fancy
| to spend my precious spare time.
|
| As a backup, I'd love to hear how to learn vim as a something
| modern and fancy. I'm happy to be convinced.
| vbsteven wrote:
| In my opinion the only way to learn vim is to fully commit to
| it: Use it as your only editor and every time you hit a wall,
| spend the time to learn and unblock yourself. Productivity will
| take a serious hit for weeks, likely months.
|
| I did this 10 years ago and never looked back. Although in the
| last years I have evolved to an 80/20 JetBrains/vim split.
| Using the excellent IdeaVIM plugin to bring all my vim skills
| and configs to a full IDE.
| juniperplant wrote:
| What do you think about using vim emulation in VSCode?
|
| For me it seems impossible to be productive without the
| ecosystem of extensions VSCode provides.
|
| I am intrigued by the power of modal editing, but going all-
| in vim seems a step back with regard do "modern" development
| workflows.
|
| In vim it appears you have to configure every piece of it
| from scratch, while in VSCode if you pick a new language it's
| usually enough to install an extension and you're good to go.
| vbsteven wrote:
| I suppose vim emulation also works if the emulation plugin
| is good.
|
| The point is to make the switch and stick to it even though
| you will be slower for a while. And spend the time to look
| for better approaches when you feel like you are repeating
| yourself. (Just like you get that DRY itch to refactor when
| repeating the same code snippet a few times)
| jbverschoor wrote:
| I'm happy with VScode, but lately I'm starting to want text-mode
| UI. More grid, one font, less colors, no icons. Not just for my
| text editor, but for everything.
|
| I don't want everything to look like a glossy magazine. Norton
| commander, power menu, borland c.. Just let me focus on some
| text.
| mxuribe wrote:
| I've had a similar desire recently...my reason is because
| regardless of the power of my desktop machine, I've grown
| impatient waiting for applications to load...but I encounter no
| such issues with apps that employ more text-mode UIs. TUIs - in
| my mind now - are a godsend; ironic that they're considered a
| "throw back" to "the older days of computing".
| agumonkey wrote:
| borland TUI was so neat
| bern4444 wrote:
| That's exactly why I really dislike a lot of IDEs and editors.
| I've been using (n)vim for 3+ years now as my main editor.
|
| A big value of (neo)vim is the lack of clutter and how easy it
| is to bring up and hide windows/buffers when I need them.
| Editors like VSCode and IntelliJ are just too noisy and gets in
| the way of the actual coding.
|
| I know they can all be customized and configured to reduce this
| issue, but even then it still feels more visually cluttered and
| those windows usually end up coming back somehow.
| groby_b wrote:
| I'm intrigued (because I like to see experiments in the modal
| editing space), but I'd really appreciate a "why" section.
|
| The editor space is crowded, and I like understanding which pain
| points new ones address. I mean, "neovim, but in Rust" is a
| perfectly valid decision, but is it the only reason? It looks
| like this might be an ongoing experiment for the author? (See
| also the github remark on alternate renderers)
| belharius wrote:
| One day there will come an editor which has alternating line
| color theme by default - I hope. Never mind that. I hope they
| won't forget to add 'read from stdin'.
| PaulDavisThe1st wrote:
| That first trick in the video - select some text, do multi-site
| replacement - how do I do this in Emacs (35 year user, but have
| no idea :)
| natrys wrote:
| There is multiple cursors[1]. Checkout the video by
| emacsrocks[2]. You can combine that with regex tools if you
| need to do this over complex patterns[3]. There is also iedit
| which may fit your mental model better[4].
|
| [1] https://github.com/magnars/multiple-cursors.el
|
| [2] http://emacsrocks.com/e13.html
|
| [3] https://github.com/benma/visual-regexp-steroids.el
|
| [4] https://github.com/victorhge/iedit
| arc-in-space wrote:
| https://streamable.com/t4i5tx
|
| The highlights and fancy replacement preview are added by a
| plugin called anzu[0], but otherwise this is a standard emacs
| feature. I couldn't tell you what the default binding is but
| the function is query-replace-regexp.
|
| (I don't understand why people are trying to bring multiple
| cursors into this)
|
| [0] https://github.com/emacsorphanage/anzu
| jimm wrote:
| If you select a region with transient mode on, then `query-
| replace` (`M-%` by default) will only affect the region. So
| select the region you want the change to effect (just like in
| the demo video), hit `M-%`, then type the old and new text,
| then you can type `!` when prompted for what to do and all
| instances of old become new only within the region.
| TedDoesntTalk wrote:
| What exactly is post-modern about this? Perhaps the author means
| 'retro'.
| IncRnd wrote:
| > What exactly is post-modern about this? Perhaps the author
| means 'retro'.
|
| That's the absolute first question answered on the linked page.
| FAQ Post-modern?! It's a joke. If neovim is the
| modern vim, then helix is post-modern.
| CyberDildonics wrote:
| I don't know why people put up with this stuff. With something
| like this it is just a nonsensical joke to make a clickbait
| title that immediately gets walked back.
|
| I never thought people would adamantly defend links like this -
| "sure they made up something that makes no sense, but they back
| peddle once you click the link"
|
| Not only that, this isn't even a text editor, it is a front end
| for neovim.
| bovermyer wrote:
| "Front end for neovim?" Perhaps you should read the source
| code before saying such things.
| IncRnd wrote:
| > Not only that, this isn't even a text editor, it is a front
| end for neovim.
|
| Why do you believe this is a front-end for neovim and not a
| text editor?
| bern4444 wrote:
| Its funny and pokes fun at the larger conversation but I hear
| you.
|
| Though I think its fair since neo vim is referred to and
| means new vim. The author here likely believes helix to be
| more modern than neo vim hence, post modern.
|
| Whatever, I'm sure you understood that. I enjoyed the humor
| and think its fair
| frob wrote:
| The author answers this directly on the page:
|
| > Post-modern?!
|
| > It's a joke. If neovim is the modern vim, then helix is post-
| modern.
| habitmelon wrote:
| Multiple selections as a language primitive feels like a language
| smell. Why use languages with that much redundancy in their
| syntax?
| qwerty456127 wrote:
| Multiple selections is what makes an editor modern. An editor
| which can't do that easily feels obsolete.
| xaduha wrote:
| Onivim 2 is getting there. Version 0.5.5 was released two months
| ago, 0.6 would be worth taking a look at
| https://v2.onivim.io/#timeline
|
| It's a main contender for me to replace VSCode, whereas this one
| doesn't look that enticing. I want a terminal in my editor, not
| an editor in my terminal, had enough of that.
| stanislavb wrote:
| Is it any good?
| cbsmith wrote:
| There's a lot of this I like, but I'm kind of scratching my head
| about the central design feature being "multiple selections by
| default". I never even gave Kakoune a shot, because in general
| multiple-selections just didn't seem like a significant design
| advantage to me. If I'm doing a lot of multiple selection
| editing, I tend to think of it as a strong signal that my
| code/system has a design mistake.
| adamm255 wrote:
| That last part! Refactor time!
| SavantIdiot wrote:
| The FAQ made me chuckle, and then wonder what exactly a post-
| modern editor would look like? I guess if we deconstruct text
| editing, there would probably be one window filled with nothing
| but all the (non-uniquified) letters and characters you used,
| another with format rules, and another with a verbal description
| of your program...? Maybe? I'm no Derrida, so I'll defer to the
| philosophy majors.
| rosetremiere wrote:
| Looks neat! But I'm not sure I follow: what's LSP support like
| (say compared to coc.nvim)?
| hollerith wrote:
| Uses Kakoune, which uses ncurses.
| pvg wrote:
| In what sense does it 'use kakoune'? The page suggests some
| sort of design influence but the implementation is in a
| different language.
| hollerith wrote:
| I was probably mistaken: I probably misinterpreted, "Multiple
| selections by default, based on Kakoune."
| dmos62 wrote:
| I'd use this if I were starting out now (and wasn't accustomed to
| vim).
| linsomniac wrote:
| Lately I've been wanting to get out of the business of
| maintaining my own vim setup and just adapt to someone else's
| work. I'm in a state of never coming up with the time to really
| sit down and create a repeatable modern vim setup, but always
| feeling like I could be getting more. I've used vi for over 30
| years, FYI.
|
| Recently I've been playing with:
|
| OniVim2: I'm not really sure what enhancements it has, but it
| does have a standard setup. Unfortunately, I'm running into some
| problem with my setup losing Python syntax highlighting. The
| ability to use VSCode extensions seems like a real winner, I've
| never been able to get into the weight of VSCode for my every day
| shell-oriented workflows. I don't program much, YMMV.
|
| The Amix "awesome vim" setup. It is, unfortunately, TOO awesome.
| I set it up and some of my first movement commands were bringing
| up plugins (Ctrl-N and Ctrl-F). Didn't try it very long, it was a
| bit too much of a departure.
|
| SpaceVim: I spent a while in this, it was working ok once I
| adapted a few things to it. It's a contender, probably behind
| Lunar.
|
| LunarVim+NeoVim 0.5: This is looking promising so far, only used
| it a bit. But the TreeSitter plus LSP seems like a winning
| combination! Plus it works in the terminal, which OniVim does
| not. I do a fair bit of my (limited) programming via ssh from a
| chromebook (my couch compuer).
| cryptonector wrote:
| Damn it, I want modal editing.
| bern4444 wrote:
| For the multiple selections feature, how is that different from
| vim's visual selection paired with additional commands?
|
| For example, in vim I typically visually select a block and then
| run :s/foo/bar or hit > to indent etc
|
| Is the flow on helix that different? Does it save a keystroke?
| dokem wrote:
| I used to use multiple cursors in sublime, but I do find vims
| find/replace syntax to be better. Paired with a macro that
| fills out most of the find/replace command for word under
| cursor, I find it fast and flexible.
| bern4444 wrote:
| The best part is, when you need to do that across multiple
| files that you can find with a :grep or :Rg command, its
| trivial. Populate the quickfix/location with grep (or ripgrep
| or silver searcher etc) and fire off a cdo with a
| :s/foo/bar/g and watch it run.
| GekkePrutser wrote:
| This looks really good. Especially the No Electron part <3
| 0xcoffee wrote:
| FYI I didn't see Windows support listed on the installation page
| (https://docs.helix-editor.com/), but it seems to be available on
| the releases (https://github.com/helix-editor/helix/releases)
| laszlokorte wrote:
| I get this error when trying to run the latest release on
| windows
|
| > thread 'main' panicked at 'index out of bounds: the len is
| 2856 but the index is 2856', helix-tui\src\buffer.rs:185:14
| msoad wrote:
| I never really felt faster eliminating mouse from my coding
| workflow. Point and click to navigate things is pretty powerful.
| Why some devs try to avoid the mouse?
| z3t4 wrote:
| I have always used a "gaming" mouse, eg. high precision, high
| refresh rate and super smooth, with a mouse mat with just the
| right amount of friction. It however broke a few month ago and
| I got a cheap replacement, since then I have been
| subconsciously avoiding using the mouse, because the experience
| with the cheap replacement mouse is so bad. So I think the
| reason people don't like using the mouse is because they don't
| have a good mouse and mouse pad, and because they haven't spent
| years playing first person shooters - making it possible to hit
| a spot on the screen with pixel-precision using just muscle
| memory...
| cvak wrote:
| Moving your hand from keyboard to mouse 1000 times a day is
| really good recipe for RSI. Ask yourself this question after
| doing this 10y+ in a row.
| Vhano wrote:
| omg I realized this recently after using Android Studio for a
| short while. Keyboard+mouse workflow is objectively horrible
| for the wrists. Unfortunately no other alternatives exist for
| these IDEs.
| brabel wrote:
| Android Studio is based on the Jetbrains IDE, IntelliJ, and
| you don't need the mouse to do anything with them. If you
| don't know how, I recommend you watch some guides on
| https://blog.jetbrains.com/idea/category/tips-tricks/ or
| find some presentations on Youtube (after I watched one
| many years ago, I've been feeling like I have superpowers
| and can do anything with a couple of shortcuts).
| hota_mazi wrote:
| Actually, that's not true.
|
| What causes RSI is mostly centered around tendon and their
| sheath tension.
|
| For example, if you use a straight keyboard (don't! Ergonomic
| all the way!) that is raised toward you as opposed to away
| from you, keeping your hands on that keyboard for multiple
| hours in a row without ever reaching for the mouse is pretty
| much guaranteed to give you RSI. Reaching for the mouse will
| actually bring relief to your tendons.
|
| Another keyboard habit that will put a great deal of stress
| on your hands and wrists is leaving the Control key at the
| bottom left of the keyboard. Typing a control key with this
| configuration will bring great stress on your pinky and other
| tendons in your hand.
|
| Recommendation: map Control on Caps.
| yw3410 wrote:
| One point to add to all of the great points here is
| consider getting a smaller keyboard (or an ergodox)
| especially if you're on the smaller side (for the same
| reason as the last point, stretching less tends to be nicer
| on the tendons).
| rajin444 wrote:
| This was 10 years ago, but I remember reading up and
| something with the forces enacted on your tendons moving
| the mouse around were exponentially worse than typing on a
| keyboard.
|
| I use a touchpad when possible knowing that, but I've never
| double checked myself. Anecdotally, I've only developed RSI
| in my mouse hand from gaming (same story for my friends who
| game as well).
|
| NHS seems to back this as well: https://www.nhs.uk/live-
| well/healthy-body/tips-to-prevent-rs...
| bernawil wrote:
| there's two things that make my hands cringe: drag-
| clicking (e.g drag file to trashcan) and mouse-wheel
| click (close chrome tab).
|
| I built a trackball into my split keyboard and now I move
| it with my right hand and perform al clicks on my right-
| hand side of the keyboard.
| littlestymaar wrote:
| I'm a mouse user, but moving you hands out of your keyboard to
| get to the mouse is annoying, and can cause shoulder strain.
| vbezhenar wrote:
| That's my main issue with terminal emulators. Why can't I click
| anywhere to put a cursor in there? Why can't I delete a
| selected text? Some hotkeys work as expected (e.g.
| Ctrl+Delete), but others don't (e.g. Ctrl+Backspace). Those are
| simple things from a user standpoint. Terminal could be so much
| more usable. I'm not even talking about integrating real GUI
| into terminal, for example pressing Tab should open dropdown
| list, not emulate it with text.
| SpaceNugget wrote:
| You can use the mouse to select things in the terminal. In
| vim/neovim `:set mouse=a` and you can scroll around, select
| things and move the cursor just like you can in a regular GUI
| editor.
| kbenson wrote:
| Thanks for this, you finally got me to look at the mouse
| options in vim, which I've always preferred off, as it's
| extremely annoying when using multiple windows and a click
| to focus window manager (like explorer, for the most part)
| when it places me somewhere else.
|
| Now that I know how to enable it for specific modes, I'll
| definitely be using it for visual mode, and maybe insert
| mode (we'll see how much that annoys me). Now I'm off to
| see if I can get the mouse wheel to work at all times but
| click to place cursor off except when I want it, which
| would be ideal.
| glaukopis wrote:
| I'm always a bit disappointed that people making the case for
| mouse-lite workflows stop at "it makes you faster." In many
| cases, this is patently false at a global scale - I've been
| using Emacs for a month and I'm certain that I've already spent
| way more hours customizing and researching than I'll ever make
| back from saving a couple deciseconds every time I use a
| keyboard shortcut instead of a mouse.
|
| For me, using Vim keybindings and Emacs shortcuts is valuable
| because reaching for a mouse or navigating menus adds mental
| overhead. I view the moment-to-moment practice of programming
| as largely being an exercise in working memory. You're trying
| to hold an abstraction in your head and implement it in an
| existing codebase that's filled with other abstractions and
| interacting parts. Personally, removing a mouse from my
| workflow does wonders for ensuring that all my mental resources
| are dedicated to the task at hand. Going mouse-lite might save
| a trivial amount of time in the moment, but (for me) it makes
| programming more seamless and natural - which makes it not only
| more fun, but more productive.
| tartoran wrote:
| To add to this, some shortcuts favorite to some users are
| used millions of times. Think of all that mental overhead
| that is saved in the long run.
|
| I am a heavy user of shortcuts and a lot of the times I don't
| even know what the shortcut is, it's all muscle memory.
| Intent turns into an action and feedback is both tactile and
| visual and there is usually an easy way to get back of that
| also with shortcuts. Using the mouse in some scenarios is
| like looking through a keyhole. That is not to say that using
| the mouse is bad all the time, because the mouse beats
| shortcuts in other scenarios.
|
| To me scrolling using the mouse scroll wheel or using
| keyboard keys are somewhat similar. Where the mouse workflow
| is eating the mental overhead is aiming a fly on a small
| landing 200th the size of the screen thousands of times or
| more daily.
| pxc wrote:
| For me, tracking the mouse cursor and moving it visually is
| harder than moving a text cursor, since with a text cursor I
| can generally look at a piece of text and summon the cursor
| directly to that location. I have trouble seeing and
| distinguishing the mouse cursor a lot, and I'm much more
| likely to overshoot it (or move it frustratingly slowly) than
| a text cursor.
|
| It just feels better for me to use. I do less squinting. :)
| Rapzid wrote:
| Yeah, in a work year writing just 400 lines of code per day
| will net >100k lines of code in year. That's.. A lot of new
| code. Greenfield, best-case kind of scenario. Keyboard
| shortcuts aren't going to be the secret sauce to writing a
| measly 2k lines of code, much less 400. Just thinking about
| this and discussing it probably wastes more time than a lot
| of those shortcuts would ever save.
|
| As long as somebody isn't being a huge detractor because they
| refuse to use the tools everybody else on the team does I
| don't really care. Not even enough to engage in a discussion
| about it. Unless there are beers.
| gnull wrote:
| I'm not sure if Emacs qualifies as an editor for saving time.
| As you say yourself, Emacs people tend to play a lot with
| customization (and Emacs didn't seem useful with default
| config to me; what the hack is C-x 2?). At the same time, it
| doesn't add anything useful to editing itself. It's basically
| scriptable MS Notepad.
|
| Try a text editor that does something for text editing, not
| scripting. Vim is an option. I personally used Kakoune with
| (almost) default config for some 3 years and I'm sure it
| saved me a lot of time. I never redefined default keys, they
| were good enough, I only added a few user mode bindings.
| (Although I felt a lack of some features over that time;
| Kakoune with no plugins is a bit too minimalistic.)
|
| Recently I spent a few days setting up LSP and some useful
| plugins, now I'm going to forget about customization for few
| more months again.
| Scarbutt wrote:
| Emacs and Vim are both equally efficient at text editing, I
| don't think you gave Emacs a fair shot. OTOH, VSCocde is
| frustrating to use if you are proficient at vim/emacs.
| daptaq wrote:
| > At the same time, it doesn't add anything useful to
| editing itself. It's basically scriptable MS Notepad.
|
| I don't know, fill-paragraph (M-q), the sexp commands,
| transpose commands, upcase-downcase-capitalize commands,
| indent-rigidly are all built-in, bound by default and I use
| them a lot. And let's not forget Macros.
| gnull wrote:
| Vim provides a different, more efficient modal language
| for talking to the editor (which Kakoune further
| improves). Emacs on the other hand doesn't, it just gives
| you some ad-hoc shortcuts. Emacs's language is no
| different from the one of Notepad or VS Code. It's the
| language of insert mode + scripted shortcuts.
|
| Shortcuts can improve your experience, yes, but not in
| such a fundamental way as a new model of editing.
|
| UPD.
|
| For example, the Emacs way of dealing with tables in
| markdown/latex is to have a custom plugin which will have
| a separate shortcut for each action one might want. As a
| consequence, you need to remember the keys for each of
| them.
|
| Kakoune, on the other hand, gives you a language that can
| express most of those operations naturally. And the
| language is no different than the one you use for other
| everyday tasks, no need to memorize new shortcuts.
| gnubison wrote:
| > it just gives you some ad-hoc shortcuts
|
| Give me M-q any day over gqap (or, if you're inside a
| multiline comment, 3gqq; or, if you're inside a multiline
| comment starting on the same line as code, just giving
| up).
|
| Edit: though I have to admit that I'm missing 'dt.',
| 'd/something', etc.
| pmontra wrote:
| > Emacs people tend to play a lot with customization
|
| I used to do that when I was young. Lots of elisp. Then I
| threw away a lot of customizations I didn't use anymore,
| added packages for the languages I'm using now and I think
| I ended up with a straightforward configuration.
| olau wrote:
| This is also why learning touch typing is helpful. It frees
| up mind resources. Sadly, not many people put in the effort.
| qbasic_forever wrote:
| There's a benefit to reduce stress on your hand in my
| experience too. Constantly switching from keyboard to mouse
| and back again, or even worse keyboard to trackpad, can
| really get aggravating after a while for some folks. I
| sometimes like a happy medium of VS code or other fancy
| editor with a VIM key mapping plugin.
| allenu wrote:
| I agree. It's not so much "saving time" as when you are in a
| state of flow, you want to remove anything that slows you
| down from converting what's in your head to code.
|
| I notice that when I am totally in the zone, I start to get
| frustrated quickly when tools take longer than normal or stop
| working correctly. You have a map of where you want to go and
| have the mental acuity to do it, but when tools get in your
| way, it takes you out of the flow.
| [deleted]
| city41 wrote:
| I don't find it's about speed, but rather about staying in the
| zone. vim enables very intricate navigation and editing that is
| much more tedious to pull off with a mouse. Since I have these
| commands memorized and very strong muscle memory, I just do
| them by instinct and my focus on what I'm doing never drifts.
| didip wrote:
| Reducing mouse usage certainly helped my RSI (tendonitis)
| problem but I am not sure if I am any faster.
| the-smug-one wrote:
| Good key chords matter.
|
| Here are some of mine:
|
| M-. jump to source
|
| M-, pop back to previous source
|
| C-x f r Find References
|
| C-x f i Find Implementations
|
| C-x f t Find Type
|
| C-x r v Rename Variable
|
| C-x c a Code Actions
|
| And a bunch more. I'd like to have an analogue to jump back
| with my C-x stuff like I do with M-. and M-, - any emacs people
| have suggestions on how to do that?
|
| I don't know how fast you are with the mouse, but I've watched
| my co-workers jump into source and they can be so slow. I
| believe that I can answer questions I have regarding the
| codebase faster than they can, I don't have to rely on my
| memory for trivialities.
| hota_mazi wrote:
| I don't find them particularly good. All these \C-x that
| emacs forces on you introduce extensive risks of RSI,
| especially if your Control key is still at the bottom left of
| your keyboard.
|
| Better chords would be simple shortcuts for actions you do
| often (for example, "Go to symbol" in IDEA is \C-b).
| hvis wrote:
| > I'd like to have an analogue to jump back with my C-x stuff
| like I do with M-. and M-, - any emacs people have
| suggestions on how to do that?
|
| If you use Xref UI for "Find
| References/Implementations/Type", M-, should work in those
| cases too.
|
| There is a more general question: how to "jump forward"
| again, without re-invoking the previous navigation command
| with the exact arguments. IDEA, already mentioned in
| comments, has key bindings for that.
|
| There are several third-party packages which attempt to solve
| it as well. I'm using this one:
|
| https://github.com/tcw165/history
|
| You can also add "jump back" to your other navigation
| commands, even if they don't use the Xref UI.
| brabel wrote:
| > I'd like to have an analogue to jump back with my C-x stuff
| like I do with M-. and M-
|
| Use IntelliJ, it's trivial to do that with `Cmd+B` (on Mac).
| soperj wrote:
| There's no muscle memory in point & click, and it is a lot
| slower for a lot of things. For instance, you wouldn't type on
| an on-screen keyboard with point & click. Once you've been
| using VIM for a while, pretty well any mouse interaction feels
| like doing just that.
| gnull wrote:
| Watch a skilled Dota player in action, you will find a lot of
| muscle memory with the mouse there.
| vladvasiliu wrote:
| I'm not familiar with Dota, but I'd guess that like other
| games whatever interface elements a player has to click are
| always in the same place and they're probably already
| having their hand on the mouse so know exactly where the
| cursor is.
|
| Now compare this with an usual "desktop session", where you
| may have multiple windows which aren't always in the exact
| same place, the cursor moves around, maybe even hidden
| because you've been typing, etc. Now you have to spend some
| extra time to 1. locate the cursor, 2. locate the button to
| click, 3. move the mouse over. It will probably not be
| _slow_ but it clearly takes you out of the flow compared to
| keeping your hands where they were and knowing that
| whatever your shortcut you have to press will do what you
| expect.
| gnull wrote:
| Yes, I agree.
|
| What you say reminds me of synchronous-asynchronous
| analogy I just made in another branch of this thread.
| colordrops wrote:
| I hate the analog-like nature of the mouse - having to move
| where you want, then slow down until you get to the right spot,
| then click, then click again because the cursor is a character
| or two off; and going through menus is a pain. And it's worse
| when you are hungover or tired. I just want a discrete and
| quick way to move around, and after using vim for a long time,
| it's not even a question that it's way faster and easier than a
| mouse. A mouse is a huge drag once you are strong with key
| bindings
| the_cat_kittles wrote:
| you wont know until you know. if two people can both use a
| mouse, but only one can do it all with the keyboard, you have
| to decide if they are being pretentious or if its actually
| better. i personally think its better for almost all code
| related tasks, but the mouse still has uses elsewhere
| gnull wrote:
| Even though I'm a big admirer of keyboard-driven interfaces, I
| don't think mouse should be eliminated. Mouse can be better
| than keyboard for some tasks.
|
| The problem I see is: a lot of things that non-modal, GUI
| interfaces use mouse for can be better done with a keyboard.
|
| For example, all sorts of drop-down menus and icons that you
| click on to launch programs. This kind of interface is
| inherently synchronous: the computer suggests, you pick. To me,
| it's way more natural to asyncronously type in what I want
| without having my attention hijacked by whatever suggestions my
| machine has (sometimes those actually make me forget what I was
| trying to do in the first place). I love the related metaphor
| ESR came up with in his Unix Coans [1].
|
| [1]: http://www.catb.org/~esr/writings/unix-koans/gui-
| programmer....
| vladvasiliu wrote:
| > To me, it's way more natural to asyncronously type in what
| I want without having my attention hijacked by whatever
| suggestions my machine has
|
| Yes, especially when the suggestions change all the time,
| like when you go to click something and the icon is replaced
| by something completely different.
| thefz wrote:
| Because once a keypress gesture enters your muscle memory, you
| are a fraction of a second away from doing what you intend to.
| TacticalCoder wrote:
| > Why some devs try to avoid the mouse?
|
| I use the equivalent of "easy motion" aka "ace-jump" or "avy"
| under Emacs to move to any character on screen about 4 to 5
| keypresses. Two to invoke that "jump to any character on
| screen" command, one to tell which character I want to jump to,
| then one or two depending on how many occurrences of that
| character there are on the screen.
|
| I'll put it simply: my cursor is where I want it before you
| have even grabbed your mouse. And that is the reason why I
| avoid the mouse.
|
| Same for "menus" and commands: shortcuts are faster than using
| the mouse. Once a list of potential candidates shows up, I use
| the same "select any candidate using the minimal possible
| amount of keypresses" command.
| yonl wrote:
| Point and click to navigate is pretty slow compared to keyboard
| driven approaches. Realized after switching to vim. Probably
| because, after certain point, it just the reflex which drives
| vim.
| jamespwilliams wrote:
| Automatic refactoring etc is still a long way off being good in
| Vim.
|
| But I've recently started using a combination of Neovim +
| treesitter + LSPs, and have found it incredibly powerful.
| Extremely responsive automatic compilation that feels
| instantaneous, good inline error messages, very good and fast
| syntax highlighting through treesitter... At what it does, I'd
| go as far as saying as it achieves more than any other IDEs
| I've tried. But of course, what it does is more limited.
|
| At the moment I rarely even touch a mouse. I work primarily in
| Vim, with DWM as a window manager and a Vim extension in the
| browser. When I have to work in a different environment and use
| a mouse again, I find the constant context switching very
| distracting
| fourseventy wrote:
| I'm yet to dive into treesitter. Was it hard to get it
| installed for nvim. Also, was it hard to get the language
| plugins installed?
| jamespwilliams wrote:
| I found it straightforward to install based on the
| documentation in the READMEs of both:
|
| - https://github.com/nvim-treesitter/nvim-
| treesitter#quickstar...
|
| - https://github.com/neovim/nvim-lspconfig#install
|
| Just by following the instructions I had a pretty good
| setup already, but I made a couple of further changes, like
| setting up autoformatting on save, which was a bit
| trickier. `vim.lsp.buf.formatting` was useful there, but I
| had to do a bit of research to figure out how to use it (it
| wasn't immediately available on the READMEs).
| eitland wrote:
| Here's my view:
|
| When I have my hands on the keyboard I prefer to keep them
| there so I use ctrl - w to close tabs, ctrl-t to open a new tab
| etc.
|
| When I have my hand on the mouse I prefer to keep it there so I
| used to love mouse gestures on older Firefox versions at least.
| frob wrote:
| Agreed! I have a keyboard full of OS-level macros and I've
| rebound the extra buttons on my mouse to ctrl+c, ctrl+v, and
| enter. If I'm leaning back and browsing through docs, I want
| to be able to move text around and execute commands without
| reaching for the keyboard.
| thomasahle wrote:
| My view:
|
| Use vim shortcuts in all the programs, so you never have to
| use the mouse or learn new keyboard shortcuts.
|
| For Firefox something like Vimium works well.
| Un1corn wrote:
| I found a nice solution to this with an MMO mouse. I have a
| Logitech G600 with 12 keys on the side and I mapped them to
| my most common operations like opening and closing tabs or
| moving between workspaces.
| stinos wrote:
| This. Using both (and touch as well sometimes), the right
| tool at the right time for the job at hand, is what is the
| fastest for me. Doesnt matter whether it's editing or
| browsing or ...
|
| What do you mean with older FF? I've been using mouse
| gestures for decades (Opera anyone?) and I still use the same
| ones today on FF. Different extension/plugin of course, but
| works the way it should?
| dmos62 wrote:
| Because we don't want to move the hand around. With keyboard-
| only solutions your wrist stays pretty much put. That's
| mechanically more fluid and faster.
| SkyMarshal wrote:
| It's all about avoiding context-switching from keyboard to
| mouse and back.
| mro_name wrote:
| and also in your brainz (no context switching)
| foldr wrote:
| When there's a trackpad below the keyboard you only have to
| move your hand slightly to use it.
| pjerem wrote:
| I don't get why you are being downvoted. A good trackpad
| under a keyboard (like on the Macbooks) is probably the (or
| at least, my) best input method. I would pay high price for
| a desktop keyboard with a qualitative touchpad right under
| the keyboard.
| pmontra wrote:
| I would buy such a keyboard too. Or a touchscreen. I can
| raise my hand, touch the screen to place the cursor close
| to where I want and probably be faster than with a
| touchpad, surely much faster than with a mouse.
| Unfortunately I would have to clean my screen as often as
| my glasses.
| dmos62 wrote:
| In my experience, a good work environment let's you go a
| really long way without even thinking of the mouse (or
| trackpad). So discussing which pointer device is most
| comfortable is sort of foreign to me. For context, I use
| shells and vim in tmux. If I don't need a web browser,
| I'll often not even start an X server (so no mouse at
| all).
| foldr wrote:
| Obviously it's possible to just use the keyboard if
| that's how you want to work.
|
| The point is that using a good quality trackpad
| positioned below a keyboard doesn't actually require you
| to move your wrist much, if at all. With this set up,
| there is not really any cost associated with switching
| between the trackpad and the keyboard. Thus, there is
| really no benefit to using the keyboard for tasks which
| can also be accomplished efficiently using the trackpad
| (as you are not paying any significant penalty for
| switching between the two input methods). For example, I
| was able to move my mouse cursor to the 'update' button
| to submit this form faster than I would have been able to
| use the relevant keyboard shortcut.
| foldr wrote:
| Indeed. If the challenge is to move to an arbitrary
| location visible on screen, then it's logically almost
| certain that a good trackpad is more efficient than any
| combination of keyboard shortcuts. Keyboard shortcuts can
| be more efficient in some specific cases of course (e.g.
| moving to the beginning of the next word, or something
| like that). But I see no point in memorizing the more
| obscure shortcuts when the trackpad works so efficiently
| and requires no thought or memorization.
| imiric wrote:
| The difference is that with a pointer device you need to
| control the input very carefully and precisely, which
| wastes time and brain cycles. A misclick could result in
| either maximizing or closing a window. Consecutive clicks
| can be interpreted differently depending on the
| configured period. Dragging and dropping is awkward, etc.
|
| On any trackpad other than Apple's this becomes even more
| difficult. Gestures are nice but also require nuance and
| IME don't become part of muscle memory as quickly as
| keyboard use does.
|
| Keyboard-driven workflows have no such issues. A keyboard
| shortcut is an immediate command to the computer to
| perform an action, and if that's something you do often,
| it will save you time and effort right away. You'll
| memorize it soon and forget about it since it will become
| part of muscle memory.
|
| > If the challenge is to move to an arbitrary location
| visible on screen, then it's logically almost certain
| that a good trackpad is more efficient than any
| combination of keyboard shortcuts.
|
| But moving "to a location on screen" is never a challenge
| worth using keyboard shortcuts for. If moving a cursor is
| your only UI option then a trackpad will be more
| efficient than doing the same with a keyboard of course.
| What you should do is use hotkeys to perform the action
| you would with a pointer so that you don't have to move
| it to begin with.
| foldr wrote:
| I'm not really sure what you're getting at. I find my
| MacBook trackpad to be a fast and precise method of
| placing the cursor at an arbitrary location within a text
| buffer. Outside of certain special cases it is faster for
| this purpose than fiddling around with keyboard
| shortcuts. There should not be any significant mental
| overhead associated with using a pointer device if you
| are sufficiently practiced at it.
|
| If trackpads don't work well for you then don't use them.
| I believe you, and have no interest in proving that your
| favored working methods are suboptimal. However, having
| tried the 'keyboard first' approach, I know that it is
| less efficient for me.
|
| I do tire of the ritual haranguing of anyone who notes
| that they find the use of pointer devices an aid to their
| working efficiency.
| tokamak-teapot wrote:
| Have you tried a MacBook with its trackpad right in front of
| the keyboard? I like keyboard-only too, but some jobs are
| faster when you can point at the screen
| smoldesu wrote:
| "pointing at the screen" can be done a lot better, a number
| of different ways. My personal favorite is the Trackpoint,
| IBM's nifty little nipple that lets you use a joystick from
| the home row. You can actually type _while_ using your
| mouse, and it 's a a very jarring experience. Barring that,
| a touchscreen is also a great interface for quickly
| interacting with specific UI elements. I like Apple's
| trackpads, but the rest of their input peripherals are
| pretty terrible for ergonomics.
| imiric wrote:
| I've been a huge fan of the Trackpoint for many years,
| but unfortunately it's always been plagued by annoying
| drift issues, where the cursor keeps moving in one
| direction and you have to fight with it to make it stop.
| This has been an issue on older IBM ThinkPads as well as
| modern Lenovo models. It's a disgrace the technology
| hasn't improved much (at all?) in the last 20 years that
| this is still a recurring problem.
| smoldesu wrote:
| There was also just shy of a dozen different Trackpoint
| designs, I don't doubt that one or two were seriously
| faulty, and I certainly have my preferences (the lower
| profile ones definitely don't track as well). In any
| case, the positioning and design of it is pretty ideal
| for people looking to reduce context switching at any
| cost.
| vladvasiliu wrote:
| I have, and it's much better than a mouse, especially since
| I've got used to working the trackpad with my thumb.
|
| But I still prefer keyboard shortcuts, they juste feel more
| natural while the hands are already in "typing mode". I
| feel like there's a question of "waiting around". Even
| though I've always found the mac trackpad to be very
| precise, even for quick movements, you still have to aim
| for an icon, move the cursor to it, click, etc.
|
| Now in the particular case of a macbook, where the windows
| will probably be maximized or not move around a lot, you
| may get some kind of muscle memory. But you still have to
| look around for the icon, etc. Whereas a shortcut is always
| the same, you press the keys and you're done, it doesn't
| matter where your cursor and / or window happen to be. I
| also prefer hidden icon toolbars, this allows me to gain
| some vertical space.
|
| But, as another commenter said, some actions are easier
| with the mouse and wouldn't throw mine away. In my case,
| that's web browsing.
| dmos62 wrote:
| I've not used a MacBook, but I've used laptops with
| trackpads. Either way, I'm a vim user, so I really don't
| have a reason to use the mouse for editing.
| smoldesu wrote:
| Modal editors in particular can be a mixed bag, they do seem a
| little out of place in the world of IDEs and Visual Studio
| Code, but I'd be lying if I said I don't use them heavily. The
| main appeal for something like this is to keep your hands on
| the keyboard so you can focus on writing.
|
| > Why some devs try to avoid the mouse?
|
| Because a keyboard is a much better peripheral to use when
| you're SSHing into your server. A mouse also has a much higher
| latency ceiling to execute most commands because it requires
| much more spacial awareness and brainpower to perform the task
| than just invoking the keybind. When you move your mouse to
| hover over a "send" button on an email client, your body is
| performing subconscious inverse kinematics to try to figure out
| how far to push the mouse, and when to stop. You can then only
| click once your mouse successfully lands in the designated
| area, at which point an additional 50-500ms of latency will
| ensue, depending on what UI framework your text editor is based
| off of.
| fpoling wrote:
| For me the appeal of Vim-type editors is that I do not need
| to learn new shortcuts when switching between Mac, Linux and
| Windows that I have to do at work periodically. This is a
| reason I use a Vim plugin with VS-Code with few custom
| keybindings to minimize the usage of Ctrl key.
| paxys wrote:
| IMO part of the reason is cultural. Computing became mainstream
| only after the mouse and GUI were invented, but programmers
| have been at it since well before that. So now it's somewhat of
| a badge of honor that you can be as productive without the
| newer conveniences. This apples to any new tools or processes
| like IDEs or linting as well. There was a very distinguished
| engineer at my company who chastised young engineers for using
| graphical step-through debugging.
| mixmastamyk wrote:
| Some actions are more productive at the keyboard. Other times
| I use the mouse.
| SuboptimalEng wrote:
| I made a video[0] explaining why it is beneficial to use Vim
| commands. You can watch from 00:48 seconds to 03:53.
|
| TL;DR: Moving away from the home row to arrow keys or mouse can
| cause wrist pains.
|
| [0] https://youtu.be/h-epcklOC_g?t=48
| dwoot wrote:
| This is a fair thought. It's why some wonder why people use
| Vim, emacs, or keyboard shortcuts in general...
|
| However, one of my reasons is that I work out of coffee shops a
| lot. Not having to bring an extra piece of hardware that takes
| up space is a big deal for me and not taking my hands off the
| keys is a big deal.
|
| I was a gamer (Counter-strike), and as precise as I believe my
| mouse-clicking to be, it is far less precise than the correct
| sequence of keystrokes to get to some parts...
|
| Readline shortcuts available in most shells, i.e., ctrl-a
| (beginning of line), ctrl-e (end of line), meta-b (back a
| word), meta-f (forward a word).
|
| In Vim - I can delete entire code-blocks with a quick sequence
| and have my cursor ready to type, and I can move chunks of code
| with their delimiters far more easily than my fairly precise
| mouse clicking and highlighting then moving my hand back to the
| keyboard to hit backspace. I can also switch to a "tab" (buffer
| in Vim) with a few keys without having to cycle through tabs or
| use a mouse to find the tab I'm looking for with a mouse.
|
| There are many benefits, it's why even though text editors have
| come so far, people still continue to write Vim plugins for
| them -- think VS Code, Atom, and all the IDEs that Jetbrains
| produces...
| lights0123 wrote:
| Vim still has visual mode, so if you want to use a mouse, you
| can use it, although only for selecting text and changing
| cursor position.
| fourseventy wrote:
| Using the mouse to highlight text in order to copy/paste it has
| always been a pain for me. Especially if the text is wider than
| the screen. I'm constantly highlight too much or too little.
| For me its way easier to use vim commands to grab the text I
| want. Its just one small example, but I can say for certain
| that I'm faster at editing text in vim than I ever was in a
| Jetbrains or VSCode editor.
| ConanRus wrote:
| no M-x ?? we don't need this editor then.
| jll29 wrote:
| Boehm, Atkinson and Plass (1995) proposed ropes as an alternative
| to strings for use in text editors.
|
| hx uses the Ropey crate (Rust library) to implement ropes:
| https://crates.io/crates/ropey
|
| Boehm, Hans-J., Russ Atkinson and Michael Plass (1995) "Ropes: an
| alternative to strings", Software--Practice & Experience 25:
| 1315-1330, DOI: 10.1002/spe.4380251203,
| https://dl.acm.org/doi/10.1002/spe.4380251203 (cited 2021-06-01).
| bruce343434 wrote:
| Can't find a download link of that article on that page nor
| another article explaining what "ropes" are. Can somebody tell
| me what a rope is?
| josephg wrote:
| A rope is a "smart string". Its a string where instead of
| storing the characters in an array, the characters are stored
| in a different data structure. Ropey stores a string where
| the characters are kept in a b-tree. This allows log(n) time
| complexity for inserts or deletes anywhere in the string.
|
| So you can have a string with millions of characters (a
| loaded document) and you can edit it efficiently.
| brundolf wrote:
| When you think about it, keeping editor text in a naive
| array-based string would be absolutely nutty
| banana_giraffe wrote:
| It's a b-tree for strings, optimizing for editor tasks that
| are traditionally inefficient if you keep a text document as
| a simple string.
|
| https://iq.opengenus.org/rope-data-structure/
| gnull wrote:
| Ropes is a performance improving technique, not a conceptually
| new model to think about strings, isn't it?
| nielsbot wrote:
| Depends if you're talking from the perspective of the API
| client or the string storage implementor's.
| malthejorgensen wrote:
| My impression is that most editors already use this or similar
| optimized data structures for representing the text internally.
| ljm wrote:
| It's great to see more projects in the space, but for me it's not
| really about the editor itself any more, it's about the ecosystem
| and the extensibility. The act of selecting and changing text is
| just a small part of the problem space.
|
| I use emacs not because I'm a neckbeard, but because I can script
| it to do whatever the hell I like. I switch to vscode when I want
| to do something my emacs setup isn't yet good for (like, working
| with Typescript).
|
| On the flip side, I use sublime text as a notepad replacement
| because it's that fast. I still use nano as my default editor for
| commit messages. Sometimes I use vim because that's what I
| happened to type to open a file.
|
| This isn't a comment on helix editor itself...just that, it's a
| pretty saturated space and I'm keen to see something as novel as
| light table play out again, but only more successfully.
| Rapzid wrote:
| > I'm keen to see something as novel as light table play out
| again
|
| All these years and I was starting to believe I had imagined
| light table. How else could one explain no editors adopting
| inline, always-on evaluation?!
| icholy wrote:
| I think that Julia's Pluto notebooks are the closest
| realisation of that dream.
| zygy wrote:
| https://blog.robenkleene.com/2020/09/21/the-era-of-visual-st...
| thomasahle wrote:
| It's interesting he values company management so much. What's
| stopping Microsoft from one day abandoning VS Code, like Atom
| was abandoned? Is Microsoft even making any money from it?
| dataflow wrote:
| > On the flip side, I use sublime text as a notepad replacement
| because it's that fast.
|
| Try SciTE if you want something super lightweight!
| kevincox wrote:
| It is a chicken and egg problem though. The quality of the
| ecosystem can be improved with a really strong editor
| underneath. However bringing the ecosystem to the editor is
| incredibly hard.
|
| I think vim is a messy pile of hacks, and I would love to see
| that changed. Neovim is nice with the extend and evolve
| approach but I'm always looking for something that can really
| provide a clean base for extensions to build on. (Yes ,yes, I
| know emacs is an editor-writing IDE)
|
| On the other hand I see nothing about plugins here. I think the
| approach to extensions is a very important question to answer
| early on.
| atweiden wrote:
| If you like VSCode, you might be interested in Onivim -- it's
| a VSCode/Vim hybrid.
| linsomniac wrote:
| Not sure about OniVim1, but just last week I bought the
| OniVim2 Early Access license, after watching oni 1/2 for a
| few years. I will say that it seems a bit early, but it
| does look promising. For example: My main workstation loses
| syntax highlighting after I do two motion commands ("jj" or
| "Gk" for example).
| pradn wrote:
| How about Emacs in eVIl mode?
| Koshkin wrote:
| The worst of both worlds?
| drums8787 wrote:
| Nah, it's the best. A recent thread on this convinced me
| to try Doom Emacs. It's great and just doubled my nerd
| factor.
| 1_player wrote:
| Evil mode is better than VIM itself and a good editor for
| the Emacs operating system which previously lacked one.
| alpaca128 wrote:
| Many people constantly recommending Evil mode don't seem
| to get why some use Vim.
|
| No, Evil mode is not better than Vim itself. For one it's
| slower, defining keybindings is much more verbose,
| everything outside the actual text file has completely
| different controls, and I lose most of the seamless
| interoperability with other terminal tools. And it runs
| within an environment that tries to be literally every
| text-related tool by itself, making it overly complicated
| in many aspects.
| 1_player wrote:
| > everything outside the actual text file has completely
| different controls
|
| Not sure what you mean by this
|
| > lose most of the seamless interoperability with other
| terminal tools
|
| It's not like VIM is more or less interoperable than
| Emacs is with other shell tools. They live in their own
| space, you don't (often) pipe stuff in or out of it.
|
| Though there's not much to read into my comment, it was
| an attempt of being witty, but evil mode is the best VIM
| implementation found in any editor and just for the fact
| that Elisp >> Vimscript, makes evil mode a better
| environment than VIM itself.
| prussian wrote:
| not sure about worse. enabling evil-ex-visual-char-range
| allows you to do things ex commands in (neo)vim cannot
| do. That is, run things like !rev on a visual select. in
| (neo)vim this reverses the whole line where with (evil-
| ex-visual-char-range t) enabled in evil does what I'd
| argue is expected, only reversing the string selected in
| visual mode.
| gnubison wrote:
| OTOH, Neovim lets you edit the ex command line; e.g. '!}'
| might expand to ':.,.+5!', which lets you execute any
| other ex command simply by deleting the '!'. They both
| have advantages, and I'm certainly not advocating that
| forcing ex commands to work on lines is the best idea.
| m8s wrote:
| Maybe I'm not the common use case, but when you say "because
| [Sublime] is that fast", what do you mean? Creating a new file
| in VSCode, for example, couldn't be any faster. Is it the case
| that you close VSCode often? Is it booting the application that
| is slow? This isn't criticism by the way, I'm genuinely curious
| since I hear this a lot.
| [deleted]
| ljm wrote:
| I can open and close an instance of sublime whenever I need
| to, without having to keep it running somewhere. I'll only
| use it for tweaking the odd file here and there when I'm in
| Windows.
|
| I also literally only use VSCode when I have to work with
| Typescript.
| robenkleene wrote:
| VSCode is many times slower than most non-Electron apps,
| e.g., in the below examples it's 9 and 14 times slower:
|
| 1. It takes nine times as long as Vim to open a minified
| JavaScript file, and then format it with Prettier:
| https://twitter.com/robenkleene/status/1285631026648276993
|
| 2. It takes 14 times as long to open an empty text file than
| BBEdit:
| https://twitter.com/robenkleene/status/1257724392458661889
|
| I'm just as surprised as you are that people _do_ see it,
| that some people _don 't_ see it. I have no idea what the
| explanation is, but there's something radically different
| about me versus people who can tolerate VSCode's slowness
| (I'll use VSCode if I have to, but I'll avoid it if at all
| possible, just because it's slow).
| treeman79 wrote:
| I'm looking for jumping to definitions, etc. In a dynamic
| language. ruby.
|
| In IntelliJ command B will take me where something is
| defied, be it system library or in code base. Not perfect
| but close.
|
| I've not had luck getting vim to do this.
| robenkleene wrote:
| Vim has supported jump to definition via `ctags` for
| decades, works great for Ruby. Here's a tutorial from
| ThoughtBot
| (https://thoughtbot.com/upcase/videos/intelligent-
| navigation-...).
|
| Vim also supports the same LSP implementations that
| VSCode uses via Coc.nvim
| (https://github.com/neoclide/coc.nvim), which provides
| the same code navigation features that VSCode has,
| including jump to definition.
| floydnoel wrote:
| I think what the poster you replied to may have been
| referring to is that the marginal cost once the editor is
| open is roughly zero. If VS Code is being used, a user can
| hit Ctrl/Cmd-N and have a new empty text field in no time.
| Similarly, opening a text file is so quick that I can't
| perceive any passing of time between clicking on it in the
| file tree and seeing the file open. Perhaps users with
| slower computers have a different experience?
| robenkleene wrote:
| The second example I posted, illustrating that VSCode is
| 14 times slower than BBEdit, was opening a file with
| VSCode already open (it's not obvious, but VSCode was
| already open in both recordings, so this difference has
| nothing to do with its launch time).
|
| There's some truth to your comment though, in that
| VSCode's optimizations are very on rails, i.e., if you go
| the slightest bit off the beaten path (like I opened a
| file from the Finder, instead of from the sidebar, in the
| BBEdit/VSCode video), then VSCode approach to
| optimization falls apart (you can find accounts of the
| tricks VSCode uses to appear fast online, there's a lot
| of smoke and mirrors based around specific workflows -- I
| think making a new tab is actually the example they use).
| It wouldn't surprise me if part of the reason I perceive
| it as so slow is I expect every feature to be fast, not
| just to most common ones. And I think this is a perfectly
| fair metric to measure by. Emacs, Vim, BBEdit, and
| Sublime Text are all fast at everything they do,
| therefore I think it's fair to call VSCode a slow editor,
| even if technically it's average for a couple of
| features.
| alpaca128 wrote:
| Often VS Code literally takes longer to process a single
| key input than Vim takes to start, load all plugins and
| open a session with multiple files on my machine.
|
| Granted, it's not a high-end workstation, just a laptop
| from 2016. But I don't think it's slow; when Vim first
| released it could have beaten the fastest supercomputer.
| Now of course that's a matter of perspective, but I hope
| I'm not the only one who thinks editing a package.json
| shouldn't make any modern PC sweat.
| Koshkin wrote:
| Eats memory, too... Eight Gigabytes And Constantly
| Swapping!
| debaserab2 wrote:
| I still prefer sublime text for opening very large files or
| jotting quick notes.
|
| VSCode load times are heavily correlated to what files I had
| open last and what extensions I have installed that trigger
| because of my previously opened files.
|
| When I freshly install VSCode on a machine, it feels
| blazingly fast. A couple months later when I've loaded up a
| few linting extensions? Not so much. Of course, the power of
| these extensions is why I'm using VSCode in the first place.
| I've yet to see an IDE that can integrate these types of
| features and not slow-down in some aspect, and VSCode does
| seem to _try_ to stay as lightweight as possible.
|
| VScode also often has notification prompts when I open it,
| either from extensions, or as popups generated from the
| editor itself. This doesn't add load time perse, but it does
| add to my mental perception of it's load time.
| simias wrote:
| It's interesting because I come from the exact opposite
| direction. I started with IDEs, then Emacs for almost 15 years,
| and last year I switched to Vim.
|
| Ecosystems change all the time, even if you've been coding in C
| for decades chances are that you've dealt with a bunch of build
| and package systems over the years.
|
| The more time passes the more I value ecosystem- and language-
| agnostic tools. Dummy completion, tag-based cross-reference
| (admittedly not completely language-agnostic, but close
| enough), find, (rip)grep, fzf etc...
|
| No setup, no configuration, it's lightning fast and it just
| works.
|
| I'm not arguing that my approach is better than yours btw, if
| you like more integrated environments then go for it. I just
| sometimes wonder if "kids these days" even consider that
| there's a world outside of Visual Studio and ultra-heavy
| language runtimes. The zen of a 10 line Makefile.
| zozbot234 wrote:
| LSP and Tree-sitter seem to have the right approach, aiming
| to provide a standard layer that can support a wide variety
| of languages and ecosystems throughout. Language-agnostic
| tools can interoperate with this approach too but they only
| provide very basic features, not really enough to compare
| well with existing workflows.
| rodgerd wrote:
| LSP seems like a real blessing for editor authors, since
| "it can't do anything useful with my preferred programming
| language" has been a big lock-in.
| linsomniac wrote:
| Just this morning I upgraded to NeoVim 0.5 and set up
| TreeSitter and LSP with Lunar. I haven't had much time to
| play with it today, but it's looking good so far.
| https://github.com/ChristianChiarulli/LunarVim
| majkinetor wrote:
| Yeah, give me generics and a language to pipeline them into
| anything I want. Full stop. Let Harry Potter and his friends
| play with magic.
| Scarbutt wrote:
| Seems you are agreeing with GP.
| TacticalCoder wrote:
| > I still use nano as my default editor for commit messages.
|
| You don't work with Git as a DVCS? Or you work with Git and
| Emacs but don't use Magit!?
| ljm wrote:
| I use magit extensively because it's an utter fucking marvel,
| but sometimes I'm in a shell without emacs open, or I have to
| run some internal tooling that wraps around git.
|
| My point overall was that I see all of these as a collection
| of tools. Which one I choose depends a lot on context, and
| it's served me well to be baseline comfortable with all of
| them rather than depending too heavily on my emacs setup.
| mijoharas wrote:
| I'll admit to doing that. Command line git is baked into my
| muscle memory now.
|
| (magit is brilliant, but for some reason it's never stuck
| with me, unless I want to interactively stage a few specific
| chunks, and then it's much nicer than using the cli).
| maxqin1 wrote:
| > The whole design is based around multiple selections as an
| editing primitive
|
| This makes a lot of sense and I wish it were easier to do
| elsewhere. Probably wouldn't leave the vs code ecosystem for this
| alone, though.
| lalaithion wrote:
| The one page you should add to the documentation is "differences
| from Vim".
|
| For example,
| https://github.com/purescript/documentation/blob/master/lang...
| makes picking up PureScript as a Haskell programmer much easier
| than having to read all of the documentation and do the diff
| yourself.
___________________________________________________________________
(page generated 2021-06-01 23:00 UTC)