Re: [vim/vim] Make indentexpr evaluate from older vim scripts (PR #14936)

[Yegappan Lakshmanan]

On Sun, Jun 9, 2024 at 9:52 AM Christian Brabandt 
wrote:

> Hm, I suppose if we make this change, we also don't need the import
> statement anymore. @yegappan  @dkearns
>  what is your opinion on this?
>
>
>
If there is a need to support using "indentexpr" from a legacy script, then
I don't see an issue with this change.

Regards,
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/CAAW7x7%3DqPp0R1xCYhGpeNFMwYJLg6xZcPij-QUM9kJnkyaKBcA%40mail.gmail.com.

Re: [vim/vim] Fix errors in using the latest termdebug.vim (PR #14941)

[Yegappan Lakshmanan]

On Sat, Jun 8, 2024 at 9:08 PM Shane-XB-Qian 
wrote:

> > > what other window in the middle you were trying to say?
> > > did you manually opened var/asm window?
> > >
> >
> > No. I am not using the var/asm windows. I use the following
> > termdebug option to
> > set the window width:
> >
> > let g:termdebug_config = {}
> > let g:termdebug_config['wide'] = 164
>
> then i do not know what happened to you, since the auto-layout is only
> about 'Var' and 'Asm' window,
> if you did not manually open it (or enabled the option of auto, but i
> supposed you would not do so),
> it should be not impact your other windows e.g source and gdb window.
> // please check the code _before_ https://github.com/vim/vim/pull/14903
> that vim9 convert,
> // or after that convert, but i did not upgrade or tried to use that _yet_.
>
>
>
This turned out to be a bug in the term_start() function.  This function
doesn't clear the vertical
split command modifier correctly.  I have opened a PR to address this.

Regards,
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/CAAW7x7nB0CrWKhXr%2Bvpyevxq4vVcoTgRqwhApYFHfOy5G7Jk4w%40mail.gmail.com.

Re: [vim/vim] Fix errors in using the latest termdebug.vim (PR #14941)

[Yegappan Lakshmanan]

On Sat, Jun 8, 2024 at 11:08 AM Shane-XB-Qian 
wrote:

> what other window in the middle you were trying to say?
> did you manually opened var/asm window?
>

No.  I am not using the var/asm windows.  I use the following
termdebug option to
set the window width:

let g:termdebug_config = {}
let g:termdebug_config['wide'] = 164

With the above setting, when I run the ":Termdebug ./vim" command from the
Vim src
directory, I used to get a window layout with two vertically split
windows.  The left window
is horizontally split into two windows with GDB in the top window and Vim
in the bottom
window.  The vertically split right window contains the source.

After this patch, now I get three vertically split windows.  GDB in the
leftmost window,
Vim in the middle window and the source in the rightmost window.

- Yegappan

if yes, you still also can move that window to bottom or somewhere by
> manually too.
> // if say so, otherwise I did not know but wish you keep to review this
> vim9 convert of termdebug if not revert this vim9 convert.
>
>

-- 
-- 
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/CAAW7x7m_sZG-sqUC8dK0Kh-PpO_t5RvbrOzVTX3aM7CO-m%2BAhA%40mail.gmail.com.

Re: [vim/vim] Fix errors in using the latest termdebug.vim (PR #14941)

[Yegappan Lakshmanan]

On Sat, Jun 8, 2024 at 9:33 AM Shane-XB-Qian 
wrote:

> it is difficult to switch between the GDB window and the source window
> (because there are other windows in the middle).
>
> i do not know how or what was leading you to such result, since the layout
> change looked was about 'Var' and 'Asm' window;
> maybe that vim9 convert? i did not upgrade this convert yet (which i
> forsee there would be some broken since changed too much), so maybe you can
> varify that convert more if it was ok to do so? i may more trust you did
> that.
>
>
> The change in window layout is not caused by the Vim9 script conversion.
This is caused by
the changes made in
https://github.com/vim/vim/commit/ca48202b6f46cfb40a0d1d80033a2f3e8cb7b813.

Regards,
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/CAAW7x7kbR1MKE1wyEYNZHzhu7pL1C%2B5o6QLjsYj3pgaqOAON7w%40mail.gmail.com.

Re: [vim/vim] Fix errors in using the latest termdebug.vim (PR #14941)

[Yegappan Lakshmanan]

On Sat, Jun 8, 2024 at 9:18 AM Shane-XB-Qian 
wrote:

> i meant the vim9 convert,
> as for the layout #13474 (comment)
>  had
> explained it.
>
>
> What was the problem the layout change was trying to address?  The layout
was usable before
this change.  With this change now, it is difficult to switch between the
GDB window and the source
window (because there are other windows in the middle).  Also, the source
code window has
less than 80 characters leading to the wrapping of the source code.  This
change should be
reverted.

Regards,
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/CAAW7x7m9YnTgqDFh-3ZSq9tyEu%2Bn%2BbjTCC%3DnWE40t3VQqfL%2BhQ%40mail.gmail.com.

CodeQL Github action is failing

[Yegappan Lakshmanan]

Hi all,

The cpp CodeQL check is failing in Github Actions
(https://github.com/vim/vim/actions/runs/9299006067/job/25592019947)
with the following messages:

-
CodeQL job status was configuration error.
RequestError [HttpError]: Bad credentials
at 
/home/runner/work/_actions/github/codeql-action/v3/node_modules/@octokit/request/dist-node/index.js:86:21
at process.processTicksAndRejections
(node:internal/process/task_queues:95:5)
at async requestWithGraphqlErrorHandling
(/home/runner/work/_actions/github/codeql-action/v3/node_modules/@octokit/plugin-retry/dist-node/index.js:71:20)
at async Job.doExecute
(/home/runner/work/_actions/github/codeql-action/v3/node_modules/bottleneck/light.js:405:18)
{
  status: 401,
  response: {
url: 'https://api.github.com/repos/vim/vim/code-scanning/analysis/status',
status: 401,
headers: {
  'access-control-allow-origin': '*',
  'access-control-expose-headers': 'ETag, Link, Location,
Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining,
X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset,
X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval,
X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation,
Sunset',
  'content-length': '80',
  'content-security-policy': "default-src 'none'",
  'content-type': 'application/json; charset=utf-8',
  date: 'Thu, 30 May 2024 07:59:09 GMT',
  'referrer-policy': 'origin-when-cross-origin,
strict-origin-when-cross-origin',
  server: 'GitHub.com',
  'strict-transport-security': 'max-age=31536000;
includeSubdomains; preload',
  vary: 'Accept-Encoding, Accept, X-Requested-With',
  'x-content-type-options': 'nosniff',
  'x-frame-options': 'deny',
  'x-github-media-type': 'github.v3; format=json',
  'x-github-request-id': '4848:802D9:12C9D2A:20444FD:665831CD',
  'x-ratelimit-limit': '60',
  'x-ratelimit-remaining': '39',
  'x-ratelimit-reset': '1717058897',
  'x-ratelimit-resource': 'core',
  'x-ratelimit-used': '21',
  'x-xss-protection': '0'
},
data: {
  message: 'Bad credentials',
  documentation_url: 'https://docs.github.com/rest'
}
  },
  request: {
method: 'PUT',
url: 'https://api.github.com/repos/vim/vim/code-scanning/analysis/status',
headers: {
  accept: 'application/vnd.github.v3+json',
  'user-agent': 'CodeQL-Action/3.25.6 octokit-core.js/3.6.0
Node.js/20.8.1 (linux; x64)',
  authorization: 'token [REDACTED]',
  'content-type': 'application/json; charset=utf-8'
},
body: 
'{"action_name":"init-post","action_oid":"unknown","action_ref":"v3","action_started_at":"2024-05-30T07:59:09.439Z","action_version":"3.25.6","analysis_key":".github/workflows/codeql-analysis.yml:analyze","commit_oid":"32a5faa6d7592795c6ec77e44dc0357b92b8a681","first_party_analysis":true,"job_name":"analyze","job_run_uuid":"771a84a8-9fa0-4749-918a-167140c91248","ref":"refs/heads/master","runner_os":"Linux","started_at":"2024-05-30T07:55:08.130Z","status":"success","testing_environment":"","workflow_name":"CodeQL","workflow_run_attempt":1,"workflow_run_id":9299006067,"actions_event_name":"push","languages":"cpp","runner_available_disk_space_bytes":21901520896,"runner_total_disk_space_bytes":77851254784,"completed_at":"2024-05-30T07:59:09.593Z","matrix_vars":"{\\n
 \\"language\\":
\\"cpp\\"\\n}","runner_arch":"X64","runner_image_version":"20240526.1.0","upload_failed_run_error":"Bad
credentials","upload_failed_run_stack_trace":"HttpError: Bad
credentials\\nat
/home/runner/work/_actions/github/codeql-action/v3/node_modules/@octokit/request/dist-node/index.js:86:21\\n
   at process.processTicksAndRejections
(node:internal/process/task_queues:95:5)\\nat async
requestWithGraphqlErrorHandling
(/home/runner/work/_actions/github/codeql-action/v3/node_modules/@octokit/plugin-retry/dist-node/index.js:71:20)\\n
   at async Job.doExecute
(/home/runner/work/_actions/github/codeql-action/v3/node_modules/bottleneck/light.js:405:18)","job_status":"JOB_STATUS_CONFIGURATION_ERROR"}',
request: { agent: [Agent], hook: [Function: bound bound register] }
  }
}
Warning: An unexpected error occurred when sending code scanning status report.
-

Regards,
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 

Re: [vim/vim] Make command-line execute vim9script without typing vim9cmd (Issue #14785)

[Yegappan Lakshmanan]

Hi,

On Sat, May 18, 2024 at 12:11 PM Lifepillar 
wrote:

> The comment about getting rid of the command line was a bit tongue in
> cheek. But the point is that the command line is pretty limited as a means
> to support script development. Some of the limitations wouldn't go away
> even if the command line provided better support for Vim 9 script (e.g.,
> limited editing possibilities).
>
> Regarding the scratch buffer: what if you want to step? Shall you define
> buffer local mappings?
>
> You may certainly do that (you may even do it in your current Vim buffer):
>
> nnoremap  x execute 'vim9cmd' getline('.')+
>
>
> You can also prefix the "source" command  with "vim9cmd" and a range to
source a range
of lines in the current buffer as Vim9 script.

Regards,
Yegappan

-- 
-- 
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/CAAW7x7k68W%2B2GCc%3Da90wL8wTjKiss5e1A5jvqHo5D8_YnpYNAQ%40mail.gmail.com.

Re: Commit: patch 9.1.0376: Vim9: Trailing commands after class/enum keywords ignored

[Yegappan Lakshmanan]

Hi,

On Sat, Apr 27, 2024 at 10:08 AM Christian J. Robinson
 wrote:
>
> I think this patch, or one of the others around this same time, broke adding 
> comments after "}", as in the following:
>
> vim9script
>
> class Foo
> static const bar = { # {{{
> baz: 'qux'
> } # }}}
> endclass
>
> Results in:
>
> Error detected while processing C:\Users\hepti\comment.vim:
> line6:
> E488: Trailing characters: # }}}
>

Thanks for reporting the issue.  I have created a  PR
(https://github.com/vim/vim/pull/14651) to address this issue.

Regards,
Yegappan

> On Sat, Apr 27, 2024 at 4:00 AM Christian Brabandt  wrote:
>>
>> patch 9.1.0376: Vim9: Trailing commands after class/enum keywords ignored
>>

-- 
-- 
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/CAAW7x7mAZ%2BVcBXDb35dVecyyf7SfY5jSNg9_Ag80QJS%3Dxgb_KQ%40mail.gmail.com.

Re: [vim/vim] cbuffer/cad doesn't take visual selection as range '<,'>cad (Issue #14638)

[Yegappan Lakshmanan]

Hi Christian,

On Fri, Apr 26, 2024 at 9:02 AM Christian Brabandt <
vim-dev-git...@256bit.org> wrote:

> Hm, even the mentioned
> 
> '<,'>cgetbuffer does no longer work. It seems at least the following two
> commands would need to use ADDR_LINES instead of ADDR_OTHER.
>
> Something like this:
>
> diff --git a/src/ex_cmds.h b/src/ex_cmds.h
> index 70e57708f..bd195a72f 100644--- a/src/ex_cmds.h+++ b/src/ex_cmds.h@@ 
> -271,7 +271,7 @@ EXCMD(CMD_cabove,   "cabove",   ex_cbelow,
> ADDR_UNSIGNED),
>  EXCMD(CMD_caddbuffer,  "caddbuffer",   ex_cbuffer,
> EX_RANGE|EX_WORD1|EX_TRLBAR,-   ADDR_OTHER),+   ADDR_LINES),
>  EXCMD(CMD_caddexpr,"caddexpr", ex_cexpr,
> EX_NEEDARG|EX_WORD1|EX_NOTRLCOM|EX_EXPR_ARG,
> ADDR_NONE),@@ -331,7 +331,7 @@ EXCMD(CMD_cgetfile, "cgetfile", 
> ex_cfile,
> ADDR_NONE),
>  EXCMD(CMD_cgetbuffer,  "cgetbuffer",   ex_cbuffer,
> EX_RANGE|EX_WORD1|EX_TRLBAR,-   ADDR_OTHER),+   ADDR_LINES),
>  EXCMD(CMD_cgetexpr,"cgetexpr", ex_cexpr,
> EX_NEEDARG|EX_WORD1|EX_NOTRLCOM|EX_EXPR_ARG,
> ADDR_NONE),
>
> It seems ADDR_OTHER doesn't make sense here. @yegappan
>  what do you think?
>
>
>
Yes.  The above change looks good to me.

The change to ADDR_OTHER was introduced by Patch 8.1.1241
(b731689e85b4153af7edc8f0a6b9f99d36d8b011).
Currently there is no test for using a range with the caddbuffer and
cgetbuffer commands. That is why this regression
was not caught earlier.  We should add a few tests for using a range with
these commands.

Regards,
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/CAAW7x7k23YVKCNrvvsySMscO7dYV2sgqgfCX_OFEADbZthyO-w%40mail.gmail.com.

Re: [vim/vim] compile_def_function() is too long. Move out the code to compile the body of a function (PR #14622)

[Yegappan Lakshmanan]

Hi Christian,

On Tue, Apr 23, 2024 at 11:46 PM Christian Brabandt <
vim-dev-git...@256bit.org> wrote:

> Hi Yegappan,
> Coverity complains about this one here however:
> https://scan5.scan.coverity.com/#/project-view/41242/10101?selectedIssue=1596610
>
> I think this is a false positive?
>
>
> Yes.  This is a false positive.  I ran a few tests to compile a def
function with different types
of comments under valgrind to make sure that the vim9_bad_comment()
function doesn't
perform an out-of-bounds access.  I also compared the code before and after
the
refactoring to make sure that the logic is not changed.

Regards,
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/CAAW7x7%3D8Qkhw82Td6HDXZ3j02tjUssYNrEbZu1uoRDpOF5HZNw%40mail.gmail.com.

Re: [vim/vim] Running test_vim9_builtin.vim tests is slow (PR #14614)

[Yegappan Lakshmanan]

On Sun, Apr 21, 2024 at 6:09 PM Yegappan Lakshmanan <
vim-dev-git...@256bit.org> wrote:

> The tests in test_vim9_builtin.vim use the CheckDefAndScriptFailure(),
> CheckDefExecFailure(), etc. functions from the vim9.vim file.
> These functions store the supplied lines in a file and then source the
> file. This takes time. Instead of using a file, these lines can be stored
> in a buffer and then sourced. This method is already used by the new Vim9
> test scripts (e.g. test_vim9_class.vim, test_vim9_typealias.vim,
> test_vim9_enum.vim etc.). Convert the tests in test_vim9_builtin.vim to use
> the new functions.
>
> Before this change, it used to take around 22 seconds to run the tests.
> After this change, it takes around 2.5 seconds.
>
>
I was running the test with the address sanitizer enabled which resulted in
22 seconds.  Without ASAN, it takes around
8 seconds to run the tests in test_vim9_builtin.vim.

-- 
-- 
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/CAAW7x7n4Cx8CRuc7Kz0y6aosJdOQ_5HKsaxde0rLn25hwRC9%3Dw%40mail.gmail.com.

Re: matchbufline() and the 'ignorecase' option value

[Yegappan Lakshmanan]

Hi,

On Thu, Feb 22, 2024 at 7:56 AM shane.qian  wrote:
>
> > The recently introduced matchbufline() and matchstrlist() functions
> > use the 'ignorecase' option value.  If this option is set, then these
> > functions ignore the case when matching the strings.
> > So the behavior of a plugin using these functions depends on a user
> > configuration.
> > To ignore this option setting, the plugins need to either clear this
> > option or use the "\C" or "\c" atom
> > when calling this function.
> >
> > Should we modify these functions to ignore the 'ignorecase' option
> > value?  The plugins can
> > then choose to either ignore or not ignore the case explicitly and
> > will be independent of a
> > user configuration.
>
> please keep it, since it is same behavior like 'matchstr()'
>

Yes.  It makes sense to keep the behavior of these new functions
consistent with the
existing match*() functions.  I missed the note about 'ignorecase',
'smartcase' and
'magic' in the help for match().  I will add a link to this note in
the help text for the
matchbufline() and matchstrlist() functions.

Regards,
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/CAAW7x7nAgpL70QaotjtrYJVW%2Bph6asSOWKear0uFgwVunjv6%3Dw%40mail.gmail.com.

matchbufline() and the 'ignorecase' option value

[Yegappan Lakshmanan]

Hi all,

The recently introduced matchbufline() and matchstrlist() functions
use the 'ignorecase' option value.  If this option is set, then these
functions ignore the case when matching the strings.
So the behavior of a plugin using these functions depends on a user
configuration.
To ignore this option setting, the plugins need to either clear this
option or use the "\C" or "\c" atom
when calling this function.

Should we modify these functions to ignore the 'ignorecase' option
value?  The plugins can
then choose to either ignore or not ignore the case explicitly and
will be independent of a
user configuration.

Note: These functions currently ignore the 'smartcase' option value.

Regards,
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/CAAW7x7%3D5Oh4d9V20n6c1GLnfoy904gKf-Or2n0XxMc9GcJO%2Baw%40mail.gmail.com.

Re: [vim/vim] Add a place holder section for version 9.2 (PR #14060)

[Yegappan Lakshmanan]

Hi,

On Mon, Feb 19, 2024 at 6:52 PM Maxim Kim  wrote:

> Should we have Breaking changes section as well?
>
> one that comes to my mind is default colorscheme visual highlight now has
> defined foreground which breaks colorschemes that were relying on Visual
> guifg=NONE.
>
>
>
Yes.  I have updated the PR to include the "incompatible changes" section.

Regards,
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/CAAW7x7nr4d36D6YUmAXF%2BG%3DmHLwk15d0_qQ%2B9tV9EtbzEKs9Tg%40mail.gmail.com.

New PRs - tests and coverage

[Yegappan Lakshmanan]

Hi all,

When you submit a new PR, after the CI tests are successfully
completed, the coverage
information is shown in the PR diff page.  Can you please go through
that and make sure
that most of the newly added or modified lines are covered by tests?
If not, please add
additional tests to make sure that the newly added lines are covered by tests.
In addition to the functional tests, also make sure to add tests for
invalid arguments
and negative/boundary conditions.

A lot of effort has gone in the last few years to add a significant
number of tests to cover
most of the Vim code base.  Let us make sure that this doesn't regress.

The latest coverage information is available at
https://app.codecov.io/gh/vim/vim.

The instructions to generate the coverage information in a Linux system is at:
https://github.com/vim/vim/blob/master/src/Makefile#L668

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/CAAW7x7%3DoN5empg3vFBMOqFQT_G2kwkxYWTQ9ENFpn3hwufy_dw%40mail.gmail.com.

Re: Question about tooling and stiling

[Yegappan Lakshmanan]

Hi,

On Mon, Feb 12, 2024 at 6:55 AM Luca Saccarola
 wrote:
>
> Hi,
> I was experimenting with setting up clangd and clang-format for the
> codebase. I've read the `:h develop` but I still have missing
> information.
>
> 1. Tabs or spaces? The documentation doesn't specify it and the source
>files sometimes mix spaces and tabs.
>

The Vim source base uses 'softtabstop' (a mix of spaces and tabs):

https://vimhelp.org/options.txt.html#%27softtabstop%27

The following options are set for the source files through a modeline:

tabstop=8 softtabstop=4 shiftwidth=4 noexpandtab

> 2. What parts of C99 are supported? There are some listed but there are
>more?
>
> There are some recommended tooling for develop, analyze the vim
> source code? It would be welcomed if I setup some tooling if none
> are there?
>

I created https://gist.github.com/yegappan/1e88a9aed4f9f266d91d768b633487f3
to document
some of the steps that I follow for my contributions.

Regards,
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/CAAW7x7mO-z2MP35hO3BznbMskRVyytHk9zu2Zb-uA3wRPN6OLA%40mail.gmail.com.

Re: [vim/vim] Add support for the diff() function using the built-in diff support (PR #12321)

[Yegappan Lakshmanan]

Hi,

On Fri, Feb 2, 2024 at 10:54 PM rickhowe  wrote:

> Hi,
>
> Thank you for providing diff(). I checked how it works while comparing
> with nvim's vim.diff() as follows.
>

Note that nvim's vim.diff() is a lua function whereas the newly introduced
diff() is a
Vim builtin function.  Lua uses 1-based indexing whereas Vimscript uses
0-based
indexing.  So the indices returned by the diff() function are 0-based
whereas the
indices returned by the vim.diff() lua function are 1-based.

An interpretation of the indices for the below examples is inline.

diff(['a'], ['x', 'a'])
> unified: @@ -0,0 +1 @@
> indices: {0, 0, 0, 1} *
> nvim:[0, 0, 1, 1]
>
>
One string at index 0 in {list2} is inserted before the string at index 0
in {list1}.


>
>
> diff(['a'], ['a', 'x'])
> unified: @@ -1,0 +2 @@
> indices: {1, 0, 1, 1} *
> nvim:[1, 0, 2, 1]
>
>
One string at index 1 in {list2} is inserted before the string at index 1
in {list1}.


>
> diff(['x', 'a'], ['a'])
> unified: @@ -1 +0,0 @@
> indices: {0, 1, 0, 0} *
> nvim:[1, 1, 0, 0]
>
>
One string at index 0 in {list1} is removed from {list2} at index 0.


> diff(['a', 'x'], ['a'])
> unified: @@ -2 +1,0 @@
> indices: {1, 1, 1, 0} *
> nvim:[2, 1, 1, 0]
>
>
One string at index 1 in {list1} is removed from {list2} at index 1.

>
> *: {from_idx, from_count, to_idx, to_count}
>
>
When the from_count is zero, the strings from to_idx to (to_idx + to_count)
in {list2} are inserted at from_idx in {list1}.
When the to_count is zero, the strings from from_idx to (from_idx +
from_count) are removed from {list2} at to_idx.


>  I am a bit confused about idx, In unified, idx 0 always means '^'. But
> in indices, idx 0 means '^' if count = 0 else the first index of hunk. In
> nvim, vim.diff() returns the equivalent value of the unified as indices.
>

We can add the "idx 0 means '^' if count is 0, otherwise it is the first
index of the hunk" note to
the help text.


> Is it difficult to follow vim.diff() as indices to make it simple and
> consistent between vim and nvim?
>
>
> Yes.  The Vimscript diff() function should use 0-based indexing.  This
helps the caller in
directly using the returned index to access the lists.

Regards,
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/CAAW7x7mTM7DG0y%2BZrUHsZwY_sWeouOrpYq4FmnVS4hdO0FneCw%40mail.gmail.com.

Re: Commit: patch 9.1.0071: Need a diff() Vim script function

[Yegappan Lakshmanan]

Hi,

On Fri, Feb 2, 2024 at 12:56 PM John Marriott  wrote:
>
>
>
> On 02-Feb-2024 08:30, Christian Brabandt wrote:
>
> patch 9.1.0071: Need a diff() Vim script function
>
> Commit: 
> https://github.com/vim/vim/commit/fa37835b8c0ed0f83952978fca4c332335ca7c46
> Author: Yegappan Lakshmanan 
> Date:   Thu Feb 1 22:05:27 2024 +0100
>
> patch 9.1.0071: Need a diff() Vim script function
>
> Problem:  Need a diff() Vim script function
> Solution: Add the diff() Vim script function using the
>   xdiff internal diff library, add support for
>   "unified" and "indices" mode.
>   (Yegappan Lakshmanan)
>
> fixes: #4241
> closes: #12321
>
> Signed-off-by: Yegappan Lakshmanan 
> Signed-off-by: Christian Brabandt 
>
>
> After this patch, msys2 (clang x64 17.0.6) gives these errors if FEAT_DIFF is 
> disabled:
> 
> clang -c -I. -Iproto -DWIN32 -DWINVER=0x0A00 -D_WIN32_WINNT=0x0A00 
> -DHAVE_PATHDEF -DFEAT_NORMAL -DHAVE_STDINT_H -D__USE_MINGW_ANSI_STDIO -pipe 
> -Wall -O3 -fomit-frame-pointer -fpie -fPIE -DFEAT_GUI_MSWIN -DFEAT_CLIPBOARD 
> diff.c -o gobjx86-64/diff.o
> diff.c:3499:25: error: use of undeclared identifier 
> 'DIFF_INTERNAL_OUTPUT_UNIFIED'
>  3499 | *diff_output_fmt = DIFF_INTERNAL_OUTPUT_UNIFIED;
>   |^
> diff.c:3501:25: error: use of undeclared identifier 
> 'DIFF_INTERNAL_OUTPUT_INDICES'
>  3501 | *diff_output_fmt = DIFF_INTERNAL_OUTPUT_INDICES;
>   |^
> diff.c:3510:15: error: use of undeclared identifier 'DIFF_IBLANK'
>  3510 | *diffopts |= DIFF_IBLANK;
>   |  ^
> diff.c:3512:15: error: use of undeclared identifier 'DIFF_ICASE'
>  3512 | *diffopts |= DIFF_ICASE;
>   |  ^
> diff.c:3514:15: error: use of undeclared identifier 'DIFF_IWHITE'
>  3514 | *diffopts |= DIFF_IWHITE;
>   |  ^
> diff.c:3516:15: error: use of undeclared identifier 'DIFF_IWHITEALL'
>  3516 | *diffopts |= DIFF_IWHITEALL;
>   |  ^
> diff.c:3518:15: error: use of undeclared identifier 'DIFF_IWHITEEOL'
>  3518 | *diffopts |= DIFF_IWHITEEOL;
>   |  ^
> diff.c:3530:27: error: unknown type name 'diffin_T'
>  3530 | list_to_diffin(list_T *l, diffin_T *din, int icase)
>   |   ^
> diff.c:3563:23: error: unknown type name 'diffhunk_T'
>  3563 | get_diff_hunk_indices(diffhunk_T *hunk)
>   |   ^
> 9 errors generated.
> make: *** [Make_cyg_ming.mak:1214: gobjx86-64/diff.o] Error 1
> 
>
> Sorry, I'm not sure what the correct fix is.
>

I have created PR #13964 to address this build error.

- 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/CAAW7x7m0%2BtiG%3D49%3DoBfPm%2BxXBx8DNKSGsJxp99BdjYCRKNe2vQ%40mail.gmail.com.

Re: [vim/vim] Add a new list-based interface for programming list options in Vim (Issue #13891)

[Yegappan Lakshmanan]

Hi,

On Fri, Jan 19, 2024 at 3:02 PM bfrg  wrote:

> @yegappan  Why v:vim.opt.shiftwidth and not
> just v:opt.shiftwidth (or v:option.shiftwidth)? The vim prefix seems
> redundant.
>
>
> I chose v:vim to be consistent with the Python and Lua language interfaces.

Regards,
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/CAAW7x7msiO3hhUfCJUzHmqU-WCQLarZ4nW92%2BspZKwBCff8%2Bgw%40mail.gmail.com.

Re: [vim/vim] Add a new list-based interface for programming list options in Vim (Issue #13891)

[Yegappan Lakshmanan]

Hi Christian,

On Fri, Jan 19, 2024 at 2:39 PM Christian Brabandt <
vim-dev-git...@256bit.org> wrote:

> That patch would only help, if it makes a list or Dict for options with
> several sub-options.
>

Yes.  But that patch can be enhanced to return an option value with several
sub-values as a List.


> But we would need probably 3 different dicts: for global options,
> buffer-local and window-local options. Is it really worth it?
>
>
> I was not very clear on the benefits.  So that is why I didn't pursue this
PR further.
But if this has merits/benefits, this can be implemented.

Regards,
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/CAAW7x7%3D_qfD6zfAspZ6jNKKtLpsZRBNEZ8aiva7OQ6xLZh%2Bofg%40mail.gmail.com.

Re: [vim/vim] Add a new list-based interface for programming list options in Vim (Issue #13891)

[Yegappan Lakshmanan]

Hi,

On Fri, Jan 19, 2024 at 1:04 PM Timothy Madden 
wrote:

> Many list options in Vim, like 'path' and 'tags', are difficult to parse
> correctly from a string, because of the escapes that need to be applied
> (for the comma ',' and backslash '' characters). Also for the generating a
> :set command, there is a second level of escapes that needs to be
> applied... While the complexity can still be dealt with if carefully
> reading the help text, and experimenting for a while, the process remains
> very much prone to errors.
>
> Maybe some new interface can be added to access such options as a list
> value instead of a string, so no parsing or escaping will be needed for
> vimscript authors.
>
> For example maybe v:tags (and v:path and similar ...) can be a list of tag
> files, the same as given in the 'tags' option, but already parsed into a
> list.
>
> Programatically modifying v:tags would also modify the 'tags' option as
> well, while taking care of properly escape any special characters that
> should be escaped.
>
> Otherwise the alternative for manually parsing the string value into the
> list remains to:
>
>- manually split the string value on comma characters ',' that are not
>preceeded by an odd number of backslashes...
>- escape the remaining backslashes by replacing every '\' sequence
>with ''
>
> Surely every vimscript author out there would like an easier way to deal
> with this ...
>
> While on this topic, maybe it is possible for fnameescape() function to
> implement a new flag for escaping a comma ',' character in the file name,
> for use with :set path command for example.
>
> Maybe I can even make a patch for this if I get enough time to see how the
> v: dictionary works in Vim source code, and the options themseves ... would
> that help ? Though I fear the new bytecode engine could make this difficult
> :(
>

Some time ago I proposed a patch for accessing the Vim options as a Dict:

https://groups.google.com/g/vim_dev/c/sCINiwbbs3c/m/mR-jf5HfAgAJ

With this approach, it is possible to export the option value string list
as a List.

Bram didn't see any advantages in this approach compared to the existing
method
of accessing options.

Regards,
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/CAAW7x7%3DnUV5-Rmk9VWtS2Uxr_z3yYUCEMstUS7hQ9a0_ezhoYg%40mail.gmail.com.

Re: Commit: patch 9.1.0009: Cannot easily get the list of matches

[Yegappan Lakshmanan]

On Sun, Jan 7, 2024 at 8:30 AM Yegappan Lakshmanan 
wrote:

> Hi all,
>
> On Thu, Jan 4, 2024 at 1:45 PM Christian Brabandt 
> wrote:
>
>> patch 9.1.0009: Cannot easily get the list of matches
>>
>> Commit:
>> https://github.com/vim/vim/commit/f93b1c881a99fa847a1bafa71877d7e16f18e6ef
>> Author: Yegappan Lakshmanan 
>> Date:   Thu Jan 4 22:28:46 2024 +0100
>>
>> patch 9.1.0009: Cannot easily get the list of matches
>>
>> Problem:  Cannot easily get the list of matches
>> Solution: Add the matchstrlist() and matchbufline() Vim script
>>   functions (Yegappan Lakshmanan)
>>
>>
> To demonstrate the use of the new matchbufline() function, I have created
> the following script.  This does search text completion from the list of
> words
> in the current buffer.  After typing a few letters in the "/" prompt, if
> you press
> Tab, it will complete the word from the current buffer.  If you press Tab
> again,
> then it will go to the next match.  If you press Shift-Tab, it will go
> back to
> the previous match.
>
>
I have uploaded this plugin to the
https://github.com/yegappan/searchcomplete repository.

Regards,
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/CAAW7x7kPYmq0czTLH62es-NzoYfhFkH_G8BM5Kk%3Ds94tpd0KaQ%40mail.gmail.com.

Re: Commit: patch 9.1.0009: Cannot easily get the list of matches

[Yegappan Lakshmanan]

Hi Gary,

On Mon, Jan 8, 2024 at 12:14 PM Gary Johnson  wrote:

> On 2024-01-07, Yegappan Lakshmanan wrote:
>
> > To demonstrate the use of the new matchbufline() function, I have created
> > the following script.  This does search text completion from the list of
> words
> > in the current buffer.  After typing a few letters in the "/" prompt, if
> you
> > press
> > Tab, it will complete the word from the current buffer.  If you press Tab
> > again,
> > then it will go to the next match.  If you press Shift-Tab, it will go
> back to
> > the previous match.
>
> I saved your script to a file and sourced it, but it gives me an
> error.
>
> Error detected while processing /home/gary/.vim/match_tab.vim:
> line9:
> E1171: Missing } after inline function
>
> Line 9 is:
>
> def SearchComplete(forward: bool): string
>
>
I am not sure what is wrong from the above error message.  In case there
is a cut/paste error, can you please try the attached file?

- Yegappan


> I've updated to 9.1.16 and done a clean build without any
> configuration options.
>
> I haven't done anything with vim9script, so I don't recognize syntax
> errors by sight, nor do I know what else I might be missing.
>
> Regards,
> Gary
>
> 
> $ VIMRUNTIME=runtime src/vim --version
> VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Jan  8 2024 11:48:09)
> Included patches: 1-16
> Compiled by gary@epicurus
> Huge version with GTK3 GUI.  Features included (+) or not (-):
>
>

-- 
-- 
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/CAAW7x7kZMc%2BrgZ1A8FEtiPROxN83UG-V5orKy4s4gEMG6y4u4g%40mail.gmail.com.


searchcomplete.vim
Description: Binary data

Re: Commit: patch 9.1.0009: Cannot easily get the list of matches

[Yegappan Lakshmanan]

Hi all,

On Thu, Jan 4, 2024 at 1:45 PM Christian Brabandt 
wrote:

> patch 9.1.0009: Cannot easily get the list of matches
>
> Commit:
> https://github.com/vim/vim/commit/f93b1c881a99fa847a1bafa71877d7e16f18e6ef
> Author: Yegappan Lakshmanan 
> Date:   Thu Jan 4 22:28:46 2024 +0100
>
> patch 9.1.0009: Cannot easily get the list of matches
>
> Problem:  Cannot easily get the list of matches
> Solution: Add the matchstrlist() and matchbufline() Vim script
>   functions (Yegappan Lakshmanan)
>
>
To demonstrate the use of the new matchbufline() function, I have created
the following script.  This does search text completion from the list of
words
in the current buffer.  After typing a few letters in the "/" prompt, if
you press
Tab, it will complete the word from the current buffer.  If you press Tab
again,
then it will go to the next match.  If you press Shift-Tab, it will go back
to
the previous match.

Regards,
Yegappan


vim9script

var searchMatches: list = []
var prevMatchIndex: number = 0
var prevCmdline: string = ''
var prevCmdlinePrefix: string = ''
var prevPat: string = ''

def SearchComplete(forward: bool): string
  var cmdtype: string = getcmdtype()
  if cmdtype != '/' && cmdtype != '?'
feedkeys(forward ? "\" : "\", 'nt')
return ''
  endif

  var cmdline: string = getcmdline()
  if cmdline != '' && cmdline ==# prevCmdline
# Jump to the next/previous match
if (cmdtype == '/' && forward) || (cmdtype == '?' && !forward)
  prevMatchIndex += 1
else
  prevMatchIndex -= 1
endif
if prevMatchIndex < 0
  prevMatchIndex = searchMatches->len() - 1
elseif prevMatchIndex >= searchMatches->len()
  prevMatchIndex = 0
endif
var s = searchMatches[prevMatchIndex][strlen(prevPat) : ]

prevCmdline = prevCmdlinePrefix .. s
setcmdline(prevCmdlinePrefix)
return s
  endif

  var cmdpos: number = getcmdpos()

  var start: number = cmdpos - 1
  if start >= strlen(cmdline)
start -= 1
  endif
  while start > 0 && cmdline[start - 1] =~ '\k'
start -= 1
  endwhile
  var pat: string = cmdline[start : cmdpos]

  # Get the List of matches
  var start_lnum =  || cmdtype == '?' ? 1 : line('.')
  var end_lnum =  || cmdtype == '/' ? '$' : line('.')
  var l = matchbufline('', $'\<{pat}\k\+\>', start_lnum, end_lnum)
  if l->empty()
return ''
  endif

  var curline = line('.')
  var curcol = col('.')
  var patStartByte = curcol - 1 - strlen(pat)

  l->filter((_, v) => v.lnum == curline ? cmdtype == '/' ? v.byteidx >=
patStartByte : v.byteidx <= patStartByte : true)
  if l->empty()
return ''
  endif

  # Sort by matched string and line/byte index
  l->sort((a, b) => {
if a.text > b.text
  return 1
elseif a.text == b.text
  if a.lnum > b.lnum
return 1
  elseif a.lnum == b.lnum
return a.byteidx > b.byteidx ? 1 : 0
  endif
  return 0
endif
return 0
  })
  # Remove duplicates
  l->uniq((a, b) => a.text ==# b.text ? 0 : 1)
  # Sort by byte index and line number
  l->sort((a, b) => a.lnum == b.lnum ? a.byteidx - b.byteidx : a.lnum -
b.lnum)

  var startIdx: number
  if cmdtype == '/'
startIdx = l->indexof((_, v) => v.lnum == curline ? v.byteidx >=
patStartByte : v.lnum > curline)
  else
startIdx = l->copy()->reverse()->indexof((_, v) => v.lnum == curline ?
v.byteidx <= patStartByte : v.lnum < curline)
startIdx = l->len() - startIdx - 1
  endif

  if startIdx == -1
startIdx = forward ? 0 : searchMatches->len() - 1
  endif

  # Save the matched strings
  searchMatches = l->map((_, v) => v.text)

  var s = searchMatches[startIdx][strlen(pat) : ]

  # Save the state for jumping to the next previous match
  prevMatchIndex = startIdx
  prevPat = pat
  prevCmdline = cmdline .. s
  prevCmdlinePrefix = cmdline

  return s
enddef

cnoremap  =SearchComplete(v:true)
cnoremap  =SearchComplete(v:false)

# vim: ts=8 sw=2 sts=2 expandtab tw=80


-- 
-- 
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/CAAW7x7nDkmO_MQRy4XycR%3DhDPmAVi1pHh2DSV23cPj65%3Dfi%2BQg%40mail.gmail.com.

Re: Vim 9.1 has been released

[Yegappan Lakshmanan]

Happy to see the 9.1 release.  Thanks Christian for your hard work in making
this release happen.

Regards,
Yegappan

On Tue, Jan 2, 2024 at 9:46 AM Christian Brabandt  wrote:

> Dear Vim users,
>
> The Vim project is happy to announce that Vim 9.1 has finally been
> released. This release is dedicated to Bram Moolenaar, Vim's lead
> developer for more than 30 years, who suddenly passed away in August
> 2023.
>
> The most notable changes are support for Vim9 classes and objects,
> smooth scrolling support and virtual text support. And as usual, runtime
> files have been updated, many bugs have been fixed and potential
> security relevant fixes have been included. You can find the full
> announcement https://www.vim.org/vim-9.1-released.php
>
> I would like to thank everybody who contributed to the project through
> patches, translations, bug reporters and everybody else who helped
> making this release! We are very grateful for any support.
>
> If you like Vim, you are encouraged to make a donation for needy
> children in Uganda. Please visit the ICCF web site for more information:
> https://iccf-holland.org
>
> Thanks and Happy New Year 2024!
> Christian
>

-- 
-- 
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/CAAW7x7m%2Bo8t_3gXvk7AMYRWqdq7jh0s%2B8%2BCBxtThK%3Dmr5Lzgqg%40mail.gmail.com.

Re: Function to find all matches in a string?

[Yegappan Lakshmanan]

Hi Tim,

On Sat, Dec 23, 2023 at 2:35 PM Tim Chase  wrote:

> I was looking for something similar to Python's re.findall()/finditer()
> function to answer a question on Reddit[1] but was surprised I
> couldn't find anything in
>
>   :help function-list
>
> The general intent would be to take an input string and return a
> List containing all the sub-strings matching a pattern like
>
>   let matches=findall('amwenxipyuqz', '[aeiou]')
>
> would set matches to
>
>   ['aw', 'en', 'ip', 'uq']
>
> I was able to cobble together a hack-job in this case, but I'd hoped
> to be able to do something like
>
>   :let a=[] | g/#\w\+/call extend(a, findall(getline('.'), @/))
>
> Does such a function exist and I just missed it?
>
>
Currently no such function exists.  I have created PR
https://github.com/vim/vim/pull/13766
to add support for the matchall() function.  Can you try that out?

Thanks,
Yegappan


> Thanks!
>
> -tim
>
> [1]
> https://www.reddit.com/r/vim/comments/18pcd84/the_vim_way/kenedxq/
>
>
>

-- 
-- 
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/CAAW7x7mvoU%3DkxhBPbdPAnATW9vNgJ3ZXYD9YoJzv4jbwvdcw8g%40mail.gmail.com.

Re: [vim/vim] Fix error messages for :type/:class used in expressions (PR #13706)

[Yegappan Lakshmanan]

Hi Ernie,

On Wed, Dec 20, 2023 at 10:40 AM errael  wrote:

> @chrisbra  @yegappan
>  If it is relevant, when considering if this
> PR should make it into vim9.1, this PR is all about error messages. It was
> delayed a few days by discovering/fixing an old bug that interfered.
>
>
>
The changes look good to me.

Regards,
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/CAAW7x7mxkLSyup9uFGePdoMeJR3W8xZQXcwDunhq2M_hq7vtKw%40mail.gmail.com.

Re: Commit: runtime(doc): Create Changelog until v9.0.2175 (#13728)

[Yegappan Lakshmanan]

Hi Christian,

On Tue, Dec 19, 2023 at 11:15 AM Christian Brabandt 
wrote:

> runtime(doc): Create Changelog until v9.0.2175 (#13728)
>
> Commit:
> https://github.com/vim/vim/commit/5872bcb6e8dfc15d7a5c0aaaf94d8029f3a1fa3f
> Author: Christian Brabandt 
> Date:   Tue Dec 19 20:10:43 2023 +0100
>
> runtime(doc): Create Changelog until v9.0.2175 (
> https://github.com/vim/vim/issues/13728)
>
> Patch list created using:
> ```
> git log --grep='^patch' --reverse --pretty='format:%D%gs%n%b'
> "v9.0.~1"..master  |sed -e '/^Signed-off-by:.*/d' -e
> '/^\(closes\|fixes\)/d' -e 's/^tag: v/Patch /'
> ```
>
> and then post-processed using vim.
>
> Signed-off-by: Christian Brabandt 
>
> diff --git a/runtime/doc/version9.txt b/runtime/doc/version9.txt
> index 09d6b3b7e..ea3fc611c 100644
> --- a/runtime/doc/version9.txt
> +++ b/runtime/doc/version9.txt
> @@ -1,4 +1,4 @@
> -*version9.txt*  For Vim version 9.0.  Last change: 2023 Aug 09
> +*version9.txt*  For Vim version 9.0.  Last change: 2023 Dec 19
>
>
> +Problem:The options[] array is still not sorted alphabetically
> +(after: v9.0.2154), causing test failures
> +Solution:   Sort the remaining items
> +
> +Patch 9.0.2172
> +Problem:Vim9: compiling :defer may fail
> +Solution:   compile defer, when ctx_skip is not SKIP_YES
> +
> +Patch 9.0.2173
> +Problem:Vim9: Vim crashes when compiling a for statement with a
> +non-existing type
> +Solution:   Error out when  lhs_type is not null
> +
> +Patch 9.0.2174
> +Problem:Vim9: segfault when assigning to type
> +Solution:   do not clear typeval, add missing patch number
> +
>
>
The patch information for the previous releases included the author name
and the name of the person who reported the problem.  The 9.0.x patches
don't have the author name.  Going forward, can we include the author name
in the commit solution text, so that it is easy to get this information?

Regards,
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/CAAW7x7mYt4fOQv9S8n7jXTgBn%3DhSpTG4%2BLOqENh0W_crvTsOBA%40mail.gmail.com.

Re: After applying patches 9.0.2168 to 9.0.2173 : warning -Wmaybe-uninitialized in vim9cmds.c (not in Tiny)

[Yegappan Lakshmanan]

On Sun, Dec 17, 2023 at 2:20 AM Tony Mechelynck <
antoine.mechely...@gmail.com> wrote:

> On Sun, Dec 17, 2023 at 3:26 AM Yegappan Lakshmanan 
> wrote:
> >
> > Hi Tony,
> >
> > On Sat, Dec 16, 2023 at 3:50 PM Tony Mechelynck <
> antoine.mechely...@gmail.com> wrote:
> >>
> >> vim9cmds.c: In function ‘compile_defer’:
> >> vim9cmds.c:2051:18: warning: ‘type’ may be used uninitialized
> >> [-Wmaybe-uninitialized]
> >>  2051 | else if (check_func_args_from_type(cctx, type,
> argcount, TRUE,
> >>   |
> ^
> >>  2052 | arg_start) == FAIL)
> >>   | ~~
> >> vim9cmds.c:2003:18: note: ‘type’ was declared here
> >>  2003 | type_T  *type;
> >>   |  ^~~~
> >>
> >
> > Which environment and compiler are you using? I don't see this warning.
> "type" is
> > initialized at line 2027 and used at line 2051.  We can initialize
> "type" to NULL at line 2003.
> > But I don't think this is necessary.
> >
> > Regards,
> > Yegappan
> >
> I am using gcc 13.2.1 20231130 on openSUSE Tumbleweed, and I see this
> on all +eval configurations. For instance my "normal" build is defined
> as follows:
>
> export CONF_OPT_GUI='--enable-gui=motif'
> export CONF_OPT_MULTIBYTE='--enable-multibyte'
> export CONF_OPT_AUTOSERVE='--enable-autoservername'
> export CONF_OPT_SODIUM='--enable-libsodium'
> export CONF_OPT_FEAT='--with-features=normal'
> export CONF_ARGS2='--with-vim-name=vim-normal'
> export CONF_OPT_COMPBY='"--with-compiledby=antoine.mechely...@gmail.com"'
>
> I also compile two different "huge" builds (which get the same error)
> and two different "tiny" builds (which don't).
>
>
Thanks.  I have opened the PR https://github.com/vim/vim/pull/13711 to
address this warning.

Regards,
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/CAAW7x7%3D5GWAhBdX5EwQ5J7aocT5kEo2S1cgS8C_KSbke1ioS3w%40mail.gmail.com.

Re: After applying patches 9.0.2168 to 9.0.2173 : warning -Wmaybe-uninitialized in vim9cmds.c (not in Tiny)

[Yegappan Lakshmanan]

Hi Tony,

On Sat, Dec 16, 2023 at 3:50 PM Tony Mechelynck <
antoine.mechely...@gmail.com> wrote:

> vim9cmds.c: In function ‘compile_defer’:
> vim9cmds.c:2051:18: warning: ‘type’ may be used uninitialized
> [-Wmaybe-uninitialized]
>  2051 | else if (check_func_args_from_type(cctx, type, argcount,
> TRUE,
>   |
> ^
>  2052 | arg_start) == FAIL)
>   | ~~
> vim9cmds.c:2003:18: note: ‘type’ was declared here
>  2003 | type_T  *type;
>   |  ^~~~
>
>
Which environment and compiler are you using? I don't see this warning.
"type" is
initialized at line 2027 and used at line 2051.  We can initialize "type"
to NULL at line 2003.
But I don't think this is necessary.

Regards,
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/CAAW7x7%3DkERn01BC_ZAkZxh9A9EYoXUDza-BgeSic160nsoDnug%40mail.gmail.com.

Re: [vim/vim] Support final object and class variables (PR #13655)

[Yegappan Lakshmanan]

Hi,

I was waiting for PR https://github.com/vim/vim/pull/13670 to be merged.
As that PR is now merged, this PR (support for final and const object/class
variables) is ready.

Regards,
Yegappan

On Sun, Dec 10, 2023 at 11:21 AM Yegappan Lakshmanan <
vim-dev-git...@256bit.org> wrote:

> Implement the following item from the todo list:
>
>- "final" object members - can only be set in the constructor.
>
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/vim/vim/pull/13655
> Commit Summary
>
>- 4948130
>
> <https://github.com/vim/vim/pull/13655/commits/4948130ba72781b79095d86685134cc0856ad9d2>
>Support final object and class variables
>
> File Changes
>
> (8 files <https://github.com/vim/vim/pull/13655/files>)
>
>- *M* runtime/doc/vim9class.txt
>
> <https://github.com/vim/vim/pull/13655/files#diff-95676ca19ceda742311aa875c53ffcf159d6e92b687bd76e886be2c247860b60>
>(32)
>- *M* src/errors.h
>
> <https://github.com/vim/vim/pull/13655/files#diff-f0dcf081b343951b0348e086a69a58360a1479cdf0be1a8e21b6fdce03d86a22>
>(4)
>- *M* src/eval.c
>
> <https://github.com/vim/vim/pull/13655/files#diff-3f6891fec05432f415cfd49150db67e2bc72d20e0a94a4e3ac762f7ff55f9921>
>(7)
>- *M* src/proto/vim9class.pro
>
> <https://github.com/vim/vim/pull/13655/files#diff-3b28934e140b9749089a47e0b0f152b8649036c021b6d95d3ee91b1cf1775f48>
>(1)
>- *M* src/structs.h
>
> <https://github.com/vim/vim/pull/13655/files#diff-6500c47e4afabd64a8cb2f853a4bc5e8c33f43814d3f9a0a9f4371025578a798>
>(1)
>- *M* src/testdir/test_vim9_class.vim
>
> <https://github.com/vim/vim/pull/13655/files#diff-c64e9113ce4143c2a3194aad8d123a917f9c99dac537a70cbf289bd6f37bd8c4>
>(254)
>- *M* src/vim9class.c
>
> <https://github.com/vim/vim/pull/13655/files#diff-8e2956e6a4ccbdea6b0afe8c3941b810c32aaa94e11b404d5e7aa1a01d953a4c>
>(39)
>- *M* src/vim9compile.c
>
> <https://github.com/vim/vim/pull/13655/files#diff-53b492570146ce32a1ad32ea8cbb41dd29baf71a5055fc7a188f53b004206d41>
>(16)
>
> Patch Links:
>
>- https://github.com/vim/vim/pull/13655.patch
>- https://github.com/vim/vim/pull/13655.diff
>
>
>

-- 
-- 
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/CAAW7x7m7VGp3%3DyMrK5JVVWKiABnSXtvBMVM48V%3DiYtyxnw7TuQ%40mail.gmail.com.

Re: [vim/vim] Treat null the same as using null_ when used in an assignment (PR #13492)

[Yegappan Lakshmanan]

On Sun, Nov 19, 2023 at 5:32 AM dkearns  wrote:

> It seems it's not currently possible to distinguish null from the default
> values? If bool, number and float are to become nullable then they probably
> also need null_ values for consistency.
> --
>
> I noticed this bug, in passing. The following results in an error E1012:
> Type mismatch; expected special but got bool. This works on master.
>
> vim9scriptvar x = nullx = null
>
>
>
This issue should be addressed in the latest updated PR.

Regards,
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/CAAW7x7%3DCGzf1qHU%3DN90qsqRriJZ%3D%2BoDO8nGwHyWBhsA43rA68w%40mail.gmail.com.

Re: [vim/vim] Treat null the same as using null_ when used in an assignment (PR #13492)

[Yegappan Lakshmanan]

On Sun, Nov 19, 2023 at 12:18 PM errael  wrote:

> (In awe of the evolution of this PR)
>
> There's a difference between script/:def.
>
> vim9script
>
> var sv1 = null
> echo typename(sv1)
> def F1()
> var fv1 = null
> echo typename(fv1)
> enddef
> F1()
>
> Expect function to report special, not number
>
> special
> number
>
> The following gets a compilation error; incompatible with vim9.0.
> Also, it could be useful/meaningful.
>
> def F2(x: any = null)
> enddef
>
> E38: Null argument
>
>
>
These issues are now addressed in the latest updated PR.

Regards,
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/CAAW7x7nPo-VidpaJJPYCsVcKtSvGOB%2BfeNhdpiK5F%2BuUD9Hqog%40mail.gmail.com.

Re: [vim/vim] Vim9script internals, how to read the source code and in what order (Discussion #13543)

[Yegappan Lakshmanan]

Hi,

On Sat, Nov 18, 2023 at 3:14 AM stefanos  wrote:

> I'm fascinated by programming languages and I always find myself digging
> deep in their internals to learn how each creator implements specific
> language features they may find interesting.
>
> In case of Vim's scripting language, how do I read the source code to
> familiarize myself with it?
>

For Vim9 script support, you can go through the following source files:

https://github.com/vim/vim/blob/master/src/vim9compile.c
https://github.com/vim/vim/blob/master/src/vim9expr.c
https://github.com/vim/vim/blob/master/src/vim9execute.c
https://github.com/vim/vim/blob/master/src/vim9instr.c
https://github.com/vim/vim/blob/master/src/vim9script.c
https://github.com/vim/vim/blob/master/src/vim9cmds.c
https://github.com/vim/vim/blob/master/src/vim9class.c

For Vim9 def function compilation, you can start with the
compile_def_function() function.
For Vim9 script execution, you can start with the exec_instructions()
function.

With the implementation of vim9script, I can see we have added "primitive"
> types and class objects and I would like to see how they have improve the
> whole performance and / or what type of bytecode or native code they
> generate behind the scenes.
>

Only code in def functions are compiled and converted to bytecode.  You can
use the 'defcompile'
and 'disassemble ' command  to see the generated
bytecode.  Example:

vim9script

def Foo()
   var i = 10
   i = i + 20
enddef
defcompile
disassemble Foo


> Are there any plans to write in the near future anything like PHP's internals
> book ?
>
>
> There are currently no plans to write an internal book.

Regards,
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/CAAW7x7mf0hONqJiiNQ7RuYKztagsSC2kDQKeDmqGon0hyZ2z2w%40mail.gmail.com.

Vim9 class implementation update

[Yegappan Lakshmanan]

Hi all,

The following Vim9 class features have been implemented so far:

1. Class definition and object creation
2. Class variables and methods
3. Object variables and methods
4. Read-only, Read-write and private access control for class/object
variables
5. Extending a class (overriding methods)
6. Defining an interface
7. Implementing an interface
8. Defining an abstract class
9. Extending an abstract class

The list of known issues is here:
https://github.com/vim/vim/issues?q=is%3Aopen+is%3Aissue+label%3Avim9class

We need to freeze the Vim9 class specification for the Vim 9.1 release.
It will be helpful if folks can try these features out and report any
issues.

We are mainly looking for any modifications to the specification
that will break backward compatibility.  Bug fixes and new features can
be addressed after the Vim 9.1 release.

It is also helpful to get some feedback on the documentation:
https://github.com/vim/vim/blob/master/runtime/doc/vim9class.txt

The Vim9 class todo list is here:
https://github.com/vim/vim/blob/master/runtime/doc/todo.txt#L124

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/CAAW7x7mKzU68NLfkB8Ba4FjkmBcBH6oD-%2BRarszAmHdrpwZRoA%40mail.gmail.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Yegappan Lakshmanan]

On Sun, Oct 1, 2023 at 4:16 PM Ernie Rael  wrote:

> On 23/10/01 2:56 PM, Yegappan Lakshmanan wrote:
>
>
> On Sun, Oct 1, 2023 at 11:06 AM Ernie Rael  wrote:
>
>> On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote:
>>
>> Hi,
>>
>> On Sun, Oct 1, 2023 at 5:17 AM shane qian  wrote:
>>
>>> and I meant vim9script so far I felt it's good for type-checking and
>>> performance, but vim9 class to me I felt a bit burdened, not sure if
>>> still a chance to make it be simple to use (use for scripting), still wish
>>> that's the goal. @errael  @yegappan
>>>
>>>
>> I haven't introduced any fancy OOP features so far.  These are the
>> features
>> that Bram has partially implemented or planned for and were already in
>> the todo list.
>>
>> The spec clearly says (said)
>>
>> Object methods of the base class can be overruled.  *The signature
>> (arguments,*
>> *argument types and return type) must be exactly the same*.  The method
>> of the
>> base class can be called by prefixing "super.".
>>
>> I can't find where Bram partially implemented or planned to allow
>> contravariant parameters. In fact it looks the other way around. See
>> comments
>> https://github.com/vim/vim/pull/13221#issuecomment-1741637630 .
>>
>> After we've all worked hard to resolve incomplete spec issues (thinking
>> statics) and to get the implementation to meet the spec. This last minute
>> spec change, which doesn't seem to offer any useful functionality and
>> hasn't been discussed or tested, feels ill-conceived.
>>
>
> We have two options for the method parameter types.
>
>
> Actually, we have *three options*. We could follow the original spec
> which is invariant parameters: The signature [...] must be exactly the same.
>
> I've been repeating myself. But I still have not seen any answer as to why
> the spec, invariant parameters, should be changed rather than simply
> enforcing the spec for vim9.1, and revisiting
> the issue at some future point. I'd be interested in seeing a real world
> example that makes this
> change worthwhile.
>

I have created PR https://github.com/vim/vim/pull/13248 to use invariant
type check instead
of contra-variant type check for the derived method argument type checks.
We can revisit
this type check later.

- Yegappan


> To be clear, if a method signature says "def Foo(): return A", that
> doesn't mean that a subclass of A can't be returned from Foo().
>
> We can either follow the Typescript/Java
> specification, which supports covariance for the method parameters or
> follow the Dart specification
> which supports contra-variance for the method parameters.  As we are
> already following the Dart
> specification for interfaces, I choose the Dart specification.
>
>
> So what if we chose Dart for one thing. There are some cases where other
> languages are followed, the idea is to pick something consistent with the
> vim9script design philosophy. I do not understand why change the spec for a
> confusing concept. I've only seen contravariant parameters in relationship
> to generics, for example
>
> In the common case of a generic data structure ilist, covariant parameters
> are used for methods getting data out of the structure, and contravariant
> parameters for methods putting data into the structure. the mnemonic for
> Producer Extends, Consumer Super (PECS), from the book Effective Java by
> Joshua Bloch gives an easy way to remember when to use covariance and
> contravariance.
>
> But in our case we are not talking about a generic data structures. And no
> matter what words you use to describe it, it is not a simple concept. I
> still review PECS when I design a Java generic class/method. IIRC, generics
> are on the vim9class todo list; that's probably the proper time to consider
> contravariant parameters.
>
> -ernie
>
>
>
>> While this may be something for the future, *I see no reason to change
>> the spec now*.
>>
>> These features are basic to any OOP language.
>>
>> Can you point to a language that doesn't have overloaded methods that
>> allows contravariant parameters? I'm not saying there aren't any (I'm just
>> a country language-lawyer).
>>
>
> Are you referring to covariant parameters here?  If you are, then Dart
> allows only contravariant parameters
> for overloaded methods.
>
> Regards,
> 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/CAAW7x7%3DhFSqf28Oj_en5y%3D0Sqer%3DfJESfe9iwuQm0FrmHyA7cw%40mail.gmail.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Yegappan Lakshmanan]

On Sun, Oct 1, 2023 at 11:24 AM Ernie Rael  wrote:

> On 23/10/01 8:02 AM, shane qian wrote:
>
> 1. we may ask core members to vote, if class is just a struct then no all
> of those arguments. these were all gone. :smile:
>
> 2. it was just saying **default** was to be  `public`, didn't mean no
> `private`.
>
> 3. if `new()` is accessed only by `new C`, empty()/length() perhaps can be
> limited to only internal use too.
>
> I haven't yet looked at the empty()/len() addition; this *was* in the
> todo list. I'm guessing this allows the programmer to do
>
> class C...
> len(obj_of_type_C)
>
> and get a value defined by the class, could be very handy for a class that
> is used as a container. Not sure what happens if class didn't define a
> __len function; guess I'll find out.
>
> What I don't understand is why these spec changes are needed at the last
> minute. Seems better to add them after 9.1 is released.
>

If we decide to use "__" for these methods in a future release, then we
need to reserve them now.
As the changes are small, instead of just reserving the "__" prefix for
now, I went ahead with the
implementation.

- Yegappan


>
> Unless the idea is to wait several months to shake out these  new
> additions. Something being in the todo list does not always imply it gets
> into a release. Unless it's a simple change, I'd think that stuff would go
> in at the beginning of the release cycle and not the end.
>
> -ernie
>
>
> anyway, let's listen someone else if there were, or I am worried what's
> the end this OOP of vim9 how it would be easy to use.
> // and sorry I am actually not sure why I was joining to argue this too,
> aha... maybe there  no job to bother me. :lol:
>
>

-- 
-- 
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/CAAW7x7n-L22BDyDSZc8ejO1Y6x5k_CsJCO%2B_aaSf%3DSHG_Vtikg%40mail.gmail.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Yegappan Lakshmanan]

On Sun, Oct 1, 2023 at 11:06 AM Ernie Rael  wrote:

> On 23/10/01 6:44 AM, Yegappan Lakshmanan wrote:
>
> Hi,
>
> On Sun, Oct 1, 2023 at 5:17 AM shane qian  wrote:
>
>> and I meant vim9script so far I felt it's good for type-checking and
>> performance, but vim9 class to me I felt a bit burdened, not sure if
>> still a chance to make it be simple to use (use for scripting), still wish
>> that's the goal. @errael  @yegappan
>>
>>
> I haven't introduced any fancy OOP features so far.  These are the features
> that Bram has partially implemented or planned for and were already in
> the todo list.
>
> The spec clearly says (said)
>
> Object methods of the base class can be overruled.  *The signature
> (arguments,*
> *argument types and return type) must be exactly the same*.  The method
> of the
> base class can be called by prefixing "super.".
>
> I can't find where Bram partially implemented or planned to allow
> contravariant parameters. In fact it looks the other way around. See
> comments
> https://github.com/vim/vim/pull/13221#issuecomment-1741637630 .
>
> After we've all worked hard to resolve incomplete spec issues (thinking
> statics) and to get the implementation to meet the spec. This last minute
> spec change, which doesn't seem to offer any useful functionality and
> hasn't been discussed or tested, feels ill-conceived.
>

We have two options for the method parameter types.  We can either follow
the Typescript/Java
specification, which supports covariance for the method parameters or
follow the Dart specification
which supports contra-variance for the method parameters.  As we are
already following the Dart
specification for interfaces, I choose the Dart specification.


> While this may be something for the future, *I see no reason to change
> the spec now*.
>
> These features are basic to any OOP language.
>
> Can you point to a language that doesn't have overloaded methods that
> allows contravariant parameters? I'm not saying there aren't any (I'm just
> a country language-lawyer).
>

Are you referring to covariant parameters here?  If you are, then Dart
allows only contravariant parameters
for overloaded methods.

Regards,
Yegappan


> [...]
> I think using a formal type checking term like "covariance" and
> "contra-variance"
> confuses people to think that we are introducing fancy features.  But
> these are
> just terms for describing the type check and not new features.
>
> I don't believe that is accurate regarding contra-variant parameters; that
> is new. And for returning a covariant type that could already be done *without
> removing the requirement* that "the signature ... must be exactly the
> same".
>
>
>   I could have
> used "implement appropriate type check for method arguments and return
> types in extended classes".
>
>
>

-- 
-- 
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/CAAW7x7mPtLqJsD0w8a%3DODLj5V%3Dj4-OZ__TPbkC90AXz%3D5byNrw%40mail.gmail.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Yegappan Lakshmanan]

On Sun, Oct 1, 2023 at 7:20 AM shane qian  wrote:

> hi yegappan,
>
>
> 4. about the `term`, I believe easy way or pre-agreed term before impl and
> documented it may be better.
>
>
>
Please look at the list of outstanding Vim9 class items in the todo.txt
file:

https://github.com/vim/vim/blob/master/runtime/doc/todo.txt#L124

Look at the outstanding Vim9 class bugs:

https://github.com/vim/vim/issues?q=is%3Aopen+is%3Aissue+label%3Avim9class

Look at the following discussions:

https://github.com/vim/vim/discussions/13041
https://github.com/vim/vim/discussions/13195
https://github.com/vim/vim/discussions/13085
https://github.com/vim/vim/discussions/13069
https://github.com/vim/vim/discussions/13197

What would be more helpful is to test the current implementation and report
bugs (if any) and
provide suggestions or patches for implementing the outstanding items.

Regards,
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/CAAW7x7kRRqZNMpfUduLh9jWvyBwOvMvPsXuS6V--CnRgYx_oag%40mail.gmail.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Yegappan Lakshmanan]

On Sun, Oct 1, 2023 at 7:20 AM shane qian  wrote:

> hi yegappan,
>
> 1. first of all, to me the `simple` meant `class` is class like `struct`,
> I was not like the OOP in vim9script actually, but well that probably would
> not be accepted by you all now.
>

Bram didn't intend the Vim9 classes to be simple structus.  Please do read
the Vim9 class
documentation and the items in the todo.txt file before the recent changes
(early august).


>
> 2. about the implementation, we've discussed to make class var be default
> public and only one static keyword. that's another meant `simple`.
>

You do need to provide access control for object variables.  Without that
you cannot support
user-defined types.  A user-defined type should be able to support private
variables and
methods.


>
> 3. about the implementation still, now another ticket your proposal class
> douder methods, that's really something like mixture, if you preferred
> keyword then how about keyword `new C` for initiation? if you preferred
> underscore then how about add length()/empty() as another private method?
> etc.
>

The difference is that these methods are intended to be called internally
by the Vim builtin functions
and not directly by the user and other methods.  The goal is to support
operations like a built-in
type (e.g. List, Dict, Blob, etc.) for objects.  The underscores are used
to make it explicit that
these functions are not intended to be directly used.

Regards,
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/CAAW7x7%3D5Stje%2BiAEifv0Gy%3D8dFdq55hkuRwyd_%2BDSnxuRyP3FQ%40mail.gmail.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Yegappan Lakshmanan]

Hi,

On Sun, Oct 1, 2023 at 5:17 AM shane qian  wrote:

> and I meant vim9script so far I felt it's good for type-checking and
> performance, but vim9 class to me I felt a bit burdened, not sure if
> still a chance to make it be simple to use (use for scripting), still wish
> that's the goal. @errael  @yegappan
>
>
I haven't introduced any fancy OOP features so far.  These are the features
that Bram has partially implemented or planned for and were already in
the todo list.  These features are basic to any OOP language.  Most of the
changes are about fixing bugs, following the specification, making the
behavior
similar to the behavior in languages like Dart, Java and TypeScript and
making
the type checking strict.

I think using a formal type checking term like "covariance" and
"contra-variance"
confuses people to think that we are introducing fancy features.  But these
are
just terms for describing the type check and not new features.  I could have
used "implement appropriate type check for method arguments and return
types in extended classes".

Regards,
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/CAAW7x7%3DEMWHk1FmdAfyuZesgyon8BFeB06GUqxsVMULOpasS_A%40mail.gmail.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Yegappan Lakshmanan]

Hi,

On Fri, Sep 29, 2023 at 2:51 PM errael  wrote:

> Shades of Java's PECS.
>
> There were two ways to deal with #12965
> .
>
>1. Adjust the parser to meet the spec.
>
>
The spec currently states that:

Object methods of the base class can be overruled. The signature (arguments,
argument types and return type) must be exactly the same.

The current implementation doesn't match with this spec.   If we follow
this spec,
then the type in an overruled method cannot be a covariant or
contra-variant.
I think that will be limiting, as the method in an extended class may want
to return
a covariant type.


>
>1. Change the spec and various implementation things.
>
> Doing 1. is backwards compatible with future implementation of the
> requested features.
> Doing 2. seems rushed.
>
> My first look, not running any code, this change seems to add little, at
> the expense of *conceptual complexity*. I was in the process of manually
> working through some things related to this, so I could make a comment,
> when it got checked in (seemed pretty quick for a change that wasn't
> understood).
>

Let me know if you see any cases that will break with the latest changs.

> What's to rush to add new features that have not been debated?
>
>
>
No rush.  I didn't see any objection to the proposal in
https://github.com/vim/vim/issues/12965
and this is closer to the Dart spec.

As the changes are minimal to support this, if needed, we can make
adjustments.

Regards,
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/CAAW7x7%3DkLdEStPJ4smSDfmkqNVVm2Jjy6rmHoYD-LoNapEALeQ%40mail.gmail.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Yegappan Lakshmanan]

On Fri, Sep 29, 2023 at 12:50 PM vim-dev ML 
wrote:

> Hi Christian,
>
> On Fri, Sep 29, 2023 at 10:30 AM Christian Brabandt <
> ***@***.***> wrote:
>
> > what is contr-variant?
> >
> >
> > Consider the following example (from #12965):
>
> class A
> endclass
>
> class B extends A
> endclass
>
> class C extends B
> endclass
>
> In this example, type "C" is a covariant of type "B" and "A" is
> contra-variant of type "B".
>
> This matters when overruling methods in an extended class. The method
> return value
> type in an extended class can use a covariant type of return value in the
> parent class.
> The type of method arguments in an extended class can use a contra-variant
> type.
>
> For example (continuing the above example):
>
> class Foo
> def Doit(p: B): B
> return B.new()
> enddef
> endclass
>
> class Baz extends Foo
> def Doit(p: A): C
> return C.new()
> enddef
> endclass
>
> The Doit() method in class Foo uses "B" as the argument type and "B" as
> the
> return type.
> The Doit() method in class Baz uses "A" as the argument type and "C" as
> the
> return type.
> "A" is a contra-variant of "B" and "C" is a co-variant of "B".
>
> A detailed explanation about this is in
>
> https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
> ..
>
> I wanted to follow the model used in the Dart language (
> https://medium.com/dartlang/dart-declaration-site-variance-5c0e9c5f18a5).
>
>
>
Currently the type of the method arguments and return value can be a
covariant type
of the ones in the parent class method.

- 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/CAAW7x7mijRHgkxqVUU28J4n-myndap6R0HXqtzWXiOXF0JKQ_Q%40mail.gmail.com.

Re: [vim/vim] Support contra-variant type check for object method arguments (similar to Dart) (PR #13221)

[Yegappan Lakshmanan]

Hi Christian,

On Fri, Sep 29, 2023 at 10:30 AM Christian Brabandt <
vim-dev-git...@256bit.org> wrote:

> what is contr-variant?
>
>
> Consider the following example (from #12965):

class A
endclass

class B extends A
endclass

class C extends B
endclass

In this example, type "C" is a covariant of type "B" and "A" is
contra-variant of type "B".

This matters when overruling methods in an extended class.  The method
return value
type in an extended class can use a covariant type of return value in the
parent class.
The type of method arguments in an extended class can use a contra-variant
type.

For example (continuing the above example):

class Foo
  def Doit(p: B): B
return B.new()
  enddef
endclass

class Baz extends Foo
  def Doit(p: A): C
return C.new()
  enddef
endclass

The Doit() method in class Foo uses "B" as the argument type and "B" as the
return type.
The Doit() method in class Baz uses "A" as the argument type and "C" as the
return type.
"A" is a contra-variant of "B" and "C" is a co-variant of "B".

A detailed explanation about this is in
https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)
.

I wanted to follow the model used in the Dart language (
https://medium.com/dartlang/dart-declaration-site-variance-5c0e9c5f18a5).

Regards,
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/CAAW7x7mTBy9PecxrxazoT4dDZFX9au9AiiFDso4t5Zceg5Xt%2BA%40mail.gmail.com.

Re: lockvar/unlockvar

[Yegappan Lakshmanan]

Hi,

On Mon, Sep 25, 2023 at 8:26 AM Ernie Rael  wrote:
>
> Hi all,
>
> I'm wondering if I'm seeing an error
>
> ":help lockvar" seems to indicate that the following should work.
> The goal is to get a writable variable "l1" that holds a locked list.
>
>  vim9script
>  var l0: list> = [ [1, 2, 3], [4, 5, 6], [7, 8, 9] ]
>  var l1 = l0
>  lockvar! l1
>  unlockvar 0 l1  # < expect "l1" writable, list still locked
>

I see the same problem in a legacy script and from the comments in
the var_check_permission function
, it looks
like this is done for
backward compatibility.

Regards,
Yegappan

>  # Not modifying the value, but gets a value locked error
>  l1 = null_list  # E741: Value is locked: l1
>
> Can do it this way
>
>  vim9script
>
>  var l0: list> = [ [1, 2, 3], [4, 5, 6], [7, 8, 9] ]
>  lockvar! l0
>  var l1 = l0
>
>  #l1[0] = []  # fails as exepcted
>  l1 = null_list  # works as expected
>
> -ernie
>

-- 
-- 
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/CAAW7x7k7bY%2BxOLKM%2B%3DNsntv7vQ9Lj%3DQMWhWqfRTiOChBXN5fNw%40mail.gmail.com.

Re: [vim/vim] Fix class constructor regression (PR #13113)

[Yegappan Lakshmanan]

Hi,

On Sun, Sep 24, 2023 at 6:44 AM Christian Brabandt <
vim-dev-git...@256bit.org> wrote:

> thanks!
>
>
>
The CI ASAN test is failing after this patch.  There is a memory leak with
this PR.

Regards,
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/CAAW7x7krWBuAA0SgP4r-FO99gY2L_RSa3h4GEjgj_fk6nC%3DAbQ%40mail.gmail.com.

Re: [vim/vim] Language Specification: interface interitance (Discussion #13085)

[Yegappan Lakshmanan]

On Sun, Sep 17, 2023 at 11:34 AM dkearns  wrote:

> Sorry, this is moving a bit fast for me to keep up.
>
>
>1. An interface can have only read-only and read-write instance
>variables.
>
> Interfaces generally specify behaviour, not data, and languages with this
> sort of type system usually allow properties but not fields to appear in
> interfaces.
>

As Bram described in
https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/UTFWOY5VAgAJ (which you
quoted in another discussion),
it is useful to directly specify an interface from a class definition.  If
we support this, then interfaces will have both data and behavior.


> Irrespective of whether this is a good idea or not it's surprising that it
> passes through without comment. Is anyone paying attention?
>
>
> The changes to interfaces and class members/methods were discussed in the
past two weeks.  Now that all the
changes are merged, can you try out the latest Vim version and let me know
if you have any comments?

-- 
-- 
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/CAAW7x7kyo7EYxyi_zWBpBXhVuJkrQCazHod81q0DVRFu2GMntw%40mail.gmail.com.

Re: [vim/vim] [vim9script] Regression after fixing constructor argument type checking bug (Issue #13102)

[Yegappan Lakshmanan]

Hi,

On Sat, Sep 16, 2023 at 1:30 AM Lifepillar 
wrote:

> Steps to reproduce
>
> Patch 9.0.1724 (“vim9class constructor argument type checking bug”) has
> introduced a regression in one of my Vim 9 libraries. I have a test suite
> that caught that
> ,
> but I was able to nail down the issue to the following self-contained
> script:
>
> vim9script
> def ListifyKeys(keys: any): list>
>   if type(keys) == v:t_string
> return [[keys]]
>   endif
>   return keysenddef
> class Rel
>   this.keys: list>
>
>   def new(keys: any)
> const keys_: list> = ListifyKeys(keys)
>   enddef
> endclass
> def Test()
>   var R = Rel.new('A')enddef
> Test()
>
> This fails with E1013: Argument 1: type mismatch, expected
> list> but got string.
>
> Interestingly, if the this.keys attribute is removed, no error occurs.
> Expected behaviour
>
> I would expect the script above to run without errors. That was the case
> before patch 9.0.1724.
>
> The code currently checks for the type of arguments to the new()
constructor, even if the argument
name does not start with "this".  In the above example, if you rename the
"keys" argument to the
new() function, then you will not see this issue.

The following patch is needed to address this:

diff --git a/src/vim9instr.c b/src/vim9instr.c
index ccec0bcc3..7af478f71 100644
--- a/src/vim9instr.c
+++ b/src/vim9instr.c
@@ -1838,9 +1838,13 @@ generate_CALL(
{
class_T *clp = mtype->tt_class;
char_u  *aname = ((char_u **)ufunc->uf_args.ga_data)[i];
-   ocmember_T *m = object_member_lookup(clp, aname, 0,
NULL);
-   if (m != NULL)
-   expected = m->ocm_type;
+   if (STRNCMP(aname, "this.", 5) == 0)
+   {
+   aname += 5;
+   ocmember_T *m = object_member_lookup(clp, aname, 0,
NULL);
+   if (m != NULL)
+   expected = m->ocm_type;
+   }
}
}
else if (ufunc->uf_va_type == NULL

Some of the existing tests need to be adjusted for this change.

Regards,
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/CAAW7x7miWmq5tcFQL4YAS5rC_buoL74zXZX5DAt1Mxhg_Wsy%3DQ%40mail.gmail.com.

Re: [vim/vim] Interfaces should not support class methods and variables (PR #13100)

[Yegappan Lakshmanan]

Hi,

On Sat, Sep 16, 2023 at 10:26 AM errael  wrote:

> This seems like it should work. Gets
>
> E1315: White space required after name: I1, I2
>
> vim9script
>
> interface I1
> def F1()
> def F2()
> endinterface
>
> interface I2
> def F2()
> def F3()
> endinterface
>
> interface I3 extends I1, I2
>
>
Currently only one interface or class name can be specified after "extends"
(an interface can extend
only one interface).

Regards,
Yegappan


>
> endinterface
>
> class C implements I3
> def F1()
> enddef
> def F2()
> enddef
> def F3()
> enddef
> endclass
>
>
>

-- 
-- 
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/CAAW7x7nYRhhZweUNBz1ruNQTC5OLMreUANADuJEe1nKQ5%3D2ZJQ%40mail.gmail.com.

Re: [vim/vim] Class members are accesible only from the class where they are defined. (PR #13086)

[Yegappan Lakshmanan]

Hi Christian,

On Sat, Sep 16, 2023 at 4:20 AM Christian Brabandt <
vim-dev-git...@256bit.org> wrote:

> Coverity complains about this part here:
>

I have opened the PR https://github.com/vim/vim/pull/13103 to fix this.

Regards,
Yegappan


> *** CID 1544700:  Control flow issues  (DEADCODE)
> /src/vim9class.c: 1114 in add_classfuncs_objmethods()
> 1108if (loop == 1 && STRNCMP(
> 1109
> extends_cl->class_class_functions[i]->uf_name,
> 1110"new", 3) == 0)
> ++skipped;
> 1112else
> 1113{
> >>> CID 1544700:  Control flow issues  (DEADCODE)
> >>> Execution cannot reach the expression 
> >>> "extends_cl->class_class_functions" inside this statement: "pf = (loop == 
> >>> 1) ? extends_...".
> 1114ufunc_T *pf = (loop == 1
> 1115? 
> extends_cl->class_class_functions
> 1116: 
> extends_cl->class_obj_methods)[i];
> 1117(*fup)[gap->ga_len + i - skipped] = copy_function(pf);
> 1118
> 1119// If the child class overrides a function from the 
> parent
>
>
>

-- 
-- 
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/CAAW7x7kL0tpNpq01-kSiOahp8eSJS6KJdjQV4QfodgWbEL1m5A%40mail.gmail.com.

Re: [vim/vim] How do I contribute to the project? (Discussion #13087)

[Yegappan Lakshmanan]

Hi,

On Thu, Sep 14, 2023 at 10:23 AM Gary Watson 
wrote:

> I'm interested in contributing to the project... Starting up this
> discussion thread for two reasons...
>
>1. To find out the best way I can personally contribute
>2. Other people might be interested in contributing too, if so,
>whatever answers I get, they might find useful too :)
>
> To that end...
>
>1. What tasks could I help with (assuming something from the issue
>tracker might be good)
>
>
Thanks for reaching out. I would recommend the following tasks:

1. Develop test scripts for the Vim features.  There are a large number of
example scripts in the
src/testdir directory (
https://github.com/vim/vim/tree/master/src/testdir).  Vim has an extensive
test infrastructure for developing different types of tests.  You can
use the Vim code coverage
information (https://app.codecov.io/gh/vim/vim/tree/master/src) to see
the lines of codes that
   are not yet covered by tests and develop new tests for them.  Note that
Vim currently has
   around 82% code coverage.  This will significantly help in improving the
quality of Vim,
   refactoring of the code base and adding new features without introducing
regressions.
   This work may not be as fancy as adding new features, but this helps
more than adding
   new features to Vim.
2. Help with triaging the issues reported in Github issue tracker (
https://github.com/vim/vim/issues).
3. Develop test scripts for the issues listed in Github.  This will help in
reproducing the issue and
adding it to the test suite.
4. Develop fixes for the issues reported in Github.  The latest todo.txt
help
file (https://github.com/vim/vim/blob/master/runtime/doc/todo.txt)
contains the list of
known issues and feature requests.
5. Develop new features listed in the todo.txt file.  The major features
that currently need help
are virtual text and classes.


>1. Are there any conventions I should know about to not get made fun
>of too much :)
>2. Where's the best place to communicate about such things (or is this
>discussion section it?)
>1. side note, is there a good live chat somewhere?
>
>
>
You can use the vim-dev mailing list for any development related discussion.

Regards,
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/CAAW7x7%3DmwCQTC5L-ut4uxh-LMXaN6DY_26462SaOv7_Vvbc2bA%40mail.gmail.com.

Re: [vim/vim] Class members are accesible only from the class where they are defined. (PR #13086)

[Yegappan Lakshmanan]

On Thu, Sep 14, 2023 at 10:32 AM errael  wrote:

> I played around with vim including this PR. While trying stuff, ran into 
> #13041
> (comment)
> ;
> doesn't have anything to do with this PR.
>
> Unless there's something particular you'd like explored, I'll wait for the
> merge.
>

Thanks.  Did you see any issues with using class variables and methods in
script context, def function context, derived class, another class, using
an instance, instance method, class method and different access controls?
I know this is a long list. But there are too many scenarios where a class
variable and method can be used.

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/CAAW7x7m-GtCiiXwGZ%3DHhzQ1xVZkbTDyzM-FKK4SHSLKAhf3H9g%40mail.gmail.com.

Re: bell(), looking for builtin function to ring the bell

[Yegappan Lakshmanan]

Hi,

On Wed, Sep 13, 2023 at 9:32 AM Ernie Rael  wrote:
>
> Greetings,
>
> In a plugin I'm working on, when certain simple errors occur, I want to ring 
> the bell, some kind of alert. A popup, use in some place in the plugin, is 
> more than is needed.
>
> The closest thing I can find is
>
> call sound_playevent('bell')
>
> which isn't cross platform.
>
> What have I missed?
>

There is no builtin function to just ring the bell.  You can try using
the following:

   set errorbells
   echoerr ''
   set noerrorbells

Regards,
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/CAAW7x7mK%3DaxzkxCN3dMhHsOzqDu5uqwEkYZ-kTjP4pQW_4cMgA%40mail.gmail.com.

Re: [vim/vim] vim9class work/bugs TODO for vim9.1 (Discussion #13041)

[Yegappan Lakshmanan]

On Tue, Sep 5, 2023 at 9:56 PM Yegappan Lakshmanan  wrote:
>
> Hi,
>
> On Tue, Sep 5, 2023 at 8:20 PM errael  wrote:
>>
>> (Short term discussion)
>>
>> Over a week ago, there was a one week estimate to take bug fixes. Some 
>> notable missing features were discovered:
>>
>> access control was not implemented (could write to privates)
>> reading/writing statics outside of a class not implemented
>>
>> Basic access control was fixed, reading statics outside of a class fixed.
>> Variety of other fixes, for example garbage collection of class/interface.
>> I don't think there are any open issues regarding specification of 
>> syntax/semantics.
>>
>> Issues I'm aware of and/or I'm not sure about
>>
>> writing statics in s :def outside of a class
>> more access control situations
>> script level access issues, maybe only statics
>
>
> Thanks for summarizing the outstanding issues.
>
>>
>> Still not feature complete because of 1.
>> The second could be considered bugs, the third hasn't been triaged (AFAIK), 
>> could be missing feature or bugs.
>>
>> Putting together tests for 2. over the last day. Some bugs found/fixed; 
>> Good/Bad news, it's still pretty easy to find bugs (though I can be brutal, 
>> so maybe it's not that bad). I've add some fails below, depending can open 
>> them as bugs (certainly will if they are not fixed for 9.1)
>>
>> @yegappan @chrisbra Those at a higher pay grade than I will have to 
>> contemplate, meditate, and otherwise look at the situation, and make a 
>> scheduling update. I put TODO in the tile, but things change...
>>
>> Following run with 9.0.1872 and PR #13032
>>
>> script level static access example
>>
>> line8:
>> E1326: Member not found on object "A": svar1
>>
>> vim9script
>>
>> class A
>> public static svar1: number
>> endclass
>>
>> var oa = A.new()
>> echo oa.svar1
>>
>> weird name duplication error
>
>
> I have opened PR https://github.com/vim/vim/pull/13042 with a fix for this 
> issue.
>

Both of these issues are now addressed in the PR.

Regards,
Yegappan

>
>>
>> line5:
>> E1369: Duplicate member: s_var
>>
>> Flip the order of the declarations, and there is no error. Probably off by 1 
>> for duplicate name check
>>
>> vim9script
>>
>> class C
>> public static s_var2: number
>> public static s_var: number
>> endclass
>>
>>

-- 
-- 
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/CAAW7x7n9mTUQNYHLqJqb6ZgW%3DP8sOuXFNOxMc3Ubht8miruyDw%40mail.gmail.com.

Re: [vim/vim] vim9class work/bugs TODO for vim9.1 (Discussion #13041)

[Yegappan Lakshmanan]

Hi,

On Tue, Sep 5, 2023 at 8:20 PM errael  wrote:

> (Short term discussion)
>
> Over a week ago, there was a one week estimate to take bug fixes. Some
> notable missing features were discovered:
>
>1. access control was not implemented (could write to privates)
>2. reading/writing statics outside of a class not implemented
>
> Basic access control was fixed, *reading* statics outside of a class
> fixed.
> Variety of other fixes, for example garbage collection of class/interface.
> I don't think there are any open issues regarding specification of
> syntax/semantics.
>
> Issues I'm aware of and/or I'm not sure about
>
>1. writing statics in s :def outside of a class
>2. more access control situations
>3. script level access issues, maybe only statics
>
>
Thanks for summarizing the outstanding issues.


>
>
> Still not feature complete because of 1.
> The second could be considered bugs, the third hasn't been triaged
> (AFAIK), could be missing feature or bugs.
>
> Putting together tests for 2. over the last day. Some bugs found/fixed;
> Good/Bad news, it's still pretty easy to find bugs (though I can be brutal,
> so maybe it's not that bad). I've add some fails below, depending can open
> them as bugs (certainly will if they are not fixed for 9.1)
>
> @yegappan  @chrisbra
>  Those at a higher pay grade than I will
> have to contemplate, meditate, and otherwise look at the situation, and
> make a scheduling update. I put TODO in the tile, but things change...
>
> Following run with 9.0.1872 and PR #13032
> 
>
> *script level static access example*
>
> line8:
> E1326: Member not found on object "A": svar1
>
> vim9script
>
> class A
> public static svar1: number
> endclass
>
> var oa = A.new()
> echo oa.svar1
>
> *weird name duplication error*
>

I have opened PR https://github.com/vim/vim/pull/13042 with a fix for this
issue.

Regards,
Yegappan


> line5:
> E1369: Duplicate member: s_var
>
> Flip the order of the declarations, and there is no error. Probably off by
> 1 for duplicate name check
>
> vim9script
>
> class C
> public static s_var2: number
> public static s_var: number
> endclass
>
>
>

-- 
-- 
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/CAAW7x7%3D1PBdQq6yap5QT80nWtfJovbnpZr3BFhTaX%3D1Vr2zYsg%40mail.gmail.com.

Re: Commit: patch 9.0.1857: [security] heap-use-after-free in is_qf_win()

[Yegappan Lakshmanan]

Hi Christian,

On Sun, Sep 3, 2023 at 11:30 AM Christian Brabandt  wrote:
>
> patch 9.0.1857: [security] heap-use-after-free in is_qf_win()
>
> Commit: 
> https://github.com/vim/vim/commit/fc68299d436cf87453e432daa77b6d545df4d7ed
> Author: Christian Brabandt 
> Date:   Sun Sep 3 20:20:52 2023 +0200
>
> patch 9.0.1857: [security] heap-use-after-free in is_qf_win()
>
> Problem:  heap-use-after-free in is_qf_win()
> Solution: Check buffer is valid before accessing it
>
> Signed-off-by: Christian Brabandt 
>
> diff --git a/src/testdir/crash/bt_quickfix_poc 
> b/src/testdir/crash/bt_quickfix_poc
> new file mode 100644
> index 0..bf02b4dcb
> --- /dev/null
> +++ b/src/testdir/crash/bt_quickfix_poc
> @@ -0,0 +1,9 @@
> +comman!-narg=* Xexpr lex
> +auto BufReadPre * exe"sn" ..expand("")
> +fu Xautocmd_changelist()
> +cal writefile(['Xtestfile2:4:4'],'Xerr')
> +  sil! edi Xerr
> +Xexpr 'Xtestfile:4:4'
> +endf
> +call Xautocmd_changelist()
> +call Xautocmd_changelist()
> \ No newline at end of file
>

Is there supposed to be a newline at the end of this file?

- 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/CAAW7x7n%3DJxhi6cWecWEPmfA9sNcnQTK6K6Jr2pYYs_MzGZC96A%40mail.gmail.com.

Re: vim9class: accessing statics from outside the class

[Yegappan Lakshmanan]

On Sat, Sep 2, 2023 at 9:31 AM Ernie Rael  wrote:

> AFAICT, it doesn't work. Is anyone working on this?
>
> I've run into it while working https://github.com/vim/vim/pull/13007.
>
> I am taking a look, but I don't want duplicate efforts.
>

I am not working on this.

- 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/CAAW7x7nTYsQd9XDGLGYdAq%2BHSMuQ1jVqbpmbu66t8pNMFZCNGw%40mail.gmail.com.

Re: Vim9 class/object member access control

[Yegappan Lakshmanan]

On Sat, Sep 2, 2023 at 5:02 AM Yegappan Lakshmanan  wrote:
>
> Hi all,
>
> The access control to readonly, read-write and private members in a
> class/object discussed in https://github.com/vim/vim/discussions/12979
> should all work now.  Let us know if there are any cases where the
> access control is not correctly enforced.
>
> When testing these, I found an existing memory corruption issue
> with class member variables. When a class member uses a complex
> type (e.g. List or Dict), then it is garbage collected under some
> conditions leading to a memory corruption (reported by ASAN and
> Valgrind).  I am still debugging this issue.
>

Correction: This is a use-after-free problem and not a memory corruption.

- 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/CAAW7x7%3Dzemkp07%2BwqU3rPr6tMk9PTmQgp_tKa4Kc4RiJ1CbutA%40mail.gmail.com.

Vim9 class/object member access control

[Yegappan Lakshmanan]

Hi all,

The access control to readonly, read-write and private members in a
class/object discussed in https://github.com/vim/vim/discussions/12979
should all work now.  Let us know if there are any cases where the
access control is not correctly enforced.

When testing these, I found an existing memory corruption issue
with class member variables. When a class member uses a complex
type (e.g. List or Dict), then it is garbage collected under some
conditions leading to a memory corruption (reported by ASAN and
Valgrind).  I am still debugging this issue.

Regards,
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/CAAW7x7kbtM_%2B7sSYPmz6YwZ1%3DruA9t9Rpf35G%2Bx4cMnMpiqVXQ%40mail.gmail.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[Yegappan Lakshmanan]

On Thu, Aug 31, 2023 at 6:50 AM errael  wrote:

> I have started a discussion (#12979
> ) to capture the
> access matrix.
>
> Thank you. I'll take a look. I would have done something if you'd said "go
> ahead" .
>
>
> I have marked the failing cases with "BUG".  Most of these are related to
writing to
a class member variable in a def function.

-- 
-- 
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/CAAW7x7%3DY-YF48AKkFHcoj9MMRDD-CeQyiGo9SosqP4bR2MbEbw%40mail.gmail.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 29, 2023 at 1:38 PM errael  wrote:

>
>-
>
>Able to access private static
>-
>
>Compile error when trying to write public static
>
> There's another one (a real shocker).
>
> It's OK to write to a private member.
>
> vim9script
>
> class C
> this._m: number
> #static _s: number
> def Dump()
> echo this._m
> enddef
> endclass
>
> def F()
> var o = C.new()
> o.Dump()
> o._m = 5
> o.Dump()
> #var s = C._s
> enddef
> F()
>
> I put in the Dump() because I had to see it to believe it.
>
>
>
I have created the PR https://github.com/vim/vim/pull/12963 to address this.

Regards,
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/CAAW7x7%3DBeBcUG%2Bk1tWsRpOWp2TucmdT8NZQEmkR5q-FF%2BML95A%40mail.gmail.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 29, 2023 at 1:42 PM Christian Brabandt <
vim-dev-git...@256bit.org> wrote:

> Should the example here
> https://github.com/vim/vim/blob/d01a0df61d2a322645fb393ed704fcec38e0d0fe/runtime/doc/vim9class.txt#L186-L200
>
> also be changed to use underscores? Otherwise we wouldn't need the and
> Set() function, right?
>
>
>
Yes. This example needs to be updated.

Regards,
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/CAAW7x7k94G6ow-ToPmY%2Bsaao1eZfm4%2BhEQRbfuoGU3g0gmduwA%40mail.gmail.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 29, 2023 at 11:03 AM Gianmaria Bajo 
wrote:

> Also readable doesn't exist anywhere else. If simplicity is the ultimate
> goal, I'd say this PR is ok in just removing public. We can live without
> readonly but even more so without stuff invented for vimscript that
> doesn't exist anywhere else.
>
>
> I agree.  I think this will be simple and less confusing.

Regards,
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/CAAW7x7kso_s%2B%3DY7Xk%3Dk3-3KatubzpGfRjZDFSyHE_2gmkmG1yg%40mail.gmail.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[Yegappan Lakshmanan]

On Tue, Aug 29, 2023 at 9:20 AM dkearns  wrote:
>
> Is there some strong objection to requiring a keyword modifier? Why is a 
> default needed at all?
>

If we always require a keyword modifier (like private, public, etc.)
in a member/method
declaration, then it will be too cumbersome to add this prefix to each
member/method.
A default makes it simpler.

Regards,
Yegappan

>
> We could require private and keep the required underscore as well. This is is 
> already done for functions/methods which require an uppercase character.
>
> The language uses strictly unnecessary keywords everywhere. In declarations, 
> in particular, they're cheap and clear.
>
> This would also obviate the problem with initialised declarations looking the 
> same as plain assignments.
>

-- 
-- 
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/CAAW7x7%3DY8iLTCRreYa%3Dbpb8w2tjV0K6gR%2BMnq0mRpyc07VPYWw%40mail.gmail.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 29, 2023 at 9:08 AM errael  wrote:

> readonly is working AFAICT. I still need to put together some tests. I
> can't try writing to a readonly static because of the compilation failure
> bug that prevents writing to class statics. One nice thing about readonly
> is that it doesn't affect anything unless you use it.
>

One of the goals of the Vim9 script is to be similar to other widely
scripting languages (like
typescript and python) and simple to use.  I am not sure whether any other
OO language
supports the "readonly" keyword.  Can we keep it simple and make the
methods/members
either private or public?


> I'm going to put this on the shelf while I put together the PR for
> preventing writing to private members.
>
> The readonly PR is based on this PR. So this PR, #12932
> , has to go in before I can open a
> PR for readonly. Is this PR ready to go?
>
>
> This PR can be merged based on the outcome of these discussions.

-- 
-- 
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/CAAW7x7n7PFkcNfCejMYGJiTYk-13MQYMWpRw2LiFCs09CJ6_jQ%40mail.gmail.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[Yegappan Lakshmanan]

Hi Christian,

On Tue, Aug 29, 2023 at 12:06 PM Christian Brabandt <
vim-dev-git...@256bit.org> wrote:

> so let me summarize: the current proposal is to remove the public keyword
> completely (?) and make all attributes public by default (unless they start
> with _)? So by removing this keyword, no-one complains that private
> keyword is also missing?
>

Yes.  The only supported keyword for members/methods is "static" for
declaring class members and methods.
If a member or method name starts with an underscore, then it is private.
Otherwise it is public.

Regards,
Yegappan

I like that approach, it makes it easier to spot private members directly
> in the code. But I am probably not the one going to use this a lot, so I am
> not having any saying here :)
>
>
>

-- 
-- 
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/CAAW7x7mLfPP%3DfMuw2MTiwTo%2B8gRYEfZ86%2BKDGdXwQQB_H%3Dz3Mw%40mail.gmail.com.

Fix for the CI asan test failure due to a memory leak

[Yegappan Lakshmanan]

Hi all,

The CI ASAN test is currently failing due to a memory leak.  The fix for
this is in the https://github.com/vim/vim/pull/12948 PR.

Regards,
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/CAAW7x7mpzffs%3Dd%3DCTqVb7bhpBu0B%3Dqa9ouhSUaMO2ULjbfyMSQ%40mail.gmail.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[Yegappan Lakshmanan]

Hi,

On Mon, Aug 28, 2023 at 6:47 PM errael  wrote:

> I looked around to get a feel... The following fixes the "access to
> private static" var in the example, if you want to include it. Not tested
> much.
>
> diff --git a/src/vim9expr.c b/src/vim9expr.c
> --- a/src/vim9expr.c
> +++ b/src/vim9expr.c
> @@ -434,14 +434,25 @@
>  {
> // load class member
> int idx;
> +   ocmember_T *m;
> for (idx = 0; idx < cl->class_class_member_count; ++idx)
> {
> -   ocmember_T *m = >class_class_members[idx];
> +   m = >class_class_members[idx];
> if (STRNCMP(name, m->ocm_name, len) == 0 && m->ocm_name[len] == 
> NUL)
> break;
> }
> if (idx < cl->class_class_member_count)
> {
> +   // TODO: Would kindof prefer (@yegappan what do you think)
> +   //   even though it's more likely to get a cache miss.
> +   // if (m->ocm_access == VIM_ACCESS_PRIVATE
> +   //  && !inside_class(cctx, 
> cl))
> +   // Maybe not, *name == '_' is simple to look at but...
> +   if (*name == '_' && !inside_class(cctx, cl))
> +   {
> +   semsg(_(e_cannot_access_private_member_str), m->ocm_name);
> +   return FAIL;
> +   }
> *arg = name_end;
> return generate_CLASSMEMBER(cctx, TRUE, cl, idx);
> }
>
>
>
This is the proper fix for this issue.  A similar check is used before this
block of code for
readonly object members.  Can you open a PR for this with a test for this
condition?

- 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/CAAW7x7mV2%2BnFUS2w1rkmwHJgU2tPoL4WR9pLj9HTZ1xobN-M6w%40mail.gmail.com.

Re: [vim/vim] Make object/class member variables public by default (PR #12932)

[Yegappan Lakshmanan]

Hi,

On Mon, Aug 28, 2023 at 12:14 PM errael  wrote:

> When I build objmember, with no modifications, and run this I see two
> problems
>
>1. Able to access private static
>2. Compile error when trying to write public static
>
>
I am able to reproduce the second issue even using a two months old image.
It looks like writing to a class member from a def function never worked.

Regards,
Yegappan


>
>
> Here's a test
>
> vim9script
> class C
> this._mpfoo: number
> static _spfoo: number
> this.mfoo: number
> static sfoo: number
>
> def new()
> this._mpfoo = 1
> _spfoo = 2
> this.mfoo = 201
> sfoo = 202
> enddef
> endclass
>
> def F()
> var o = C.new()
> #echo "_mpfoo" o._mpfoo
> echo "_spfoo" C._spfoo  ### < able to access private static
> echo "mfoo" o.mfoo
> echo "sfoo" C.sfoo
>
> o.mfoo = 301
> #C.sfoo = 302   ### < compilation fails
> echo "mfoo" o.mfoo
> echo "sfoo" C.sfoo
> enddef
> F()
> finish
>
>
>

-- 
-- 
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/CAAW7x7nJj8deLHk0RYUJS02m%2B1N9uysnxSZqUnZT5p0eiAgkJg%40mail.gmail.com.

Re: Updates on the Vim project

[Yegappan Lakshmanan]

On Sun, Aug 27, 2023 at 11:09 AM Christian Brabandt  wrote:
>
> I would think once Yegappan thinks the Vim9 classes is good enough to
> release, I'd go ahead. Not sure how much work this is left to be done,
> but I'd rather sooner release than later. So it depends on how far we
> want the Vim9 classes implementation have ready for the new release.
>

The following Vim 9 class related items are currently in the todo list:

1. Change access: public by default, private by prefixing "_".
2. Check for error: can't have the same name twice (ignoring "_" prefix).
3. "final" object members - can only be set in the constructor.
4. Support export/import of classes and interfaces.
5. Cannot use class type of itself in the method (Issue #12369)
6. Cannot use an object method in a lambda (Issue #12417)
7. Cannot call class member of funcref type (Issue #12324)
8. Using a list of functions does not work (Issue #12081)
9. First argument of call() cannot be "obj.Func". (Issue #11865)
10. Make ":defcompile ClassName" compile all functions and methods in the class.
11. Support forward declaration of a class.  E.g. for Clone() function.
12. Getting a member variable with "any" type should be handled at runtime.
13. "obj.Method()" does not always work in a compiled function, assumes "obj"
is a dictionary.  (Issue #12196, #12024, #11822, #12198, #11981)
14. Support empty(), len() for objects.
15. Check types for "implements" - members and methods
16. Support locking and unlocking objects/classes.
17. When checking "implements" also check types of members and function args.
18. For chaining, allow using the class name as type for function return value.
19. Implement generics
20. Add "assignable" (class or child)?
21. Use a more efficient way for interface member index than iterating
over list.
22. Implement a variant of type() that returns a different type for each class.
23. Support class local to a function.
24. Support promise class, could be used to wait on a popup close callback.

Other than the first two items, I don't think we can get to the other items in
this list for the 9.1 release.

Regards,
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/CAAW7x7mGjK%3D-L1dt5krxMBaj-e3FgCNkHCRpe2UT-x5GLco9BQ%40mail.gmail.com.

Re: Updates on the Vim project

[Yegappan Lakshmanan]

Hi Christian,

On Sun, Aug 27, 2023 at 11:09 AM Christian Brabandt  wrote:
>
> >
> > On Thu, 24 Aug 2023 at 06:18, Christian Brabandt  wrote:
> >
> > Hi,
> > this is a small update over what happened the last few weeks.
> >
> > Over the last days, I have been merging mostly runtime file changes,
> > small improvements to the Vim9 class implementations and bug fixes.
> >
> > If you check the Milestone¹ for the release 9.1, most of the remaining
> > changes are small runtime changes, for which I'd like to get an
> > ACK/NACK.
> >
> >
> > Did you have a rough date in mind for the release?  Are we looking at weeks 
> > or months?
>
> I did go through the Vim9.1 milestone and try to merge what seems
> uncontroversial and fixes crashes. But somehow I keep getting new PRs
> there all the time :) (I am joking)
>

:-).  I keep adding the runtime file changes and minor fixes to the
Vim 9.1 milestone.
Can we take fixes for one more week and then stop?

>
> I would think once Yegappan thinks the Vim9 classes is good enough to
> release, I'd go ahead. Not sure how much work this is left to be done,
>

I want to make sure that all the Vim9 class changes that may break backward
compatibility go in before the Vim 9.1 release.  I think, we are down to the
last one and it is about the default access for an object/class member variable.

Regards,
Yegappan

> but I'd rather sooner release than later. So it depends on how far we
> want the Vim9 classes implementation have ready for the new release.
>
> Also I'd like to get a few of Charles issues fixed if possible.
> @Charles, please consider sending updates and checking the vim9.1
> Milestone in Github https://github.com/vim/vim/milestone/1 for issues in
> your plugins.
>
> Thanks,
> Christian

-- 
-- 
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/CAAW7x7nkgyBnASvOyNCfYho6yKCa0G61phSawVNB8y67qBYOGg%40mail.gmail.com.

Re: Vim9: Default object member access

[Yegappan Lakshmanan]

Hi Doug,

On Sun, Aug 27, 2023 at 7:14 AM Doug Kearns  wrote:
>
>
> On Fri, 25 Aug 2023 at 23:50, Yegappan Lakshmanan  wrote:
>>
>> Hi all,
>>
>> From the email thread
>> https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
>> and the following items in the todo.txt file:
>>
>>   - Change access: public by default, private by prefixing "_".
>> Check for error: can't have the same name twice (ignoring "_" 
>> prefix).
>>
>> This is not yet implemented.  We cannot change this after releasing Vim 9.1.
>> Should we make this change now?
>
>
> I expect this will be an unpopular opinion but I'd strongly consider 
> releasing 9.1
> without significant changes to Vim9 script from the 9.0 release.  Then the 
> object model
> could be released with Vim 10.
>

Once Vim 9.1 is released, we cannot break backward compatibility.
This means that
we cannot change the current accessibility of the object/class members
and methods.

Regards,
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/CAAW7x7%3Drb-w_p8Bq5wjtS5srpsYiazexA94C8a_E5G_bO5PrPw%40mail.gmail.com.

Re: Support for Private class/object methods

[Yegappan Lakshmanan]

On Fri, Aug 25, 2023 at 3:50 PM Ernie Rael  wrote:
>
> On 23/08/25 2:07 PM, bfrg wrote:
>
> If "public" is omitted, shouldn't class members and method be private by 
> default just like "def" functions and script variables are script-local by 
> default unless prefixed with "export"?
>
> In general, I would also like it to be symmetric. So, either introducing 
> "public" and "private" together, or no modifier keyword at all.
>
> Any opinion/comment on "read-only" access in favor of adding Getters?
>
> Would "export" be better than "public" in class definitions?
>

The keyword "export" is already used to export items from one script to another.
So using it to make methods public within a script will be confusing.

Regards,
Yegappan

> In the latter case an underscore indicates private class members and methods 
> whereas public ones don't have an underscore.
>
> And another issue: why isn't this thread shown in GitHub Discussions? Wasn't 
> the whole point of enabling Discussions so that more people can participate 
> in such decision making?
> On Friday, August 25, 2023 at 6:11:34 AM UTC+2 Doug Kearns wrote:
>>
>> On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan  wrote:
>>>
>>> Hi all,
>>>
>>> The following item is in the todo.txt file for implementing private
>>> methods in a class:
>>>
>>>  - Private methods?
>>> either: private def Func()
>>> or: def _Func()
>>> Perhaps use "private" keyword instead of "_" prefix?
>>>
>>> Function and method names always start with an uppercase letter.  So
>>> if we use the
>>> "_" prefix for a private method name then it will diverge from that. So I 
>>> have
>>> implemented this using the "private" keyword.
>>>
>>> Any opinions?
>>
>>
>> Thanks very much for keeping the ball rolling on this.
>>
>> For others, there was some previous discussion[1] about it on the list when 
>> Bram asked for opinions.  My recollection is that both you and he were in 
>> favour of the "_" prefix for call-site identification purposes?
>>
>> My personal preference would be for the modifier keyword with a symmetric, 
>> even if possibly redundant, "public".  I think this is justifiable on the 
>> grounds of it meeting the "less weird" requirement for Vim9 script.  While 
>> I'm sure there are others, JavaScript is the only language I can think of 
>> off the top of my head that defaults to public and uses a sigil for private 
>> access.
>>
>> Thanks again,
>> Doug
>>
>> 1.  https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
>>
>>

-- 
-- 
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/CAAW7x7%3Dw_BuAU%2BAjSt4sbsZx4gvXs7Ap29nR%2Bu804Sy0hUtvxA%40mail.gmail.com.

Re: Support for Private class/object methods

[Yegappan Lakshmanan]

Hi,

On Fri, Aug 25, 2023 at 2:07 PM bfrg  wrote:
>
> If "public" is omitted, shouldn't class members and method be private by 
> default just like "def" functions
> and script variables are script-local by default unless prefixed with 
> "export"?
>

Currently object/class methods are always public and the object/class
private methods
are not supported.

If "public" is omitted, then object/class member variables are
read-only.  With "public",
the member variables are read/write.  If the member variable name starts with an
underscore, then it is private.

>
> In general, I would also like it to be symmetric. So, either introducing 
> "public" and "private" together,
> or no modifier keyword at all. In the latter case an underscore indicates 
> private class members and
> methods whereas public ones don't have an underscore.
>

I prefer using the underscore character to differentiate between
public and private methods.
I will create a PR to add support for private object/class methods.

>
> And another issue: why isn't this thread shown in GitHub Discussions? Wasn't 
> the whole point of enabling
> Discussions so that more people can participate in such decision making?
>

I am used to sending emails to the mailing list.  So I started this
email thread.
We can use Github discussions going forward for other features.

Regards,
Yegappan

> On Friday, August 25, 2023 at 6:11:34 AM UTC+2 Doug Kearns wrote:
>>
>> On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan  wrote:
>>>
>>> Hi all,
>>>
>>> The following item is in the todo.txt file for implementing private
>>> methods in a class:
>>>
>>>  - Private methods?
>>> either: private def Func()
>>> or: def _Func()
>>> Perhaps use "private" keyword instead of "_" prefix?
>>>
>>> Function and method names always start with an uppercase letter.  So
>>> if we use the
>>> "_" prefix for a private method name then it will diverge from that. So I 
>>> have
>>> implemented this using the "private" keyword.
>>>
>>> Any opinions?
>>
>>
>> Thanks very much for keeping the ball rolling on this.
>>
>> For others, there was some previous discussion[1] about it on the list when 
>> Bram asked for opinions.  My recollection is that both you and he were in 
>> favour of the "_" prefix for call-site identification purposes?
>>
>> My personal preference would be for the modifier keyword with a symmetric, 
>> even if possibly redundant, "public".  I think this is justifiable on the 
>> grounds of it meeting the "less weird" requirement for Vim9 script.  While 
>> I'm sure there are others, JavaScript is the only language I can think of 
>> off the top of my head that defaults to public and uses a sigil for private 
>> access.
>>
>> Thanks again,
>> Doug
>>
>> 1.  https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
>>
>>

-- 
-- 
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/CAAW7x7nZEFFvkJNyGt4-8uRaKUaGYug5Fv5i515gAWYzt_4RqA%40mail.gmail.com.

Re: [vim/vim] Change the LSP HTTP header Content-Type field (PR #12295)

[Yegappan Lakshmanan]

Hi,

On Fri, Aug 25, 2023 at 4:26 PM Magnus Groß 
wrote:

> @yegappan  Is there any reason why the
> Content-Type header is set in the first place? It causes problems with
> some LSP servers such as haskell-language-server
> , which doesn't
> support that header and crashes with the following error when it receives
> that header (when using your vim9 LSP client
> ):
>

I originally set it to follow the LSP specification.  But as we learned
over a period of time, some of
the LSP servers are not able to properly handle/ignore this header.


> Error | Failed to parse message header:
> :  string
>
> Obviously we could fix that particular server, but I think there is
> incentive to not send that header at all, because:
>
>- it is an optional header
>- the value that we set (Content-Type: application/vscode-jsonrpc;
>charset=utf-8) is already the default value
>
> 
>- other popular LSP clients also omit this header
>
> I have tested the following LSP clients and not a single one of them sets
> the Content-Type header, only the Content-Length header is set for all of
> them:
>
>- coc.nvim
>- Neovim LSP
>
> 
>- VSCode
>- Ale
>
> 
>- YouCompleteMe
>
> Therefore in order to improve compatibility with slightly misbehaving LSP
> clients, I propose to drop this header:
>
> diff --git a/src/json.c b/src/json.c
> index acf7ac57c..e2a011309 100644--- a/src/json.c+++ b/src/json.c@@ -105,8 
> +105,7 @@ json_encode_lsp_msg(typval_T *val)
>  ga_init2(, 1, 4000);
>  // Header according to LSP specification.
>  vim_snprintf((char *)IObuff, IOSIZE,-"Content-Length: %u\r\n"-   
> "Content-Type: application/vscode-jsonrpc; charset=utf-8\r\n\r\n",+ 
> "Content-Length: %u\r\n\r\n",
>   ga.ga_len - 1);
>  ga_concat(, IObuff);
>  ga_concat_len(, ga.ga_data, ga.ga_len);
>
>
I don't see a problem in removing the Content-Type header.  Can you create
a PR with this change?

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/CAAW7x7mTetOb-8FtN66pvJMwa1rKj-8FnmTjQMknJajw_Zmf7g%40mail.gmail.com.

Re: Vim9: Default object member access

[Yegappan Lakshmanan]

On Fri, Aug 25, 2023 at 9:32 AM shane qian  wrote:
>
> best choice was leading lowercase, but seems it's not a choice in vim script.
>
> so I prefer and vote both to use leading `private` for var and method.
> and in that github ticket I think bram also said he wish it's `consistent`.
> vs leading underscore was a bit magic, IMO it even may lost in kw search 
> since it needed to ignore leading _ to confirm.
>

As discussed in the other email thread, using a leading underscore makes it
apparent that the referred method or member variable is private.
Otherwise one needs to look at the method/variable definition to see whether it
is private or not. I prefer the leading underscore for private methods and
member variables.

Regards,
Yegappan

>
> --
> shane.xb.qian
> 
> From: vim_dev@googlegroups.com  on behalf of 
> Yegappan Lakshmanan 
> Sent: Saturday, August 26, 2023 12:12:35 AM
> To: vim_dev@googlegroups.com 
> Subject: Re: Vim9: Default object member access
>
> Hi,
>
> On Fri, Aug 25, 2023 at 9:01 AM shane qian  wrote:
> >
> > the default perhaps was `protect`, since looks default it cannot be 
> > accessed out of pkg.
> >
> > I think another bram's comment in another github issue ticket (I cannot 
> > open that google link) had
> > showed his preference which is using `private` keyword vs not magic leading 
> > underscore.
> >
>
> Currently the name of private object member variables are prefixed
> with an underscore and
> the keyword "private" is not used.  If we use the "private" keyword
> for private object methods,
> then it will be different from object member variables.
>
> To keep them symmetric, either we should support the "private" keyword
> for both the private
> member variables and private methods or support the underscore for both of 
> them.
>
> Regards,
> Yegappan
>
> > --
> > shane.xb.qian
> >
> > 
> > From: vim_dev@googlegroups.com  on behalf of 
> > Yegappan Lakshmanan 
> > Sent: Friday, August 25, 2023 9:50:28 PM
> > To: vim_dev 
> > Subject: Vim9: Default object member access
> >
> > Hi all,
> >
> > From the email thread
> > https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
> > and the following items in the todo.txt file:
> >
> >   - Change access: public by default, private by prefixing "_".
> > Check for error: can't have the same name twice (ignoring "_" 
> > prefix).
> >
> > This is not yet implemented.  We cannot change this after releasing Vim 9.1.
> > Should we make this change now?
> >
> > 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/CAAW7x7kp9y8nFqRKQ-fGK-AQxScTudndaMpm%3Df5QC3nsi-xQxw%40mail.gmail.com.

Re: Vim9: Default object member access

[Yegappan Lakshmanan]

Hi,

On Fri, Aug 25, 2023 at 9:01 AM shane qian  wrote:
>
> the default perhaps was `protect`, since looks default it cannot be accessed 
> out of pkg.
>
> I think another bram's comment in another github issue ticket (I cannot open 
> that google link) had
> showed his preference which is using `private` keyword vs not magic leading 
> underscore.
>

Currently the name of private object member variables are prefixed
with an underscore and
the keyword "private" is not used.  If we use the "private" keyword
for private object methods,
then it will be different from object member variables.

To keep them symmetric, either we should support the "private" keyword
for both the private
member variables and private methods or support the underscore for both of them.

Regards,
Yegappan

> --
> shane.xb.qian
>
> ____
> From: vim_dev@googlegroups.com  on behalf of 
> Yegappan Lakshmanan 
> Sent: Friday, August 25, 2023 9:50:28 PM
> To: vim_dev 
> Subject: Vim9: Default object member access
>
> Hi all,
>
> From the email thread
> https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
> and the following items in the todo.txt file:
>
>   - Change access: public by default, private by prefixing "_".
> Check for error: can't have the same name twice (ignoring "_" prefix).
>
> This is not yet implemented.  We cannot change this after releasing Vim 9.1.
> Should we make this change now?
>
> 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/CAAW7x7mXbp71Omn3957S-fYFy1zwfbqGY%3D8h5CXqphQUQ%3DST0A%40mail.gmail.com.
>
> --
> --
> 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/OS3P286MB09131F1A2FAB712AF41FCD3DEBE3A%40OS3P286MB0913.JPNP286.PROD.OUTLOOK.COM.

-- 
-- 
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/CAAW7x7kNDAiYdvf2Brv0180rSwq_F-VhWzPCvyiKGU8j0fBibA%40mail.gmail.com.

Vim9: Default object member access

[Yegappan Lakshmanan]

Hi all,

>From the email thread
https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
and the following items in the todo.txt file:

  - Change access: public by default, private by prefixing "_".
Check for error: can't have the same name twice (ignoring "_" prefix).

This is not yet implemented.  We cannot change this after releasing Vim 9.1.
Should we make this change now?

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/CAAW7x7mXbp71Omn3957S-fYFy1zwfbqGY%3D8h5CXqphQUQ%3DST0A%40mail.gmail.com.

Re: Support for Private class/object methods

[Yegappan Lakshmanan]

Hi,

On Thu, Aug 24, 2023 at 9:11 PM Doug Kearns  wrote:
>
> On Fri, 25 Aug 2023 at 13:18, Yegappan Lakshmanan  wrote:
>>
>> Hi all,
>>
>> The following item is in the todo.txt file for implementing private
>> methods in a class:
>>
>>  - Private methods?
>> either: private def Func()
>> or: def _Func()
>> Perhaps use "private" keyword instead of "_" prefix?
>>
>> Function and method names always start with an uppercase letter.  So
>> if we use the
>> "_" prefix for a private method name then it will diverge from that. So I 
>> have
>> implemented this using the "private" keyword.
>>
>> Any opinions?
>
>
> Thanks very much for keeping the ball rolling on this.
>
> For others, there was some previous discussion[1] about it on the list when 
> Bram asked for opinions.
> My recollection is that both you and he were in favour of the "_" prefix for 
> call-site identification purposes?
>

Yes.

>
> My personal preference would be for the modifier keyword with a symmetric, 
> even if possibly redundant, "public".
>  I think this is justifiable on the grounds of it meeting the "less weird" 
> requirement for Vim9 script.
>  While I'm sure there are others, JavaScript is the only language I can think 
> of off the top of my head
> that defaults to public and uses a sigil for private access.
>

Thanks for forwarding the email thread.  I totally forgot about that
discussion.  It is unfortunate
there was no conclusion at the end of that thread that we can refer to.

Regards,
Yegappan

> Thanks again,
> Doug
>
> 1.  https://groups.google.com/g/vim_dev/c/yYpFNUHdRho/m/xjgrKqMoBQAJ?pli=1
>
>

-- 
-- 
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/CAAW7x7%3DanbqeJ9MjoZyP71zsXYPP5bT7%2BQwTB2E0JXvAaj%3DTFQ%40mail.gmail.com.

Re: Support for Private class/object methods

[Yegappan Lakshmanan]

Hi,

On Thu, Aug 24, 2023 at 8:50 PM Ernie Rael  wrote:
>
> On 23/08/24 8:18 PM, Yegappan Lakshmanan wrote:
> > Hi all,
> >
> > The following item is in the todo.txt file for implementing private
> > methods in a class:
> >
> >   - Private methods?
> >  either: private def Func()
> >  or: def _Func()
> >  Perhaps use "private" keyword instead of "_" prefix?
> >
> > Function and method names always start with an uppercase letter.  So
> > if we use the
> > "_" prefix for a private method name then it will diverge from that.
>
> That's mostly a parsing issue? The requirement becomes _[A-Z] means private.
>

Yes. It is a parsing issue.  Using the "_" prefix for both private members
and methods will make it symmetric though.

>
> >   So I have
> > implemented this using the "private" keyword.
>
> Can "private" be used with members, in addition to prefixing "_"?
>

We can make changes to support the "private" keyword for members also.


>
> > Any opinions?
> I'm personally OK with "private", and happy to avoid the parsing
> hassles. Would like to see it usable with class/instance members.
>

Let me see whether we can support using the "_" prefix for private methods.

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/CAAW7x7%3DcCempeBm2aW%3DP6%3DyjWdYTVJ_w8bXNZyfor6OuiiwB9g%40mail.gmail.com.

Support for Private class/object methods

[Yegappan Lakshmanan]

Hi all,

The following item is in the todo.txt file for implementing private
methods in a class:

 - Private methods?
either: private def Func()
or: def _Func()
Perhaps use "private" keyword instead of "_" prefix?

Function and method names always start with an uppercase letter.  So
if we use the
"_" prefix for a private method name then it will diverge from that. So I have
implemented this using the "private" keyword.

Any opinions?

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/CAAW7x7nGpgMAmCyMkezRJxFKJyEtujmmhBn1rOShnb2sx4%3D4Tg%40mail.gmail.com.

Re: Updates on the Vim project

[Yegappan Lakshmanan]

Hi Christian,

On Wed, Aug 23, 2023 at 1:18 PM Christian Brabandt  wrote:
>
> Hi,
> this is a small update over what happened the last few weeks.
>
> Over the last days, I have been merging mostly runtime file changes,
> small improvements to the Vim9 class implementations and bug fixes.
>

Thanks.

>
> If you check the Milestone¹ for the release 9.1, most of the remaining
> changes are small runtime changes, for which I'd like to get an
> ACK/NACK.
>
> Thanks for all your contributions, this is really appreciated!
>
> I am not sure, what the status of the Vim9 classes implementation is and
> if we are going to get further improvements there or if we can consider
> this "good enough".
>
> @Yegappan, what is your opinion?
>

There are still several todo items related to Vim9 classes.  But I
think it is usable
for simple plugins.  We can keep improving the support after the 9.1 release.

The https://github.com/vim/vim/pull/12890 PR should be merged.  I also
found another
minor issue and will open a PR for that.

Regards,
Yegappan

>
> If you are a runtime file maintainer, or you have been providing
> translations, now it's time to check your runtime files against the
> version in the Vim repository and please consider sending updated files.
>
> I also checked the huntr organization, but it looks like there are no
> open security issues reported over there.
>
> On a somewhat related note, I have been asked how to handle security
> issues in the future and I am thinking about creating a "private" list
> for this. Not sure how to handle packagers or if it is good enough, if I
> mark commits/mails with some security related flag.
>
> Regarding the vim Homepage, I'll move it to a new hoster after the
> release has been done. I got several offers so that should not be a
> problem.  I'll also need to check the amount of work to migrate the old
> php5 code to an updated php version.
>
> Regarding the ftp server, I decided to no longer use it. I checked with
> the owners and while they were willing to help, I come to the conclusion
> that it stems from an old time and it no longer required, so I will not
> update the data there.  I may however need to download the generated
> spell files and move this to the new Vim Homepage, once it has been
> moved.
>
> For a similar reason and because of the mess I created with the
> mercurial mirror, I am thinking to retire the mercurial repository. I
> think it is pretty clear that nowadays git is the preferred VCS of
> choice for most programmers.
>
> Let me know, what you all think.

-- 
-- 
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/CAAW7x7%3DQwXB1K5Mf%2BeK_DTyakOJt3H7bpNNSrKFSm505aNRqYw%40mail.gmail.com.

Re: Commit: runtime(dosini): save and restore cpo value in syntax script

[Yegappan Lakshmanan]

Hi Christian,

On Sun, Aug 20, 2023 at 10:51 PM Christian Brabandt  wrote:
>
>
> On So, 20 Aug 2023, Yegappan Lakshmanan wrote:
>
> > On Sun, Aug 20, 2023 at 10:00 PM Christian Brabandt  
> > wrote:
> > > runtime(dosini): save and restore cpo value in syntax script
> >
> > A similar change is needed in the runtime/syntax/context.vim file also.
> >
> > I used the following command to find this:
> >
> > $ cd vim/runtime/syntax
> > $ egrep '^ +\\'  `grep -L cpo *.vim`
>
> Oh but that is using vim9script. Does that make a difference?
>

Yes.  I missed that it is written in vim9script.  In that case, 'cpo'
need not be set and modified.

Regards,
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/CAAW7x7nyPTLsNCN9FiiOeKTO-2ns3RBg5SLOkoyd8WUvGCa-NQ%40mail.gmail.com.

Re: Commit: runtime(dosini): save and restore cpo value in syntax script

[Yegappan Lakshmanan]

Hi,

On Sun, Aug 20, 2023 at 10:00 PM Christian Brabandt  wrote:
>
> runtime(dosini): save and restore cpo value in syntax script
>

A similar change is needed in the runtime/syntax/context.vim file also.

I used the following command to find this:

$ cd vim/runtime/syntax
$ egrep '^ +\\'  `grep -L cpo *.vim`

Regards,
Yegappan

> Commit: 
> https://github.com/vim/vim/commit/690963924956d800b94bb86076aa9d25f04565ac
> Author: Christian Brabandt 
> Date:   Mon Aug 21 06:49:38 2023 +0200
>
> runtime(dosini): save and restore cpo value in syntax script
>

-- 
-- 
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/CAAW7x7kA%2B%2BEMLx7Gc1TNHPLD%3DjPK8M3Uk2Dp1ULnSMYMRjAe5Q%40mail.gmail.com.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi Rob,

On Sun, Aug 20, 2023 at 8:27 PM Robert Webb  wrote:
>
> Wow, very sad to hear about Bram, and so young (62).  I did quite a lot of
> work on vim more than 30 years ago.  At first I didn't even have my own
> computer.  Sometimes I'd print out code at work, take it home, write new code
> on paper, then try it out after hours at uni or work.  Now I barely have time
>

Thanks for your contributions to Vim.  As a Vim user, I still remember eagerly
waiting for the release of the GUI version of Vim on MS-Windows back in 1997-98.

Regards,
Yegappan

> for my own projects.  I'm still on some vim mailing lists, but they forward
> to a folder I rarely look at.  Just noticed I have 34,439 unread messages in
> that folder!  So I only just heard about Bram.  He was always great to
> communicate with, and did such a great job with vim.  Many thanks to those
> who will carry on the flame.
>
> Rob.
>
> On Wed, 9 Aug 2023 at 05:36, Doug Kearns  wrote:
>>
>> On Wed, 9 Aug 2023 at 04:52, Christian Brabandt  wrote:
>>>
>>>
>>> On Mi, 09 Aug 2023, Doug Kearns wrote:
>>>
>>> > Runtime file updates often include test updates (e.g., filetype detection 
>>> > tests) and changes to runtime infrastructure (e.g., runtime/ftplugin.vim) 
>>> > are also arguably worth a version bump.
>>> >
>>> > Bram's distinction here actually makes a lot of sense but may, I 
>>> > understand, not be tenable.
>>>
>>> Yes indeed. So https://github.com/vim/vim/issues/12722 shall increase the 
>>> minor or not?
>>
>>
>> In an ideal world I think file type detection improvements like this should 
>> get a bump.  It feels like core functionality and is tested by the main test 
>> suite.
>>
>> Regards,
>> Doug
>>

-- 
-- 
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/CAAW7x7k_T6%3DMQS-C%2BSvQo0s-SPyy%2BU8QuDQ_juoeqDDLg2svwA%40mail.gmail.com.

Re: Commit: patch 9.0.1771: regex: combining chars in collections not handled

[Yegappan Lakshmanan]

Hi Christian,

On Sun, Aug 20, 2023 at 11:45 AM Christian Brabandt  wrote:
>
> patch 9.0.1771: regex: combining chars in collections not handled
>
> Commit: 
> https://github.com/vim/vim/commit/ca22fc36a4e8a315f199893ee8ff6253573f5fbe
> Author: Christian Brabandt 
> Date:   Sun Aug 20 20:34:22 2023 +0200
>
> patch 9.0.1771: regex: combining chars in collections not handled
>

The CI tests started failing after this commit with the following errors:

>From test_regex_char_classes.vim:
Found errors in Test_s_search():
Caught exception in Test_s_search(): Vim(substitute):E875: (NFA
regexp) (While converting from postfix to NFA), too many states left
on stack @ command line..script
D:/a/vim/vim/src/testdir/runtest.vim[601]..function
RunTheTest[54]..Test_s_search[2]..RunSTest, line 3
Found errors in Test_x_search():
Caught exception in Test_x_search(): Vim(call):E875: (NFA regexp)
(While converting from postfix to NFA), too many states left on stack
@ command line..script
D:/a/vim/vim/src/testdir/runtest.vim[601]..function
RunTheTest[54]..Test_x_search[16]..RunXTest, line 3

Regards,
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/CAAW7x7kTT%3DTNyYPPC0Uzgykm4%3DKu9afYL8ud4Wbm%2B9tFA7VibQ%40mail.gmail.com.

Re: vim9class, getting it usable

[Yegappan Lakshmanan]

On Fri, Aug 18, 2023 at 8:22 PM Yegappan Lakshmanan  wrote:
>
> Hi,
>
> On Fri, Aug 18, 2023 at 8:21 PM Ernie Rael  wrote:
> >
> > Hi all,
> >
> > Working on a project Feb/Mar using vim9 classes I filed several issues. 
> > Each time found a workaround, and went on. Finally ran into
> >
> > https://github.com/vim/vim/issues/12089
> > vim9class: Calling a base class method through an extending class fails 
> > #12089
> >
> > Also included "Calling a method in an extended class fails" (fixed a few 
> > days ago)
> >
>
> I have been working on this and have a fix for this.  I will create a
> PR for this.
>

Created the PR https://github.com/vim/vim/pull/12848 to fix this.

Regards,
Yegappan

>
> > Put the project back on the shelf, didn't make sense to go on without 
> > inheritance. I wonder if it's worth doing 9.1 if classes (inheritance) 
> > doesn't work.
> >
> > Took a quick look at the code in Apr/May, but seemed like too much to take 
> > on at the time. Thinking again about moving forward, however slowly, the 
> > first thing I thought to do is add some debug commands to vim that would 
> > dump class and hierarchy information; adding to the commands as more 
> > information was needed. Even the basic structure isn't clear to me and how 
> > it evolves to compilation/run-time. The examples in the issue referenced 
> > above work at script level, fail in a :def. Does this mean the basic class 
> > hierarchy structures are interpreted from script and then combined into 
> > some structures that are used by the compiler, are the structures also used 
> > during runtime. Anyway, I was encourages to see @yegappan get some things 
> > fixed in this area.
> >
> > I'm not sure how I can best contribute (or, as goes without saying, how 
> > much time I'll have). The biggest problem is it looks like a steep learning 
> > curve. Looking for any suggestions on getting up to speed enough to 
> > contribute.
> >
> > -ernie
> >
> > PS I went with here, rather than discussion. Right choice?
> >

-- 
-- 
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/CAAW7x7k6%2BnNuBBXu1jyCV13qaDH_FRVGo-cZwfPLs%2BkCDQ7gPg%40mail.gmail.com.

Re: vim9class, getting it usable

[Yegappan Lakshmanan]

Hi,

On Fri, Aug 18, 2023 at 8:21 PM Ernie Rael  wrote:
>
> Hi all,
>
> Working on a project Feb/Mar using vim9 classes I filed several issues. Each 
> time found a workaround, and went on. Finally ran into
>
> https://github.com/vim/vim/issues/12089
> vim9class: Calling a base class method through an extending class fails #12089
>
> Also included "Calling a method in an extended class fails" (fixed a few days 
> ago)
>

I have been working on this and have a fix for this.  I will create a
PR for this.

Regards,
Yegappan

> Put the project back on the shelf, didn't make sense to go on without 
> inheritance. I wonder if it's worth doing 9.1 if classes (inheritance) 
> doesn't work.
>
> Took a quick look at the code in Apr/May, but seemed like too much to take on 
> at the time. Thinking again about moving forward, however slowly, the first 
> thing I thought to do is add some debug commands to vim that would dump class 
> and hierarchy information; adding to the commands as more information was 
> needed. Even the basic structure isn't clear to me and how it evolves to 
> compilation/run-time. The examples in the issue referenced above work at 
> script level, fail in a :def. Does this mean the basic class hierarchy 
> structures are interpreted from script and then combined into some structures 
> that are used by the compiler, are the structures also used during runtime. 
> Anyway, I was encourages to see @yegappan get some things fixed in this area.
>
> I'm not sure how I can best contribute (or, as goes without saying, how much 
> time I'll have). The biggest problem is it looks like a steep learning curve. 
> Looking for any suggestions on getting up to speed enough to contribute.
>
> -ernie
>
> PS I went with here, rather than discussion. Right choice?
>

-- 
-- 
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/CAAW7x7nRP9MU4FGhR%3D4S62yHQk8xR00KCxUG-ZDDus%3DYBE-h1g%40mail.gmail.com.

PRs for the Vim 9.1 release milestone

[Yegappan Lakshmanan]

Hi all,

Most of the outstanding PRs are now either assigned to the vim-9.1 milestone or
to the backlog:

https://github.com/vim/vim/milestone/1
https://github.com/vim/vim/milestone/2

If you think a PR should be or should not be part of these milestones,
let us know.

The criteria for the vim-9.1 milestone PRs are:

1. Fix for a Vim crash.
2. Security vulnerability fix.
3. Coverity analysis fix.
4. Fix for a bug in an existing feature.
5. Runtime file update.
6. Minor new feature.

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/CAAW7x7%3DU3AEfLTsEdGA4y1fZz%3DDJekbLQPA6Yg%3DNxppXPOvb-w%40mail.gmail.com.

CI Linux tests are failing

[Yegappan Lakshmanan]

Hi,

The CI Linux tests are failing for the past few days due to missing
linux-modules-extra-5.15.0-1042-azure package.

Should we disable the sound tests temporarily and disable the installation
of this package?

Regards,
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/CAAW7x7nf37eRxgbDf19G2B6MJWAVOCwq6KPO4d6JqAgoiu4MEQ%40mail.gmail.com.

Re: Surprising test failure after rebasing PR

[Yegappan Lakshmanan]

Hi,

On Mon, Aug 14, 2023 at 6:39 PM Ernie Rael  wrote:
>
> Bunch of failures, all of them
>
> Set up snd-dummy
> E: Package 'linux-modules-extra-5.15.0-1042-azure' has no installation 
> candidate
>
> I see this after rebasing and pushing two PR's.
>
> Is there something I need to do?
>

No.  We started seeing these failures for the past few days.

Regards,
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/CAAW7x7kyUZUvQW42jDDV%3DT0Q%3D6Vz9kHLGr4-T5K_TvtDgp263A%40mail.gmail.com.

Re: The future of the Vim project

[Yegappan Lakshmanan]

Thanks Christian for putting this together.

On Wed, Aug 9, 2023 at 3:12 AM Christian Brabandt  wrote:
>
> Hi,
> I started making a few changes to continue with Vim. This is the current
> status:
>
> - Access to the github organization is possible and Ken and me have been
>   granted admin rights by Brams family, so we can continue with Github.
>   (Thanks @Fokke!)
>
> - I invited a few more members to join the Vim organization: Yegappan
>   Lakshmanan, Dominique Pellé, @mattn and @zeertzjq who have been
>   contributed to Vim in the past. Congratulations and welcome guys! ;)
>

Thanks.

>
> - People from the github organization should also have access to
>   huntr.dev (https://huntr.dev/repos/vim/vim/) where security problems
>   are being reported. We'll need to take a look there.
>
> - I merged the first 2 commits. As mentioned elsewhere, for now I will
>   try to merge only bug fixes, security related fixes, documentation
>   updates and other clear improvements. For the main source of Vim I'll
>   therefore like to have approval from the other project members before
>   merging anything yet. Please expect some bumps here, we need a bit of
>   time until we know how to properly handle all of this (and it may be
>   subject to change, when we all agree of a better method).
>

Should we look at the outstanding PRs and tag which ones are possible
candidates for the 9.1 release?

>
> - After we have gone through the current backlog, I'd like to get a Vim
>   9.1 maintenance release ready, until then we should continue with
>   incrementing the minor patch version. After the release, I am thinking
>   about moving to a more modern approach, similar to how Neovim is doing
>   it. But as discussed elsewhere, this may have some consequences for
>

Agreed.  This is a more scalable approach.

Regards,
Yegappan

>
>   the various subprojects: vim-win32-installer, vim-appimage, macVim, so
>   not sure what will be the best way.
>
> - I have access to the OSDN.net project page and am able to edit the
>   vim.org homepage. However for various reasons, we may have to move the
>   Vim homepage elsewhere. More on that further down.
>
> - Bram was owner of the all of the mailing lists. I don't know yet how
>   he managed this and how to request access specifically for
>   vim-announce and vim-mac (is this actually still used?) Does anybody
>   have a contact to the googlegroups admins?
>
> - The mailing lists vim-dev and vim-use are currently managed by myself,
>   Tony Mechelynk, John Beckett, Ben Schmidt and Ben Fritz (of whom I
>   think the last two are no longer active at least for the Vim project,
>   CC'ing them to see if they are still interested in managing this)
>
> - The Vim Domain is managed by @sec (CC'ed). Can you please confirm, you
>   will be taking care of extending the domains (I think this is vim.org,
>   vim8.org, vim9.org and possibly iccf-holland.org)?
>
> - I don't have access yet to the main Vim FTP Server. Currently checking
>   with Brams family if they know the credentials. (CC'ed)
>
> - I am reaching out to all maintainers of the runtime files, to find out
>   if they have sent anything directly to Bram, which may otherwise be
>   lost. (to be done).
>
> Regarding the Vim Homepage, as you may all know, we have had problems
> with the stability of it for the past months, in particular the
> connection to the MySQL Server (I am also currently unable to access the
> vim project page directly, as osdn.net/projects/vim seems to be down for
> me, but I doubt that this page is actually being used by anybody). It is
> currently run by OSDN.net as offered by Shuji Sado (former CEO) since
> 2018. Unfortunately, OSDN.net is apparently now being owned by OSChina
> and we currently do not have any support by OSDN.net or OSChina teams.
> @Shuji, thank you for maintaining the Vim Website since 2018 and all the
> best for the future!
>
> I've reached out to OSChina regarding what their plans are, but haven't
> received any answers yet. Therefore I am also considering to move the
> Vim homepage to another provider. A good friend of mine, Marc Schöchlin
> offered to take care of the hosting. The Vim project is very thankful
> for the kind offer!
>
> Please note: This is just a consideration however, nothing has been
> decided yet.
>
> The hosting consists of the following:
> - PHP Files with access to a MySQL Database. I think it is currently
>   using PHP 5, which seems to have reached end-of-life.
> - Vims Source in form of a Mercurial repository (which is mirrored from
>   https://hg.256bit.org/vim). Is anybody actually using the mercurial
>   repository (except for Tony ;)) ?
> - Sourceforge (where the vim homepage was hosted until 201

Re: Patch patch 9.0.1679: Cleanup Tests from leftover files

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 8, 2023 at 12:57 PM Christian Brabandt  wrote:
>
>
> On Di, 08 Aug 2023, Christian Brabandt wrote:
>
> > patch 9.0.1679: Cleanup Tests from leftover files
>
> Sorry, trying to get the patch mails working.
>
> While this seems to fix the recent CI test failures about the file
> Xcrypt_sodium_v2.txt now I am seeing sodium_mlock() failures. I don't
> know yet why this happens :(
>

The git log commit message for this patch has a lot of details.  Bram
used to mention
a short description of the problem and the solution in the commit log.
Should we follow
that model going forward?

Regards,
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/CAAW7x7mx8NrvNeY5qYB%3D_BzMW5SCv%2BF5x8BDKWOiAjrBkKs12Q%40mail.gmail.com.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 8, 2023 at 8:39 AM Yegappan Lakshmanan  wrote:
>
> Hi Dominique,
>
> On Mon, Aug 7, 2023 at 1:12 PM Dominique Pellé
>  wrote:
> >
> > Yegappan Lakshmanan wrote:
> >
> > > Hi all,
> > >
> > > I am listing the tasks that Bram used to do for developing and maintaining
> > > Vim below (as far I can remember):
> > >
> > > 1. Developing fixes for Vim crash reports including the analysis of
> > >fuzzy test files.
> > > 2. Addressing reported security vulnerabilities including those reported
> > >in https://huntr.dev/repos/vim/vim.  I think various Linux
> > >distribution maintainers report these issues directly to Bram.
> > > 3. Fixing Coverity warnings reported in
> > >https://scan.coverity.com/projects/vim
> > > 4. Fixing CI build breakages including ASAN errors.
> > > 5. Create patches based on pull requests from Vim contributors
> > >(including updating the patches to match the Vim coding style and
> > >perform minor refactoring).
> > > 6. Developing major new features (e.g. Vim9 script, virtual text, etc.)
> > > 7. Reproducing the reported issues and developing fixes for those
> > >issues.
> > > 8. Improving the test infrastructure.  For example, he recently
> > >incorporated coding style checks and the support for syntax
> > >highlighting checks.
> > > 9. Incorporating the runtime file updates (e.g. syntax files, file
> > >types, etc.)
> > > 10. Updating the Vim documentation based on discussions and pull
> > > requests.
> > > 11. Maintaining the todo.txt file to track the roadmap for features and
> > > fixes.
> > > 12. Responding to questions and discussions in the Vim-dev mailing list.
> > > 13. Updating the vim.org website with news.
> > > 14. Preparing and making Vim releases (maybe once a year).
> > >
> > > Regards,
> > > Yegappan
> >
> > Thanks Yegappan for this list.
> >
> > About point #2 i.e. "Addressing reported security
> > vulnerabilities including those reported in https://huntr.dev/repos/vim/vim;
> > I never looked at this, as I thought only Bram had
> > access to bug reported there for security reasons.
> > But if I can have access (?) I would be interested in:
> > - minimizing crash fuzzing POC
> > - and attempting to fix them
> >
>
> I am able to view all the reports and the discussions.  Are you able
> to view them?
>
> >
> > About point #9 i.e. "Incorporating the runtime file updates"
> > I've always found it odd that some changes were split into
> > a commit in src and another commit later in runtime. It
> > often caused confusion, with PR author asking "part of
> > my change was not included?!" and the response being
> > "it will be in the next runtime update". Perhaps that's
> > something worth revisiting?
> >
>
> Yes. I think we should move the PR model for the runtime file updates.
>

I am not suggesting a separate minor release for each runtime file update here.
Otherwise, we will have too many minor releases.  Can we make a minor release
only for PRs that change the C code and not the runtime files (still
merge the runtime
changes as separate PRs)?

Regards,
Yegappan

>
> > In fact, this happened to my last PR at
> > https://github.com/vim/vim/pull/12544/files
> > where only part of it was merged and the
> > remaining part was meant to be in the next
> > runtime update, which sadly never happened.
> > I'll create a PR when I have time for what went
> > missing.
> >
> > There might also be other unrelated changes
> > which were pending in the next runtime update
> > that never happened. Often Bram responded
> > with "I'll include it" when people reported
> > corrections to the docs for example.
> >
> > Regards
> > Dominique
> >

-- 
-- 
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/CAAW7x7kct3BmGbJYkM290dfFYvf-CFkv5BP0f-kuSMzn%3DDGB6Q%40mail.gmail.com.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi Dominique,

On Mon, Aug 7, 2023 at 1:12 PM Dominique Pellé
 wrote:
>
> Yegappan Lakshmanan wrote:
>
> > Hi all,
> >
> > I am listing the tasks that Bram used to do for developing and maintaining
> > Vim below (as far I can remember):
> >
> > 1. Developing fixes for Vim crash reports including the analysis of
> >fuzzy test files.
> > 2. Addressing reported security vulnerabilities including those reported
> >in https://huntr.dev/repos/vim/vim.  I think various Linux
> >distribution maintainers report these issues directly to Bram.
> > 3. Fixing Coverity warnings reported in
> >https://scan.coverity.com/projects/vim
> > 4. Fixing CI build breakages including ASAN errors.
> > 5. Create patches based on pull requests from Vim contributors
> >(including updating the patches to match the Vim coding style and
> >perform minor refactoring).
> > 6. Developing major new features (e.g. Vim9 script, virtual text, etc.)
> > 7. Reproducing the reported issues and developing fixes for those
> >issues.
> > 8. Improving the test infrastructure.  For example, he recently
> >incorporated coding style checks and the support for syntax
> >highlighting checks.
> > 9. Incorporating the runtime file updates (e.g. syntax files, file
> >types, etc.)
> > 10. Updating the Vim documentation based on discussions and pull
> > requests.
> > 11. Maintaining the todo.txt file to track the roadmap for features and
> > fixes.
> > 12. Responding to questions and discussions in the Vim-dev mailing list.
> > 13. Updating the vim.org website with news.
> > 14. Preparing and making Vim releases (maybe once a year).
> >
> > Regards,
> > Yegappan
>
> Thanks Yegappan for this list.
>
> About point #2 i.e. "Addressing reported security
> vulnerabilities including those reported in https://huntr.dev/repos/vim/vim;
> I never looked at this, as I thought only Bram had
> access to bug reported there for security reasons.
> But if I can have access (?) I would be interested in:
> - minimizing crash fuzzing POC
> - and attempting to fix them
>

I am able to view all the reports and the discussions.  Are you able
to view them?

>
> About point #9 i.e. "Incorporating the runtime file updates"
> I've always found it odd that some changes were split into
> a commit in src and another commit later in runtime. It
> often caused confusion, with PR author asking "part of
> my change was not included?!" and the response being
> "it will be in the next runtime update". Perhaps that's
> something worth revisiting?
>

Yes. I think we should move the PR model for the runtime file updates.

Regards,
Yegappan

> In fact, this happened to my last PR at
> https://github.com/vim/vim/pull/12544/files
> where only part of it was merged and the
> remaining part was meant to be in the next
> runtime update, which sadly never happened.
> I'll create a PR when I have time for what went
> missing.
>
> There might also be other unrelated changes
> which were pending in the next runtime update
> that never happened. Often Bram responded
> with "I'll include it" when people reported
> corrections to the docs for example.
>
> Regards
> Dominique
>

-- 
-- 
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/CAAW7x7kxatPYJDCCo4wE2LW8PTSUjcbEZWX2_FDuC6bR4nfKKA%40mail.gmail.com.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi,

On Tue, Aug 8, 2023 at 8:18 AM Doug Kearns  wrote:
>
> On Tue, 8 Aug 2023 at 06:12, Dominique Pellé  
> wrote:
>
> 
>
>> About point #9 i.e. "Incorporating the runtime file updates"
>> I've always found it odd that some changes were split into
>> a commit in src and another commit later in runtime. It
>> often caused confusion, with PR author asking "part of
>> my change was not included?!" and the response being
>> "it will be in the next runtime update". Perhaps that's
>> something worth revisiting?
>
>
> I assume you're aware of how it worked but for others, user-maintained
> runtime file additions and updates didn't receive a patch number and
> were batched in a periodic "Update runtime files" commit.  However,
> any related changes to the core runtime like filetype detection were
> committed separately with priority as these did receive a patch
> number.
>
> I discussed this with Bram a couple of times over the years and the
> distinction was intentional.  I don't have a strong view on it but I
> agree that it's quite confusing for new and casual contributors.
>

I think Bram followed this approach to minimize the number of commits with
small changes to the runtime files.  This was the model followed before the
Vim source moved to github.

I think we can move to the PR model for runtime file changes to attribute
the changes to the proper author and to encourage more participation.
This is one of the points that was frequently brought up in the past in many
forums.

> 
>
>> There might also be other unrelated changes
>> which were pending in the next runtime update
>> that never happened. Often Bram responded
>> with "I'll include it" when people reported
>> corrections to the docs for example.
>
>
> It seems that there hasn't been an update of the user maintained
> runtime files since June 11[1] so there's likely to be a significant
> number of submissions that have been dropped.  For example, Bram
> didn't respond to my last emailed update on July 6.  Perhaps we should
> make a request for these to be resubmitted by PR at some stage.
>

Yes.  Also, there are references in the todo.txt file about many
patches sent directly
to Bram in the past.  All these patches are lost now.

Regards,
Yegappan

> Regards,
> Doug
>
> 1. https://github.com/vim/vim/commit/10e8ff9b26078994cae57c2422b145d37aaf714e
>

-- 
-- 
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/CAAW7x7kZe5cDs9-Giin5dN-AinchQa2oXK_AA8TGHho8AaRisQ%40mail.gmail.com.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi all,

I am listing the tasks that Bram used to do for developing and maintaining
Vim below (as far I can remember):

1. Developing fixes for Vim crash reports including the analysis of
   fuzzy test files.
2. Addressing reported security vulnerabilities including those reported
   in https://huntr.dev/repos/vim/vim.  I think various Linux
   distribution maintainers report these issues directly to Bram.
3. Fixing Coverity warnings reported in
   https://scan.coverity.com/projects/vim
4. Fixing CI build breakages including ASAN errors.
5. Create patches based on pull requests from Vim contributors
   (including updating the patches to match the Vim coding style and
   perform minor refactoring).
6. Developing major new features (e.g. Vim9 script, virtual text, etc.)
7. Reproducing the reported issues and developing fixes for those
   issues.
8. Improving the test infrastructure.  For example, he recently
   incorporated coding style checks and the support for syntax
   highlighting checks.
9. Incorporating the runtime file updates (e.g. syntax files, file
   types, etc.)
10. Updating the Vim documentation based on discussions and pull
requests.
11. Maintaining the todo.txt file to track the roadmap for features and
fixes.
12. Responding to questions and discussions in the Vim-dev mailing list.
13. Updating the vim.org website with news.
14. Preparing and making Vim releases (maybe once a year).

Regards,
Yegappan

On Mon, Aug 7, 2023 at 7:53 AM Christian Brabandt  wrote:
>
> Hi all,
> thanks for all this. As Dominique mentioned, please send future
> contributions (in the order of my preference):
> - create a PR in the Vim github repo
> - Send patches (or full files) to the vim-dev mailinglist
> - continue sending the files to me (I'll handle it as Bram did)
>
> I appreciate all your help suggestions.
>
> Thanks,
> Chris
>

-- 
-- 
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/CAAW7x7%3DBPfZ3%2Bgi6NPrjPWdFxeM7pnCB94%3DCWrK5iP-ygsWa-Q%40mail.gmail.com.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi,

Can someone with the admin access to https://www.vim.org/ update the
"News" section with a
link to the message from Bram's family?

Regards,
Yegappan

On Mon, Aug 7, 2023 at 7:13 AM Antonio Giovanni Colombo
 wrote:
>
> Hi everybody,
>
> I too will miss Bram a lot.
>
> I am a minor contributor to Vim, for the translation of messages. I have been 
> in touch with Bram since the Nineties, and even visited him in Venlo.
>
> I used to send new versions of language related files, like e.g. 
> "src/po/it.po" directly to Bram, who included them in the Vim distribution 
> without the need of patches. Pending further decisions, I will send future 
> modifications of such files to Christian Brabandt. This is not only about me, 
> but about a group of other translators. Bram sometimes sent mail to this 
> group, just before a new version of Vim was in sight.
>
> VALE, Bram! We will try to keep up the good work.
>
> Antonio
>
> Il giorno dom 6 ago 2023 alle ore 21:43 Dominique Pellé 
>  ha scritto:
>>
>> Zoltan Arpadffy wrote:
>>
>> > This is truly shocking - I do not have a word.
>> > I just sent Bram a mail about a week ago - with no answer - when he
>> > replied mails almost immediately in the past 20+ years.
>> >
>> > I am so sad.
>> > My deepest condolences to the family.
>> >
>> > I have been in contact with Bram since 1998 - when I started to work
>> > on the OpenVMS port and I am still maintaining the OpenVMS related
>> > code and distributing the VMS executable packages on
>> > http://polarhome.com/vim/
>> >
>> > I am working on the the patch for Vim 9.0 and for the new x86_64 VMS
>> > port (beside VAX, AXP and IA64)
>> > I have had sent him my patches directly that he merged into the
>> > eleases.
>> >
>> > Ken, Chris could you please instruct me, how can I continue to
>> > contribute > to the Vim development?
>>
>> We're all shocked and feel empty with the loss of Bram.
>>
>> Thanks Zoltan for your contributions to Vim since 1998. That's
>> amazing dedication. For now, I suggest to either send patch
>> attachments to this mailing list, or better if you can, to submit
>> git pull requests. A PR is preferable as CI will run and it makes
>> it easier for people to review contributions. Code reviews were
>> always important, but they have become even more important
>> now the gate-keeper Bram is no longer here.
>>
>> I assume it will take some time before we figure out how to
>> merge changes to the master branch. So PR may stay
>> open for a while. Let's be patient.
>>
>> I will also try to contribute, as much as I can. I fear that some
>> of the Vim internals are hard to maintain without Bram.
>> I hope the community will step up to the challenge and honor
>> Bram's project by continuing its development.
>>
>> Even if I have a personal preference for Vim rather than Neovim
>> for various reasons (no need to go into details as to why here),
>> it's clear that Neovim showed that the community was able to
>> make impressive deep changes to Vim's code. Neovim still
>> depended on Vim and Bram's work to some extent (regularly
>> merging Vim patches). And Neovim was standing on the
>> shoulders of giants by reusing Vim's code. So I hope that
>> some of the Neovim developers can also help continuing
>> the Vim development adventure.
>>
>> Regards
>> Dominique
>>

-- 
-- 
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/CAAW7x7kKtFnLCcUcj90T-pr%2B1%3DHsr5E8mgGBCjNWdY3%2BmxvAOQ%40mail.gmail.com.

Re: Where is Bram?

[Yegappan Lakshmanan]

Hi,

On Sat, Aug 5, 2023 at 9:11 AM Christian Brabandt  wrote:
>
> Am 2023-08-05 16:30, schrieb Yegappan Lakshmanan:
> > On Sat, Aug 5, 2023 at 5:53 AM Maxim Kim  wrote:
> >>
> >> https://groups.google.com/g/vim_announce/c/tWahca9zkt4
> >>
> >
> > I am truly saddened and shocked to hear this news.
> >
> > I have been following him for more than 25 years and have interacted
> > with him for more than 22 years.  He has been an inspiration to me and
> > many others.  He has really changed the world for the better.  He has
> > single handedly improved the productivity of countless developers and
> > companies around the world.  He dedicated his entire life to work on
> > Vim.  His vision and ability to design some of the most complex
> > features
> > (such as the vim9script compiler, spell check, syntax highlighting,
> > channels, tab pages, virtual text, and many others) have always amazed
> > me.
> >
> > We will all miss him deeply. Rest In Peace, Bram, and thank you for
> > everything.
>
>
> As all of you, so was I deeply shocked when I heard the news. Bram was a
> great leader
> to the Vim community and I really enjoyed working with him over the past
> years, since I became
> involved with the development of Vim almost 20 years ago.
>
> Bram was of great inspiration in creating a great community, helping
> people with his charity and
> he was a great mentor. And now he left too soon. We lost a great leader
> and I regret never having
> met him in person...
>
> However to all of the community: I will continue and I hope all of the
> other contributors will
> also keep up the good work. I do have access to the Vim homepage and the
> Vim organization (not sure
> if all the rights, but I am sure we will work on the details in the near
> future.
>
> Once I return from vacation, I'll go through the PRs and review them
> (and also commit the missing
> patch to github). I'll welcome anybody to contribute to make Vim better.
>

Yes.  I will continue to contribute to Vim.  Let me know how I can help.

Regards,
Yegappan

>
> I still don't know all the internals of the various areas (vim9, virtual
> text, syntax highlighting to name
> a few) and I don't know how much time I can dedicate, but I hope
> together we will be able to continue
> successfully.
>

-- 
-- 
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/CAAW7x7%3Dd2CgTP4ZQ-ipdiWYJP%3DU%2BeF6Jr9eAfj6vEMYb4b0ReA%40mail.gmail.com.

Re: Where is Bram?

[Yegappan Lakshmanan]

On Sat, Aug 5, 2023 at 5:53 AM Maxim Kim  wrote:
>
> https://groups.google.com/g/vim_announce/c/tWahca9zkt4
>

I am truly saddened and shocked to hear this news.

I have been following him for more than 25 years and have interacted
with him for more than 22 years.  He has been an inspiration to me and
many others.  He has really changed the world for the better.  He has
single handedly improved the productivity of countless developers and
companies around the world.  He dedicated his entire life to work on
Vim.  His vision and ability to design some of the most complex features
(such as the vim9script compiler, spell check, syntax highlighting,
channels, tab pages, virtual text, and many others) have always amazed
me.

We will all miss him deeply. Rest In Peace, Bram, and thank you for
everything.

- Yegappan

>
> RIP Bram.
>
> On Saturday, August 5, 2023 at 8:18:33 PM UTC+10 tooth pik wrote:
>>
>> i've been wondering the same thing -- my guess was he's in africa again
>>
>> On Sat, Aug 5, 2023 at 12:34 AM Yegappan Lakshmanan  
>> wrote:
>>>
>>> Hi all,
>>>
>>> I haven't seen any emails from Bram to the mailing list for more than a 
>>> month.
>>> Is he on vacation?  Has anyone had any contact with him in the last month?
>>>
>>> Regards,
>>> 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/CAAW7x7kW5pKsYeN2U7Zd40jHmUhzh5Mbf4cuy8nsutVVdGzoqA%40mail.gmail.com.