I use bang commands quite often, and sometimes I really miss the bash
completion for long arguments. I know I can add custom completion
entries for Vim user-defined commands, but that would get tedious for
someone who uses a lot of tools. Any way to add bash completions to Vim
commands?
Apart from using ":!cmd --arg=val", I use ":grep" quite a lot. I used
to use ripgrep which has short arguments so it's easy to type. But I
have switched to GNU grep and some of its arguments are quite long, eg,
"--exclude" and "--exclude-dir". Any way to complete arguments for Vim
commands that underneath calls external tools?
Enan
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20230901125319.77de913f%40cirdan.
Thursday, August 31, 2023
Re: Vim9 script performance vs. legacy
My (less rigorous) findings were on a Windows 10 machine with a GVim 9.0.1677 that I built myself, but didn't tweak to optimise beforehand. (Stock 64-bit GUI build with Python enabled, built using Ming)
Salman
On Thu, Aug 31, 2023, 15:03 Lifepillar <lifepillar@lifepillar.me> wrote:
On 2023-08-31, Salman Halim <salmanhalim@gmail.com> wrote:
> On Wed, Aug 30, 2023 at 5:25 PM Lifepillar <lifepillar@lifepillar.me> wrote:
>> For a more apples-to-apples comparison, below is the execution time of
>> `libcolor.Neighbours()` from my libcolor library,³ which is a literal
>> translation of a legacy colortemplate#colorspace#k_neighbours() from
>> Colortemplate v2:
>>
>> k | Legacy Vim script | Vim 9 script
>> ---|-------------------|-------------
>> 1 | 73.8 ms | 5.1 ms
>> 10 | 648.4 ms | 42.9 ms
>> 20 | 1164.1 ms | 97.7 ms
>>
>> The advantage of Vim 9 script is very significant. The benchmarking code
>> is at the end of this message for reference.
>>
>
> This is between 11 to 15+ times faster. Interestingly, running it 20 times
> reduced the advantage slightly. Just an anomaly where the CPU started doing
> something else, d'you suppose?
That k is an argument of the function (the function finds the k colors
that are most similar to a given color). Each reported figure is an
average of ten executions. I have not reported (and not computed)
confidence intervals, so 11–15x may just be within noise limits.
Interestingly, I ran those benchmarks on a version of Vim compiled by
myself. If I use my system's Vim I get better results:
k | Legacy Vim script | Vim 9 script
---|-------------------|-------------
1 | 33.1 ms | 4.0 ms
10 | 283.9 ms | 20.7 ms
20 | 512.8 ms | 51.0 ms
The gap narrows a bit: Vim 9 script is 8–10x faster. Still quite a lot.
Now, I have to find out how to optimize my custom build...
Life.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ucqo6c%248i9%241%40ciao.gmane.io.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CANuxnEedoAM08t%2BqFa%3DyNHBxKJ0tc3it8X-F-67K3iwMgAs-Pw%40mail.gmail.com.
Re: Vim9 script performance vs. legacy
On 2023-08-31, Salman Halim <salmanhalim@gmail.com> wrote:
> On Wed, Aug 30, 2023 at 5:25 PM Lifepillar <lifepillar@lifepillar.me> wrote:
>> For a more apples-to-apples comparison, below is the execution time of
>> `libcolor.Neighbours()` from my libcolor library,³ which is a literal
>> translation of a legacy colortemplate#colorspace#k_neighbours() from
>> Colortemplate v2:
>>
>> k | Legacy Vim script | Vim 9 script
>> ---|-------------------|-------------
>> 1 | 73.8 ms | 5.1 ms
>> 10 | 648.4 ms | 42.9 ms
>> 20 | 1164.1 ms | 97.7 ms
>>
>> The advantage of Vim 9 script is very significant. The benchmarking code
>> is at the end of this message for reference.
>>
>
> This is between 11 to 15+ times faster. Interestingly, running it 20 times
> reduced the advantage slightly. Just an anomaly where the CPU started doing
> something else, d'you suppose?
That k is an argument of the function (the function finds the k colors
that are most similar to a given color). Each reported figure is an
average of ten executions. I have not reported (and not computed)
confidence intervals, so 11–15x may just be within noise limits.
Interestingly, I ran those benchmarks on a version of Vim compiled by
myself. If I use my system's Vim I get better results:
k | Legacy Vim script | Vim 9 script
---|-------------------|-------------
1 | 33.1 ms | 4.0 ms
10 | 283.9 ms | 20.7 ms
20 | 512.8 ms | 51.0 ms
The gap narrows a bit: Vim 9 script is 8–10x faster. Still quite a lot.
Now, I have to find out how to optimize my custom build...
Life.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ucqo6c%248i9%241%40ciao.gmane.io.
> On Wed, Aug 30, 2023 at 5:25 PM Lifepillar <lifepillar@lifepillar.me> wrote:
>> For a more apples-to-apples comparison, below is the execution time of
>> `libcolor.Neighbours()` from my libcolor library,³ which is a literal
>> translation of a legacy colortemplate#colorspace#k_neighbours() from
>> Colortemplate v2:
>>
>> k | Legacy Vim script | Vim 9 script
>> ---|-------------------|-------------
>> 1 | 73.8 ms | 5.1 ms
>> 10 | 648.4 ms | 42.9 ms
>> 20 | 1164.1 ms | 97.7 ms
>>
>> The advantage of Vim 9 script is very significant. The benchmarking code
>> is at the end of this message for reference.
>>
>
> This is between 11 to 15+ times faster. Interestingly, running it 20 times
> reduced the advantage slightly. Just an anomaly where the CPU started doing
> something else, d'you suppose?
That k is an argument of the function (the function finds the k colors
that are most similar to a given color). Each reported figure is an
average of ten executions. I have not reported (and not computed)
confidence intervals, so 11–15x may just be within noise limits.
Interestingly, I ran those benchmarks on a version of Vim compiled by
myself. If I use my system's Vim I get better results:
k | Legacy Vim script | Vim 9 script
---|-------------------|-------------
1 | 33.1 ms | 4.0 ms
10 | 283.9 ms | 20.7 ms
20 | 512.8 ms | 51.0 ms
The gap narrows a bit: Vim 9 script is 8–10x faster. Still quite a lot.
Now, I have to find out how to optimize my custom build...
Life.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ucqo6c%248i9%241%40ciao.gmane.io.
Wednesday, August 30, 2023
Re: Vim9 script performance vs. legacy
On Wed, Aug 30, 2023 at 5:25 PM Lifepillar <lifepillar@lifepillar.me> wrote:
I have rewritten Colortemplate v3¹, which is a somewhat complex project,
in Vim 9 script. This is how long it takes to build some sets of color
schemes on my laptop:
Template | Legacy Vim | Vim 9 script
--------------------------------------------
Gruvbox 8 | 17.2s | 3.7s
Solarized 8 | 17.4s | 2.2s
Vim colorschemes²| 20.5s | 3.2s
¹ https://github.com/lifepillar/vim-colortemplate
² https://github.com/vim/colorschemes
And this comparison is a bit apples vs oranges because it was not
a porting, but a complete rewrite. For instance, instead of an hoc
top-down recursive-descent parser, I am now using a parser combinators
library in functional style³—something that would be cumbersome to write
in legacy Vim script, and it would most likely perform horribly.
Functions calls are much more efficient in Vim 9 script.
This is really interesting; the fact that you have a real-life example instead of my contrived test makes your findings more valuable. About five to six times faster, notwithstanding your different implementation approach.
For a more apples-to-apples comparison, below is the execution time of
`libcolor.Neighbours()` from my libcolor library,³ which is a literal
translation of a legacy colortemplate#colorspace#k_neighbours() from
Colortemplate v2:
k | Legacy Vim script | Vim 9 script
---|-------------------|-------------
1 | 73.8 ms | 5.1 ms
10 | 648.4 ms | 42.9 ms
20 | 1164.1 ms | 97.7 ms
The advantage of Vim 9 script is very significant. The benchmarking code
is at the end of this message for reference.
This is between 11 to 15+ times faster. Interestingly, running it 20 times reduced the advantage slightly. Just an anomaly where the CPU started doing something else, d'you suppose?
³ https://github.com/lifepillar/vim-devel
> I find that a significant amount of my script-writing time is used in
> calling functions such as matchlist, popup_create and the such, which seem
> to me to be identical (unless you tell me that Vim 9 has access to more
> optimised version of these).
I believe that built-in functions and commands should mostly show
similar performance.
I expect that, also; unless Vim 9 versions of these are written that are statically typed (which only matters in some cases where an argument could be one of several types), these aren't going to be the factors that determine the response time.
> Maybe the 'for' loop where I iterate over a list of strings is faster in
> Vim 9 because it's both compiled and statically typed?
Likely so. Not an answer to your question, but you may take a look at
some Vim 9 script benchmarks here:
https://github.com/lacygoill/wiki/blob/main/vim/vim9.md
in the "What's the fastest between" section, and maybe compare with
similar loops in legacy Vim script.
Super useful link and pretty much answers a lot of the questions I had, including some I didn't manage to articulate!
From my experience on porting scripts to the new syntax, the stricter
typing rules help finding bugs and write cleaner code. It is a win,
regardless of speed.
I have actually ported a few of my existing scripts over to Vim 9, but I've tried to restrict it to more intensive tasks as legacy scripts are often fast enough for everyday work.
But Vim 9 script also has to coexist with the ecosystem of Vim
functions, and in some cases there is some unavoidable friction, as in
your example. For your specific example, I'd probably wrap the annoying
conversion into a function (did I say that function calls are cheap?):
def PopupLine(lineNumber: string): any
if lineNumber == 'cursor'
return lineNumber
endif
return str2nr(lineNumber)
enddef
Btw, differently from legacy script, an `if` command is not slower than
using `?`: both constructs gets compiled into the same bytecode.
I actually rewrote a routine with a ternary into an if/else earlier today for the sake of readability, but felt like I was damning it to a slower execution cycle while I did it. It's good to know that I might not have sacrificed performance for maintainability.
I have been trying to avoid 'any' as a type because I feel that it loses some of the speed advantages of Vim 9, but it can't always be helped. I had actually come up with version of your PopupLine that uses the fact that str2nr just returns 0 if the conversion fails as this allows more than just a value of 'cursor' (to make it a more generic function):
def GetStrOrNr(in: string): any
if (in == '0')
return 0
endif
var line: number = str2nr( in )
return line == 0 ? in : line
enddef
if (in == '0')
return 0
endif
var line: number = str2nr( in )
return line == 0 ? in : line
enddef
> What do people use for their own stuff these days?
Only Vim 9 script. Bram gave us a wonderful gift, and I am very glad to
see that other developers are actively maintaining it and refining it.
I'm definitely using it for all my new stuff, also. Glad to be in good company.
Happy Vim scripting!
Life.
Thank you for the detailed response. Much appreciated.
All the best,
Salman
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CANuxnEdUGNK0cpBARuamVLbs0b-kTGrW%3DL8kGLLv9GMQm8nBkw%40mail.gmail.com.
Re: Vim9 script performance vs. legacy
On 2023-08-29, Salman Halim <salmanhalim@gmail.com> wrote:
> Hello,
>
> I've been writing my scripts using Vim 9 recently (though without classes)
> and was wondering if anybody had any performance metrics/benchmarks they
> would be willing to share that compare Vim 9's speed compared to the same
> thing written in legacy code.
I have rewritten Colortemplate v3¹, which is a somewhat complex project,
in Vim 9 script. This is how long it takes to build some sets of color
schemes on my laptop:
Template | Legacy Vim | Vim 9 script
--------------------------------------------
Gruvbox 8 | 17.2s | 3.7s
Solarized 8 | 17.4s | 2.2s
Vim colorschemes²| 20.5s | 3.2s
¹ https://github.com/lifepillar/vim-colortemplate
² https://github.com/vim/colorschemes
And this comparison is a bit apples vs oranges because it was not
a porting, but a complete rewrite. For instance, instead of an hoc
top-down recursive-descent parser, I am now using a parser combinators
library in functional style³—something that would be cumbersome to write
in legacy Vim script, and it would most likely perform horribly.
Functions calls are much more efficient in Vim 9 script.
For a more apples-to-apples comparison, below is the execution time of
`libcolor.Neighbours()` from my libcolor library,³ which is a literal
translation of a legacy colortemplate#colorspace#k_neighbours() from
Colortemplate v2:
k | Legacy Vim script | Vim 9 script
---|-------------------|-------------
1 | 73.8 ms | 5.1 ms
10 | 648.4 ms | 42.9 ms
20 | 1164.1 ms | 97.7 ms
The advantage of Vim 9 script is very significant. The benchmarking code
is at the end of this message for reference.
³ https://github.com/lifepillar/vim-devel
> I find that a significant amount of my script-writing time is used in
> calling functions such as matchlist, popup_create and the such, which seem
> to me to be identical (unless you tell me that Vim 9 has access to more
> optimised version of these).
I believe that built-in functions and commands should mostly show
similar performance.
> Maybe the 'for' loop where I iterate over a list of strings is faster in
> Vim 9 because it's both compiled and statically typed?
Likely so. Not an answer to your question, but you may take a look at
some Vim 9 script benchmarks here:
https://github.com/lacygoill/wiki/blob/main/vim/vim9.md
in the "What's the fastest between" section, and maybe compare with
similar loops in legacy Vim script.
> One of the things that caught me recently was that popup_create takes a
> parameter called 'line' which can be either a number or the word 'cursor'.
> It cannot be the STRING '2', it has to be the NUMBER 2 while 'cursor' is a
> string. In legacy script, no problem. Here, I had to make it a string
> variable and then see do something like 'lineNumber != "cursor" ?
> str2nr(lineNumber) : lineNumber' to convert it to a number if needed. i'm
> trying to figure out whether there is a measurable speed advantage to going
> through these motions or if I should just write my scripts in legacy Vim
> script.
From my experience on porting scripts to the new syntax, the stricter
typing rules help finding bugs and write cleaner code. It is a win,
regardless of speed.
But Vim 9 script also has to coexist with the ecosystem of Vim
functions, and in some cases there is some unavoidable friction, as in
your example. For your specific example, I'd probably wrap the annoying
conversion into a function (did I say that function calls are cheap?):
def PopupLine(lineNumber: string): any
if lineNumber == 'cursor'
return lineNumber
endif
return str2nr(lineNumber)
enddef
Btw, differently from legacy script, an `if` command is not slower than
using `?`: both constructs gets compiled into the same bytecode.
> What do people use for their own stuff these days?
Only Vim 9 script. Bram gave us a wonderful gift, and I am very glad to
see that other developers are actively maintaining it and refining it.
Happy Vim scripting!
Life.
---
vim9script
# Benchmarking a naive k-neighbors algorithm
# in legacy Vim script vs Vim 9 script
import 'libcolor.vim' as libcolor
def Benchmark(Fn: func, args: list<any> = [], repeat = 1): float
var i = 0
const start = reltime()
while i < repeat
call(Fn, args)
++i
endwhile
return 1000 * reltime(start)->reltimefloat() / repeat
enddef
const n_repeat = 10
for k in [1, 10, 20]
# Vim 9 script
echomsg Benchmark(libcolor.Neighbours, ['#f54f29', k], n_repeat) "ms"
# Legacy Vim script
echomsg Benchmark(
colortemplate#colorspace#k_neighbours, ['#f54f29', k], n_repeat
) "ms"
endfor
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ucoc3n%24od6%241%40ciao.gmane.io.
> Hello,
>
> I've been writing my scripts using Vim 9 recently (though without classes)
> and was wondering if anybody had any performance metrics/benchmarks they
> would be willing to share that compare Vim 9's speed compared to the same
> thing written in legacy code.
I have rewritten Colortemplate v3¹, which is a somewhat complex project,
in Vim 9 script. This is how long it takes to build some sets of color
schemes on my laptop:
Template | Legacy Vim | Vim 9 script
--------------------------------------------
Gruvbox 8 | 17.2s | 3.7s
Solarized 8 | 17.4s | 2.2s
Vim colorschemes²| 20.5s | 3.2s
¹ https://github.com/lifepillar/vim-colortemplate
² https://github.com/vim/colorschemes
And this comparison is a bit apples vs oranges because it was not
a porting, but a complete rewrite. For instance, instead of an hoc
top-down recursive-descent parser, I am now using a parser combinators
library in functional style³—something that would be cumbersome to write
in legacy Vim script, and it would most likely perform horribly.
Functions calls are much more efficient in Vim 9 script.
For a more apples-to-apples comparison, below is the execution time of
`libcolor.Neighbours()` from my libcolor library,³ which is a literal
translation of a legacy colortemplate#colorspace#k_neighbours() from
Colortemplate v2:
k | Legacy Vim script | Vim 9 script
---|-------------------|-------------
1 | 73.8 ms | 5.1 ms
10 | 648.4 ms | 42.9 ms
20 | 1164.1 ms | 97.7 ms
The advantage of Vim 9 script is very significant. The benchmarking code
is at the end of this message for reference.
³ https://github.com/lifepillar/vim-devel
> I find that a significant amount of my script-writing time is used in
> calling functions such as matchlist, popup_create and the such, which seem
> to me to be identical (unless you tell me that Vim 9 has access to more
> optimised version of these).
I believe that built-in functions and commands should mostly show
similar performance.
> Maybe the 'for' loop where I iterate over a list of strings is faster in
> Vim 9 because it's both compiled and statically typed?
Likely so. Not an answer to your question, but you may take a look at
some Vim 9 script benchmarks here:
https://github.com/lacygoill/wiki/blob/main/vim/vim9.md
in the "What's the fastest between" section, and maybe compare with
similar loops in legacy Vim script.
> One of the things that caught me recently was that popup_create takes a
> parameter called 'line' which can be either a number or the word 'cursor'.
> It cannot be the STRING '2', it has to be the NUMBER 2 while 'cursor' is a
> string. In legacy script, no problem. Here, I had to make it a string
> variable and then see do something like 'lineNumber != "cursor" ?
> str2nr(lineNumber) : lineNumber' to convert it to a number if needed. i'm
> trying to figure out whether there is a measurable speed advantage to going
> through these motions or if I should just write my scripts in legacy Vim
> script.
From my experience on porting scripts to the new syntax, the stricter
typing rules help finding bugs and write cleaner code. It is a win,
regardless of speed.
But Vim 9 script also has to coexist with the ecosystem of Vim
functions, and in some cases there is some unavoidable friction, as in
your example. For your specific example, I'd probably wrap the annoying
conversion into a function (did I say that function calls are cheap?):
def PopupLine(lineNumber: string): any
if lineNumber == 'cursor'
return lineNumber
endif
return str2nr(lineNumber)
enddef
Btw, differently from legacy script, an `if` command is not slower than
using `?`: both constructs gets compiled into the same bytecode.
> What do people use for their own stuff these days?
Only Vim 9 script. Bram gave us a wonderful gift, and I am very glad to
see that other developers are actively maintaining it and refining it.
Happy Vim scripting!
Life.
---
vim9script
# Benchmarking a naive k-neighbors algorithm
# in legacy Vim script vs Vim 9 script
import 'libcolor.vim' as libcolor
def Benchmark(Fn: func, args: list<any> = [], repeat = 1): float
var i = 0
const start = reltime()
while i < repeat
call(Fn, args)
++i
endwhile
return 1000 * reltime(start)->reltimefloat() / repeat
enddef
const n_repeat = 10
for k in [1, 10, 20]
# Vim 9 script
echomsg Benchmark(libcolor.Neighbours, ['#f54f29', k], n_repeat) "ms"
# Legacy Vim script
echomsg Benchmark(
colortemplate#colorspace#k_neighbours, ['#f54f29', k], n_repeat
) "ms"
endfor
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ucoc3n%24od6%241%40ciao.gmane.io.
Re: Vim9 script performance vs. legacy
Amazing! Thank you for doing this benchmarking.
On Tue, Aug 29, 2023 at 6:38 PM Salman Halim <salmanhalim@gmail.com> wrote:
--On Tue, Aug 29, 2023 at 10:33 AM Christian Brabandt <cblists@256bit.org> wrote:
On Di, 29 Aug 2023, Salman Halim wrote:
> Hello,
>
> I've been writing my scripts using Vim 9 recently (though without classes) and
> was wondering if anybody had any performance metrics/benchmarks they would be
> willing to share that compare Vim 9's speed compared to the same thing written
> in legacy code.
>
...
> Maybe the 'for' loop where I iterate over a list of strings is faster in Vim 9
> because it's both compiled and statically typed?
>
...
> What do people use for their own stuff these days?
I haven't done any measurements but I noticed converting to Vim9 script
helps, if you are calling your scripts many times.
So I have rewritten parts of vim-airline for those parts, that are
executed many many times and that are known to cause performance
degrations (see https://github.com/vim-airline/vim-airline/wiki/FAQ)
Best,
ChristianI took matters into my own hands and did a HIGHLY scientific test where I wrote these two functions that just add up the lengths of all the lines in the current file:function! CountLengths()
let total = 0
for i in range( 1, line( '$' ) )
let total += getline( i ) ->strchars()
endfor
return totalendfunctionexport def g:V9CountLengths(): number
var total: number = 0
for i in range( 1, line( '$' ) )
total += getline( i ) ->strchars()
endfor
return total
enddefI tried to keep the implementations as close to identical as possible. Then, I opened up a fairly large file (13 megs) where wordcount() returns:{'chars': 13705032, 'cursor_chars': 1, 'words': 1515632, 'cursor_words': 1, 'bytes': 14136260, 'cursor_bytes': 1} <-- Guess where in the file I had my cursor!I ran the legacy function ONCE (several times to verify) and got a time of 1.5754 seconds, which is definitely noticeable from when I pressed enter and when I got control back. I ran the Vim 9 version and it appeared to finish almost immediately, so I ran it TEN times in a loop and got a total time of 1.272675.Thus, here, the Vim 9 function is more than twelve times faster. This result makes me happy and tells me that I should keep writing in Vim 9.The only reason I can think of to stick with legacy is if people are now concerned about portability with Neovim if they're thinking that now, because of recent sad events, is a time to think about making a move.For the curious, my timing function (legacy Vim, I know):function! HowLong( command, numberOfTimes )
" We don't want to be prompted by a message if the command being tried is an echo as that would slow things down while
" waiting for user input.
let more = &more
set nomore
let startTime = reltime()
for i in range( a:numberOfTimes )
execute a:command
endfor
let result = reltime( startTime )
let &more = more
return result
endfunctionAnd I tested it like this:let g:result = HowLong('call CountLengths()', 1) ->reltimestr()
let g:result9 = HowLong('call V9CountLengths()', 10) ->reltimestr()All the best,Salman
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CANuxnEfC28j7D24rWj2h1EeS-SVaaTuJOQxLHPz2ZNfmLH_WPw%40mail.gmail.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAOmRJrdVPVNyreQ%2BdHNDyHEVc7JLGHOud%2BLjg5xAPeVHB0ymKw%40mail.gmail.com.
Tuesday, August 29, 2023
Re: Vim9 script performance vs. legacy
On Tue, Aug 29, 2023 at 10:33 AM Christian Brabandt <cblists@256bit.org> wrote:
On Di, 29 Aug 2023, Salman Halim wrote:
> Hello,
>
> I've been writing my scripts using Vim 9 recently (though without classes) and
> was wondering if anybody had any performance metrics/benchmarks they would be
> willing to share that compare Vim 9's speed compared to the same thing written
> in legacy code.
>
...
> Maybe the 'for' loop where I iterate over a list of strings is faster in Vim 9
> because it's both compiled and statically typed?
>
...
> What do people use for their own stuff these days?
I haven't done any measurements but I noticed converting to Vim9 script
helps, if you are calling your scripts many times.
So I have rewritten parts of vim-airline for those parts, that are
executed many many times and that are known to cause performance
degrations (see https://github.com/vim-airline/vim-airline/wiki/FAQ)
Best,
Christian
I took matters into my own hands and did a HIGHLY scientific test where I wrote these two functions that just add up the lengths of all the lines in the current file:
let total = 0
for i in range( 1, line( '$' ) )
let total += getline( i ) ->strchars()
endfor
return total
endfunction
export def g:V9CountLengths(): number
var total: number = 0
for i in range( 1, line( '$' ) )
total += getline( i ) ->strchars()
endfor
return total
enddef
var total: number = 0
for i in range( 1, line( '$' ) )
total += getline( i ) ->strchars()
endfor
return total
enddef
I tried to keep the implementations as close to identical as possible. Then, I opened up a fairly large file (13 megs) where wordcount() returns:
{'chars': 13705032, 'cursor_chars': 1, 'words': 1515632, 'cursor_words': 1, 'bytes': 14136260, 'cursor_bytes': 1} <-- Guess where in the file I had my cursor!
I ran the legacy function ONCE (several times to verify) and got a time of 1.5754 seconds, which is definitely noticeable from when I pressed enter and when I got control back. I ran the Vim 9 version and it appeared to finish almost immediately, so I ran it TEN times in a loop and got a total time of 1.272675.
Thus, here, the Vim 9 function is more than twelve times faster. This result makes me happy and tells me that I should keep writing in Vim 9.
The only reason I can think of to stick with legacy is if people are now concerned about portability with Neovim if they're thinking that now, because of recent sad events, is a time to think about making a move.
For the curious, my timing function (legacy Vim, I know):
function! HowLong( command, numberOfTimes )
" We don't want to be prompted by a message if the command being tried is an echo as that would slow things down while
" waiting for user input.
let more = &more
set nomore
let startTime = reltime()
for i in range( a:numberOfTimes )
execute a:command
endfor
let result = reltime( startTime )
let &more = more
return result
endfunction
" We don't want to be prompted by a message if the command being tried is an echo as that would slow things down while
" waiting for user input.
let more = &more
set nomore
let startTime = reltime()
for i in range( a:numberOfTimes )
execute a:command
endfor
let result = reltime( startTime )
let &more = more
return result
endfunction
And I tested it like this:
let g:result = HowLong('call CountLengths()', 1) ->reltimestr()
let g:result9 = HowLong('call V9CountLengths()', 10) ->reltimestr()
let g:result9 = HowLong('call V9CountLengths()', 10) ->reltimestr()
All the best,
Salman
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CANuxnEfC28j7D24rWj2h1EeS-SVaaTuJOQxLHPz2ZNfmLH_WPw%40mail.gmail.com.
Re: Vim9 script performance vs. legacy
On Di, 29 Aug 2023, Salman Halim wrote:
> Hello,
>
> I've been writing my scripts using Vim 9 recently (though without classes) and
> was wondering if anybody had any performance metrics/benchmarks they would be
> willing to share that compare Vim 9's speed compared to the same thing written
> in legacy code.
>
> I find that a significant amount of my script-writing time is used in calling
> functions such as matchlist, popup_create and the such, which seem to me to be
> identical (unless you tell me that Vim 9 has access to more optimised version
> of these).
>
> Maybe the 'for' loop where I iterate over a list of strings is faster in Vim 9
> because it's both compiled and statically typed?
>
> One of the things that caught me recently was that popup_create takes a
> parameter called 'line' which can be either a number or the word 'cursor'. It
> cannot be the STRING '2', it has to be the NUMBER 2 while 'cursor' is a string.
> In legacy script, no problem. Here, I had to make it a string variable and then
> see do something like 'lineNumber != "cursor" ? str2nr(lineNumber) :
> lineNumber' to convert it to a number if needed. i'm trying to figure out
> whether there is a measurable speed advantage to going through these motions or
> if I should just write my scripts in legacy Vim script.
>
> What do people use for their own stuff these days?
I haven't done any measurements but I noticed converting to Vim9 script
helps, if you are calling your scripts many times.
So I have rewritten parts of vim-airline for those parts, that are
executed many many times and that are known to cause performance
degrations (see https://github.com/vim-airline/vim-airline/wiki/FAQ)
Best,
Christian
--
<knghtbrd> add a GF2/3, a sizable hard drive, and a 15" flat panel and
you've got a pretty damned portable machine.
<Coderjoe> a GeForce Two-Thirds?
<knghtbrd> Coderjoe: yes, a GeForce two-thirds, ie, any card from ATI.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ZO4BnSEOwkNkw7Hj%40256bit.org.
> Hello,
>
> I've been writing my scripts using Vim 9 recently (though without classes) and
> was wondering if anybody had any performance metrics/benchmarks they would be
> willing to share that compare Vim 9's speed compared to the same thing written
> in legacy code.
>
> I find that a significant amount of my script-writing time is used in calling
> functions such as matchlist, popup_create and the such, which seem to me to be
> identical (unless you tell me that Vim 9 has access to more optimised version
> of these).
>
> Maybe the 'for' loop where I iterate over a list of strings is faster in Vim 9
> because it's both compiled and statically typed?
>
> One of the things that caught me recently was that popup_create takes a
> parameter called 'line' which can be either a number or the word 'cursor'. It
> cannot be the STRING '2', it has to be the NUMBER 2 while 'cursor' is a string.
> In legacy script, no problem. Here, I had to make it a string variable and then
> see do something like 'lineNumber != "cursor" ? str2nr(lineNumber) :
> lineNumber' to convert it to a number if needed. i'm trying to figure out
> whether there is a measurable speed advantage to going through these motions or
> if I should just write my scripts in legacy Vim script.
>
> What do people use for their own stuff these days?
I haven't done any measurements but I noticed converting to Vim9 script
helps, if you are calling your scripts many times.
So I have rewritten parts of vim-airline for those parts, that are
executed many many times and that are known to cause performance
degrations (see https://github.com/vim-airline/vim-airline/wiki/FAQ)
Best,
Christian
--
<knghtbrd> add a GF2/3, a sizable hard drive, and a 15" flat panel and
you've got a pretty damned portable machine.
<Coderjoe> a GeForce Two-Thirds?
<knghtbrd> Coderjoe: yes, a GeForce two-thirds, ie, any card from ATI.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ZO4BnSEOwkNkw7Hj%40256bit.org.
Vim9 script performance vs. legacy
Hello,
-- I've been writing my scripts using Vim 9 recently (though without classes) and was wondering if anybody had any performance metrics/benchmarks they would be willing to share that compare Vim 9's speed compared to the same thing written in legacy code.
I find that a significant amount of my script-writing time is used in calling functions such as matchlist, popup_create and the such, which seem to me to be identical (unless you tell me that Vim 9 has access to more optimised version of these).
Maybe the 'for' loop where I iterate over a list of strings is faster in Vim 9 because it's both compiled and statically typed?
One of the things that caught me recently was that popup_create takes a parameter called 'line' which can be either a number or the word 'cursor'. It cannot be the STRING '2', it has to be the NUMBER 2 while 'cursor' is a string. In legacy script, no problem. Here, I had to make it a string variable and then see do something like 'lineNumber != "cursor" ? str2nr(lineNumber) : lineNumber' to convert it to a number if needed. i'm trying to figure out whether there is a measurable speed advantage to going through these motions or if I should just write my scripts in legacy Vim script.
What do people use for their own stuff these days?
Thanks so much, everybody.
--
Salman
I, too, shall something make and glory in the making.
Salman
I, too, shall something make and glory in the making.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CANuxnEd%2BPL_-Vfe9U5yNX3WUiRnrbiDQqu%3DHQ9EMWd45koGd_A%40mail.gmail.com.
Monday, August 21, 2023
Re: RIP Bram
Very sad news.
One of the best open source developers, he has given so much to all the community.
Respect.
Very sad to hear.--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/cae319bf-57a1-4213-89c0-6329781a914an%40googlegroups.com.
Un saludo
Best Regards
Pablo Giménez
-- Best Regards
Pablo Giménez
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAKt3ggLY_M8Fct1cSbdO7-QS5cZ3OvrY%3DyQBRubHn%3DK5qYyaVQ%40mail.gmail.com.
Sunday, August 20, 2023
Re: Patch 1766 doesn't exist
On Sun, Aug 20, 2023 at 10:14 PM Christian Brabandt <cblists@256bit.org> wrote:
>
>
> On So, 20 Aug 2023, Tony Mechelynck wrote:
>
> > With all patches in, :version (or vim --version) includes the line
> >
> > Included patches: 1-1765, 1767-1769
> >
> > meaning that there is no patch 1766. I suppose that this is just an
> > oversight and that no Vim user should be alarmed by it.
> >
> > I'm sending this to vim_use to let all users of Vim know that this
> > "missing patch" should probably be no cause for alarm.
>
> Sorry, I must have messed it up when adding the Commit prefix to the
> script. Somehow the mercurial mirror lost some changes. They should now
> be in sync again, but some patches between 1766 - 1775 are probably be
> not in sync with the git patches :/
>
> I apologize for this mess.
>
> Best,
> Christian
> --
> I am not a politician and my other habits are also good.
> -- A. Ward
Yeah, shortly after I sent the above message there came additional
changesets, with a couple of additional missing versions ; then "hg
fetch" refused to merge because there were several outlying heads in
the default branch — so I merged them back manualy as best I could
with each other and with my (few) local changes, and "hg merge" each
time displayed a 3-way vimdiff for src/version.c — to make sure that
the merge took the right copy I made all three buffers equal to what I
thought was wanted — and now Vim says "Included patches: 1-1778". The
latest "hg fetch" pulled and merged without requiring my intervention
so I assume that my clone is OK again.
Oh, BTW : src/version.o has a line for patch 1778 but AFAICT there is
no tag v9.0.1778 known to Mercurial.
Best regards,
Tony.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXuAFLZAzd8cN_TLhTfpof7W1DEZTpoNXWnG7Z5081FB4w%40mail.gmail.com.
>
>
> On So, 20 Aug 2023, Tony Mechelynck wrote:
>
> > With all patches in, :version (or vim --version) includes the line
> >
> > Included patches: 1-1765, 1767-1769
> >
> > meaning that there is no patch 1766. I suppose that this is just an
> > oversight and that no Vim user should be alarmed by it.
> >
> > I'm sending this to vim_use to let all users of Vim know that this
> > "missing patch" should probably be no cause for alarm.
>
> Sorry, I must have messed it up when adding the Commit prefix to the
> script. Somehow the mercurial mirror lost some changes. They should now
> be in sync again, but some patches between 1766 - 1775 are probably be
> not in sync with the git patches :/
>
> I apologize for this mess.
>
> Best,
> Christian
> --
> I am not a politician and my other habits are also good.
> -- A. Ward
Yeah, shortly after I sent the above message there came additional
changesets, with a couple of additional missing versions ; then "hg
fetch" refused to merge because there were several outlying heads in
the default branch — so I merged them back manualy as best I could
with each other and with my (few) local changes, and "hg merge" each
time displayed a 3-way vimdiff for src/version.c — to make sure that
the merge took the right copy I made all three buffers equal to what I
thought was wanted — and now Vim says "Included patches: 1-1778". The
latest "hg fetch" pulled and merged without requiring my intervention
so I assume that my clone is OK again.
Oh, BTW : src/version.o has a line for patch 1778 but AFAICT there is
no tag v9.0.1778 known to Mercurial.
Best regards,
Tony.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXuAFLZAzd8cN_TLhTfpof7W1DEZTpoNXWnG7Z5081FB4w%40mail.gmail.com.
Re: coding with AI in vim (and writing in general)
It's looking good, but it is paid for. I use the chat with a
clipboard. I modify a source code in the chat, then paste it into Vim.
--
Kit
ne 20. 8. 2023 v 15:45 odesílatel Renato Fabbri
<renato.fabbri@gmail.com> napsal:
>
> I found: https://github.com/madox2/vim-ai
> have you used this or something else or what can you say?
> best,
> rf
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/5e36e3e8-1101-42d3-8854-376cff43dfb3n%40googlegroups.com.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAAVKVq-isSVy5dQT74oM4-krdho5Dg1uCJDDA3VTS3F2Fu28dA%40mail.gmail.com.
clipboard. I modify a source code in the chat, then paste it into Vim.
--
Kit
ne 20. 8. 2023 v 15:45 odesílatel Renato Fabbri
<renato.fabbri@gmail.com> napsal:
>
> I found: https://github.com/madox2/vim-ai
> have you used this or something else or what can you say?
> best,
> rf
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/5e36e3e8-1101-42d3-8854-376cff43dfb3n%40googlegroups.com.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAAVKVq-isSVy5dQT74oM4-krdho5Dg1uCJDDA3VTS3F2Fu28dA%40mail.gmail.com.
Re: SOLVED: Vim error message when opening .ini file
I was just assuming that, for example, the string"DARK_BLUE" in the line
"DARK_BLUE = 0,55,218" was supposed to actually be dark blue, and the same for the other color-names in the file.
I'm actually glad to to hear that that notion wrong. I'm not using a standard colorscheme, I've set all (or most) of my color-groups individually in my .vimrc, though I'm still working on my whole color setup..
On Sunday, August 20, 2023 at 3:43:56 PM UTC-4 Enan Ajmain wrote:
On Sun, 20 Aug 2023 11:51:23 -0700 (PDT)
"Melvin Q. Watchpocket" <watch...@gmail.com> wrote:
> On Sunday, August 20, 2023 at 2:42:01 PM UTC-4 Enan Ajmain wrote:
> > Look at Windows Terminal colortool schemes and see if Vim renders it
> > with proper colors:
> > https://github.com/microsoft/terminal/blob/d28b6bf1f2c5a0078e85fe68b3e7ca4c167c4223/src/tools/ColorTool/schemes/campbell.ini
>
> All the color names, to the left of the equal signs and numbers, are green,
> everything in brackets is orange. clearly not the proper colors.
How did you come to that conclusion? AFAI see, that seems correct. The
syntax item to the left of equal sign is dosiniLabel, to the right of
equal sign is dosiniValue, and in brackets is dosiniHeader. Your color
scheme determines what the color is for each of these syntax items.
--
Enan
> Shouldn't the dosini.vim file have fixed that?
> On Sunday, August 20, 2023 at 2:42:01___PM UTC-4 Enan Ajmain wrote:
>
> > On Sun, 20 Aug 2023 10:56:26 -0700 (PDT)
> > "Melvin Q. Watchpocket" <watch...@gmail.com> wrote:
> > > On Sunday, August 20, 2023 at 1:40:32 PM UTC-4 Christian Brabandt wrote:
> > > [...]
> > > > this does not seem to be a typical ini file. Not sure why you are using
> > > > the .ini file extension.
> > >
> > > I'm runing Steve Gibson's DNSBench program under wine.
> > > https://www.grc.com/dns/benchmark.htm
> > >
> > > It automatically creates a custom list of nearby DNS servers *as a .ini
> > > file* and puts it in the same directory as the program.
> >
> > ini files _should_ look similar to toml files. But I have seen many
> > Windows software use ini files to store user configuration, without
> > adhering to general ini format. I myself have done it (if only because
> > I have seen others do it). Don't know what the history of this misuse
> > is.
> >
> > > Before this, I probably have never before opened a .ini file in Vim.
> >
> > Look at Windows Terminal colortool schemes and see if Vim renders it
> > with proper colors:
> >
> > https://github.com/microsoft/terminal/blob/d28b6bf1f2c5a0078e85fe68b3e7ca4c167c4223/src/tools/ColorTool/schemes/campbell.ini
> >
> > --
> > Enan
> >
> > > On Sunday, August 20, 2023 at 1:40:32___PM UTC-4 Christian Brabandt
> > wrote:
> > >
> > > >
> > > > On So, 20 Aug 2023, Melvin Q. Watchpocket wrote:
> > > >
> > > > > OK! This works!
> > > > > I've replaced the old dosini.vim file with yours posted above.
> > > >
> > > > Great to hear.
> > > >
> > > > >
> > > > > Using this file now as my /usr/share/vim/vim90/syntax/dosini.vim
> > file, I
> > > > can open a .ini file WITHOUT getting any error messages.
> > > > >
> > > > > Thank you, Christian!
> > > > >
> > > > > One question: should I be seeing some syntax coloring in a .ini file
> > > > like the one I've opened in Vim? Here is the file, which appears in
> > "black
> > > > & white":
> > > > >
> > > > > 1 127.0.0.53 localhost
> > > >
> > > > 2 4.2.2.2 b.resolvers.level3.net
> > > > > 3 4.2.2.4 d.resolvers.level3.net
> > > > > 4 4.2.2.6 f.resolvers.level3.net
> > > > > 5 64.69.98.35 spr-resolv3-sun.onecommunications.net
> > > > > 6 64.80.255.251 ··· no official Internet DNS name ···
> > > > > 7 64.215.98.148 dns1.lon.gblx.net
> > > > > 8 66.6.65.5 ··· no official Internet DNS name ···
> > > > > 9 66.28.0.45 res1.dns.cogentco.com
> > > > > 10 66.92.159.2 dns.wdc1.speakeasy.net
> > > > > 11 66.109.229.4 dns3.dejazzd.com
> > > > > 12 66.153.50.66 dns1-nyc.paetec.net
> > > > > 13 68.237.161.12 nsnyny01.verizon.net
> > > > > 14 74.82.42.42 ordns.he.net
> > > > > 15 129.250.35.250 x.ns.gin.ntt.net
> > > > > 16 129.250.35.251 y.ns.gin.ntt.net
> > > > > 17 151.197.0.37 world4.bellatlantic.net
> > > > > 18 151.198.0.38 nsnwrk.bellatlantic.net
> > > > > 19 151.198.0.39 home5.bellatlantic.net
> > > > > 20 151.201.0.38 nspitt.bellatlantic.net
> > > >
> > > > this does not seem to be a typical ini file. Not sure why you are using
> > > > the .ini file extension.
> > > >
> > > > Best,
> > > > Christian
> > > > --
> > > > You will be winged by an anti-aircraft battery.
> > > >
> > >
> >
>
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/74b3557f-c461-4d8c-813e-f09ce7ec0046n%40googlegroups.com.
Re: Patch 1766 doesn't exist
On So, 20 Aug 2023, Tony Mechelynck wrote:
> With all patches in, :version (or vim --version) includes the line
>
> Included patches: 1-1765, 1767-1769
>
> meaning that there is no patch 1766. I suppose that this is just an
> oversight and that no Vim user should be alarmed by it.
>
> I'm sending this to vim_use to let all users of Vim know that this
> "missing patch" should probably be no cause for alarm.
Sorry, I must have messed it up when adding the Commit prefix to the
script. Somehow the mercurial mirror lost some changes. They should now
be in sync again, but some patches between 1766 - 1775 are probably be
not in sync with the git patches :/
I apologize for this mess.
Best,
Christian
--
I am not a politician and my other habits are also good.
-- A. Ward
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ZOJ0PkjPShNtdLJ/%40256bit.org.
> With all patches in, :version (or vim --version) includes the line
>
> Included patches: 1-1765, 1767-1769
>
> meaning that there is no patch 1766. I suppose that this is just an
> oversight and that no Vim user should be alarmed by it.
>
> I'm sending this to vim_use to let all users of Vim know that this
> "missing patch" should probably be no cause for alarm.
Sorry, I must have messed it up when adding the Commit prefix to the
script. Somehow the mercurial mirror lost some changes. They should now
be in sync again, but some patches between 1766 - 1775 are probably be
not in sync with the git patches :/
I apologize for this mess.
Best,
Christian
--
I am not a politician and my other habits are also good.
-- A. Ward
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ZOJ0PkjPShNtdLJ/%40256bit.org.
Re: SOLVED: Vim error message when opening .ini file
On Sun, 20 Aug 2023 11:51:23 -0700 (PDT)
"Melvin Q. Watchpocket" <watchpacket@gmail.com> wrote:
> On Sunday, August 20, 2023 at 2:42:01 PM UTC-4 Enan Ajmain wrote:
> > Look at Windows Terminal colortool schemes and see if Vim renders it
> > with proper colors:
> > https://github.com/microsoft/terminal/blob/d28b6bf1f2c5a0078e85fe68b3e7ca4c167c4223/src/tools/ColorTool/schemes/campbell.ini
>
> All the color names, to the left of the equal signs and numbers, are green,
> everything in brackets is orange. clearly not the proper colors.
How did you come to that conclusion? AFAI see, that seems correct. The
syntax item to the left of equal sign is dosiniLabel, to the right of
equal sign is dosiniValue, and in brackets is dosiniHeader. Your color
scheme determines what the color is for each of these syntax items.
--
Enan
> Shouldn't the dosini.vim file have fixed that?
> On Sunday, August 20, 2023 at 2:42:01___PM UTC-4 Enan Ajmain wrote:
>
> > On Sun, 20 Aug 2023 10:56:26 -0700 (PDT)
> > "Melvin Q. Watchpocket" <watch...@gmail.com> wrote:
> > > On Sunday, August 20, 2023 at 1:40:32 PM UTC-4 Christian Brabandt wrote:
> > > [...]
> > > > this does not seem to be a typical ini file. Not sure why you are using
> > > > the .ini file extension.
> > >
> > > I'm runing Steve Gibson's DNSBench program under wine.
> > > https://www.grc.com/dns/benchmark.htm
> > >
> > > It automatically creates a custom list of nearby DNS servers *as a .ini
> > > file* and puts it in the same directory as the program.
> >
> > ini files _should_ look similar to toml files. But I have seen many
> > Windows software use ini files to store user configuration, without
> > adhering to general ini format. I myself have done it (if only because
> > I have seen others do it). Don't know what the history of this misuse
> > is.
> >
> > > Before this, I probably have never before opened a .ini file in Vim.
> >
> > Look at Windows Terminal colortool schemes and see if Vim renders it
> > with proper colors:
> >
> > https://github.com/microsoft/terminal/blob/d28b6bf1f2c5a0078e85fe68b3e7ca4c167c4223/src/tools/ColorTool/schemes/campbell.ini
> >
> > --
> > Enan
> >
> > > On Sunday, August 20, 2023 at 1:40:32___PM UTC-4 Christian Brabandt
> > wrote:
> > >
> > > >
> > > > On So, 20 Aug 2023, Melvin Q. Watchpocket wrote:
> > > >
> > > > > OK! This works!
> > > > > I've replaced the old dosini.vim file with yours posted above.
> > > >
> > > > Great to hear.
> > > >
> > > > >
> > > > > Using this file now as my /usr/share/vim/vim90/syntax/dosini.vim
> > file, I
> > > > can open a .ini file WITHOUT getting any error messages.
> > > > >
> > > > > Thank you, Christian!
> > > > >
> > > > > One question: should I be seeing some syntax coloring in a .ini file
> > > > like the one I've opened in Vim? Here is the file, which appears in
> > "black
> > > > & white":
> > > > >
> > > > > 1 127.0.0.53 localhost
> > > >
> > > > 2 4.2.2.2 b.resolvers.level3.net
> > > > > 3 4.2.2.4 d.resolvers.level3.net
> > > > > 4 4.2.2.6 f.resolvers.level3.net
> > > > > 5 64.69.98.35 spr-resolv3-sun.onecommunications.net
> > > > > 6 64.80.255.251 ··· no official Internet DNS name ···
> > > > > 7 64.215.98.148 dns1.lon.gblx.net
> > > > > 8 66.6.65.5 ··· no official Internet DNS name ···
> > > > > 9 66.28.0.45 res1.dns.cogentco.com
> > > > > 10 66.92.159.2 dns.wdc1.speakeasy.net
> > > > > 11 66.109.229.4 dns3.dejazzd.com
> > > > > 12 66.153.50.66 dns1-nyc.paetec.net
> > > > > 13 68.237.161.12 nsnyny01.verizon.net
> > > > > 14 74.82.42.42 ordns.he.net
> > > > > 15 129.250.35.250 x.ns.gin.ntt.net
> > > > > 16 129.250.35.251 y.ns.gin.ntt.net
> > > > > 17 151.197.0.37 world4.bellatlantic.net
> > > > > 18 151.198.0.38 nsnwrk.bellatlantic.net
> > > > > 19 151.198.0.39 home5.bellatlantic.net
> > > > > 20 151.201.0.38 nspitt.bellatlantic.net
> > > >
> > > > this does not seem to be a typical ini file. Not sure why you are using
> > > > the .ini file extension.
> > > >
> > > > Best,
> > > > Christian
> > > > --
> > > > You will be winged by an anti-aircraft battery.
> > > >
> > >
> >
>
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20230821014342.00003c13%40gmail.com.
"Melvin Q. Watchpocket" <watchpacket@gmail.com> wrote:
> On Sunday, August 20, 2023 at 2:42:01 PM UTC-4 Enan Ajmain wrote:
> > Look at Windows Terminal colortool schemes and see if Vim renders it
> > with proper colors:
> > https://github.com/microsoft/terminal/blob/d28b6bf1f2c5a0078e85fe68b3e7ca4c167c4223/src/tools/ColorTool/schemes/campbell.ini
>
> All the color names, to the left of the equal signs and numbers, are green,
> everything in brackets is orange. clearly not the proper colors.
How did you come to that conclusion? AFAI see, that seems correct. The
syntax item to the left of equal sign is dosiniLabel, to the right of
equal sign is dosiniValue, and in brackets is dosiniHeader. Your color
scheme determines what the color is for each of these syntax items.
--
Enan
> Shouldn't the dosini.vim file have fixed that?
> On Sunday, August 20, 2023 at 2:42:01___PM UTC-4 Enan Ajmain wrote:
>
> > On Sun, 20 Aug 2023 10:56:26 -0700 (PDT)
> > "Melvin Q. Watchpocket" <watch...@gmail.com> wrote:
> > > On Sunday, August 20, 2023 at 1:40:32 PM UTC-4 Christian Brabandt wrote:
> > > [...]
> > > > this does not seem to be a typical ini file. Not sure why you are using
> > > > the .ini file extension.
> > >
> > > I'm runing Steve Gibson's DNSBench program under wine.
> > > https://www.grc.com/dns/benchmark.htm
> > >
> > > It automatically creates a custom list of nearby DNS servers *as a .ini
> > > file* and puts it in the same directory as the program.
> >
> > ini files _should_ look similar to toml files. But I have seen many
> > Windows software use ini files to store user configuration, without
> > adhering to general ini format. I myself have done it (if only because
> > I have seen others do it). Don't know what the history of this misuse
> > is.
> >
> > > Before this, I probably have never before opened a .ini file in Vim.
> >
> > Look at Windows Terminal colortool schemes and see if Vim renders it
> > with proper colors:
> >
> > https://github.com/microsoft/terminal/blob/d28b6bf1f2c5a0078e85fe68b3e7ca4c167c4223/src/tools/ColorTool/schemes/campbell.ini
> >
> > --
> > Enan
> >
> > > On Sunday, August 20, 2023 at 1:40:32___PM UTC-4 Christian Brabandt
> > wrote:
> > >
> > > >
> > > > On So, 20 Aug 2023, Melvin Q. Watchpocket wrote:
> > > >
> > > > > OK! This works!
> > > > > I've replaced the old dosini.vim file with yours posted above.
> > > >
> > > > Great to hear.
> > > >
> > > > >
> > > > > Using this file now as my /usr/share/vim/vim90/syntax/dosini.vim
> > file, I
> > > > can open a .ini file WITHOUT getting any error messages.
> > > > >
> > > > > Thank you, Christian!
> > > > >
> > > > > One question: should I be seeing some syntax coloring in a .ini file
> > > > like the one I've opened in Vim? Here is the file, which appears in
> > "black
> > > > & white":
> > > > >
> > > > > 1 127.0.0.53 localhost
> > > >
> > > > 2 4.2.2.2 b.resolvers.level3.net
> > > > > 3 4.2.2.4 d.resolvers.level3.net
> > > > > 4 4.2.2.6 f.resolvers.level3.net
> > > > > 5 64.69.98.35 spr-resolv3-sun.onecommunications.net
> > > > > 6 64.80.255.251 ··· no official Internet DNS name ···
> > > > > 7 64.215.98.148 dns1.lon.gblx.net
> > > > > 8 66.6.65.5 ··· no official Internet DNS name ···
> > > > > 9 66.28.0.45 res1.dns.cogentco.com
> > > > > 10 66.92.159.2 dns.wdc1.speakeasy.net
> > > > > 11 66.109.229.4 dns3.dejazzd.com
> > > > > 12 66.153.50.66 dns1-nyc.paetec.net
> > > > > 13 68.237.161.12 nsnyny01.verizon.net
> > > > > 14 74.82.42.42 ordns.he.net
> > > > > 15 129.250.35.250 x.ns.gin.ntt.net
> > > > > 16 129.250.35.251 y.ns.gin.ntt.net
> > > > > 17 151.197.0.37 world4.bellatlantic.net
> > > > > 18 151.198.0.38 nsnwrk.bellatlantic.net
> > > > > 19 151.198.0.39 home5.bellatlantic.net
> > > > > 20 151.201.0.38 nspitt.bellatlantic.net
> > > >
> > > > this does not seem to be a typical ini file. Not sure why you are using
> > > > the .ini file extension.
> > > >
> > > > Best,
> > > > Christian
> > > > --
> > > > You will be winged by an anti-aircraft battery.
> > > >
> > >
> >
>
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20230821014342.00003c13%40gmail.com.
Patch 1766 doesn't exist
With all patches in, :version (or vim --version) includes the line
Included patches: 1-1765, 1767-1769
meaning that there is no patch 1766. I suppose that this is just an
oversight and that no Vim user should be alarmed by it.
I'm sending this to vim_use to let all users of Vim know that this
"missing patch" should probably be no cause for alarm.
Best regards,
Tony.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXsF9nptN3L%2B2Xgc4K755zk-x1isdfmhhmaRhnhMCHfykg%40mail.gmail.com.
Included patches: 1-1765, 1767-1769
meaning that there is no patch 1766. I suppose that this is just an
oversight and that no Vim user should be alarmed by it.
I'm sending this to vim_use to let all users of Vim know that this
"missing patch" should probably be no cause for alarm.
Best regards,
Tony.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXsF9nptN3L%2B2Xgc4K755zk-x1isdfmhhmaRhnhMCHfykg%40mail.gmail.com.
Re: SOLVED: Vim error message when opening .ini file
All the color names, to the left of the equal signs and numbers, are green, everything in brackets is orange. clearly not the proper colors. Shouldn't the dosini.vim file have fixed that?
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/2f731d77-3096-4514-acaa-63a02d8ad35bn%40googlegroups.com.
On Sunday, August 20, 2023 at 2:42:01 PM UTC-4 Enan Ajmain wrote:
On Sun, 20 Aug 2023 10:56:26 -0700 (PDT)
"Melvin Q. Watchpocket" <watch...@gmail.com> wrote:
> On Sunday, August 20, 2023 at 1:40:32 PM UTC-4 Christian Brabandt wrote:
> [...]
> > this does not seem to be a typical ini file. Not sure why you are using
> > the .ini file extension.
>
> I'm runing Steve Gibson's DNSBench program under wine.
> https://www.grc.com/dns/benchmark.htm
>
> It automatically creates a custom list of nearby DNS servers *as a .ini
> file* and puts it in the same directory as the program.
ini files _should_ look similar to toml files. But I have seen many
Windows software use ini files to store user configuration, without
adhering to general ini format. I myself have done it (if only because
I have seen others do it). Don't know what the history of this misuse
is.
> Before this, I probably have never before opened a .ini file in Vim.
Look at Windows Terminal colortool schemes and see if Vim renders it
with proper colors:
https://github.com/microsoft/terminal/blob/d28b6bf1f2c5a0078e85fe68b3e7ca4c167c4223/src/tools/ColorTool/schemes/campbell.ini
--
Enan
> On Sunday, August 20, 2023 at 1:40:32___PM UTC-4 Christian Brabandt wrote:
>
> >
> > On So, 20 Aug 2023, Melvin Q. Watchpocket wrote:
> >
> > > OK! This works!
> > > I've replaced the old dosini.vim file with yours posted above.
> >
> > Great to hear.
> >
> > >
> > > Using this file now as my /usr/share/vim/vim90/syntax/dosini.vim file, I
> > can open a .ini file WITHOUT getting any error messages.
> > >
> > > Thank you, Christian!
> > >
> > > One question: should I be seeing some syntax coloring in a .ini file
> > like the one I've opened in Vim? Here is the file, which appears in "black
> > & white":
> > >
> > > 1 127.0.0.53 localhost
> >
> > 2 4.2.2.2 b.resolvers.level3.net
> > > 3 4.2.2.4 d.resolvers.level3.net
> > > 4 4.2.2.6 f.resolvers.level3.net
> > > 5 64.69.98.35 spr-resolv3-sun.onecommunications.net
> > > 6 64.80.255.251 ··· no official Internet DNS name ···
> > > 7 64.215.98.148 dns1.lon.gblx.net
> > > 8 66.6.65.5 ··· no official Internet DNS name ···
> > > 9 66.28.0.45 res1.dns.cogentco.com
> > > 10 66.92.159.2 dns.wdc1.speakeasy.net
> > > 11 66.109.229.4 dns3.dejazzd.com
> > > 12 66.153.50.66 dns1-nyc.paetec.net
> > > 13 68.237.161.12 nsnyny01.verizon.net
> > > 14 74.82.42.42 ordns.he.net
> > > 15 129.250.35.250 x.ns.gin.ntt.net
> > > 16 129.250.35.251 y.ns.gin.ntt.net
> > > 17 151.197.0.37 world4.bellatlantic.net
> > > 18 151.198.0.38 nsnwrk.bellatlantic.net
> > > 19 151.198.0.39 home5.bellatlantic.net
> > > 20 151.201.0.38 nspitt.bellatlantic.net
> >
> > this does not seem to be a typical ini file. Not sure why you are using
> > the .ini file extension.
> >
> > Best,
> > Christian
> > --
> > You will be winged by an anti-aircraft battery.
> >
>
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/2f731d77-3096-4514-acaa-63a02d8ad35bn%40googlegroups.com.
Re: SOLVED: Vim error message when opening .ini file
On Sun, 20 Aug 2023 10:56:26 -0700 (PDT)
"Melvin Q. Watchpocket" <watchpacket@gmail.com> wrote:
> On Sunday, August 20, 2023 at 1:40:32 PM UTC-4 Christian Brabandt wrote:
> [...]
> > this does not seem to be a typical ini file. Not sure why you are using
> > the .ini file extension.
>
> I'm runing Steve Gibson's DNSBench program under wine.
> https://www.grc.com/dns/benchmark.htm
>
> It automatically creates a custom list of nearby DNS servers *as a .ini
> file* and puts it in the same directory as the program.
ini files _should_ look similar to toml files. But I have seen many
Windows software use ini files to store user configuration, without
adhering to general ini format. I myself have done it (if only because
I have seen others do it). Don't know what the history of this misuse
is.
> Before this, I probably have never before opened a .ini file in Vim.
Look at Windows Terminal colortool schemes and see if Vim renders it
with proper colors:
https://github.com/microsoft/terminal/blob/d28b6bf1f2c5a0078e85fe68b3e7ca4c167c4223/src/tools/ColorTool/schemes/campbell.ini
--
Enan
> On Sunday, August 20, 2023 at 1:40:32___PM UTC-4 Christian Brabandt wrote:
>
> >
> > On So, 20 Aug 2023, Melvin Q. Watchpocket wrote:
> >
> > > OK! This works!
> > > I've replaced the old dosini.vim file with yours posted above.
> >
> > Great to hear.
> >
> > >
> > > Using this file now as my /usr/share/vim/vim90/syntax/dosini.vim file, I
> > can open a .ini file WITHOUT getting any error messages.
> > >
> > > Thank you, Christian!
> > >
> > > One question: should I be seeing some syntax coloring in a .ini file
> > like the one I've opened in Vim? Here is the file, which appears in "black
> > & white":
> > >
> > > 1 127.0.0.53 localhost
> >
> > 2 4.2.2.2 b.resolvers.level3.net
> > > 3 4.2.2.4 d.resolvers.level3.net
> > > 4 4.2.2.6 f.resolvers.level3.net
> > > 5 64.69.98.35 spr-resolv3-sun.onecommunications.net
> > > 6 64.80.255.251 ··· no official Internet DNS name ···
> > > 7 64.215.98.148 dns1.lon.gblx.net
> > > 8 66.6.65.5 ··· no official Internet DNS name ···
> > > 9 66.28.0.45 res1.dns.cogentco.com
> > > 10 66.92.159.2 dns.wdc1.speakeasy.net
> > > 11 66.109.229.4 dns3.dejazzd.com
> > > 12 66.153.50.66 dns1-nyc.paetec.net
> > > 13 68.237.161.12 nsnyny01.verizon.net
> > > 14 74.82.42.42 ordns.he.net
> > > 15 129.250.35.250 x.ns.gin.ntt.net
> > > 16 129.250.35.251 y.ns.gin.ntt.net
> > > 17 151.197.0.37 world4.bellatlantic.net
> > > 18 151.198.0.38 nsnwrk.bellatlantic.net
> > > 19 151.198.0.39 home5.bellatlantic.net
> > > 20 151.201.0.38 nspitt.bellatlantic.net
> >
> > this does not seem to be a typical ini file. Not sure why you are using
> > the .ini file extension.
> >
> > Best,
> > Christian
> > --
> > You will be winged by an anti-aircraft battery.
> >
>
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20230821004149.00003878%40gmail.com.
"Melvin Q. Watchpocket" <watchpacket@gmail.com> wrote:
> On Sunday, August 20, 2023 at 1:40:32 PM UTC-4 Christian Brabandt wrote:
> [...]
> > this does not seem to be a typical ini file. Not sure why you are using
> > the .ini file extension.
>
> I'm runing Steve Gibson's DNSBench program under wine.
> https://www.grc.com/dns/benchmark.htm
>
> It automatically creates a custom list of nearby DNS servers *as a .ini
> file* and puts it in the same directory as the program.
ini files _should_ look similar to toml files. But I have seen many
Windows software use ini files to store user configuration, without
adhering to general ini format. I myself have done it (if only because
I have seen others do it). Don't know what the history of this misuse
is.
> Before this, I probably have never before opened a .ini file in Vim.
Look at Windows Terminal colortool schemes and see if Vim renders it
with proper colors:
https://github.com/microsoft/terminal/blob/d28b6bf1f2c5a0078e85fe68b3e7ca4c167c4223/src/tools/ColorTool/schemes/campbell.ini
--
Enan
> On Sunday, August 20, 2023 at 1:40:32___PM UTC-4 Christian Brabandt wrote:
>
> >
> > On So, 20 Aug 2023, Melvin Q. Watchpocket wrote:
> >
> > > OK! This works!
> > > I've replaced the old dosini.vim file with yours posted above.
> >
> > Great to hear.
> >
> > >
> > > Using this file now as my /usr/share/vim/vim90/syntax/dosini.vim file, I
> > can open a .ini file WITHOUT getting any error messages.
> > >
> > > Thank you, Christian!
> > >
> > > One question: should I be seeing some syntax coloring in a .ini file
> > like the one I've opened in Vim? Here is the file, which appears in "black
> > & white":
> > >
> > > 1 127.0.0.53 localhost
> >
> > 2 4.2.2.2 b.resolvers.level3.net
> > > 3 4.2.2.4 d.resolvers.level3.net
> > > 4 4.2.2.6 f.resolvers.level3.net
> > > 5 64.69.98.35 spr-resolv3-sun.onecommunications.net
> > > 6 64.80.255.251 ··· no official Internet DNS name ···
> > > 7 64.215.98.148 dns1.lon.gblx.net
> > > 8 66.6.65.5 ··· no official Internet DNS name ···
> > > 9 66.28.0.45 res1.dns.cogentco.com
> > > 10 66.92.159.2 dns.wdc1.speakeasy.net
> > > 11 66.109.229.4 dns3.dejazzd.com
> > > 12 66.153.50.66 dns1-nyc.paetec.net
> > > 13 68.237.161.12 nsnyny01.verizon.net
> > > 14 74.82.42.42 ordns.he.net
> > > 15 129.250.35.250 x.ns.gin.ntt.net
> > > 16 129.250.35.251 y.ns.gin.ntt.net
> > > 17 151.197.0.37 world4.bellatlantic.net
> > > 18 151.198.0.38 nsnwrk.bellatlantic.net
> > > 19 151.198.0.39 home5.bellatlantic.net
> > > 20 151.201.0.38 nspitt.bellatlantic.net
> >
> > this does not seem to be a typical ini file. Not sure why you are using
> > the .ini file extension.
> >
> > Best,
> > Christian
> > --
> > You will be winged by an anti-aircraft battery.
> >
>
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20230821004149.00003878%40gmail.com.
Re: SOLVED: Vim error message when opening .ini file
I'm runing Steve Gibson's DNSBench program under wine.
https://www.grc.com/dns/benchmark.htmIt automatically creates a custom list of nearby DNS servers as a .ini file and puts it in the same directory as the program.
Before this, I probably have never before opened a .ini file in Vim.
On Sunday, August 20, 2023 at 1:40:32 PM UTC-4 Christian Brabandt wrote:
On So, 20 Aug 2023, Melvin Q. Watchpocket wrote:
> OK! This works!
> I've replaced the old dosini.vim file with yours posted above.
Great to hear.
>
> Using this file now as my /usr/share/vim/vim90/syntax/dosini.vim file, I can open a .ini file WITHOUT getting any error messages.
>
> Thank you, Christian!
>
> One question: should I be seeing some syntax coloring in a .ini file like the one I've opened in Vim? Here is the file, which appears in "black & white":
>
> 1 127.0.0.53 localhost 2 4.2.2.2 b.resolvers.level3.net
> 3 4.2.2.4 d.resolvers.level3.net
> 4 4.2.2.6 f.resolvers.level3.net
> 5 64.69.98.35 spr-resolv3-sun.onecommunications.net
> 6 64.80.255.251 ··· no official Internet DNS name ···
> 7 64.215.98.148 dns1.lon.gblx.net
> 8 66.6.65.5 ··· no official Internet DNS name ···
> 9 66.28.0.45 res1.dns.cogentco.com
> 10 66.92.159.2 dns.wdc1.speakeasy.net
> 11 66.109.229.4 dns3.dejazzd.com
> 12 66.153.50.66 dns1-nyc.paetec.net
> 13 68.237.161.12 nsnyny01.verizon.net
> 14 74.82.42.42 ordns.he.net
> 15 129.250.35.250 x.ns.gin.ntt.net
> 16 129.250.35.251 y.ns.gin.ntt.net
> 17 151.197.0.37 world4.bellatlantic.net
> 18 151.198.0.38 nsnwrk.bellatlantic.net
> 19 151.198.0.39 home5.bellatlantic.net
> 20 151.201.0.38 nspitt.bellatlantic.net
this does not seem to be a typical ini file. Not sure why you are using
the .ini file extension.
Best,
Christian
--
You will be winged by an anti-aircraft battery.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/f2f5b3e1-eb4e-4d48-94e3-8a55384feb29n%40googlegroups.com.
Re: SOLVED: Vim error message when opening .ini file
On So, 20 Aug 2023, Melvin Q. Watchpocket wrote:
> OK! This works!
> I've replaced the old dosini.vim file with yours posted above.
Great to hear.
>
> Using this file now as my /usr/share/vim/vim90/syntax/dosini.vim file, I can open a .ini file WITHOUT getting any error messages.
>
> Thank you, Christian!
>
> One question: should I be seeing some syntax coloring in a .ini file like the one I've opened in Vim? Here is the file, which appears in "black & white":
>
> 1 127.0.0.53 localhost 2 4.2.2.2 b.resolvers.level3.net
> 3 4.2.2.4 d.resolvers.level3.net
> 4 4.2.2.6 f.resolvers.level3.net
> 5 64.69.98.35 spr-resolv3-sun.onecommunications.net
> 6 64.80.255.251 ··· no official Internet DNS name ···
> 7 64.215.98.148 dns1.lon.gblx.net
> 8 66.6.65.5 ··· no official Internet DNS name ···
> 9 66.28.0.45 res1.dns.cogentco.com
> 10 66.92.159.2 dns.wdc1.speakeasy.net
> 11 66.109.229.4 dns3.dejazzd.com
> 12 66.153.50.66 dns1-nyc.paetec.net
> 13 68.237.161.12 nsnyny01.verizon.net
> 14 74.82.42.42 ordns.he.net
> 15 129.250.35.250 x.ns.gin.ntt.net
> 16 129.250.35.251 y.ns.gin.ntt.net
> 17 151.197.0.37 world4.bellatlantic.net
> 18 151.198.0.38 nsnwrk.bellatlantic.net
> 19 151.198.0.39 home5.bellatlantic.net
> 20 151.201.0.38 nspitt.bellatlantic.net
this does not seem to be a typical ini file. Not sure why you are using
the .ini file extension.
Best,
Christian
--
You will be winged by an anti-aircraft battery.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ZOJQB4M59ASRpUDJ%40256bit.org.
> OK! This works!
> I've replaced the old dosini.vim file with yours posted above.
Great to hear.
>
> Using this file now as my /usr/share/vim/vim90/syntax/dosini.vim file, I can open a .ini file WITHOUT getting any error messages.
>
> Thank you, Christian!
>
> One question: should I be seeing some syntax coloring in a .ini file like the one I've opened in Vim? Here is the file, which appears in "black & white":
>
> 1 127.0.0.53 localhost 2 4.2.2.2 b.resolvers.level3.net
> 3 4.2.2.4 d.resolvers.level3.net
> 4 4.2.2.6 f.resolvers.level3.net
> 5 64.69.98.35 spr-resolv3-sun.onecommunications.net
> 6 64.80.255.251 ··· no official Internet DNS name ···
> 7 64.215.98.148 dns1.lon.gblx.net
> 8 66.6.65.5 ··· no official Internet DNS name ···
> 9 66.28.0.45 res1.dns.cogentco.com
> 10 66.92.159.2 dns.wdc1.speakeasy.net
> 11 66.109.229.4 dns3.dejazzd.com
> 12 66.153.50.66 dns1-nyc.paetec.net
> 13 68.237.161.12 nsnyny01.verizon.net
> 14 74.82.42.42 ordns.he.net
> 15 129.250.35.250 x.ns.gin.ntt.net
> 16 129.250.35.251 y.ns.gin.ntt.net
> 17 151.197.0.37 world4.bellatlantic.net
> 18 151.198.0.38 nsnwrk.bellatlantic.net
> 19 151.198.0.39 home5.bellatlantic.net
> 20 151.201.0.38 nspitt.bellatlantic.net
this does not seem to be a typical ini file. Not sure why you are using
the .ini file extension.
Best,
Christian
--
You will be winged by an anti-aircraft battery.
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/ZOJQB4M59ASRpUDJ%40256bit.org.
Subscribe to:
Posts (Atom)