@tarruda any reason to use on prefix with underscores? why not follow the HTML spec on that matter?

I don't remember if it was discussed before or not, but have you considered using/supporting the already existing Dictionary-Function pattern, i e when a function is defined directly inside a dict, it can access that dict through an implicit self argument:

let mydict = {'data': [0, 1, 2, 3]}
function mydict.len()
   return len(self.data)
endfunction

I don't remember if it was discussed before or not, but have you considered using/supporting the already existing Dictionary-Function pattern, i e when a function is defined directly inside a dict, it can access that dict through an implicit self argument:

Is there a difference from the "user" option? Its already possible to do this:

function s:Handler(id, data, user)
endfunction

call jobstart([..], {'on_stdout': 's:Handler', 'user': {}})

edit: Plus the "user" option allow passing strings, numbers or lists(Is it possible for self to be a non-dict?).

Nothing except consistency with existing vimscript functionality. Not that
I know if theyre actaully used to any extent, but if we're settling for
funcrefs within a dict as callback pattern, there should be an explicit
desicion to either support or deprecate dict-functions.
Den 27 mar 2015 01:01 skrev "Thiago de Arruda" [email protected]:

I don't remember if it was discussed before or not, but have you
considered using/supporting the already existing Dictionary-Function
pattern, i e when a function is defined directly inside a dict, it can
access that dict through an implicit self argument:

Is there a difference from the "user" option? Its already possible to do
this:

function s:Handler(id, data, user)endfunction

call jobstart([..], {'on_stdout': 's:Handler', 'user': {}})

—
Reply to this email directly or view it on GitHub
#2247 (comment).

Nothing except consistency with existing vimscript functionality. Not that
I know if theyre actaully used to any extent, but if we're settling for
funcrefs within a dict as callback pattern, there should be an explicit
desicion to either support or deprecate dict-functions.

I could change the "user" option to "self" and pass it as a implicit self argument, but nothing would stop the user from doing this:

function s:Handler(id, data)
  self.id = 1  " self is available
endfunction

call jobstart([..], {'on_stdout': 's:Handler', 'self': {id: 0}})

Even though s:Handler is not a dictionary function. Also, I don't think there's a way avoid having to pass the "self" function despite using a dictionary function as callback:

let dict = {id: 1}
function dict.handler(id, data)
  echo self.id  " self.id == 0
endfunction

call jobstart([..], {'on_stdout': dict.handler, 'self': {id: 0}})

That is, self will always be what is passed to jobstart, not the dict where the function was defined(unless the vimscript engine "binds" dict.handler to dict, but I don't think thats the case)

Sorry if I'm misunderstanding something and this went completely over my head, but I understood @bfredl's suggestion as something like this:

let dict = {'on_stdout': function("s:Handler"), 'id': 0}
function! s:Handler() dict
    echo self.id
endfunction

call jobstart([..], dict)

Where self is the dictionary passed to jobstart, not a key in that dictionary, so that handler parameters can be stored directly in the dictionary and not passed through the "user" entry. Personally, I think calling the handlers as dictionary functions is a bit more elegant, but the "user" key is valuable in that it provides a separate namespace for parameters and avoids collisions with job-control options.

@bfredl

I know if theyre actaully used to any extent, but if we're settling for funcrefs within a dict as callback pattern, there should be an explicit desicion to either support or deprecate dict-functions.

I use dictionary functions all the time in my plugins – they are one of the rare truly high level Vim script features, allowing OOP type encapsulation of behaviour.

@tarruda

self will always be what is passed to jobstart, not the dict where the function was defined (unless the vimscript engine "binds" dict.handler to dict, but I don't think thats the case)

It doesn't – the behaviour you describe is consistent with what call() does: it binds its optional third argument (which needs to be a Dictionary) to self for the purpose of a dictionary Funcref passed as its first argument. It’s not a perfect solution by a far cry (what in Vim script is?), but I am not sure adding yet another set of Funcref semantics is going to help with that :).

@tarruda I didn't mean introduce yet another semantics for funcref passing, just supporting the existing semantics for calling a function inside a dict, i e if jobstart "was a vimscript function" the following would be expected to work

let handlers = {'myid':'0'}
function handlers.on_stdout(id, data)
    "here self.myid is available
end

function handlers.on_exit(id, data)
    "also here
end

call jobstart(args, handlers)

" separate instance
call jobstart(args, extend(handlers, {'myid':1}))

but as @pgdouyon pointed out, there would be a namespace conflict with the options here, so if this pattern was "actively" supported, there would probably be a separate "handlers" argument/option.

I've refactored to be more friendly with the dictionary pattern. Even with the possible namespace clashes, I think its simpler to reuse the job options object as "self", its not like the user will run out of keys 😄

Implemented the jobwait function which should allow @junegunn to close junegunn/vim-plug#104

Also modified jobsend so that the second argument is optional. If omitted, the job stdin is closed. @bfredl can you verify if this meets #1838 requirements?

@tarruda It does what's required, but enables to crash nvim:

let j = jobopen(["xsel", "-n", "-i"])
call jobsend(j, ["some text"])
call jobsend(j)
call jobsend(j, ["this crashes nvim"])

Also, would it hurt to have separate jobclose ? ( jobsend(j, data); jobsend(j) isn't really self-explanatory)

@bfredl Implemented your jobclose suggestion

I could change the "user" option to "self" and pass it as a implicit self argument, but nothing would stop the user from doing this:

function s:Handler(id, data)
  self.id = 1  " self is available
endfunction

call jobstart([..], {'on_stdout': 's:Handler', 'self': {id: 0}})

If you did not alter code that calls user functions then self is not passed to non-dictionary function even if it was given explicitly by call. Try the following:

function NonDict()
    echo l:
endfunction
function Dict() dict
    echo l:
endfunction
call call('NonDict', [], {}) " echoes {}
call call('Dict', [], {}) " echoes {'self': {}}

Just noted a small discrepancy between jobstart() and termopen(), while the former accepts an argv-list only, the later only accepts a shell command string. Any particular reason for this or wouldn't it make more sense for both functions to accept both formats?

Just noted a small discrepancy between jobstart() and termopen(), while the former accepts an argv-list only, the later only accepts a shell command string. Any particular reason for this or wouldn't it make more sense for both functions to accept both formats?

No reason, it's simply a consequence of how termopen() was extracted from :terminal. For :terminal I think its important to continue using the shell so pipes and other shell features can be used naturally in nvim command line, but termopen should probably be refactored to receive argv like jobstart.

any reason to use on prefix with underscores? why not follow the HTML spec on that matter?

@rainerborene I owe you a retraction: I realize now you were talking about the vimscript "on_stdin", "on_stdout", "on_stderr" keys, not the C source code. Yes, I agree we should avoid underscores in vimscript identifiers, if possible.

I think its important to continue using the shell so pipes and other shell features can be used naturally in nvim command line, but termopen should probably be refactored to receive argv like jobstart.

👍