Re: Health update

[puremo...@gmail.com]

That's so great to hear. Glad you're feeling better, Bram.

On Thursday, December 22, 2022 at 1:11:04 PM UTC Bram Moolenaar wrote:

>
> > Good evening everyone and Bram in particular. 
> > I just wanted to know if it was possible to have news of your health 
> which 
> > I hope has now fully recovered. 
>
> Everything is OK now. Thanks for caring.
>
> -- 
> ARTHUR: Bloody peasant!
> DENNIS: Oh, what a give away. Did you hear that, did you hear that, eh?
> That's what I'm on about -- did you see him repressing me, you saw it
> didn't you?
> The Quest for the Holy Grail (Monty Python)
>
> /// Bram Moolenaar -- br...@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/fca46b47-5d28-4ba2-8c6f-80d2efdebf15n%40googlegroups.com.

Re: Choices for Vim9 class implementation

[puremo...@gmail.com]

For what it's worth, I feel that the formal "var memberVariable : Type" 
syntax for member is (while more verbose) more likely to stand out. The 
`var` keyword is a signpost and so is likely to be syntax highlighted. 
Simple `memberVariable : Type` doesn't stand out anywhere and contains 
mostly identifiers without keywords.

Additionally, I personally prefer the symmetry with local variables. If all 
declarations look the same, then it's one less rule to remember.

You can then also use const: `const memberVarConstant : Type` maybe?

On Tuesday, December 20, 2022 at 12:30:50 AM UTC ch...@createng.com wrote:

>
>> The difference between a regular method and a constructor is that for a 
>> constructor it is very common to assign the argument to an object 
>> member. 
>>
>> The idea comes from Dart, and I don't think Dart supports this for 
>> anything but constructors.
>>
>
> That's a good point, it is usually constructors where it get tedious.
> I really appreciate your considered replies.  
> Thanks
>  
>

-- 
-- 
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/2b98f2fa-d3d4-4ae3-bd49-1cfe4e18b714n%40googlegroups.com.

Re: Zero cmdheight

[puremo...@gmail.com]

I tried it out and quite liked it initially. though I'm not sure if I would 
use it permanently. I think I would miss `showcmd` too much.

That said, I did a quick GitHub search. As many users put their vimrc in 
GitHub we can search for it. This probably covers only users that either 
tried the new setting or used the version (I presume) from neovim, and it's 
only a sample, but : 
https://github.com/search?q=%22cmdheight%3D0%22&type=commits

 (Note the code search didn't work, that's just commits where people have 
mentioned `cmdheight=0` in their commit message).

So I think that says a nonzero number of users will enable this, but how 
that compares as a percentage, and if that makes it worthwhile or not is 
difficult to say. Perhaps another way of looking at it - does the set of 
code changes required to make this possible open up any other opportunities 
that were previously difficult, e.g. as a refactoring does it help 
maintenance in the future, or the addition of future features? I'm guessing 
not, judging by the additional complexity being added.
On Tuesday, August 30, 2022 at 7:53:58 AM UTC+1 egz...@gmail.com wrote:

> I think people asking for it don't understand all the implications that go 
> with it. I do want to try it out. So far the workarounds for corner cases 
> I've seen look fine. Jumping last status line doesn't seem to bother me.
>
> понедельник, 29 августа 2022 г. в 22:24:14 UTC+3, Romain Lafourcade: 
>
>> I don't have links at hand but in my ten or so years spent answering Vim 
>> questions in various forums I have seen that request quite a few times. But 
>> are those drive-by askers from six years ago still here? Will they use the 
>> feature?
>>
>> From where I stand, the only use of a zero cmdheight would be in 
>> combination with a floating window à la "command palette/quake terminal". I 
>> have zero interest for such a feature and I think that there are more 
>> productive things to do.
>>
>> On Monday, August 29, 2022 at 1:56:20 PM UTC+2 toothpik wrote:
>>
>>> if we're voting put me down on the side of less work, less complicated 
>>> code
>>>
>>> i tried a zero cmdheight and immediately didn't like it
>>>
>>> On Mon, Aug 29, 2022 at 5:24 AM Bram Moolenaar  
>>> wrote:
>>>

 It takes a lot of effort to make zero 'cmdheight' work properly.
 Various bugs and corner cases keep popping up.

 I added the message window, so that various informative messages do not
 get lost, and that helps.  But it also makes it more complicated.

 There is also one bug that I don't know how to reproduce yet, which
 makes the window frames too tall.  The last statusline goes missing.

 So, I was wondering who will actually want to use this?  It gives you a
 line of extra space, at the cost of various side effects.  Especially
 the last status line jumping up when typing ":" or "/".  Is this worth
 the extra work and making the code more complicated?


 -- 
 Wi n0t trei a h0liday in Sweden thi yer?
  "Monty Python and the Holy Grail" PYTHON (MONTY) 
 PICTURES LTD

  /// Bram Moolenaar -- br...@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+u...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/vim_dev/20220829102404.A8A9B1C0907%40moolenaar.net
 .

>>>

-- 
-- 
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/e20e9e4f-ac87-4cf9-aab2-6cff5eabdc3en%40googlegroups.com.

Re: def! in legacy vimscript

[puremo...@gmail.com]

> 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?

On Thursday, February 17, 2022 at 10:59:18 AM UTC Bram Moolenaar wrote:

>
> Maxim Kim wrote:
>
> > Shouldn't def functions be prohibited in legacy vimscript?
> > 
> > 
> https://vi.stackexchange.com/questions/36829/how-can-i-define-vim9-functions-and-vim9-lambdas-in-a-vim9-script
> > 
> > Basically if you add
> > 
> > def! Hello()
> > echo "hello world"
> > enddef
> > 
> > to a regular legacy vim file (.vimrc, for example), function Hello is 
> > globally defined and one can :call Hello() and get echoed "hello world".
>
> In case you have some code that needs to be executed fast, but the rest
> of the script has some stuff you don't want to convert to Vim9, then
> putting that code in a compiled function is very useful.
>
> Wether a function is script-local or global (when not using a "s:" or
> "g:" prefix) depends on the script it's defined in. An alternatie could
> be to make :def functions always script-local by default, then you would
> have to use "g:" to make them global. I don't think this helps and it
> can be confusing.
>
> 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.
>
> -- 
> Keyboard not found. Think ENTER to continue.
>
> /// Bram Moolenaar -- br...@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/5e525c68-abc8-44c7-8493-a8703462a849n%40googlegroups.com.

Re: [vim/vim] [FEATURE REQUEST] A solution for getting all the text properties in a buffer (Issue #9128)

[puremo...@gmail.com]

Bram, we _think_ the overhead is calling prop_list for every line, and that 
doing that in one call spanning the whole buffer would be more efficient. 
(currently we're doing a request per line, filtering the result for the 
types that start with Ycm, then adding them to a python list).

That said, it would be certainly useful for our use case to be able to only 
return props of a given list of types as well. That allows us to say 
"return us all the properties of  in  of the 
buffer". I'd suspect that for _most_ plugin authors that they would only be 
interested in props that they created themselves. I can imagine scenarios 
where PluginA looks at PluginB's text properties, but would expect that to 
be the rare case rather than the norm.

I think that would be relatively faster when scanning the memlines than 
doing a request per-line and filtering in vimscript land.

> Whatever solution we pick, it is likely still slow for a very long file.

Yes, this is true. In fact, we already disable this functionality on very 
large files (the inefficiency was actually discovered because of a bug in 
that!); we're now more thinking about efficiency on moderate usage as that 
affects more users of course.

> Have you considered only dealing with visible lines?

I don't think we had considered this. Certainly this adds quite a lot of 
complexity - we would have to listen for scrolling events and update the 
properties as the user scrolls, handling there being multiple windows per 
buffer etc. I had previously assumed this wasn't even possible (is there an 
autocmd for "window scrolled"?), but I admit I haven't thought hard about 
it.

On Sunday, November 14, 2021 at 10:32:36 PM UTC Bram Moolenaar wrote:

>
> > [prop_list_profile.txt](
> https://github.com/vim/vim/files/7527900/prop_list_profile.txt)
> >  The problem
> > 
> > If a plugin wants to grab all of the previously placed text properties 
> that the same plugin has placed, the current `prop_list` requires some work:
> > 
> > 1. Loop over the lines of the buffer.
> > 2. Grab all the text properties from each line and aggregate in some 
> list.
> > 3. Filter out all properties that are not produced by the plugin. A 
> plugin might need to grab two types of properties, so making vim filter by 
> `type` isn't perfect either.
> > 
> > This results in a ton of vimscript API calls and is a similar thing to 
> what lead to https://github.com/vim/vim/issues/8675.
> > 
> > Basically, what a plugin is running is this:
> > 
> > ```viml
> > function! g:UpdateMatches()
> > let properties = []
> > for line in range( line('$') )
> > call extend(properties, filter(prop_list( line + 1, { 'bufnr': 1 } ), 
> 'v:val[ "type" ][ :3 ] ==# "Ycm"' ))
> > endfor
> > endfunction
> > ```
> > The profile is here: 
> https://gist.github.com/bstaletic/84c10b75be93c99f321a27af73278a8d
> > 
> > ### The neovim API
> > 
> > I'm not the biggest fan of neovim, but its API here is really nice.
> > 
> > Each plugin gets a unique namespace ID. Then, when getting (neovim's 
> equivalent of) all the properties in a buffer, besides the buffer number, 
> the ID is passed as well. Introducing this namespace ID thing to text 
> property APIs would be perfect. Vim's `sign_foo()` family of functions 
> already has the `group` thing. 
> > 
> >  Alternative
> > 
> > A simpler solution is just introducing something like 
> `prop_list_range()`, where not only a single line would be passed, but 
> rather a range of lines. That way plugins could request all text properties 
> from line N to line M. It would still leave filtering to the users.
> > 
> > Note that the two ideas aren't exactly exclusive.
> > 
> >  Context
> > 
> > I'm a maintainer of YouCompleteMe. The way YCM updates text properties 
> for a specific buffer is basically described in the "problem" section. In 
> more detail:
> > 
> > - We define two property types: 
> https://github.com/ycm-core/YouCompleteMe/blob/master/autoload/youcompleteme.vim#L418-L433
> > - When we update the diagnostics, we do it like this:
> > - [First, we grab all placed properties](
> https://github.com/ycm-core/YouCompleteMe/blob/master/python/ycm/diagnostic_interface.py#L133
> )
> > - [For each new diagnostic](
> https://github.com/ycm-core/YouCompleteMe/blob/master/python/ycm/diagnostic_interface.py#L137
> )
> > - [if the exact same has already been placed, just skip](
> https://github.com/ycm-core/YouCompleteMe/blob/master/python/ycm/diagnostic_interface.py#L149
> )
> > - [else, place a new one](
> https://github.com/ycm-core/YouCompleteMe/blob/master/python/ycm/diagnostic_interface.py#L151-L156
> )
> > - Could be optimized with `prop_add_list()`. In the TODO list.
> > - Once we have skipped all the ones we want to keep and added the new 
> ones, what remains is [to remove the stale ones](
> https://github.com/ycm-core/YouCompleteMe/blob/master/python/ycm/diagnostic_interface.py#L158-L159
> )
> > - There's no batch remove of properties, but *so far* that hasn'

Re: [vim/vim] [FEATURE REQUEST] A solution for getting all the text properties in a buffer (Issue #9128)

[puremo...@gmail.com]

We are not trying to modify them per se, in fact we're trying _not to_.

YCM receives a batch of diagnostics, say:
  - A:  an error on line 10 spanning { 10, 4 } to { 10, 8 }.
  - B: a warning on line 13 spanning { 13,1 } to { 14, 2 }

YCM creates text props spanning those ranges with the some 
YcmError/YcmWarning highlight group.

Some time later, YCM receives another batch of diagnostics, perhaps the 
following:
  - A: an error on line 10 spanning { 10, 4 } to { 10, 8 }
  - C: an error on line 20 spanning { 20, 10 } to { 20,10 }

YCM is trying to make minimal changes to the props, ie:
 - leave A as is
 - remove B
 - add C

On Sunday, November 14, 2021 at 10:20:15 PM UTC yegapp...@gmail.com wrote:

> Hi,
>
> On Fri, Nov 12, 2021 at 5:45 AM Boris Staletic  
> wrote:
>
>> prop_list_profile.txt 
>> 
>> The problem 
>>
>> If a plugin wants to grab all of the previously placed text properties 
>> that the same plugin has placed, the current prop_list requires some 
>> work:
>>
>>1. Loop over the lines of the buffer. 
>>2. Grab all the text properties from each line and aggregate in some 
>>list. 
>>3. Filter out all properties that are not produced by the plugin. A 
>>plugin might need to grab two types of properties, so making vim filter 
>> by 
>>type isn't perfect either.
>>
>>
> How are you using the property dict value returned by prop_list()? I see 
> that you cannot
> modify the value returned by prop_list() and then update the text property 
> by using
> the prop_add() or the prop_add_list() function.
>
> BTW, I have implemented the prop_list_range() function to return the list 
> of text
> properties placed on a range of lines in a specified buffer:
>
> https://github.com/yegappan/vim/tree/textprop
>
> But I am trying to understand how the returned value will be used. If you 
> have a text
> property that spans multiple lines, then you cannot simply modify the 
> value returned
> by prop_list_range() and place the text properties again.
>
> Regards,
> Yegappan
>  
>
>>
>>
>> This results in a ton of vimscript API calls and is a similar thing to 
>> what lead to #8675 .
>>
>> Basically, what a plugin is running is this:
>>
>> function! g:UpdateMatches()
>>
>>   let properties = []
>>
>>   for line in range( line('$') )
>>
>> call extend(properties, filter(prop_list( line + 1, { 'bufnr': 1 } ), 
>> 'v:val[ "type" ][ :3 ] ==# "Ycm"' ))
>>
>>   endfor
>> endfunction
>>
>> The profile is here: 
>> https://gist.github.com/bstaletic/84c10b75be93c99f321a27af73278a8d
>> The neovim API 
>>
>> I'm not the biggest fan of neovim, but its API here is really nice.
>>
>> Each plugin gets a unique namespace ID. Then, when getting (neovim's 
>> equivalent of) all the properties in a buffer, besides the buffer number, 
>> the ID is passed as well. Introducing this namespace ID thing to text 
>> property APIs would be perfect. Vim's sign_foo() family of functions 
>> already has the group thing.
>> Alternative 
>>
>> A simpler solution is just introducing something like prop_list_range(), 
>> where not only a single line would be passed, but rather a range of lines. 
>> That way plugins could request all text properties from line N to line M. 
>> It would still leave filtering to the users.
>>
>> Note that the two ideas aren't exactly exclusive.
>> Context 
>>
>> I'm a maintainer of YouCompleteMe. The way YCM updates text properties 
>> for a specific buffer is basically described in the "problem" section. In 
>> more detail:
>>
>>- We define two property types: 
>>
>> https://github.com/ycm-core/YouCompleteMe/blob/master/autoload/youcompleteme.vim#L418-L433
>>  
>>- When we update the diagnostics, we do it like this: 
>>   - First, we grab all placed properties 
>>   
>> 
>>  
>>   - For each new diagnostic 
>>   
>> 
>>  
>>   - if the exact same has already been placed, just skip 
>>   
>> 
>>  
>>   - else, place a new one 
>>   
>> 
>>  
>>  - Could be optimized with prop_add_list(). In the TODO list. 
>>   - Once we have skipped all the ones we want to keep and added the 
>>   new ones, what remains is to remove the stale ones 
>>   
>> 
>>  
>>  - There's no batch remove of properties, but *so far* that 
>>  hasn't been a problem. 
>>   
>> The algorithm is made that way, because in common cases it's faster than 
>> removi

Re: RFC - External debugger API for debugging vimscript

[puremo...@gmail.com]

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.
On Monday, April 13, 2020 at 4:45:23 PM UTC+1 Bram Moolenaar wrote:

>
> Ben Jackson wrote:
>
> [...]
>
> > > 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.
>
> Sounds like the message redirection should allow for redirecting to a
> function, which would then send it over a channel. Currently it's
> possible to redirect to a variable, it should be possible to redirect to
> a callback function.
>
> > >> 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.
>
> Both would work. I was thinking of the symmetry with ":redir", it's
> kind of redirecting the input.
>
> > >> - 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)
> > > 
> > > This sounds similar to something as the "frame" command in gdb, to
> > > change the debugger scope.
> > 
> > It is, and I initially actually added debug_setframe, but in practice
> > it was safer/easier in my testing to add a function to evaluate an
> > expression in a specific frame (reason was that if the expression
> > threw an exception it was hard to un-set this frame without things
> > getting messed up). If you prefer the more general approach I’ll spend
> > more time on that.
>
> I suppose setting the frame is something that exists in the remote
> debugger. The API can include the frame in the evaluation command,
> without changing the frame for following commands.
>
>
> -- 
> ./configure
> Checking whether build environment is sane ...
> build environment is grinning and holding a spatula. Guess not.
>
> /// Bram Moolenaar -- br...@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/9265c59d-b403-4194-b419-0c2ff9f1a1c9n%40googlegroups.com.

Re: [vim/vim] proposal: allow popup col/line relative to the mouse position (#7645)

[puremo...@gmail.com]

Or popup_beval ?

On Saturday, January 9, 2021 at 3:35:29 PM UTC Bram Moolenaar wrote:

> Is there a reason you can't use getmousepos() ?
>
> —
> 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/75ecb57c-8cd9-4ad3-932f-4f32547851f9n%40googlegroups.com.

Re: [vim/vim] Compiling VIM with Huge and Python Results in Error: This version was built without iconv(). (#7642)

[puremo...@gmail.com]

> vim --version output is for macvim which is too old for what I need

the latest MacVim is more than sufficient.

On Saturday, January 9, 2021 at 10:13:44 AM UTC puremo...@gmail.com wrote:

> > I am trying to install the latest version of VIM on macOS and compile it 
> with a different configuration. I want to do this because I'm trying to 
> install vimspecto <https://github.com/puremourning/vimspector>
>
>
> `brew install vim` is sufficient for that FYI
>
> On Saturday, January 9, 2021 at 4:03:02 AM UTC CharlesARoy wrote:
>
>> Closed #7642 <https://github.com/vim/vim/issues/7642>.
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub 
>> <https://github.com/vim/vim/issues/7642#event-4186700639>, or unsubscribe 
>> <https://github.com/notifications/unsubscribe-auth/ACY5DGEJCLL4B5KIAUUEXB3SY7IO7ANCNFSM4V3DR6HA>
>> .
>>
>

-- 
-- 
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/a10c162b-1f11-4047-928c-27f76274f98bn%40googlegroups.com.

Re: [vim/vim] Compiling VIM with Huge and Python Results in Error: This version was built without iconv(). (#7642)

[puremo...@gmail.com]

> I am trying to install the latest version of VIM on macOS and compile it 
with a different configuration. I want to do this because I'm trying to 
install vimspecto 


`brew install vim` is sufficient for that FYI

On Saturday, January 9, 2021 at 4:03:02 AM UTC CharlesARoy wrote:

> Closed #7642 .
>
> —
> 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/939aeec2-ffc5-4b35-aeb5-a7d68ac9094dn%40googlegroups.com.

Re: [vim/vim] Impossible to pass non-UTF-8 strings from vim to Python 3 (#1053)

[puremo...@gmail.com]

Bit off the wall, but perhaps we should provide a py3 api something like 
`vim.eval_bytes()` returning a `bytes` instance rather than trying to 
decode the evaluated bytes into a (unicode) `str` object. In the general 
case a vim string variable can contain any bytes (except NUL?); to read 
that into a python object, we have to decode it, but if it's just a 
variable with no context, we can't assume that it's encoded in any 
particular way.

I believe that's actually what happens what you access `vim.vars` - you get 
a `bytes` instance:

i.e. doing "let g:test = 'byte me'" and then
* Ctrl-r= py3eval( 'vim.eval( "g:test" )' )
* Ctrl-r= py3eval( 'type( vim.eval( "g:test" ) ).__name__' )
and
* Ctrl-r=py3eval( 'vim.vars[ "g:test" ]' )
* Ctrl-r=py3eval( 'type( vim.vars[ "g:test" ] ).__name__' )

```
Eval: byte me
  Type: str

vim.vars: byte me
  Type: bytes
```

This would push he burden of the decoding on to the script author, who may 
have better knowledge of what the variable contains (encoding wise) ?

Just a thought.
On Monday, December 21, 2020 at 7:25:11 PM UTC Bram Moolenaar wrote:

> Reopened #1053 .
>
> —
> You are receiving this because you commented.
> 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/793cf800-a95b-40fe-9c30-4ee652a08e83n%40googlegroups.com.

Re: [vim/vim] complete_info().selected is -2 when 'menuone' is set and only 1 completion (#6945)

[puremo...@gmail.com]

I get the same behaviour. we get `-1` when it should be `0`.

The original report was that it would return `-2` which was invalid by the 
spec. `-1` is just incorrect I think.

On Monday, October 26, 2020 at 1:25:12 AM UTC csh wrote:

> @puremourning  I use vim(patch 8.2.1987 
> ubuntu20.10)，and I use your test.vim, complete_info().selected is -1 when 
> 'menuone' is set and only 1 completion, would you mind test it again?
>
> —
> 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/3caf669f-8eec-422f-a51d-ca6d1ae6c380n%40googlegroups.com.

Re: Vim9: rethinking conditions and boolean expressions

[puremo...@gmail.com]

> 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"`


On Sunday, October 4, 2020 at 10:47:15 PM UTC+1 Bram Moolenaar wrote:

>
> > In javascript you can use !! operator to always convert it to boolean.
> > 
> > var name = ''
> > var nameExists = !!(name || 'Prabir')
>
> Yes, and I think we should do the same. It should already work like
> that now.
>
> Thus in most places where a condition is expected, such as with ":if"
> and ":while", a boolean is expected. With legacy script you could use a
> string, which was converted to a number and easily leads to mistakes.
> Also numbers could be used. With Vim9 script only the numbers zero and
> one can be used. This avoids making mistakes, but it's a bit strict.
>
> The new "??" operator can be used with any expression. Just like with
> "!" accepts any expression. In these places the expression is tested to
> be "falsy" or "truthy".
>
> I might have missed something, we might need a few more tests.
>
>
> -- 
> hundred-and-one symptoms of being an internet addict:
> 32. You don't know what sex three of your closest friends are, because they
> have neutral nicknames and you never bothered to ask.
>
> /// Bram Moolenaar -- br...@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/b0bcb397-317c-4fa7-b42f-5ac6eebd3402n%40googlegroups.com.

Re: [vim/vim] termux ycm mouse openating (#7007)

[puremo...@gmail.com]

 > I don't think that the ycm (YouCompleteMe) .. relevant here.

Confirmed. YCM just calls complete() with completeopt+=noselect set


On Thursday, September 24, 2020 at 12:01:03 PM UTC+1 Dominique Pellé wrote:

> My understanding of this issue is that we cannot select an item in the pum 
> (popup menu) by the mouse, even with set mouse=a. Clicking on an item in 
> the pum just closes the pum and selects the active item, regardless of 
> where we click. I suppose that the bug reporter expected that clicking with 
> the mouse on an item in the pum selects the item where we click. That said, 
> the bug report is clearly not detailed enough. I don't think that the ycm 
> (YouCompleteMe) plugin or termux are relevant here.
>
> —
> 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/68920981-76ea-4793-b9f9-0e137cf439dbn%40googlegroups.com.

Re: [vim/vim] Request for vim9: Cast to boolean implicitly (#6903)

[puremo...@gmail.com]

Python's take on this is that if you want a bool, you use the bool 
constructor `bool(  )`; we could add a vimscript function (like 
`string`) which takes an expr and returns either `v:true` or `v:false`, as 
in `return bool( 'string' )` or `return bool( 99 )`. The semantics of the 
type specified would have to determine how 'truthy' a value is. I think 
that's already defined for vimscript as mentioned.

On Wednesday, September 9, 2020 at 1:56:33 PM UTC+1 Bram Moolenaar wrote:

> Closed #6903  via 29a86ff 
> 
> .
>
> —
> 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/c693b76c-c7e2-4822-a9a4-6c28b1cb0c80n%40googlegroups.com.

Re: [vim/vim] Treat tmux as an xterm-like terminal (#6609)

[puremo...@gmail.com]

> logic were *configurable*

It's pretty configurable now - you can set every t_* code manually. But 
really, isn't that literally what terminfo/termcap database and 
nottybuiltin is for ? As in, if you install the rxvt termcap and set 
'nottybuiltin' then it's completely configurable.

On Monday, August 3, 2020 at 5:04:57 AM UTC+1 Jonathan Rascher wrote:

> Issue #1830  seems related, but 
> is probably overkill. Vim doesn't include a custom builtin termcap for rxvt 
> (instead just treating it as xterm) even though rxvt has way more 
> differences from xterm than screen has from xterm.
>
> If we're gonna do something fancy, it'd be neat if the builtin termcaps 
> and accompanying logic were *configurable* rather than hardcoded in Vim 
> at compile time, but that feels much larger in scope than adding one line 
> to os_unix.c. :)
>
> —
> 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/3afc8e9c-38bf-47d1-bab3-2fbbe0afaccdn%40googlegroups.com.