[HN Gopher] Vim9 Script Feature-Complete
___________________________________________________________________
Vim9 Script Feature-Complete
Author : elvis70
Score : 95 points
Date : 2022-01-01 14:34 UTC (8 hours ago)
(HTM) web link (groups.google.com)
(TXT) w3m dump (groups.google.com)
| wizardofmysore wrote:
| This seems like a too smart for your own good situation.
|
| Just because you can write a programming / scripting language
| doesn't mean you should.
|
| There are tons being developed already, why not just adopt one of
| those.
|
| I support NeoVims decision of going the lua route.
| davidgrenier wrote:
| So I just did this command for the hell of it, and it worked:
|
| :e
| https://raw.githubusercontent.com/vim/vim/master/runtime/doc...
| totorovirus wrote:
| vim is cool but it's simply not worth investing time to learn a
| language that only works for one specific editor.
| layer8 wrote:
| The vim scripting language is an extension of the command
| language used interactively in vim, so it does make some sense
| for the transferable knowledge.
| ncmncm wrote:
| 100+ emacs-lisp users disagree with you.
| wolverine876 wrote:
| I don't write much in Vim script, but what are the implications
| for my beloved, carefully tended .vimrc file?
| ezekiel68 wrote:
| This looks great. Some takeaways from looking into the
| documentation:
|
| They're promising 10x - 100x better performance (since vim9script
| is typed and will be compiled). Also -- you can mix vimscript and
| vim9script in a function, a file, or a module. This will let
| legacy modules or scripts stay mostly the same but port some of
| the slower-running bits to vim9script to gain the benefits
| without a giant effort to port the whole thing.
| Tyr42 wrote:
| Ah, that's the key part people are missing above, you can opt
| in on a function by function level.
| lawn wrote:
| This is a perfect example of NIH (Not Invented Here).
|
| So you have the huge success of first-class Lua support in
| Neovim, and it's clear that there is a very real need for a
| better scripting language in Vim.
|
| But not only do you skip Lua, and lose out on the work and
| plugins that has already been done, you decide to write yet
| another custom scripting language.
| [deleted]
| wolverine876 wrote:
| How do we meaure 'huge success'? The only place I hear about
| Neovim is on HN, where people hijack Vim threads with it.
| drekipus wrote:
| Not to join in the lynching, but nvim is stable and healthy
| in terms of development velocity.
|
| It's not as popular as vim per say, but it's definitely
| catching up. It's kinda silly to suggest otherwise.
| wolverine876 wrote:
| They said "huge success". Huge successes in text editors
| are Vim, Emacs and maybe Sublime. And do you have anything
| to backup your claims about neovim's popularity?
| [deleted]
| L0stLink wrote:
| One measure is the number of stars on github and active
| contributors 49.7k vs 25.7k and 737 vs 79. The other
| measure can be the number of new extensions being written
| for each of them (particularly extremely high quality
| ones like telescope). Searching `nvim` on github yields
| many plugins which are advertising the Neovim editor by
| having it in their name, some of these are even ones
| which support vim e.g. Shougo/denite.nvim all of which
| point to the fact that neovim is a huge success and is on
| tract to overtake vim. It would not be an exaggeration to
| say that a lot if this is due to first class lua support
| in Neovim. By adding nice features like treesitter and
| LSP it has become an improved version of vim, an editor
| that actually understands the code being edited beyond
| simple text objects (e.g.
| https://youtu.be/E4uaPs9e9UU?t=68)
| leadingthenet wrote:
| According to the latest Stack Overflow developer survey,
| neovim is used by almost as many people as Emacs is[1].
|
| By your own definition, Emacs is a "huge success",
| therefore I'd expect you to extend that description to
| nvim, too.
|
| [1]:
| https://insights.stackoverflow.com/survey/2021#section-
| most-...
| blindseer wrote:
| I think it's kind of crazy that vim9script is even a thing,
| especially when neovim has proven how much more viable lua is as
| a scripting language. Lua is way more beginner friendly than
| vimscript or vim9script, with luajit you get killer performance,
| lua has an awesome language server implementation, it's a saner
| programming language imo and so much more going for it. There's
| even transpilers to convert typescript / other languages to lua.
| There's plugins written in lua today that just wouldn't be
| possible in vimscript or vim9script script.
|
| Vim9script on the other hand seems like an exploration in PL,
| which I'm all for generally but not in a software like vim. Like,
| just imagine writing and maintaining something like magit or org
| mode in vim9script. It's a large complicated piece of software,
| you'll have to write it using without any linter, formatter or
| language server (at least for the foreseeable future) and your
| skills are not transferable to any other tool. Just the sheer
| probability of better plugins existing and thriving in your
| ecosystem drop significantly once you choose to have vim9script
| as the scripting language. I'm curious to see how this all pans
| out but I'm not optimistic.
|
| The worst part is that it doesn't appear that existing plugins
| will work in vim9script. Even the syntax for commenting is
| different: set number " This is a comment in
| vimscript set number # This is a comment in vim9script
|
| See https://vimhelp.org/vim9.txt.html#vim9-differences
|
| And to get any performance improvement, plugin authors will have
| to do a LOT of work that is not compatible with their existing
| plugins.
|
| I for one am glad neovim exists, and I encourage people to throw
| a few bucks their way :)
|
| https://github.com/sponsors/neovim
| gtsop wrote:
| I've avoided neovim because my current vim setup justworks(tm)
| and i trully depend on it for being productive on my job. As
| time goes by i really feel like i should switch based on how
| the two projects progress. Do you know of a resource that could
| hold my hand?
| junon wrote:
| Err unless something has changed, everything that works in
| vim8 should work in neovim. It was a drop-in replacement for
| me. Nothing new to learn unless you're a plugin developer.
| the_duke wrote:
| The exception is the async API which was first implemented
| by Neovim, but Vim followed with something incompatible.
| Most plugins that need it are compatible with both though.
| rectang wrote:
| I've been using MacVim for 15 years; it has been pretty much
| solid the entire time, and I'm used to its mouse integration.
| When I started out, I was doing a lot of cross-platform
| development and there was a Windows version of Vim which
| behaved almost the same. It was great to have a powerful text
| editing experience which was pretty much the same everywhere.
|
| I tried out NeoVim, but as far as I can tell, it seems to be
| terminal-only/keyboard-only? I _can_ use Vim keyboard-only
| (certainly I do that all the time over ssh), but it 's not my
| preference.
|
| My second choice for editing behind MacVim isn't NeoVim but
| VSCode, but I don't use VSCode with Vim bindings because in
| my experience grafting Vim bindings onto any editor not Vim
| won't be feature complete. In a perfect world, there would be
| an IDE which is truly a Vim-style modal editor at its core.
| andrewl wrote:
| I just started looking into Neovim, and I had the same
| concern about it being terminal-only. But then I saw this
| on the Neovim site:
|
| "Graphical interfaces are not packaged with Neovim. GUIs
| are not limited by terminal capabilities and can choose to
| override the rendering of certain neovim elements (cursor,
| tabline, popup menu, etc)...See Neovim's wiki[1] for a list
| of many of the available GUIs."
|
| [1] https://github.com/neovim/neovim/wiki/Related-
| projects#gui
| rectang wrote:
| This looks interesting:
|
| https://github.com/asvetliakov/vscode-neovim
|
| > _This extension uses a full embedded Neovim instance,
| no more half-complete VIM emulation! VSCode 's native
| functionality is used for insert mode and editor
| commands, making the best use of both editors._
|
| I like lots of things about VSCode, but there are
| inefficiencies with editing that just drive me bananas so
| I keep falling back to good old familiar MacVim. For
| instance, line wrapping, auto-indenting, and mouse-
| select-then-rewrap in comments -- comment support in the
| Vim ecosystem seems to have been designed by and for
| people who really care about good documentation, while I
| have to work much harder to get my comments and docs to
| look good when editing with VSCode.
|
| Hopefully the mechanism of embedding a full NeoVim
| instance will allow for a moe-or-less feature-complete
| Vim editing experince.
| cassepipe wrote:
| There is also Onivim although it is not 1.0 yet.
| Development is financed through selling licenses but it
| is open source and you can build it yourself. Development
| has stalled when the main dev got a job some months but
| there are apparently still people willing to develop it.
|
| https://www.onivim.io/
| halostatue wrote:
| Oni2 is not vim. It does not act like vim. It uses
| neither Vimscript nor Lua, but instead Javascript
| (VSCode-based extensions).
|
| I paid for an Oni2 licence and regret it, because it
| isn't what I want, which is a MacVim.app wrapper for
| neovim.
|
| If you like MacVim.app, there is _absolutely no GUI that
| is acceptable_ for neovim. I understand why, and I'm not
| interested in taking on the development myself. But until
| someone makes a GUI that is as well-integrated with macOS
| as MacVim.app, I will be using vim and not neovim.
| sigzero wrote:
| Yeah, there are a bazillion UIs (and most have stopped
| being updated) but nothing that comes with like vim/gvim. I
| might have looked at neovim if there was a neovim/gneovim
| but that isn't the case. I am okay with Lua. I am okay with
| Vimscript and Vimscript9. So neither of those is a pusher
| for me.
| thayne wrote:
| In addition to the fact that there are guis for neovim,
| neovim in the terminal _does_ support mouse interaction as
| well (assuming your terminal emulator supports it, which
| should be the case for most modern terminals).
| rectang wrote:
| I just tried out nvim in the MacOS Terminal, and a couple
| of things didn't work right away.
|
| First, clicking on a location didn't set the cursor.
| Especially when editing large files, I like to scroll in
| MacVim, click to set the cursor and then start typing.
| While I _can_ do things like note the line number and
| jump, or scroll by moving the cursor with key commands, I
| find those less efficient.
|
| Second, selecting text using the mouse didn't produce a
| selection that Vim knew about. I use this feature all the
| time in MacVim, to produce a visual selection which I
| then rewrap using `gq`, filter by piping the selection
| through an autoformatter like `rustfmt`, etc. Again, I
| _can_ do this using keyboard navigation exclusively to
| make visual selections, but I find it easier to select
| using the mouse.
| thayne wrote:
| Interesting, all of those things work for me with
| alacritty, kitty, gnome terminal, etc. Maybe it is a
| limitation of MacOS Terminal? Or you need to explicitly
| enable `set mouse=a`?
| 1_player wrote:
| Mouse support isn't enabled by default, on any terminal.
| You need set mouse=a
| rectang wrote:
| Thank you, that solves the issue!
|
| This seems to be something in Vim rather than a NeoVim-
| specific setting, as I tried the same thing with the
| standard Vim and it worked the same. The scrolling feel
| in the Terminal isn't as smooth as MacVim, but it's still
| pretty good.
| dummy_physicist wrote:
| You can give VimR[0] a try, I don't know what mouse
| features you use on MacVim, but that was the most pleasing
| GUI version of vim/neovim I've used.
|
| [0]: https://github.com/qvacua/vimr
| rectang wrote:
| I've just installed it and started playing around.
|
| On first open, a lot of the interface was unreadable
| because VimR seemed to be assuming a dark background, but
| I use a white background. `set bg=light` didn't fix it.
| `colorScheme=PaperColor` fixed it incidentally because it
| didn't find the color scheme and reverted to something
| legible, haha.
|
| Next, I tried to set the font size for the navigator to
| something bigger because my eyes aren't that great.
| Although I can use `set guifont` to set the editor area
| font, the navigation area doesn't change. Presumably
| there's _some_ way to fix it, I just haven 't found it
| yet.
|
| VimR looks cool and I really like having the navigator
| there IDE-style, but it seems like there will be a period
| of adjustment. Nothing new for someone accustomed to Vim,
| haha.
|
| The main IDE-style features I've been going without in my
| ordinary day-to-day editing with MacVim are the
| autocompletion, suggestion, and hover-to-show-
| documentation. (I've started using ALE which is helpful
| but needs some tweaking before it's really usable.) It
| might be possible to get those with either MacVim or
| NeoVim, and it would be worth the configuration to set
| them up if so.
| rafamaddd wrote:
| Well in theory everything that works in vim will work in
| neovim (there's a few exceptions[^1]). So you really don't
| loose anything by installing neovim and using your same
| .vimrc for it.
|
| You can start experimenting with Lua and the new plugins
| whenever you're able to.
|
| [1]: https://github.com/neovim/neovim/issues/1716
| gtsop wrote:
| Thanks for all the replies, didn't know it was meant to be
| a drop-in replacement, will give it a try :)
| petre wrote:
| I have the same setup in both vim8 and neovim. It's symlinked
| over from neovim, because I like the xdg _~ /.config_ dir
| better, keeps things tidier. Basically pathogen, lightline
| and vim polyglot. I use vim8 most if the time out of habbit.
| I like Lua better but I understand it has poor handling of
| strings and I don't know how that fares with and editor
| extension language.
| leephillips wrote:
| How is Lua's string handling supposed to be poor?
| [deleted]
| _TwoFinger wrote:
| > it has poor handling of strings and I don't know how
| that fares with an editor extension language.
|
| I guess the parent refers to Lua treating strings as
| simple byte arrays, whereas a text editor has to deal
| with characters in various encodings, some of which can
| be multi-byte.
| petepete wrote:
| When I switched in 2018 my config essentially just worked, I
| had to replace a plugin that no longer worked but everything
| else went smoothly, the process took about ten minutes.
| halostatue wrote:
| I have set up a complex neovim configuration, but I don't use
| it.
|
| Why? Because there's not a _single_ neovim client that is as
| good as MacVim.app. I paid for Oni2 (I regret that; it's
| _not_ a vim replacement). I have contributed code and time to
| helping a couple of other GUIs fix their issues. But they are
| all crap compared to MacVim.app.
|
| Until that is fixed, I don't think that there's a good reason
| to consider switching.
| xvilka wrote:
| I hope they will get enough money to hire someone full-time.
| That would be really awesome. I am proud sponsor of it myself.
| bin_bash wrote:
| Vimscript is like regex: no matter how long I write it I still
| don't bother trying to read it. If something isn't working I
| usually throw a good portion of my config away and start from
| scratch.
|
| I've been using neovim for a while now but just switched my
| config over to Lua yesterday. I've never seen a line of Lua
| before yesterday but I _already_ find it way easier to write
| than vimscript--which I've been writing since the early 2000s.
| kubb wrote:
| Was there some reason why Bram didn't go for Lua adoption, and
| instead opted for his own language? Is is the NIH syndrome
| only? Lua seems just a really good option as far as embeddable
| languages go. People love complaining about minor issues with
| it like the 1-based arrays, but building a new language from
| scratch is just not worth it, no matter how you look at it.
| Maybe I'm missing something here.
| MichaelMoser123 wrote:
| Lua and vimscript are both the same age; Lua came out in
| 1992, and vimscript in 1991, so it would not have been an
| obvious choice. I think that vimscript has the same problem
| as shell scripts: there are a lot of editor/shell commands,
| and they didn't want to introduce a special syntax for
| distinguishing between the language proper and the editor
| commands.
|
| I don't think that vimscript is that bad. What i don't like
| about are the scope rules, i.e. special prefixes for function
| arguments, locals and globals. Also the call keyword is
| required for function calls and let keyword for assignments.
|
| Anyway, Python can be used as a vim extension language, i am
| not sure if Lua is superior in this respect to python.
| ncmncm wrote:
| Lua is probably way, way faster. Does that matter? It could
| matter. It would be awful if it did matter, and you chose
| wrong.
| Trex_Egg wrote:
| What is NIH syndrome?
|
| Edit: got it, its called "Not Invited Here" syndrome.
| soperj wrote:
| not in house.
| darrenf wrote:
| "Not _Invented_ Here" is how I've always known it.
| ncmncm wrote:
| This is the correct one.
| [deleted]
| bitigchi wrote:
| I think he does not like to go with the flow, but instead
| implement things the way he thinks best suited and best
| performant with Vim. I don't think he cares about NeoVim.
| thayne wrote:
| You could ask the same question about why he decided to make
| the async api and terminal mode incompatible with existing
| equivalents in neovim. Sadly, the ecosystem seems to be
| splitting more and more between vim and neovim.
| Yuioup wrote:
| My impression is that Bram is trying his best to outcompete
| neovim.
| mi_lk wrote:
| That goes without saying, and it's just unfortunate that
| he chooses to compete rather than collaborate
| BooneJS wrote:
| Competition is good, and it's the reason why Neovim was
| created in the first place!
| Tyr42 wrote:
| I mean, the reason is that those async patches were just
| sitting in the queue for a year, and by starting Neovim,
| they could get them in right away.
|
| Then Bram started competing afterwards.
| Taywee wrote:
| Vim started in 1991. I don't know when VimL became a thing,
| but there's a serious possibility that Lua wasn't a great
| option at the time, and the only established embeddable
| language might have been some lisp or Tcl. I am not super
| versed in this area though.
| capableweb wrote:
| > building a new language from scratch is just not worth it
|
| Seems this has been said about every single language ever
| (except the first I guess?), even languages as Golang and
| Rust have gone through a phase where many question "why even
| build a new language when X does Y and Z perfectly fine
| already?", and then they end up really popular anyways as
| they solved some slice of problem(s) is a particular way that
| many like.
| 41b696ef1113 wrote:
| I think there is a big difference between designing a new
| freestanding language vs one designed for
| extensions/plugins. The freestanding languages are free to
| iterate and incorporate novel, wacky ideas. An extension
| language should do the best it can to avoid rocking the
| boat.
|
| I have a dear place in my heart for tiny focused languages
| and think if Vim had stated they were going to suddenly
| make Wren, Gravity, Janet, etc first class languages, there
| would be less reluctance than a new thing.
| blindseer wrote:
| For every golang and rust, there's probably tens or
| hundreds of programming languages that will never end up
| popular. I guess that is to say the probablity that
| vim9script will succeed isn't high.
|
| And golang initially started off as a replacement for C,
| and then pivoted because they couldn't achieve that purpose
| ... now, it's touted for simplicity. When Rust was a pet
| project of Graydon, it looked VERY different to what it is
| right now. My point is that vim9script as it stands right
| now doesn't solve any real world use case that lua wouldn't
| be better suited for. Maybe vim9script will be better for
| something else entirely in the future, and that will be, as
| you describe something people may like. But right now we
| don't even know what that is, and surely that can't be a
| reason to decide to go explore language design in such a
| large community such as the one vim has? It is definitely
| Bram's right to do so, but I fear that people will rather
| move to neovim or vscode or emacs than learn and write
| vim9script, and as a user of that community I think that
| would be bad.
|
| Also, it's not like people were proclaiming vimscript was
| awesome you know. There's a talk from one of the core devs
| of vim-lsp on YouTube [1], on features of vimscript, and
| literally in every slide the presenter caveats the
| vimscript feature in one way or another. I find it
| hilarious, it's a perfect example of the frustration of
| when writing plugins with vimscript.
|
| [1] https://www.youtube.com/watch?v=7fcJWwl1-SU
| victorvosk wrote:
| Go and Rust compared to vim script is an Apples to Space
| Shuttle comparison.
| capableweb wrote:
| Yes, if you compare their functionality, performance and
| on a bunch of other attributes sure. But I'm not doing
| that, I'm comparing them on the attribute of "new
| programming language", which all of them have been at one
| point or another.
|
| It might just have been that Vimscript didn't go the way
| it was intended to, or people moved towards different
| paradigms to doing modal editing in a sane(r) way, but
| maybe in some alternative universe, Vimscript became a
| popular scripting tool.
| ncmncm wrote:
| Nate's Law says, "Only an idiot expects anybody to use
| their new language". First corollary is "All new languages
| are designed by idiots".
|
| Very, very rarely, lots of people find reasons use a
| language designed by (such) an idiot, _anyway_. We are
| lucky when the language is not terrible, because how good
| it is even more rarely affects whether it will take off.
|
| In practice, languages almost always ride to popularity on
| the back of something else. C rode Unix, C++ rode C, Java
| rode Sun Microsystems' $billions and the promise of getting
| off Microsoft's framework-hell treadmill, C# rode .Net,
| Javascript rode HTML (and then web services because the
| same people were coding both, at first), Go rode Google and
| Docker. Lua got where it is by being really easy to embed,
| and being simple, powerful, not weird, and (lately) fast.
|
| Python got there mostly the hard way, but _also_ by being
| easy to embed and to extend with C ABI-compatible plugins,
| despite being weird and extra-super-slow.
|
| Amazon, BTW, might be unique among IT behemoths in not
| hustling its own walled-garden language. (Or maybe I just
| don't know about it.)
| pasabagi wrote:
| I don't think making a new language is so much more crazy
| than making any other piece of tooling. Obviously, it's
| going to have to have compelling advantages to convince
| people to move from the tools they know and love. But, if
| you're putting in the time, you probably imagine you have
| some compelling advantages. Rust is an obvious example of
| this, as is something like Java, or C++.
| fnord123 wrote:
| I think there is some concern among some people in the
| rust community that amazon will gain more influence over
| the steering of rust to guide it towards it's own walled
| garden.
|
| I don't share that sentiment and I personally think that
| as amazon adopts rust it will gain rust community
| principles. But I'm probably wrong.
| tyingq wrote:
| Vim and Lua evolved in similar timelines. It's plausible that
| vimscript was written without him knowing Lua was a choice.
| blindseer wrote:
| vim9script was most definitely written way after lua was
| integrated into neovim, and well well after lua was popular
| as an embedded programming language choice. While it is
| plausible that the idea for vim9script was conceived
| without him knowing Lua was a choice, it is unlikely that
| work on it was started without Bram knowing. There's even
| people that have commented on the google groups as far back
| as 2016 about neovim's use of lua. It's unlikely that Bram
| wouldn't have seen that.
| tyingq wrote:
| vim9script, though, is the evolution of vimscript, and
| has some amount of backwards compatibility, short-ish
| migration guides, etc. Initially choosing an embedded
| script language and migrating to a new one are fairly
| different scenarios.
| capableweb wrote:
| I don't know about the timeline of Vimscript in particular,
| but seemingly Vim was first released in 1991 while Lua
| first 1993, so by the first release of Lua, Vim already
| existed by then. Not sure when Vimscript appeared though.
|
| On other trends (Google Trends to be specific), search
| volume for Lua only became larger than for Vim in 2004,
| with Lua hitting it's peak in 2009. Search volume for Vim
| would have been much larger before 2004 if we had a single
| search engine everyone could have used, but hard to know in
| afterhand I guess.
| bitigchi wrote:
| It was the result of a poll:
|
| 1 - https://groups.google.com/g/vim_dev/c/__gARXMigYE/m/iskHV
| wgU...
|
| 2 - https://github.com/vim/vim/issues/3573
| wolverine876 wrote:
| Perhaps neovim isn't the Truth to which we all aspire, or care
| about. Certainly there are many, many ways to do things that
| are not newovim. If someone chooses one of those ways, 'why
| didn't you use neovim's way' isn't a serious question.
|
| (Can we stop hijacking Vim threads? Submit a FPP about neovim.)
| mlyle wrote:
| This is a reasonable question on the discussion of vimscript.
| Does it make sense to have tool-specific languages like this
| anymore?
|
| I don't love lua, but moving to a "standard" scripting
| language has a lot of value.
|
| And neovim proves that lua is viable, so...
| wolverine876 wrote:
| Let's be realistic: If people were really concerned with
| some issues with Vim9Script, they could address them in
| nearly infinite ways. Yet they choose neovim, again, and as
| some standard of truth or excellence (where else is neovim
| a standard of excellence for anything?).
|
| Every Vim discussion has neovim people finding ways to
| attack Vim. The signal is always negative which makes the
| signal meaningless - the source is just tuned to transmit
| negative.
|
| It's a major reason I don't consider neovim. Who wants to
| be involved in that community, defined it seems by hating
| someone else's hard work - which they are giving to the
| public for free - and being parasites on the other's
| reputation. Just do your own thing, in your own way, and do
| something wonderful - don't worry about criticizing others.
| Ugh.
| Taywee wrote:
| I haven't seen what you're saying. I've seen people
| addressing specific problems, and suggesting specific
| solutions, and I really don't understand why neovim isn't
| a reasonable suggestion. Maybe you can point out some of
| these unreasonably negative comments for me.
|
| Neovim is literally people doing their own thing in their
| own way and succeeding. I don't understand your concerns
| or why you don't consider a solution to this problem to
| be viable just because it acknowledges the problem as a
| problem. Sounds a bit kafkaesque to me, to refuse to
| consider a solution because even bringing up the problem
| is considered too negative. How should neovim have done
| it? Do you think they should simply not have bothered?
| augstein wrote:
| I'm neither pro nor against VIM or NeoVIM, but your
| comment is imo completely negative and not helpful at
| all.
|
| I for one are glad for NeoVIM improving upon VIM and
| pointing out some weaknesses.
|
| Since NeoVIM was released, Bram has been improving VIM
| much faster than before and even added features like
| async I/O support, that he previously rejected.
| mlyle wrote:
| The only person I'm seeing here as a reactionary is you.
|
| I love vim. I'm using neovim a fair bit now, too. How
| wonderful is it to be spoiled for choice?
|
| I think it's great we have two vibrant lines of *vim
| development and the opportunity to learn the best lessons
| from each. Here, I think it's a bit of a bummer: neovim
| has proven lua to be pretty decent (as much as I dislike
| lua itself) and this would have been a decent place for
| vim itself to consider following.
|
| As a result, we're going to have a plugins/scripts
| ecosystem that's more fragmented than it needs to be.
| Meh.
| blindseer wrote:
| I have to say that I love vim, and super respect Bram and
| all the other contributors for everything that they have
| done for vim.
|
| There just happens to be some technical choices in vim
| that I don't agree with / don't find appealing, where
| neovim happens to have made an alternate technical choice
| that I do agree with / find appealing. vim9script is one
| of them, which is highly relevant to the submission. I
| apologize if I came across as hating someone else's hard
| work.
|
| My point isn't about being concerned about a specific
| issue with vim9script per say, it's vim9script itself. If
| Bram and a bunch of core vim devs were spending time on
| their _extremely_ valuable time on anything, the last
| thing I'd want it to be would be a vimscript offspring.
| That is just my opinion, and that is truly the extent of
| my opinion. Again, I apologize to Bram and the core devs
| if that came across as anything else.
|
| I have used vim for more than 10 years now (neovim for
| just 2 of those years), and I expect to be using vim /
| neovim for the rest of my life. And having written some
| useful but niche plugins for vim, I felt like expressing
| my opinion here about the direction of vim / vimscript /
| vim9script wasn't unreasonable.
| coliveira wrote:
| Lua is already a supported scripting language in Vim.
| xigoi wrote:
| But it doesn't have first-class support like in Neovim.
| coliveira wrote:
| This is great news. I think Vim9Script is an excellent language.
| Just the fact that it will help speedup existing scripts is going
| to been a boom for Vim usage and plugin development.
| petre wrote:
| So is Lua or Guile. No need for a new extension language with
| bashisms and Java and JS inspired stuff.
| gbrown_ wrote:
| I should start by saying my Vim config is reasonably minimal,
| but I'm highly skeptical of this making plugins noticeably
| faster. How much time are plugins spending executing Vimscript
| vs executing external tools?
| blindseer wrote:
| I don't believe it'll speed up existing plugins though. If I
| remember correctly, vim9script is akin to an entire new
| programming language. Heck, even the syntax for comments has
| changed.
|
| set number " This is a comment in vimscript
|
| set number # This is a comment in vim9script
|
| There's going to be a LOT of porting of existing plugins for
| this to all work.
| capableweb wrote:
| Your comment seems to be at direct odds with
| https://news.ycombinator.com/item?id=29759980
|
| > This is not a breaking change. Everything that works on
| Vim8 script will continue to work.
|
| So seems it won't require much porting unless people want to
| do the porting.
| blindseer wrote:
| You are right, my apologies. Reading through this
| https://vimhelp.org/vim9.txt.html again, it appears that
| you can intermix vimscript and vim9script.
| Daedren wrote:
| Interested to see how this will impact the plugin community, as
| the Neovim maintainer mentioned he wouldn't implement vim9script
| there.
| capableweb wrote:
| More or less furthering the gap we all knew was coming at one
| point or another (opinion from former Vim user but current
| Neovim user). Neovim ecosystem mostly write plugins in Lua by
| now, and most new Vim plugins will probably require something
| from Vim9 Script at one point.
| neurobashing wrote:
| If I had to guess: someone will eventually build a
| transpiler/converter of some sort, most likely vim9->Lua
| (assuming my guess that vim still has more users than Neovim).
| blindseer wrote:
| TJ (one of neovim's core devs) has already started work on
| that: https://github.com/tjdevries/vim9jit
|
| Their twitch streams where they work on this are a lot of fun
| too.
| wolverine876 wrote:
| > help me help AIDS victims -- http://ICCF-Holland.org
|
| What happened to the orphanage in Uganda? Not a criticism, just
| curious about the change. It's fantastic that Bram uses Vim's
| platform to lead and encourage others to support those in need.
| ncmncm wrote:
| AIDS is also a huge problem throughout Africa.
| co_dh wrote:
| I still prefer kakoune, and using sh as scripting language for
| it's simplicity.
| diegocg wrote:
| Kakoune is vi done right. I'm surprised it isn't used more
| often
| drekipus wrote:
| I would love to change but neovin is just too useful for me.
| cassepipe wrote:
| There's a Kakoune like text editor written in Rust that is not
| 1.0 that should worth looking into. It's called Helix
| https://helix-editor.com/
| turminal wrote:
| I feel like vim should really be focusing on other, less shiny
| things. Users that primarily want a shiny editor are already
| using VS code and the like.
| the_duke wrote:
| There is an overview here: https://vimhelp.org/vim9.txt.html
|
| I do question if a breaking change for a custom language is the
| right way to go.
|
| Built in Lua support in Neovim (with LuaJIT) has done wonders for
| the plugin ecosystem.
|
| There is a lot of activity, and a lot of pluings with great
| quality have quickly replaced older ones.
|
| That's no surprise. LuaJIT is fast, much easier to write, has a
| has a sizeable ecosystem and a good LSP server.
|
| Even an overhauled Vimscript won't be anything more than a odd
| niche language with worse performance.
|
| I would have loved for Vim to also adopt Lua and the Lua API from
| Neovim to prevent a complete ecosystem split.
|
| I just don't see how implementing a new language makes sense in
| this context, except for fun.
| coliveira wrote:
| This is not a breaking change. Everything that works on Vim8
| script will continue to work. The new scripting language will
| provide extensions that you can use to get better speed.
|
| > I would have loved for Vim to also adopt Lua
|
| Vim has supported Lua for a long time. Anyone who wants to
| really use Lua for Vim plugins already has the option of doing
| so.
| capableweb wrote:
| > Vim has supported Lua for a long time. Anyone who wants to
| really use Lua for Vim plugins already has the option of
| doing so.
|
| How does that compare to writing Lua plugins for Neovim?
| Seemingly all search results for "write vim plugin in lua"
| are dominated by results for writing lua plugins for neovim.
| Does vanilla Vim have something like Neovim's "Remote Plugin"
| or how does it work?
| blindseer wrote:
| My understanding is that neovim devs would like to see a
| lua interface in vim, but right now there's a lot of
| functions in neovim's lua interface that are not available
| in vim's lua interface.
|
| But for the stuff that is available, you can either use the
| vim help to learn about it or search on vim's github issues
| / PRs, e.g. https://github.com/vim/vim/pull/7959. I'm
| curious if there are other ways to learn more about vim's
| lua interface, searching on google as you said does not
| give great results for vim, just neovim.
| drekipus wrote:
| Vim's Lua interface is through the remote plugins, so you
| could look for that.
|
| Really not sure why you would want to though
___________________________________________________________________
(page generated 2022-01-01 23:02 UTC)