-
-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make command-line execute vim9script without typing vim9cmd #14785
Comments
Well, I just tried
I am not so convinced that this is good suggestion. I think we should rather keep one consistent way for the commandline and not introduce a second method to enter commands (with different syntax and semantics). For command line use, I often don't even adhere to the recommended style guide like adding spaces around assignments, etc. I am rather sloppy there :/ In any case, have you tried the following workaround?
|
I was victime of the same annoyance and this trick is very nice! :) |
Let's say I have a function :call foo#F()
:let foo#x = 1 Is there a way to use Vim 9 script syntax for those? The obvious: :vim9cmd foo.F()
:vim9cmd foo.x = true fail with |
I cannot declare a variable this way:
I get:
But this works:
Are variables declared inside the command-line automatically scoped as global variables? If so, a similar mechanism may apply to Vim9 script variables, allowing us to avoid prefixing each variable with
We already have a second method with different syntax and semantics when one types In my view, Vim9 script is the last great gift Bram left us. It goes without saying that vim9script is more 'user-friendly' compared to the suboptimal legacy script. New users are more likely to adopt Vim9 script if they don’t have to type |
Yes, that's because Regarding the other stuff, I am unsure if we should change it. Let's see what other people think. |
My opinion: the idea of having an option |
Are you referring to lifepillar's reply? If so, one application is to customize a plugin through command-line by directly manipulating its options (maybe for testing). |
There is only upside to my proposal. Introducing Aside: The |
Not really, there are at least 2 issues I can see right now:
For the UI issue that means, people will ask questions or send bug report and we will have to check the I am just trying to weight the benefits vs the costs and I have no opinion yet. That's why I am asking for more opinions.
Well, it's a workaround. I actually find it quite convenient, that it clears the |
Vim9 simplified the language by not supporting the command-line use and supporting only the script level use. For example, in a legacy script the Also, as Chrisitan mentioned in his comment, making this an option will confuse users (as some commands they saw in a forum will not work depending on the option setting). |
If Why would global variables defined in Vim9 syntax enjoy the In short, I don't mind typing |
I think I see both the points and I understand how annoying is to write :vim9cmd while developing plugins (I tend to use the command window when developing, if it may help :) ) But I have something else that is rolling behind my head right now: from a business perspective I have never seen any company (profit or non-profit) that come out with a new version of an existing product and then push for the old version because otherwise users could get confused. This has nothing to do with retro-compatibility which in-fact, is there, alive and kicking ;-). Otherwise, what is the plan to make Vim9 to takeoff if we don't push it? Or the plan is to make plugin developers to use Vim9 but users to stick to vim legacy? I am genuinely curious :) Note that for my specific case is not a big deal one way or the other, but given that different opinions have been requested here are my 2 cents :) |
I was under the impression that supporting vim9script vs legacy script is a matter of switching the parser when parsing command line. At any time, only one language is supported. Does parsing text in command-line (before execution) follow a different mechanism than the parser used to parse script files?
Requiring users to type |
I sympathize with this view. I use Vim9 script and have avoided learning the legacy script because it is not user-friendly. Typing |
I'd say it's not an issue at all. In Vim 9 script, prepending And I now realize that autoloaded names are not resolved because afaik in VIm 9 script you need |
Maybe, a plugin might cover this use case. Proto idea: vim9script
var cmd = input('> ')
execute 'vim9cmd' cmd If I run this script and type |
Well, I guess it ends up as a script-local variable. But yes, it sounds like a great project for a new plugin, you could even make it fancy with popup window or so. In any case, I think nobody here wishes that vim9script does not become successful. I think it is a great scripting language for plugins. I just don't see it that much useful for the commandline, mainly because I am sloppy testing one-off commands and don't adhere to the style guide and the performance advantage is neglectable here. But for any serious newly written plugins, I definitly would recommend to use vim9script. |
The idea of developing a plugin with a command window popup could be nice! Yet, I think there is some misunderstanding on the use-case. That is, say that I am developing a function Once I have secured that my chunk of code is doing what I want, then I copy/paste it in The process of removing all those If it may help, I have the following in my
That, along with the autocmd suggested by @chrisbra at the beginning, smooth things out quite a lot. |
github.com//pull/13670#issuecomment-1857256030 |
I rarely use the command-line during Vim9 script development. I'd rather have a scratch buffer where I type or paste some code, which then I source with Perhaps, Vim 9 script is an opportunity to start using the command line less. Who knows, maybe the command line will follow the fate of Ex mode eventually. |
Perhaps I am missing something about the command line, but I use it quite a bit: :copen, :cnext, :3,15norm! $x, :%y, … are just examples. Is there any trend to use the command line less that I am not aware of? Regarding the scratch buffer: what if you want to step? Shall you define buffer local mappings? Also, with a scratch buffer you lose everything when you close the window. In the command window you have all there… I am just trying to figure out what is the best approach. |
The comment about getting rid of the command line was a bit tongue in cheek. But the point is that the command line is pretty limited as a means to support script development. Some of the limitations wouldn't go away even if the command line provided better support for Vim 9 script (e.g., limited editing possibilities).
You may certainly do that (you may even do it in your current Vim buffer): nnoremap <buffer> <leader>x <scriptcmd>execute 'vim9cmd' getline('.')<cr>+ Vim may also be used in debug mode: see |
There's When I'm working on some new vim9 code, I usually have a named file with code and code snippets with a lot of little test cases and/or functions related to what I'm working on. This play file might be used for days, or be revisited after weeks if things don't go as planned or just to review what I've been working on, or what experiments I've tried, over the last... |
Hi,
On Sat, May 18, 2024 at 12:11 PM Lifepillar ***@***.***> wrote:
The comment about getting rid of the command line was a bit tongue in
cheek. But the point is that the command line is pretty limited as a means
to support script development. Some of the limitations wouldn't go away
even if the command line provided better support for Vim 9 script (e.g.,
limited editing possibilities).
Regarding the scratch buffer: what if you want to step? Shall you define
buffer local mappings?
You may certainly do that (you may even do it in your current Vim buffer):
nnoremap <buffer> <leader>x <scriptcmd>execute 'vim9cmd' getline('.')<cr>+
You can also prefix the "source" command with "vim9cmd" and a range to
source a range
of lines in the current buffer as Vim9 script.
Regards,
Yegappan
|
So why create a scratch buffer in first instance? But then, when you write/close and re-open such a buffer what one shall do? Set again the local mappings and the various options? Or shall write some sort of automatism that sets it automatically? If so how? What tradeoff we shall accept if we want that sort of automatism? Sorry, I may be just aging badly, but just typing @lifepillar Still on the command line: thanks for clarifying that there isn't any sort of "phasing out" plan. But limitations of the command line have been also mentioned. I am perhaps missing something on this point as well. Could anyone elaborate a bit more about such limitations? Other than that, if we go back one second to our initial issue and if I have to express my preference, I would vote for having the command line interpreter set to Vim9 rather than the legacy Vim by default for all the Vim versions > 9.0. :) |
The command-line and the command-line window are line-oriented. |
I don't understand all the issues being discussed or exactly what people want to achieve. I never programed legacy vimscript (except a simple .vimrc). I'm not familiar with what may be the usual vim programmer development environment. And when I see a command line window it is a surprise and I wonder how I got there. (I probably won't forget now; and there's also My point with the flippant
If the settings/mapping are specific to the development work, they can be in the file.
and the highlighted command are executed, the environment should be ready to go. But I'll There's #13156 and #13460 which have some discussion/wishes for vim9 development tools. In the original post, there's
Using a file, highlight I typically run the whole file and don't have much experience with piece wise |
On the contrary, I do see usefulness in using vim9script in commandline:
|
Aside: Please refrain from discussing scratch buffer and other orthogonal stuff. |
There is nothing special about The proposed There is plenty of legacy Vim code under |
There was this comment, which was apparently deleted again:
The fix to this is simple, stick in a |
Disadvantage of having command-lines suddenly interpreted as Vim9 script language : old-timers will have to learn everything all over again (or learn to start every command-line with the word :legacy, or use the autocommand mentioned earlier, but in reverse). I started using Vim when it was at version 6.1, did the vimtutor as it was back then, then followed the evolution into Vim 7 then Vim 8, as Floats, Lists and Dictionaries, among others, were added to the syntax. All the time it was no new language but just an evolution of the same. My vimrc and any plugins I wrote myself are still in Vim8 language and I have no problem with that, in particular no speed problem. I'll learn Vim9 language all in my good time when (and if) I decide to do it, but since I know none of those newfangled programming languages which Vim 9 language is upposed to imitate, the replacement of :let by nothing, of :call by nothing, of "-comments by #-comments, of # by ## to mean the alternate file, etc., adds (for me) "cognitive overload, general weirdness and undesirable ambiguity". Please let me stay with classical Vim script, which I refuse to call a "legacy" as if it were something used by our great-grandparents but discarded long ago. I believe that the weight of numbers is in favour of the old-timers because at any time there are a few newcomers (who will learn the ropes, or depart, $DEITY forbid, if they can't) and a lot of old-timers who already know the old ways and will probably learn the new ways, but all in their good time and not necessarily instantly. Regards, |
I am closing this, as I am not seeing this as a desired change and thus are against such a change. It also seems a bit controversial to other Vim old-timers. |
I just got back to reading some of these comments, and many "old timers" never understood the proposal.
What does this even mean? Unless you set
There is no need for any ":legacy" when vim9 is active. You are manufacturing complexity to discredit my proposal.
Survival bias. New users run to Neovim since Lua looks easier and legacy script is weird and complicated. Not many new users are invested in Vim9script, and thus will not comment. Older users have already learned legacy script out of necessity, or have written plugins and would like to keep them relevant. There is not a single argument against the proposal that passes smell test. I consider closing this proposal unwarranted. |
I suppose what you want is a REPL environment for Vim9 script that can be used for plugin development. |
I like the idea of the proposal, and if it worked well, I would almost certainly use the However, as yegappan explained earlier, vim9script was not designed for command line use, and so it's hard to know how much work would be required to implement it well. A nice way to handle the issue of global scoped variables might be to say that, as there is only global scope when commands are run from the command line, the |
Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
In order to execute vim9script in command-line it has to be prefixed with
vim9cmd
. Even then it does not allow declaring new variables in vim9script.Describe the solution you'd like
Perhaps an option can be set such that command-line switches from interpreting legacy script to vim9script.
Describe alternatives you've considered
None exist, other than cumbersome
vim9cmd
.It would be convenient to have command-line provide first-class support to vim9script.
The text was updated successfully, but these errors were encountered: