51–60 of 123 posts
Removing pretty powerful feature just because author of fork doesn't use it sounds… well, actually author of fork can remove whatever he likes, but presenting neovim like "refactord vim with more features" isn't fair or even plausible in this case. And for what reasons? Oh, I see, it makes code complicated. Did he think vim'c codebase is scary for no reason? Removing all the code from vim would be the ultimate simpli…
as a developer, I think it's good to remove some rare feature to reduce code complexity. Also it's good to make this kind of feature as plugin, so it will reduce the code complexity.
I've never used ex mode, so I could be wrong about this, but briefly reading through the description for it made it seem like you could replicate the functionality through the neovim plugin/messaging architecture, and probably get something cleaner on the other side.
Earlier quoted context omitted.
Elaborate, please. (I've gone and elaborated on my own comment. I might have misworded my intent.)
Bram hasn't complained about their usage of the name (unlike the Standard Markdown fiasco). And as a Vim user what they're doing seems what Vim always wanted to do before Bram was sidetracked by other projects: they're making Vi Improved. A lot of the changes they're making seem to be redoing the Vim internals using 21st century software development practices (continuous integration: builds, tests, linting, refactori…
Me too. I would rather it become an actual 'new' Vim.
Removing pretty powerful feature just because author of fork doesn't use it sounds… well, actually author of fork can remove whatever he likes, but presenting neovim like "refactord vim with more features" isn't fair or even plausible in this case. And for what reasons? Oh, I see, it makes code complicated. Did he think vim'c codebase is scary for no reason? Removing all the code from vim would be the ultimate simpli…
A huge part of good design is being able to make good (and often hard) decisions about when and where to simplify. This includes things like occasionally eliminating features. Ones that have shipped. For months, or even decades.
There are very solid arguments presented in that thread for interactive Ex-mode's removal. Specifically, one problem that @tarruda mentions is that ex-mode is one of the blockers for "implementing GUIs over msgpack API." Seriously, I'd trade ex-mode for that in a heartbeat!
[1] http://vimdoc.sourceforge.net/htmldoc/intro.html#Ex-mode
Earlier quoted context omitted.
Not "q", but "Q". Actually, when entering Ex mode you get a little helpful message that says Type "visual" to go to Normal mode . If you do press "q" though, you're in macro mode, and you don't get any helpful message that tells you that you have to press "q" another time to exit it.
I see, thanks for the clarification :) Vim always seems like magic to me. I always use nano/pico when I need to edit something in the command line.
I like my shells to have white backgrounds. I don't know why, but it's just restful to my eyes. Nano's default syntax highlighting on bash scripts is to highlight strings in bright yellow, which on a black backdrop makes sense, but on white is impossible to read.
It took years of working with shell scripts, and a familiar litany of "I'll just look up how to change this... [one hour later] I have no idea, let's just change my Konsole background to black for a little while..." before one day I was like, "Dammit, I just need to change this one little thing over here" and typed vi instead, thinking that it was so simple that surely it'd have no highlighting.
But it did have highlighting, and it was highlighting which wasn't bonkers like nano's was.
I had struggled with vi a lot before. I did not like it. Still don't. The thing is, they could probably have won me over a million years earlier by starting me off at insert mode on the first line! It is modal, and I don't even like the modality of my cruise control system on my car, let alone the modal nature of vi -- but at least a text editor should dump a beginner in the mode which, y'know, edits text. I'm only just getting used to hjkl keys, and only then because of nethack. I don't know enough to make super expert use of vim.
But, all that aside, it won because it didn't force me to squint at yellow-on-white text every time I was SSH'ed into a system which needed me to edit string-laden syntax-highlighted files.
Earlier quoted context omitted.
"... similar to the command line mode ... Unlike the command-line mode you won't return to normal mode automatically ... enter ... by typing a Q in normal mode" So they have a mode you enter when pressing q (which quits many other programs) that you can't leave if you don't know the leave command? This is comedy gold. :D
Not "q", but "Q". Actually, when entering Ex mode you get a little helpful message that says Type "visual" to go to Normal mode . If you do press "q" though, you're in macro mode, and you don't get any helpful message that tells you that you have to press "q" another time to exit it.
Removing pretty powerful feature just because author of fork doesn't use it sounds… well, actually author of fork can remove whatever he likes, but presenting neovim like "refactord vim with more features" isn't fair or even plausible in this case. And for what reasons? Oh, I see, it makes code complicated. Did he think vim'c codebase is scary for no reason? Removing all the code from vim would be the ultimate simpli…
They're not removing command line mode , they're removing interactive Ex-mode[1]. Batch ex-mode from the command line (nvim -e) stays. From the research the team has done, most users 1) don't even know about it, 2) are annoyed when it is triggered by accident, and 3) when they do know about it, just remap it. And yes, there are a few users of ex-mode out there. A huge part of good design is being able to make good (a…
Removing pretty powerful feature just because author of fork doesn't use it sounds… well, actually author of fork can remove whatever he likes, but presenting neovim like "refactord vim with more features" isn't fair or even plausible in this case. And for what reasons? Oh, I see, it makes code complicated. Did he think vim'c codebase is scary for no reason? Removing all the code from vim would be the ultimate simpli…
If you like certain VIM features you can keep using VIM.
Removing pretty powerful feature just because author of fork doesn't use it sounds… well, actually author of fork can remove whatever he likes, but presenting neovim like "refactord vim with more features" isn't fair or even plausible in this case. And for what reasons? Oh, I see, it makes code complicated. Did he think vim'c codebase is scary for no reason? Removing all the code from vim would be the ultimate simpli…
They're not removing command line mode , they're removing interactive Ex-mode[1]. Batch ex-mode from the command line (nvim -e) stays. From the research the team has done, most users 1) don't even know about it, 2) are annoyed when it is triggered by accident, and 3) when they do know about it, just remap it. And yes, there are a few users of ex-mode out there. A huge part of good design is being able to make good (a…