Re: complete() function - does it force a redraw of every window?

[Ben Jackson]

I wonder if it would be possible to record the window ids of the windows 
overlapped by the completion pum and only redraw those with NOT_VALID rather 
than all of them?

> On 20 Aug 2022, at 19:24, Bram Moolenaar  wrote:
> 
> 
> Ben Jackson wrote:
> 
>> I have been investigating some pathological performance problems with
>> YouCompleteMe (YCM). YCM is a vim plugin which, in effect calls
>> complete() on every keystroke in insert mode. I have noticed that
>> sometimes, vim can become extremely slow while typing in this
>> scenario.
>> 
>> I did some profiling with callgrind and found that 99% of the time was
>> redrawing, and in particular syntax highlighting regex code. Of
>> course, doing something very often makes it appear “slow”.
>> 
>> Anyway, my solution has been to reduce the number of times I call
>> complete(), but I’m still curious if this can be improved. I’m not
>> super clear on the exact set of calls here, but looking at the code it
>> _appears_ that we force a redraw of all windows whenever the pum is
>> undisplayed (pum_undisplay calls redraw_all_later(UPD_NOT_VALID),
>> which is called by set_completion, via ins_compl_free, etc.).
>> 
>> I think this also happens when any key is pressed while the pum is
>> displayed (however it is displayed).
>> 
>> Am I understanding the behaviour correctly - that a full redraw is
>> requested whenever the pum is visible and a key is pressed, or
>> complete() is called?
>> Is there a way this redraw can be reduced? I seem to recall that popup
>> windows have a clever way to minimise the redraw by storing what they
>> are obscuring (or did I imagine that?).
> 
> If a popup window is closed, moved or resized, the windows under it are
> updated with UPD_NOT_VALID.  The window contents (with text and
> attributes) isn't cached, it needs to be recomputed.  Normally this is
> fast enough, but with complex syntax highlighting it can be a bit slow.
> 
> Caching the text and attributes under the popup might be possible, but
> it is tricky.  Especially with completion, some text might be put in the
> line (which is removed again when not using the completion) which
> requires redrawing text around it.  The caching only helps in limited
> situations.
> 
> What would help in general is to make syntax highlighting faster.  At
> least avoid bottlenecks.
> 
> 
> -- 
> CRONE:  Who sent you?
> ARTHUR: The Knights Who Say Ni!
> CRONE:  Aaaagh!  (she looks around in rear) No!  We have no shrubberies here.
> "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
> 
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///  \\\
> \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/F7756A28-03B7-46E0-B76A-4E03F238ABC7%40gmail.com.

complete() function - does it force a redraw of every window?

[Ben Jackson]

Hi Bram,

I have been investigating some pathological performance problems with 
YouCompleteMe (YCM). YCM is a vim plugin which, in effect calls complete() on 
every keystroke in insert mode. I have noticed that sometimes, vim can become 
extremely slow while typing in this scenario.

I did some profiling with callgrind and found that 99% of the time was 
redrawing, and in particular syntax highlighting regex code. Of course, doing 
something very often makes it appear “slow”.

Anyway, my solution has been to reduce the number of times I call complete(), 
but I’m still curious if this can be improved. I’m not super clear on the exact 
set of calls here, but looking at the code it _appears_ that we force a redraw 
of all windows whenever the pum is undisplayed (pum_undisplay calls 
redraw_all_later(UPD_NOT_VALID), which is called by set_completion, via 
ins_compl_free, etc.).

I think this also happens when any key is pressed while the pum is displayed 
(however it is displayed).

Am I understanding the behaviour correctly - that a full redraw is requested 
whenever the pum is visible and a key is pressed, or complete() is called?
Is there a way this redraw can be reduced? I seem to recall that popup windows 
have a clever way to minimise the redraw by storing what they are obscuring (or 
did I imagine that?).

I’m may have some time/impetus to work on this if it’s a plausible direction.

Cheers,
Ben

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/60D6020C-EB74-4A43-A278-1EFA3DC79CAF%40gmail.com.

Re: def! in legacy vimscript

[Ben Jackson]

OK, makes sense, thanks.

> On 18 Feb 2022, at 11:29, Bram Moolenaar  wrote:
> 
> 
>>> Wether a function is script-local or global (when not using a "s:" or
>>> "g:" prefix) depends on the script it's defined in The rule is "at the
>>> script level, the type of script defines what the scope of the items
>>> is". I think that's easy to understand. 
>> 
>> You know, I think the other rule is arguably easier to understand: "def 
>> functions are always script-local".
>> 
>> What are people's thoughts ?
>> 
>> In a sense the rule above could be used to advantage for "internal 
>> linkage" functions of a plugin. For example:
>> 
>> - I have a "public" interface of "function" functions - these are legacy 
>> vimscript for compatibility/interop
>> - internally in my "plugin" (let's say a single .vim file), I have some def 
>> functions for performance, convenience - they are script-local by default.
>> 
>> I admit the current behaviour is not difficult to explain or learn, but 
>> perhaps the "def functions are always internal unless "exported" or "g:" 
>> prefixed" is simpler logically?
> 
> Making :def functions always script-local would be OK.  But how about
> legacy functions?  If we connect the visibility to the type of function,
> you would expect a legacy function in a Vim9 script to be global.  But
> in a Vim9 script everything is script-local.  We even removed using "s:"
> for script level items.
> 
> So then the rule for :def functions would differ from legacy functions,
> which I find confusing.  If we make the script type define the
> visibility of items it's simpler and more logical.
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 64. The remote to the T.V. is missing...and you don't even care.
> 
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///  \\\
> \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/FD75E1B4-44A4-47B6-BC3A-9BC806E09E33%40gmail.com.

Re: Derivative works under the vim license

[Ben Jackson]

Thanks Bram. Much appreciated. I’ll reach out to Charles. 

> On 31 Dec 2021, at 23:13, Bram Moolenaar  wrote:
> 
> 
> Ben Jackson wrote:
> 
>> I know it’s kind of tedious, but I have question about the vim license
>> (:help license) specifically relating to the runtime files.
> 
> Yes, copyright issues can be very complicated and tedious.  At least,
> when you listen to a lawyer and try to do exactly the right thing.  And
> find out the laws of what country actually applies (every country has
> it's own laws, there is no such thing as international copyright).
> 
> The opposite is to assume nobody will complain, just copy stuff and hope
> you don't get blamed.
> 
>> I have made a derivative work of the xxd.vim syntax file as
>> distributed by vim and as authored by Charles Campbell. This is to be
>> distributed as part of a vim plugin (Vimspector) that is itself
>> licensed under the Apache 2.0 license. By derivative work here I mean
>> that I copied it, made some relatively minor changes, and applied it
>> to a different filetype.
>> 
>> Although Charles doesn’t specify, I’m assuming that the license of the
>> original xxd.vim is the same as that of vim (i.e. that in :help
>> license). Unfortunately, I wasn’t sure from that exactly what the
>> situation was for derivative works, as the license speaks mostly about
>> full copies of vim rather than “parts” such as the runtime files.
> 
> The rule is that if copyright is not specified, a work is copyrighted
> by default (in nearly all countries).  And, weird as the name my suggest
> the opposite, that means you don't have the right to copy.  Not at all
> (with very few exceptions).
> 
>> So in short the questions are:
>> 
>> 1) Are the runtime files licensed in the same way as Vim proper ?
>> 2) If so, what are the license restrictions on creating derivative
>> works of runtime files?
> 
> Well, although the file itself doesn't mention licencing rules, it is
> part of the Vim distribution, so you can assume the Vim license applies.
> If the author would not wanted that, it would be mentioned somewhere.
> 
> AFAIK Apache 2 is a good license and doesn't conflict with the Vim
> license.
> 
>> For the record, I have elected to include the entire header from
>> xxd.vim and the entire Vim license in the affected file for now, but I
>> just want to make sure that this is all legit/OK?
>> 
>> https://github.com/puremourning/vimspector/pull/507/files#diff-d2d644aaf55a7738084ecc39d6576740c16c914e74602d205c97dd30f44036bd
>>  
>> <https://github.com/puremourning/vimspector/pull/507/files#diff-d2d644aaf55a7738084ecc39d6576740c16c914e74602d205c97dd30f44036bd>
> 
> I suggest to ask the original author if he is OK with this.  Perhaps
> just ask to use the Apache 2 license to keep things simple.
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 170. You introduce your wife as "my_l...@home.wife" and refer to your
> children as "forked processes."
> 
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///  \\\
> \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9C24D9C4-AB4A-417F-90FC-D59D6076D467%40gmail.com.

Derivative works under the vim license

[Ben Jackson]

Hi all,

I know it’s kind of tedious, but I have question about the vim license (:help 
license) specifically relating to the runtime files.

I have made a derivative work of the xxd.vim syntax file as distributed by vim 
and as authored by Charles Campbell. This is to be distributed as part of a vim 
plugin (Vimspector) that is itself licensed under the Apache 2.0 license. By 
derivative work here I mean that I copied it, made some relatively minor 
changes, and applied it to a different filetype.

Although Charles doesn’t specify, I’m assuming that the license of the original 
xxd.vim is the same as that of vim (i.e. that in :help license). Unfortunately, 
I wasn’t sure from that exactly what the situation was for derivative works, as 
the license speaks mostly about full copies of vim rather than “parts” such as 
the runtime files.

So in short the questions are:

1) Are the runtime files licensed in the same way as Vim proper ?
2) If so, what are the license restrictions on creating derivative works of 
runtime files?

For the record, I have elected to include the entire header from xxd.vim and 
the entire Vim license in the affected file for now, but I just want to make 
sure that this is all legit/OK?

https://github.com/puremourning/vimspector/pull/507/files#diff-d2d644aaf55a7738084ecc39d6576740c16c914e74602d205c97dd30f44036bd
 


Thanks,
Ben

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/D8276D7F-DA0B-4750-BA82-9E8573A95A03%40gmail.com.

Re: syntax/vim.vim - support python << trim

[Ben Jackson]

Thanks, Bram, will do.

> On 25 Nov 2021, at 10:51, Bram Moolenaar  wrote:
> 
> 
> Ben Jackson wrote:
> 
>> I proposed this patch a while back to Charles, but I don’t think I got a
>> response.
>> It adds support for "py3 << trim EOF” in vim.vim syntax file.
>> I can make a GitHub PR if you prefer.
> 
> You could make a PR and ping @cecamp
> Charles is around but does not spend much time on Vim.
> 
> -- 
> Violators can be fined, arrested or jailed for making ugly faces at a dog.
>   [real standing law in Oklahoma, United States of America]
> 
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///  \\\
> \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9D2A0995-5116-4579-B67F-0FBF3D3577EE%40gmail.com.

Fwd: syntax/vim.vim - support python << trim

[Ben Jackson]

Hi Bram,I proposed this patch a while back to Charles, but I don’t think I got a response.It adds support for "py3 << trim EOF” in vim.vim syntax file.I can make a GitHub PR if you prefer.TaBenBegin forwarded message:From: Ben Jackson <puremourn...@gmail.com>Subject: Re: syntax/vim.vim - support python << trimDate: 3 April 2021 at 15:22:05 BSTTo: Charles Campbell <campb...@drchip.org>Attached correct patch. Sorry for the spam...



-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/B85B3001-388B-42BB-B8B3-DE8A9CA62EF6%40gmail.com.


0001-Runtime-vim-python-syntax-supports-trim.patch
Description: Binary data
Test with test.vim: ```py3 << EOFimport ospassEOFpy3 << trim EOFimport ospassEOFpyx <import ospassEOFpyx <import ospassEOFpyx <<import ospass.Py2or3 <import ospassMARKERPy2or3 <<import ospass.py3 pass```On 3 Apr 2021, at 15:13, Ben Jackson <puremourn...@gmail.com> wrote:Please ignore, sorry this patch is broken. I’m clearly having a bad day today :(I will re-send when I fixed it.On 3 Apr 2021, at 15:08, Ben Jackson <puremourn...@gmail.com> wrote:Hi Charles,Sorry for the confusion, here’s the patch attached.<0001-Runtime-vim-python-syntax-supports-trim.patch>Thanks,BenOn 3 Apr 2021, at 14:36, Bram Moolenaar <b...@moolenaar.net> wrote:Ben Jackson wrote:Hi Charles,Vim 8.1 has supported py3 <Would you consider including it?Forwarding with the mail address adjusted.-- hundred-and-one symptoms of being an internet addict:45. You buy a Captain Kirk chair with a built-in keyboard and mouse./// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\///  \\    sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///\\\    help me help AIDS victims -- http://ICCF-Holland.org    ///



-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/B85B3001-388B-42BB-B8B3-DE8A9CA62EF6%40gmail.com.

Re: RFC - External debugger API for debugging vimscript

[Ben Jackson]

Yeah, thanks!

If eval_variable (via lookup_debug_var) or similar would return function args 
for def functions, then that would be pretty neat and we can watch and inspect 
them. 

For my side I would need to add a list of locals and script vars for vim9 
script contexts (for the scopes window) and fix up the stack trace (which 
contains the  literally at the moment).

For breakpoints, I haven’t looked at that yet, but it think that would be the 
next thing. For legacy vim script I modified the way breakpoints are triggered 
such that a line breakpoint within the body of a function triggers both when 
defining the function _and_ when executing it the function (this allows setting 
line breakpoints within function bodies); for this I use 
dbg_find_breakpoint_in_func (here: 
https://github.com/puremourning/vim/blob/debugger/src/debugger.c#L954). 

I’d probably look to do the same for def functions. Something like calling  
dbg_find_breakpoint_in_func from the ISN_DEBUG handler, though I only looked at 
it really really briefly.

The remaining thing would be whether or not we can support arbitrary execution 
of def functions while debugging, e.g. to print the return of some def function 
call.

> On 15 Jun 2021, at 11:36, Bram Moolenaar  wrote:
> 
> 
>> Waking up this thread, just to say that this is still work in progress. I 
>> actually use it quite often for my own debugging, but I'm holding off on 
>> patches for now while vim9script develops. I think it makes logical sense 
>> for this all to happen after vim9script is mature.
>> 
>> But as a teaser, I noticed that Bram added support for debugging vim9script 
>> statements yesterday, and so I've hooked that in to my prototype. So here's 
>> a demo of Vimspector debugging a simple vim9 script:
>> 
>> https://asciinema.org/a/25SLL99WepcubhweLoQblz2Cg
>> 
>> Lots more to do on this, but now the framework is in place.
> 
> I'm glad the Vim9 debugger features work for you.  I plan to add the
> possibility to inspect function arguments next.  Not sure if I add more
> now, it should be sufficient for basic debugging.  Perhaps we need
> to be able setting a breakpoint?
> 
> -- 
> You can test a person's importance in the organization by asking how much RAM
> his computer has.  Anybody who knows the answer to that question is not a
> decision-maker.
>   (Scott Adams - The Dilbert principle)
> 
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///  \\\
> \\\sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/98FF2DF1-F968-4CE3-A561-C9264E7F3319%40gmail.com.

Re: syntax/vim.vim - support python << trim

[Ben Jackson]

Hi Charles,
> 
> Vim 8.1 has supported py3 < to the runtime file for syntax/vim.vim
> 
> Would you consider including it?
> 
> <0001-Runtime-vim-python-syntax-supports-trim.patch>
> 
> THanks,
> Ben

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/2D73FFA4-B339-41B8-B52E-3E65726BAFC0%40gmail.com.


0001-Runtime-vim-python-syntax-supports-trim.patch
Description: Binary data

syntax/vim.vim - support python << trim

[Ben Jackson]

Hi Charles,

Vim 8.1 has supported py3 

Re: Vim9: rethinking conditions and boolean expressions

[Ben Jackson]

> The "??" operator is used in TypeScript, JavaScript, C# and a few other
> 
> languages.

Oh ok, fair enough, thanks. Shows how much I know :) I’d never seen it before.

> On 5 Oct 2020, at 14:20, Bram Moolenaar  wrote:
> 
> 
>>> var name = Getname() ?? 'unknown' 
>> 
>> This `??` operator seems a bit unique to vim9script. If we're trying to be 
>> more like other languages how about either re-using `else` (as in Getname() 
>> else 'unknown') or using `or` (Like python): `Getname() or "unknown"`
> 
> Python operators are words, which I find making an expression harder to
> understand.  We don't have any operators that are words, I don't see a
> reason to use it here.
> 
> The "??" operator is used in TypeScript, JavaScript, C# and a few other
> languages.
> 
> -- 
> hundred-and-one symptoms of being an internet addict:
> 35. Your husband tells you he's had that beard for 2 months.
> 
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/D96FFEAA-B17B-4CF5-BB68-2DD836329B24%40gmail.com.

Re: Note about old style tests

[Ben Jackson]

Great work, and much appreciated.

On Sunday, August 2, 2020 at 4:39:36 PM UTC+1, yega...@gmail.com wrote:
>
> Hi all,
>
> With patch 8.2.1354, all the old style tests (except for test49 which tests
> the vim script functionality) have been converted to new style tests.
>
> - Yegappan
>
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/4bcf2263-8c49-4198-9ff3-676f92a1f901o%40googlegroups.com.

Re: [vim/vim] Vim9: type of character indexed from string wrongly inferred as number (#6563)

[Ben Jackson]

In YCM we absolutely need byte offsets but we do end up doing a fair amount of 
shenanigans the convert between bytes and characters depending on encodings and 
things. 

LSP for example regrettably uses UTF16 code units. Counting characters is made 
tricky by things like combining marks IIRC 

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/3bffc72a-6a67-4909-8f2e-d744fd524191o%40googlegroups.com.

Re: [vim/vim] Vim9: type of character indexed from string wrongly inferred as number (#6563)

[Ben Jackson]

Reasonable (if subtle) change. Need to ensure there is a way to get a byte 
index too eg a way to cast to blob ? Indexing a blob giving bytes and indexing 
a string giving characters seems solid and easy to learn. Consistent with thing 
like str/bytes in python for example. 

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/ae6ac11c-0794-44fe-8a9b-92c9619502c5o%40googlegroups.com.

Submit tests first, then fixes which update the tests ?

[Ben Jackson]

Hi Bram,

As I’m working on these changes to improve the vimscript debugging (and stack 
traces), etc., I haven’t yet written extensive tests, so I’m working through 
that.

As I do I’m wondering what your preference is regarding the patches. Would you 
prefer:

* Some changes that add tests that essentially document the current behaviour, 
followed by patches which fix/change that behaviour and update the tests, or
* The new behaviour and tests for that new behaviour.

My inclination was strongly for the former, because I think it makes it easier 
to understand the patches, even if it’s actually more work. But I realise I 
didn’t ask ... :)

Here’s a small example: the functional change is that after doing ‘up’ in the 
debugger, then any command is executed with the script context of the ‘new’ 
frame, rather than the actual current frame. This allows you to do things like 
‘up’ a few times, then ‘echo a:argument’  to get the value of the function 
argument at that stack level. Currently, this doesn’t work (your expression 
always gets executed in the real current stack frame). 

I could submit a patch which changes that and adds tests for it, but I was 
thinking to submit tests for the current behaviour, then incrementally work 
towards the new behaviour. That make sense to you?

The tests might have something like:

  call RunDbgCmd(buf, 'up', [ '>up' ] )
  call RunDbgCmd(buf, 'backtrace', [
\ '\V>backtrace',
\ '\V  2 command line',
\ '\V->1 script ' .. file1 .. '[11]',
\ '\V  0 function \.\*_File1Func',
\ '\Vline 1: let s:file1_var .= a:arg',
\ ],
\ #{ match: 'pattern' } )

  " FIXME: Unexpected: a:arg should not be accessible
  " call RunDbgCmd(buf, 'echo a:arg', [ 'E121: Undefined variable: a:arg' ] )
  call RunDbgCmd(buf, 'echo a:arg', [ 'arg1' ] )
  call RunDbgCmd(buf, 'echo s:file1_var', [ 'file1' ] )
  call RunDbgCmd(buf, 'echo g:global_var', [ 'global' ] )
  " FIXME: Unexpected: global_var should be found
  " call RunDbgCmd(buf,
  "   \'echo global_var',
  "   \[ 'global' ] )
  call RunDbgCmd(buf,
\'echo global_var',
\[ 'E121: Undefined variable: global_var' ] )

Seem ok?

Thanks,
Ben

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/0E3F881D-EBCE-4620-8D5A-4AF782CC85D9%40gmail.com.

Re: Vim9 design choice: comments

[Ben Jackson]

My opinion is that it's ok to drop double-quote comments in vim9 script. I 
think it's good to only have 1 way to do things right, so having both 
double-quote and hash comments feels off.

Vim is a somewhat of an outlier in using double-quote for comments, so it 
would seem and feel natural to me to keep hash comments on vim9script and 
respectfully wave goodbye to double-quote comments. As you say, this is 
another way that can signal that the syntax and semantics of the code 
differ between legacy vimscript and vim9script.

I don't feel it's any more jarring than being able to call an expression 
without `call`, or requiring typing. Legacy vimscript and vim9script are 
essentially 2 completely different dialects, which means picking one way to 
do comments is probably a good idea.

On Wednesday, July 15, 2020 at 1:25:48 PM UTC+1, Bram Moolenaar wrote:
>
>
> I'm trying to make the Vim9 script syntax consistent and easy to use. 
> But I'm now running into something that would be a drastic change. 
>
> I already added support for comments starting with #.  These are nice, 
> we know them from shell scripts, Python and a few other syntaxes. 
>
> Double quoted comments can currently still be used, but not everywhere. 
> E.g. when an expression might continue in the next line: 
> function("arg one", 
> "arg two") 
>
> This also shows the inconsistency: 
> myList->add(123)" works 
> g:myList->add(123)" works 
> [1, 2, 3]->Process()" works 
> #{a: 1, b: 2}->Process()" works 
> {'a': 1, 'b': 2}->Process()" works 
> "foobar"->Process()" does NOT work 
> ("foobar")->Process()" works 
> 'foobar'->Process()" does NOT work 
> ('foobar')->Process()" works 
>
> I just made the last-but-one work, since we added the rule that a range 
> must start with a colon, and using a mark in a range would thus be :'t. 
>
> To make this work with a double quoted string, we don't have much choice 
> but to disallow double quoted comments.  Since there really is no way to 
> tell the difference, both a string and a comment may contain anything. 
>
> Vim has always supported double quoted comments, disallowing them would 
> be a big divergence.  But as the above shows, it does make it consistent 
> and easy to use.  It's just not at all backwards compatible. 
>
> Opinions? 
>
> -- 
> How To Keep A Healthy Level Of Insanity: 
> 18. When leaving the zoo, start running towards the parking lot, 
> yelling "run for your lives, they're loose!!" 
>
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   
> \\\ 
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ 
> \\\ 
> \\\  an exciting new programming language -- http://www.Zimbu.org   
>  /// 
>  \\\help me help AIDS victims -- http://ICCF-Holland.org   
>  /// 
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/a44185d8-def9-4242-b59a-c33c67f5ffe4o%40googlegroups.com.

Re: [vim/vim] Allow to pass lua closures to vim script functions from lua (#6246)

[Ben Jackson]

> register_cfunc is generic enough to also work for python and ruby which 
would allow those languages to also extend if needed using this same 
mechanism. Else one would need to create global functions in vimscript and 
then use vim.funcref which isn't ideal.

That's interesting. I don't use the lua interface, but YCM and Vimspector 
both make heavy use of the embedded python3, i have been thinking about 
exposing job and channel objects to the python layer. But it sounds like 
you've gone a different way here with lua. Would you mind elaborating on 
how that mechanism would work ?

Are you saying you'd be able to do the equivalent of vim.eval ( 'job_start' 
 ) and pass a Python function as the, say 'out_cb'  (as opposed to a 
vimscript function which then does a ':py3' to call back into python ?

{on an unrelated note, i suspect that even then this wouldn't work in 
neovim as neovim's python implementation is totally different and already 
divergently incompatible with vim, but that's another story for another 
place}

On Thursday, June 18, 2020 at 12:38:12 AM UTC+1, Prabir Shrestha wrote:
>
> My current use case was to rewrite asyncomplete 
>  v3 in both vimscript 
> (for older version and backwards compatibility) and lua (for performance). 
> I need to use timers and jobs to pass functions as well as pass the 
> autocomplete callback functions around hence the main reason behind this 
> PR. My first comment in the PR included timer examples as I need it to 
> debounce on keystrokes. There are also some parts of vim-lsp 
>  I would like to write in lua 
> for perf reasons. There are also other plugins I would like to write in 
> pure lua that uses jobs. It is also lot easier to work with lua closures 
> that is multiline and contains if else than vimscript.
>
> I have tried several times in the past few years to write lua plugins but 
> always landed up with vimscript because the integration was ugly since 
> there is no good bindings. It felt that lua was more there just for the 
> sake of it rather than creating real plugins. Given that I had so hard time 
> creating lua plugins I definitely understand why there are very few to 
> almost none lua plugins for vim.
>
> Next version of neovim 0.5 is going to ship with LSP protocol by default 
> which is written in lua and as part of that work they have already gone and 
> added these apis so an entire full fledged powerful plugin can be created 
> in lua. In the past few months I have also seen rise of neovim plugins 
> written in pure lua and I expect this to continue to rise once v0.5 ships.
>
> register_cfunc is generic enough to also work for python and ruby which 
> would allow those languages to also extend if needed using this same 
> mechanism. Else one would need to create global functions in vimscript and 
> then use vim.funcref which isn't ideal.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> 
> .
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/d0b6fba7-c2cc-4016-8c7f-7803a1dfb16fo%40googlegroups.com.

Re: RFC: Function get a list of global/local marks

[Ben Jackson]

I don't use `:marks` in any of my plugins, but if I did, I would _much_ 
prefer a function returning them as a list/dict than having to parse the 
output of exectute( 'marks' )

So +1 to this, and +1 to adding one for popups too.

On Friday, May 1, 2020 at 4:52:27 PM UTC+1, yega...@gmail.com wrote:
>
> Hi all,
>
> Currently we have the line(), col(), virtcol() and getpos() functions
> to get the position of a particular mark. But we don't have a
> function to get the list of local/global marks (information displayed
> by the :marks command). A plugin needs to call the above functions
> in a loop for various supported local/global marks to create this list.
> What do you think about adding a getmarklist() function which will
> return the List of placed global/local marks? The help text for this 
> function
> is below.
>
> We have similar functions for returning the following:
>
> argument list: argv()
> buffers in a tabpage: tabpagebuflist()
> buffers: getbufinfo()
> change list: getchangelist()
> jump list: getjumplist()
> location list: getloclist()
> matches: getmatches()
> quickfix list: getqflist()
> signs: sign_getdefined(), sign_getplaced()
> tabpages: gettabinfo()
> tags: taglist()
> terminals: term_list()
> timers: timer_info()
> windows: getwininfo()
>
> Thanks,
> Yegappan
>
> ==
> getmarklist([{expr}]
>Returns a |List| with information about the global marks or 
> the
>local marks placed in a buffer. |mark|
>
>The optional {expr} argument specifies a buffer. For the use
>of {expr}, see |bufname()|. If specified, returns the
>local marks defined in buffer {expr}. If the {expr} argument
>is not supplied, then returns information about all the 
> global
>marks.
>
>Each item in the retuned List is a |Dict| with the 
> following:
>name - name of the mark prefixed by "'"
>pos - a |List| with the position of the mark:
>[bufnum, lnum, col, off]
>  Refer to |getpos()| for more information.
>file - file name
>
>Refer to |getpos()| for getting information about a specific
>mark.
>
>
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/762f1d49-c28c-4ac1-a612-a8ba277ea960%40googlegroups.com.

Re: [vim/vim] Use SGR like mouse reporting for Putty terminals (#5942)

[Ben Jackson]

I even posted a patch to support all-event mouse tracking, but no answer 
from the PuTTY owner. https://github.com/puremourning/putty/pull/1

On Thursday, April 16, 2020 at 10:09:07 PM UTC+1, Christian Brabandt wrote:
>
> oh wow, thanks for digging it up!
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub 
> , or 
> unsubscribe 
> 
> .
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/e89c4972-5723-4020-9f53-870c5c481c21%40googlegroups.com.

Re: RFC - External debugger API for debugging vimscript

[Ben Jackson]

Thanks, Bram.

> On 13 Apr 2020, at 14:46, Bram Moolenaar  wrote:
> 
> 
> Ben Jackson wrote:
> 
>> When we were discussing vim9script, I mentioned that an interface for 
>> external/graphical debuggers for vimscript would be useful. Your response 
>> at the time was:
>> 
>>>>>> * provide a interface to a debug adapter to allow debugging of 
>> vimscript 
>>>>>> executing in a Vim instance (i.e. Vim Debug Adapter) 
>>>>> 
>>>>> Sure. 
>>> 
>>>> Woo \o/. Debugging vimscript with vimspector would be very kickass. 
>>>> I’m more than willing to put in hard graft to make this happen. 
>> 
>>> It's not really related to Vim9 script, could be an independend project. 
>> 
>> So, challenge accepted. Over the last few months I've been working on this 
>> and have a mostly working prototype. I have even recently used it to debug 
>> a real problem in a real vim plugin.
>> 
>> Here's a 
>> demo: 
>> https://files.gitter.im/vimspector/Lobby/qnjv/vimspector-vimscript-demo.gif
> 
> Looks very interesting!
> 
>> What you can see in the demo:
>> 
>> - I open a .vim file, set a breakpoint and launch vim in a terminal window 
>> (using vimsector)
>> - Vim (in the terminal window) hits the breakpoint and vimspector jumps to 
>> the current line in my code
>> - Using vimspector I can step throught the vimscript, inspect local, 
>> script, window, etc. variables and view the _full_ execution stack 
>> (including source's etc.)
> 
> Do I get it right that vimspector is a Vim plugin?

Yep it’s a Debug Adapter Protocol _client_ in Vim - supports graphical 
debugging of any language that there’s an adapter for (i.e. anything VScode 
supports). DAP is like the debugging equivalent of LSP. 

All possible thanks to your incredible work on vim 8.

> 
>> Very briefly, the way this works is the vim-under-debug delegates the debug 
>> command loop (in debug.c) to a vimscript function, implemented by my 
>> "vim-debug-adapter" plugin. This callback's job is to provide a single 
>> command to execute (such as "next" or "step" or an ex command, like 'break 
>> add'). It does this by having a channel, connected to a debug adapter in a 
>> "request one command" loop. Meanwhile the debug adapter can issue other 
>> requests, implemented in the channel's callback.
> 
> That sounds like a nice mechanism.  So it's mostly the same as the
> existing debug code, but instead of prompting the user in the
> Vim-under-debug itself the prompt goes over the channel.

Yes, that’s exactly it.

> 
> I haven't dug into this, but I assume the output of a command also goes
> over the channel, thus the Vim-under-debug doesn't show any debug
> output.

Sort of, the usual debug output is mostly suppressed in vim-under-debug (it’s 
still printing the ‘breakpoint hit at file:line’), but that’s mostly just 
work-in-progress stuff.

Regarding the result of evaluations, if the command run is, say, echom or 
redraw, it will be echo’d/redrawn in vim-under-debug, but the _return_ value of 
the evaluation is sent to the debugger over the channel.

> 
>> In order to make all of this work, a fairly large amount of change is 
>> required in Vim, such as:
>> 
>> - delegating command reading from the debugger loop 
>> (https://github.com/puremourning/vim/blob/debugger/src/debugger.c#L166-L216)
> 
> This can be improved.  Instead of hard coding the function name it could
> be specified with a command:
>   :debugfunc MyDebugger
>   :debugfunc NONE

Yes, absolutely, I was actually planning to make it an option (e.g. :set 
debughandler=FunctionName). This is just in the “still discovering what to 
solve next” phase. The option seemed easy to add so I left it for later.

> 
>> - completing the implementation of estack to hold data for sourced files, 
>> ufuncs, auto commands, etc. - this allows a new function (debug_getstack) 
>> to get the full stack trace shown in the demo. Normally stack traces only 
>> include the latest run of ufunc calls.
> 
> This can most likely be a separate change.  I was working towards this
> with the "exestack" stuff.  Which was far from complete.  Should also be
> used for error messages and exceptions.

Yes, that was the plan - pull this part of the change out (and maybe improve 
general backtraces too for day-to-day operations not involving the debugger) as 
the first step.

> 
>> - adding some vimscript commands like `debug_getvariables( scope )`, 
>> `debug_eval( in_scope, expr )`, debug_getstack 

RFC - External debugger API for debugging vimscript

[Ben Jackson]

Hi Bram,

When we were discussing vim9script, I mentioned that an interface for 
external/graphical debuggers for vimscript would be useful. Your response 
at the time was:

> > >> * provide a interface to a debug adapter to allow debugging of 
vimscript 
> > >> executing in a Vim instance (i.e. Vim Debug Adapter) 
> > > 
> > > Sure. 
> 
> > Woo \o/. Debugging vimscript with vimspector would be very kickass. 
> > I’m more than willing to put in hard graft to make this happen. 

> It's not really related to Vim9 script, could be an independend project. 

So, challenge accepted. Over the last few months I've been working on this 
and have a mostly working prototype. I have even recently used it to debug 
a real problem in a real vim plugin.

Here's a 
demo: 
https://files.gitter.im/vimspector/Lobby/qnjv/vimspector-vimscript-demo.gif

What you can see in the demo:

- I open a .vim file, set a breakpoint and launch vim in a terminal window 
(using vimsector)
- Vim (in the terminal window) hits the breakpoint and vimspector jumps to 
the current line in my code
- Using vimspector I can step throught the vimscript, inspect local, 
script, window, etc. variables and view the _full_ execution stack 
(including source's etc.)

Very briefly, the way this works is the vim-under-debug delegates the debug 
command loop (in debug.c) to a vimscript function, implemented by my 
"vim-debug-adapter" plugin. This callback's job is to provide a single 
command to execute (such as "next" or "step" or an ex command, like 'break 
add'). It does this by having a channel, connected to a debug adapter in a 
"request one command" loop. Meanwhile the debug adapter can issue other 
requests, implemented in the channel's callback.

In order to make all of this work, a fairly large amount of change is 
required in Vim, such as:

- delegating command reading from the debugger loop 
(https://github.com/puremourning/vim/blob/debugger/src/debugger.c#L166-L216)
- completing the implementation of estack to hold data for sourced files, 
ufuncs, auto commands, etc. - this allows a new function (debug_getstack) 
to get the full stack trace shown in the demo. Normally stack traces only 
include the latest run of ufunc calls.
- adding some vimscript commands like `debug_getvariables( scope )`, 
`debug_eval( in_scope, expr )`, debug_getstack 
(https://github.com/puremourning/vim/blob/debugger/src/evalfunc.c#L58-L60)
- adding a way to evaluate a command in a script context (as well as a 
function context) that isn't the top of the stack (essentially use the 
_full_ execution stack for debug_backtrace_level)
- changes to breakpoints so that you can set a file-line breakpoint 
_within_ a function such that it fires when the function executes, rather 
than only when it is defined (this is quite hairy at the moment)
- probably a bunch of equivalent changes for vim9 (haven't tried this yet)

The very-work-in-progress vim changes are here 
: https://github.com/puremourning/vim/compare/master...puremourning:debugger
The runtime code that provides the interface to DAP is 
here: 
https://github.com/puremourning/vim-debug-adapter/blob/master/runtime/nub.vim 
(and the debug adapter 
itself: https://github.com/puremourning/vim-debug-adapter)

So the purpose of this RFC is to see whether I should progress further down 
this route:

- share the demo/prototype for visibility
- get your appetite for merging a patch like this (I would push the changes 
in smaller tested pieces of course)
- get your general thoughts on the approach above
- gauge community reaction, thoughts, comments, insults etc.

Thanks for everything. If the general reaction is positive, I'll make a 
proper plan and send some more detailed RFCs for the various aspects.

Kind regards,
Ben

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/4dedd56e-1347-4c1b-b9d6-291a1e15e77b%40googlegroups.com.

Re: [vim/vim] doc: Obsolete documentation of debbugers in develop.txt (#5923)

[Ben Jackson]

At the risk of too much self-promotion, we _could_ 
mention https://github.com/puremourning/vimspector as an alternative for 
multiple languages.

On Monday, April 13, 2020 at 11:45:19 AM UTC+1, Omri Sarig wrote:
>
> In the help file develop.txt, there is a line that references some 
> optional tools that can be used to run gdb together with vim (Agide and 
> clewn).
>
> It seems that this line is now unneeded since vim has the feature of 
> terminal-debug built into it. I think that this line should be removed 
> from the documentation.
>
> A patch that removes this line is attached to this issue (saved with txt 
> extension to upload it to github).
>
> remove_obsolete_debbugger_doc.txt 
> 
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub 
> , or unsubscribe 
> 
> .
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/1694117a-57e6-42af-af39-8b3ab0267c8b%40googlegroups.com.

Re: Need the terminal codes for mouse right button drag

[Ben Jackson]

It depends on the tracking mode being used. This reference (which I presume 
you've seen) is most 
useful: 
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Button-event-tracking

Note the SGR mode slightly modifies it as well.

Hope that's vaguely useful. I have to read that spec 3 or 4 times each time 
I need to parse it.



On Sunday, March 22, 2020 at 2:18:45 PM UTC, yega...@gmail.com wrote:
>
> Hi all,
>
> The testdir/mouse.vim file has a helper function for the left mouse
> button drag (MouseLeftDrag). For testing other buttons, we need
> similar MouseRightDrag and MouseMiddleDrag functions.
> I am not able to figure out the proper DEC term codes for these.
>
> Thanks,
> Yegappan
>
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/5f3d72b6-73c2-4a6c-88a6-c590223decef%40googlegroups.com.

Re: Vim9 script: first steps

[Ben Jackson]

> On 5 Jan 2020, at 18:55, Bram Moolenaar  wrote:
> 
> 
> Ben Jackson wrote:
> 
>> Hi Bram, thanks for sharing. Looks really promising.
>> 
>> Regarding https://github.com/brammool/vim9#3-better-vim-script, I have a 
>> few ideas for your consideration:
>> 
>> * Execution often relies on user configuration (ignorecase, magic, etc.) 
>> and there is common boilerplate required in many scripts to set/restore 
>> cpo. Could we say that when `scriptversion` is `vim9`, we always execute as 
>> if `set cpo&vim` ?
> 
> For :def functions those will be parsed as if 'nocompatible' is set.
> 
> For 'ignorecase' and 'magic' we can ignore those for the =~ and !~
> operators.  What else?

The “usual" expression operators behave differently (when not suffixed with # 
or ?) depending on `ignorecase`, right. As in: if x == “CaseSensitiveMatch?” 
Depends on ignorecase.

Examples from :help expr4:

"abc" ==# "Abc"   evaluates to 0
"abc" ==? "Abc"   evaluates to 1
"abc" == "Abc"evaluates to 1 if 'ignorecase' is set, 0 otherwise

I think this is one of those things you just have to know (like using === in 
javascirpt). Would be fewer accidental bugs if `==` worked consistently I guess.

> 
> Not sure yet what will happen at the script level.  No changes are
> needed for speed.  If needed the file can be put inside :def/:enddef
> and then calling that function.  Not ideal, but at least it's possible.

I guess the javascript idiom here is to have an anonymous function that’s 
immediately called:

( def ( args ) : return type
Code
enddef )()

But that’s hardly art. 

> 
> 
>> * Line continuation. I know this is probably hard to change, but could we 
>> look at a line-continuation scheme that's more familiar ? As we don't have 
>> line termination, Perhaps something more like python's e.g. if a line ends 
>> with an unbalanced parenthesis (or a ``), then assume 
>> the next line is a continuation? I think the `` syntax 
>> is unfamiliar to a lot of people.
> 
> It will be difficult to implement, and we'll still need the old way of
> line continuation in some places.  Putting the backslash at the end of
> the line isn't nice anyway, too easy to make mistakes, we should
> probably not add it. Mixing the two is probably worse.
> If we can have some statements continue on the next line without a
> backslash remains to be seen.

Sure. I figured this would be difficult.

> 
>> * Scoped functions or lambdas containing ex-commands (or better, def 
>> function bodies). When combined with try/finally, this would allow 
>> constructs that take a "block" of code, such as "WithCurrentBuffer( buf, { 
>> => block of code/commands, maybe split across lines } )" or something like 
>> this when working with external tools `SendMessageToTool( message, then = { 
>> => some block of ex commands } ). This can currently be done with Funcref, 
>> but I think that you have to do 'function ...' and then 'delfiunc' as all 
>> functions are currently global. Maybe the new scoping rules could be 
>> extended to allow this.
> 
> That a function declared locally in a function becomes a global function
> is indeed unexpected.  We can at least make them local inside a :def
> function, unless prefixed with g:, just like with variables.
> 
> Defining a function and creating a funcref in one step would also be
> useful.  Not sure about the syntax.  TypeScript does something like
> this:
>   let ref = function(arg: type): rettype { ... body };
> 
> Perhaps we can do:
>   let ref = def(arg: type): rettype
> ... body
>  enddef
> 

I personally like the python approach: a def inside a function is a local 
variable of function type. As in:

  let myFunc = function( … ) { … body }

Would be written simply as

  def myFunc( … ):
… body

In vimscript we could do the same, having a nested ‘def’ always declare a local 
Funcref by name, but have a ‘real’ name that’s hidden from the user (like a 
lambda). In the above example, that would create a local variable ‘myFunc’ 
which is a Funcref to an (unnamed?) function with ( … ) args and  … body. 
Again, not sure how practical that is, but it _feels_ smiler to how lambdas 
currently work.

>> I already mentioned elsewhere that the other barrier to entry for vim 
>> scripting is tooling and debugging. Hopefully with a these changes we can 
>> consider how to:
>> 
>> * extract the parser so that an external tool can parse and do code 
>> comprehension, go-to, refactor, etc., think Vim Language Server (there is

Re: Vim9 script: first steps

[Ben Jackson]

Hi Bram, thanks for sharing. Looks really promising.

Regarding https://github.com/brammool/vim9#3-better-vim-script, I have a 
few ideas for your consideration:

* Execution often relies on user configuration (ignorecase, magic, etc.) 
and there is common boilerplate required in many scripts to set/restore 
cpo. Could we say that when `scriptversion` is `vim9`, we always execute as 
if `set cpo&vim` ?
* Line continuation. I know this is probably hard to change, but could we 
look at a line-continuation scheme that's more familiar ? As we don't have 
line termination, Perhaps something more like python's e.g. if a line ends 
with an unbalanced parenthesis (or a ``), then assume 
the next line is a continuation? I think the `` syntax 
is unfamiliar to a lot of people.
* Scoped functions or lambdas containing ex-commands (or better, def 
function bodies). When combined with try/finally, this would allow 
constructs that take a "block" of code, such as "WithCurrentBuffer( buf, { 
=> block of code/commands, maybe split across lines } )" or something like 
this when working with external tools `SendMessageToTool( message, then = { 
=> some block of ex commands } ). This can currently be done with Funcref, 
but I think that you have to do 'function ...' and then 'delfiunc' as all 
functions are currently global. Maybe the new scoping rules could be 
extended to allow this.

I already mentioned elsewhere that the other barrier to entry for vim 
scripting is tooling and debugging. Hopefully with a these changes we can 
consider how to:

* extract the parser so that an external tool can parse and do code 
comprehension, go-to, refactor, etc., think Vim Language Server (there is 
one, but it's not canonical)
* provide a interface to a debug adapter to allow debugging of vimscript 
executing in a Vim instance (i.e. Vim Debug Adapter)
* provide better source/line information for stack traces (so that we can 
reliably jump to location of assertions e.g. test failures using cnext). I 
saw a recent patch which improves sourcing_lineno and uses a proper stack. 
I was planning to work on a patch to store source/line info when debugging 
is enabled, but might hold off while vim 9 shakes down, as this is likely 
required for the above debugger interface (assuming that's a goal).

Just a few ideas to throw in to the mix!

Thanks again, 
Ben

On Thursday, January 2, 2020 at 7:44:10 PM UTC, Bram Moolenaar wrote:
>
>
> I have created a repository for the Vim9 script experiments: 
> https://github.com/brammool/vim9 
>
> I did another measurement for a more realistic example, re-indenting a 
> large number of lines.  In old Vim script it would be: 
>
>   let totallen = 0 
>   for i in range(1, 10) 
> call setline(i, '' .. getline(i)) 
> let totallen += len(getline(i)) 
>   endfor 
>
> The timing differences are much smaller than for the computational 
> example, but Vim9 script is clearly the fastest: 
>
> Vim old:   0.853752 
> Python:0.304584 
> Lua:   0.286573 
> Vim new:   0.190276 
>
> Compared to legacy Vim script it is a 4 times faster. 
>
> If you want to look at the instructions that are used internally, the 
> ":disassemble" command shows what's the compilation result.  For 
> example, this function: 
>
> def VimNew(): number 
>   let totallen = 0 
>   for i in range(1, 10) 
> setline(i, '' .. getline(i)) 
> totallen += len(getline(i)) 
>   } 
>   return totallen 
> enddef 
>
> Results in this: 
>
>   let totallen = 0 
>0 STORE 0 in $0 
>
>   for i in range(1, 10) 
>1 STORE -1 in $1 
>2 PUSHNR 1 
>3 PUSHNR 10 
>4 BCALL range(argc 2) 
>5 FOR $1 -> 21 
>6 STORE $2 
>
> setline(i, '' .. getline(i)) 
>7 LOAD $2 
>8 PUSHS "" 
>9 LOAD $2 
>   10 BCALL getline(argc 1) 
>   11 CONCAT 
>   12 BCALL setline(argc 2) 
>   13 DROP 
>
> totallen += len(getline(i)) 
>   14 LOAD $0 
>   15 LOAD $2 
>   16 BCALL getline(argc 1) 
>   17 BCALL len(argc 1) 
>   18 ADDNR 
>   19 STORE $0 
>
>   } 
>   20 JUMP -> 5 
>   21 DROP 
>
>   return totallen 
>   22 LOAD $0 
>   23 RETURN 
>
>
> Obviously there is still an awful lot of work to be done.  Fortunately, 
> the numbers show it's worth it. 
>
> -- 
> The Law of VIM: 
> For each member b of the possible behaviour space B of program P, there 
> exists 
> a finite time t before which at least one user u in the total user space U 
> of 
> program P will request b becomes a member of the allowed behaviour space 
> B' 
> (B' <= B). 
> In other words: Sooner or later everyone wants everything as an option. 
> -- Vince Negri 
>
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   
> \\\ 
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ 
> \\\ 
> \\\  an exciting new programming language -- http://www.Zimbu.org  

Re: So, how about Vim 9?

[Ben Jackson]

Bram, if you're going to be a doing a fair amount of work on the vimscript 
side of things, one thing I would like to request is to have a mind towards 
being able to support a full-on vimscript debugger. I realise there is a 
built-in debugging mode, but it would be exceptionally cool to be able to 
implement a Debug Adapter Protocol 
 server within vim, so 
that something like Vimspector  
could 
be used to debug plugin code externally.

Obviously doesn't have to be done right away, but having it as a medium 
term goal would be great. As always, happy to contribute.


On Tuesday, December 17, 2019 at 4:49:16 PM UTC, Bram Moolenaar wrote:
>
>
> Vim 8.2 has been released, so what is next? 
>
>
> 1. FASTER VIM SCRIPT 
>
> The third item on the poll results of 2018, after popup windows and text 
> properties, is faster Vim script.  So how do we do that? 
>
> I have been throwing some ideas around, and soon came to the conclusion 
> that the current way functions are called and executed, with 
> dictionaries for the arguments and local variables, is never going to be 
> very fast.  We're lucky if we can make it twice as fast.  The overhead 
> of a function call and executing every line is just too high. 
>
> So what then?  We can only make something fast by having a new way of 
> defining a function, with similar but different properties of the old 
> way: 
> - Arguments are only available by name, not through the a: dictionary or 
>   the a:000 list. 
> - Local variables are not available in an l: dictionary. 
> - A few more things that slow us down, such as exception handling details. 
>
> I Implemented a "proof of concept" and measured the time to run a simple 
> for loop with an addition (Justin used this example in his presentation, 
> code is below): 
>
> Vim old function: 5.018541 
> Python:   0.369598 
> Lua:  0.078817 
> Vim new function: 0.073595 
>
> That looks very hopeful!  It's just one example, but it shows how much 
> we can gain, and also that Vim script can be faster than builtin 
> interfaces. 
>
> How does this work?  The function is first compiled into a sequence of 
> instructions.  Each instruction has one or two parameters and a stack is 
> used to store intermediate results.  Local variables are also on the 
> stack, space is reserved during compilation.  This is a fairly normal 
> way of compilation into an intermediate format, specialized for Vim, 
> e.g. each stack item is a typeval_T.  And one of the instructions is 
> "execute Ex command", for commands that are not compiled. 
>
>
> 2. PHASING OUT INTERFACES 
>
> Attempts have been made to implement functionality with built-in script 
> languages such as Python, Perl, Lua, Tcl and Ruby.  This never gained much 
> foothold, for various reasons. 
>
> Instead of using script language support in Vim: 
> - Encourage implementing external tools in any language and communicate 
>   with them.  The job and channel support already makes this possible. 
>   Really any language can be used, also Java and Go, which are not 
>   available built-in. 
> - Phase out the built-in language interfaces, make maintenance a bit 
> easier 
>   and executables easier to build.  They will be kept for backwards 
>   compatibility, no new features. 
> - Improve the Vim script language, so that it can be used when an 
>   external tool is undesired. 
>
> All together this creates a clear situation: Vim with the +eval feature 
> will be sufficient for most plugins, while some plugins require 
> installing a tool that can be written in any language.  No confusion 
> about having Vim but the plugin not working because some specific 
> language is missing.  This is a good long term goal. 
>
> Rationale: Why is it easier to run a tool separately from Vim than using a 
> built-in interface and interpreter?  Take for example something that is 
> written in Python: 
> - The built-in interface uses the embedded python interpreter.  This is 
> less 
>   well maintained than the python command.  Building Vim with it requires 
>   installing developer packages.  If loaded dynamically there can be a 
> version 
>   mismatch. 
> - When running the tool externally the standard python command can be 
> used, 
>   which is quite often available by default or can be easily installed. 
> - A .py file can be compiled into a .pyc file and execute much faster. 
> - Inside Vim multi-threading can cause problems, since the Vim core is 
> single 
>   threaded.  In an external tool there are no such problems. 
> - The Vim part is written in .vim files, the Python part is in .py files, 
> this 
>   is nicely separated. 
> - Disadvantage: An interface needs to be made between Vim and Python. 
>   JSON is available for this, and it's fairly easy to use.  But it still 
>   requires implementing asynchronous communication. 
>
>
> 3. BETTER VIM SCRIPT 
>
> To make Vim faster

Re: Upcoming Vim 8.2 release

[Ben Jackson]

> what is your favorite improvement since Vim 8.1?

popup windows :) I guess I'm a little biased, but I think this is a great 
improvement, and the API is really nice to use.

On Friday, November 29, 2019 at 9:13:22 PM UTC, Bram Moolenaar wrote:
>
>
> It appears the number of bug reports is getting lower.  I have included 
> many pending pull requests.  I think we are getting closer to a release. 
>
> If you have any runtime updates, please send them now! 
>
> I'm also wondering: what is your favorite improvement since Vim 8.1? 
>
> -- 
> hundred-and-one symptoms of being an internet addict: 
> 142. You dream about creating the world's greatest web site. 
>
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   
> \\\ 
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ 
> \\\ 
> \\\  an exciting new programming language -- http://www.Zimbu.org   
>  /// 
>  \\\help me help AIDS victims -- http://ICCF-Holland.org   
>  /// 
>

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/1efe08ed-fd93-4c0e-9ba3-f6e6b0f0edb0%40googlegroups.com.

Re: [vim/vim] Multiline balloons in terminal are not multiline, but display newlines as ^@ (#5193)

[Ben Jackson]

Maybe better off to use popup_beval these days. 

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/519f5cee-d780-4962-a132-f062de81bf7f%40googlegroups.com.

Re: [vim/vim] Can there be an option to scroll a popup along with the buffer? (#4560)

[Ben Jackson]

Very nice! Thanks! I had a bunch of fiddly code to approximate this. 

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/3b2aa2bf-0eb0-418f-8e05-d08d29b1719f%40googlegroups.com.

Re: How about the popup menu info popup?

[Ben Jackson]

Raised; https://github.com/vim/vim/issues/4860

> On 21 Aug 2019, at 19:26, Bram Moolenaar  wrote:
> 
> 
> Ben Jackson wrote:
> 
>> Thanks Bram. I like it a lot. 
>> 
>> One thing i would like is the ability to remove the borders. I’m not a
>> fan of the borders in general due to the extra screen space they use
>> (and this the extra code they cover). I can also live without the X in
>> the corner if the popup goes away with Ctrl-y which I think it does. 
>> 
>> I did notice a draw bug when testing. I can raise an issue if you
>> like, but I was just testing the right side of the screen. 
>> 
>> Create a vsplit and get it so the pum is towards right of screen and
>> the info popup draws to the left, but overlaps the window to the left
>> too. When changing the pum selection, artefacts are left in the non
>> active window. Example:
>> 
>> https://files.gitter.im/Valloric/ycmd/DT1n/Screenshot-2019-08-19-at-22.32.31.png
> 
> I cannot reproduce this problem now.  Perhaps it's fixed as a side
> effect of other changes?  If you can still reproduce it with the latest
> version, please send a script with reproduction steps.
> 
> -- 
> From "know your smileys":
> [:-)  Frankenstein's monster
> 
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/54C4F3F9-344E-4029-B24A-64E05D308136%40gmail.com.

Re: How about the popup menu info popup?

[Ben Jackson]

I can still repro as of latest patch just now, so I will try and write a 
minimal case.




> On 21 Aug 2019, at 19:26, Bram Moolenaar  wrote:
> 
> 
> Ben Jackson wrote:
> 
>> Thanks Bram. I like it a lot. 
>> 
>> One thing i would like is the ability to remove the borders. I’m not a
>> fan of the borders in general due to the extra screen space they use
>> (and this the extra code they cover). I can also live without the X in
>> the corner if the popup goes away with Ctrl-y which I think it does. 
>> 
>> I did notice a draw bug when testing. I can raise an issue if you
>> like, but I was just testing the right side of the screen. 
>> 
>> Create a vsplit and get it so the pum is towards right of screen and
>> the info popup draws to the left, but overlaps the window to the left
>> too. When changing the pum selection, artefacts are left in the non
>> active window. Example:
>> 
>> https://files.gitter.im/Valloric/ycmd/DT1n/Screenshot-2019-08-19-at-22.32.31.png
> 
> I cannot reproduce this problem now.  Perhaps it's fixed as a side
> effect of other changes?  If you can still reproduce it with the latest
> version, please send a script with reproduction steps.
> 
> -- 
> From "know your smileys":
> [:-)  Frankenstein's monster
> 
> /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org///
> \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/9C95309F-0DAC-4F48-9E33-7BC7D1D9A1B5%40gmail.com.

How about the popup menu info popup?

[Ben Jackson]

Thanks Bram. I like it a lot. 

One thing i would like is the ability to remove the borders. I’m not a fan of 
the borders in general due to the extra screen space they use (and this the 
extra code they cover). I can also live without the X in the corner if the 
popup goes away with Ctrl-y which I think it does. 

I did notice a draw bug when testing. I can raise an issue if you like, but I 
was just testing the right side of the screen. 

Create a vsplit and get it so the pum is towards right of screen and the info 
popup draws to the left, but overlaps the window to the left too. When changing 
the pum selection, artefacts are left in the non active window. Example:

https://files.gitter.im/Valloric/ycmd/DT1n/Screenshot-2019-08-19-at-22.32.31.png

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/f6242f6b-319a-4da0-b184-9cbcb1a2f011%40googlegroups.com.

Re: Using text properties to show rendered documents

[Ben Jackson]

On Thursday, June 6, 2019 at 3:57:41 PM UTC+1, Paul Jolly wrote:
> Hi all,
> 
> I'm somewhat/extremely behind on the text properties work, which looks
> very exciting.
> 
> In the context of govim (https://github.com/myitcv/govim), I'm
> considering using text properties as a way of showing a simple
> rendering of markdown/HTML within a Vim window (popup to be precise).
> 
> Rendering the document with text properties from the parsed
> markdown/HTML should be relatively doable, but before I start down
> this path, does anyone have any thoughts on this approach vs others?
> 
> Many thanks,
> 
> 
> Paul

Why not just use :self markdown. and a markdown syntax file?

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/497f5735-97de-4273-8af1-2b5d6485c1bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

errorformat for vim tests

[Ben Jackson]

Might be a strange question, but does anyone have a good errorformat setting 
for running vim's tests?

When editing tests, I use a mapping to run the test and populate the quick fix 
list with any tests failures. Ultimately, I have a compiler plugin, but it 
really just:

setlocal errorformat=Found\ Errors\ in\ %m,Caught\ exception\ in\ %m
:make -C %:h -B %:t:r

However, I haven't found a satisfactory way to extract the failures from this 
command and populate the quick fix list, and make return nonzero exit code if 
there are errors, so it's tricky to know when there were errors (as the actual 
:make is run in the background via a job).

I use run_test.vim in vimspector and changed it to at least include the 
filename in the output, and that sort-of works, but does anyone who frequently 
develops vim have a good errorformat, or other hints for this sort of workflow? 
Or perhaps, does anyone else use a similar workflow successfully?

Ideally, failures could include the exact file/line number when they are 
detected. Unfortunately, the context reported by vim when an exception is 
caught doesn't relate directly to the source line (line numbers are offsets 
from functions).

Any advice much appreciated.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/72ab07da-fcde-427c-9d10-4d4977b2986e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: popup window design

[Ben Jackson]

On Saturday, May 18, 2019 at 1:39:15 PM UTC+1, Bram Moolenaar wrote:
> In a recent Vim you can see the current ideas of the popup window design
> with ":help popup".  Or go to github:
> https://github.com/vim/vim/blob/master/runtime/doc/popup.txt
> 
> I have been wondering about how to specify the text and highlighting.
> The current proposal is using a list with text and text properties. An
> alterative would be to use a buffer, like we use for a normal window.
> 
> The buffer would be an unlisted scratch buffer.  It's mostly hidden from 
> buffer commands, so it doesn't get in the way.  A bit like help buffers
> (but scratch, not associated with a file).
> 
> One of the advantages is that the code to display window text can be
> used, including all the settings we have for it.  It's even possible to
> use syntax highlighting, so that a code snippet can easily be displayed
> nicely.  Also takes care of text wrapping.  This does imply that we also
> have a window for the buffer, with window-local options.
> 
> One restriction needs to be that the buffer can never be the current
> buffer.  The popup does not get keyboard focus.  Only the filter can be
> used to intercept keys while the popup is open.  The poup is not meant
> to be a window to edit text.  Not sure if it has a working cursor
> position.  And there are many commands that only work in the current
> buffer, such as syntax commands, need to figure out how to deal with
> those.  Perhaps with ":inbuffer {nr} {cmd}".
> 
> I'm not sure how much work it is to implement this, and whether it's
> less work than the list of lines.  But since this is long term
> functionality the amount of work is less important.  At least the newly
> added text properties will work right away.  It might be tricky to avoid
> flicker when moving the popup around.
> 
> Thoughts?
> 
> -- 
> At some point in the project somebody will start whining about the need to
> determine the project "requirements".  This involves interviewing people who
> don't know what they want but, curiously, know exactly when they need it.
>   (Scott Adams - The Dilbert principle)
> 
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org///
>  \\\help me help AIDS victims -- http://ICCF-Holland.org///

This is an interesting idea. I suppose my initial thoughts are, if you squint a 
lot, this is a _little bit_ like how the preview window works. My reservation 
there is that when drawing the preview widow, auto commands are triggered 
(BufLeave/BufEnter, WinLeave,WinEnter if I remember correctly).

With a number of plugins hooking things like WinLeave and BufEnter, etc. you 
can get pretty serious slowdown when you have completeopt += preview and just 
scanning through the current popup menu. Arguably, this is a plugin performance 
issue but we should consider in this design what (if any) autocomands would be 
triggered for the new "popup" window and the buffer within it. 

So in summary, I _do_ like the idea of the flexibility of having a 
window/buffer rendered as the popup, and from an engineering perspective, it is 
attractive because it seems canonical (in the sense that a buffer is a list of 
lines + some properties rendered in a window, and that's essentially a popup). 
But could that flexibility have performance and complexity trade-offs that we 
don't want? Difficult to know without trying it out I suppose. 

Just thinking out loud.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/6e9f2e8e-76a4-48b1-a667-a4e7eaec7b9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Proposal: multiline completion support (#2505)

[Ben Jackson]

On Wednesday, December 27, 2017 at 7:21:38 PM UTC, Łukasz Jan Niemier wrote:
> Currently Vim allows only single line completions. This is quite limiting as 
> there is also no way to determine beginning and end of the completed text so 
> this leaves us in the limbo where we need to do some hackish things to 
> achieve things like multiline snippets.
> 
> Most obvious way to do such thing would be to make (:h complete-items):
> 
> { 'word': "aaa\nbbb" }
> 
> to insert 2 lines:
> aaa
> bbb
> 
> 
> Currently it inserts
> aaa^@bbb
> 
> 
> Where ^@ is NUL character (:h NL-used-for-NUL).
> 
> The problems with multiline completion is that there will be open question 
> how to handle indentation.
> 
> Alternatively we could allow List as 'word' parameter where each line would 
> be one item.
> 
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub

I would be careful of underestimating the complexity of getting indentation 
"right". The main problem being that it is probably highly subjective whether 
or not the editor should reformat the completion item just because it contains 
newlines.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [vim/vim] Proposal: multiline completion support (#2505)

[Ben Jackson]

On Thursday, December 28, 2017 at 10:28:42 AM UTC, Christian Brabandt wrote:
> Alternatively we could allow List as 'word' parameter where each line would 
> be one item.
> 
> 
> +1 for this
> 
> 
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub

if support for multiline completions was added, YCM would take advantage of it. 
Not super high on the wishlist, but certainly useful. A concrete use case is 
jdt.ls (java language server) returns entire method definitions as part of 
completion items in order to implement "getters and setters" for java classes. 
Currently we silently drop these because multi-line insertions aren't possible.

Pretty niche case though.

-- 
-- 
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RFC: Signature help/argument hints in a second popup menu

[Ben Jackson]

Hi Bram and community,

I have prepared a brief request for comments on a proposed new Vim feature 
which I am personally very keen on, but would like to gauge the appetite for it 
and the thoughts of the community and maintainers at large before actually 
embarking on a proper implementation.

The feature is IDE-like display of the method signature being entered at the 
same time as the insert-mode completion menu.

The RFC is best viewed in a gist here and includes a POC and some demos in 
animated-gif form: 
https://gist.github.com/puremourning/3ac3be4527ee094250ae516fc26561a2

It's also replicated below for those that prefer plaintext :)

I'd be super grateful for any responses, comments, flames, ideas or even 
insults ;)

Cheers,
Ben

---

# TL;DR

This RFC proposes introducing a second popup menu in insert mode to display
method argument hints, current parameter, etc. similar to a number of IDEs and
editors. The proposal is to allow scripts to control this (such as on insert of
`(` and `)` characters) and for it to be non-interractive and not to interfere
with insert-mode completion.

The purpose of the RFC is to guage the appetite from Bram and the community for
such a feature, and to discuss the design/functional behaviours prior to
committing to an implementation/etc.

# Motivation

There are a number of Vim plugins which attempt to provide some IDE-like
features using Vim's completion system, in combination with omnifuncs and
insert-mode completion that is built-in. Examples:

- YouCompleteMe - https://github.com/Valloric/YouCompleteMe
- neocomplete, deoplete, neocomplcache, and other friends
- eclim?
- any number of hundreds of omnifuncs
- Microsoft language server client?
- Various other "async complete" plugins
- possibly any number of other completion plugins, including implementations
  specific to particular languages (e.g. using omnifunc), or using l

In their simplest form, these provide a list of identifiers which are
semantically valid to be inserted at the current cursor position (or the result
of the equivalent of omnifunc's 'findstart' request), using the insert-mode
completion APIs provided by Vim.

One of the most commonly requested features for YouCompleteMe is the ability to
display the valid arguments for function calls, as well as semantically correct
identifiers. This feature is known as "argument hints", "parameter
completions", "signature help" or suchlike. 
[Microsoft's Language Server Protocol][lsp] refers to them as "Signature Help".

# Illustrative example

For example, the user types something like the following, with the cursor on
`^`:

```c

typedef struct pum_T 
{
  int pum_item_count;
  int pum_selected;
  pumitem_T* items[];
} pum;

void pum_display_item( pum_T* pum,
   char_u* message,
   pumitem_T* item_list );

void pum_display_item( pum_T* pum,
   int selected_item,
   pumitem_T* item );

void main(void)
{
  pum_T pum = init_pum();
  pum_display_item( pum, pum.^
}

```

Current completion systems (or omni-completion, invoked with ``) would
typically present a popup menu with the valid options from the definition,
such as:

- `int pum_selected`
- `int pum_item_count`

Methods often have many more arguments than this toy example, and
the declaration is not likely visible when it is used. Instead, many IDEs and
other editors provide a second "popup" when the user types the `(`. Typically,
this is _above_ rather than below the current line and contains the list of
overloads of the fucntion and their arguments, often highlighting (one way or
another) the "current" argument being entered.

For example, it might look like this:

||
| pum_display_item( pum_T* pum, **char_u *message**, pumitem_T* item )   |
| pum_display_item( pum_T* pum, **int selected_item**, pumitem_T* item ) |
||
pum_display_item( pum, pum.^
   |---|
   | pum_selected int  |
   | int pum_item_count   int  |
   |---|

# Known existing attempts in Vim

- **The preview window.**
  By using the extra data in the completion menu item structure, we can show
  some static information in the preview window. The drawbacks are that the
  preview window has to always be visible (taking up valuable screen real
  estate), or it pops in and out of visibility, causing the current row to
  shift disconcertingly on the screen. Requires `preview` in the `completeopt`
  and other autocmds etc. to show/hide it. Cursor moving into and out of
  the preview window triggers `BufEnter` autocoms, which causes meaningful lag
  when the completion menu is visible (OK, this could be blamed mostly on the
  plugins using `Buf