The current implementation does change the buffer, but the user needs to switch to another window first to see the changes. I'm certain that just changing the buffer the window points to cannot be all there is to it. The do_buffer function is nearly 300 lines long, a good chunk of it is just figuring out what it needs to do based on the arguments, but there is also a lot of cleanup.

I have looked into the implementation of nvim_set_current_buf, but its use of do_buffer assumes that we want to set the buffer in the current window, not just any arbitrary window, so I cannot use its implementation.

As a side-note, nvim_set_current_buf could then be implemented on top of nvim_win_set_buf in VimScript as

function! nvim_set_current_buf(buffer)
    call nvim_win_set_buf(nvim_get_current_win(), a:buffer)
endfunction

Opinions on this by the Neovim maintainers?

I have looked into the implementation of nvim_set_current_buf, but its use of do_buffer assumes that we want to set the buffer in the current window, not just any arbitrary window, so I cannot use its implementation.

For better and worse, a lot of API (and recent vimL functionality) is implemented by changing curwin and/or curbuf, call an existing function that assumes curwin/curbuf, and then restoring the old current values. So I wouldn't be this quick to conclude that do_buffer can't be used.

but the user needs to switch to another window first to see the changes.

Most likely that indirectly runs do_buffer, accidentally doing the necessary fixups.

nvim_set_current_buf, but its use of do_buffer assumes that we want to set the buffer in the current window

Why not set the current window temporarily, then unwind it? That's the usual way. Disabling autocommands etc makes it fast.

For better and worse, a lot of API (and recent vimL functionality) is implemented by changing curwin and/or curbuf, call an existing function that assumes curwin/curbuf, and then restoring the old current values.

Why not set the current window temporarily, then unwind it? That's the usual way.

And for a moment there I though I could get away from Vim's ritualistic code by going to the actual source. It's rituals all the way down, isn't it?

(oops)

Well, the insides can be ugly, but we hide the ugly behind a nice API. Better to get it right before worrying about elegance.

One could change do_buffer to take a buf_T parameter in the future, perhaps.

Well, the insides can be ugly, but we hide the ugly behind a nice API. Better to get it right before worrying about elegance.

You are right. My problem with ritualistic code is that it is easy to miss part of the ritual and have things work fine for the most part, but not always. Take for example the updated code I just pushed, it works well, but the error handling is messed up. Looking at the function, it would have been better if I had just written it straight up in VimScript instead.

function! nvim_win_set_buf(win, buf)
    let old_win = nvim_get_current_win();
    call nvim_set_current_win(a:win)
    call nvim_set_current_buf(a:buf)
    call nvim_set_current_win(old_win)
endfunction

I had hoped that writing this directly in the source would avoid triggering fifty side effects from switching windows, but that would require digging even deeper into Neovim's core code and going down to the bare bytes. At this point I'm not sure if there is even a point in continuing with this anymore.

I had hoped that writing this directly in the source would avoid triggering fifty side effects from switching windows, but that would require digging even deeper into Neovim's core code and going down to the bare bytes. At this point I'm not sure if there is even a point in continuing with this anymore.

No need to be so defeatist this quickly. "Ritual" or not, other API functions have managed to avoid filthy side effects without too much raw byte banging. If we look at nvim_win_set_option (the arguably most side effect-full operation so far), and dig into the implementation in api/private/helpers.c, we find that it uses switch_win/restore_win, which is purposely built for this save/restore situation. It will probably work better that goto_tabpage_win which does implement user visible switching, and indeed would be equivalent to the vimscript visible functions.

@bfredl You are right, I guess I'm just in a bad mood and threw in the towel too early. switch_win/restore_win seems to do the trick, looking for comments on my implementation.

Much better! Just needs a couple tests and address the TODO. Might want to add another sentence or two in the docstring explaining the motivation or an example.

I noticed something weird:

" There are two windows: 1000 and 1001, I am in window 1001 at the moment
call nvim_win_set_option(1000, 'stl', 'Hello world')
" The above changes the status line in the other window, as expected
call nvim_win_set_buf(1000, 2)
" The above changes the buffer, as expected

Now both windows show the same status line. Switching back to the original buffer restores my Hello world status line. It is as if the option is local to the buffer, not the window. Is this correct? The same happens if I stay inside the window I want to change and use nvim_set_current_buf().

Just needs a couple tests and address the TODO.

Sure thing, I just wanted to get this to work before applying the polish. What should be the API level? 6?

It is as if the option is local to the buffer, not the window. Is this correct?

Not sure. How does it behave with VimL?

What should be the API level? 6?

See NVIM_API_LEVEL in CMakeLists.txt

Not sure. How does it behave with VimL?

That was VimL. Nevermind anyway, I looked into how options are set:

// File src/nvim/private/helpers.c
// Omitting irrelevant code
static void set_option_value_for(char *key,
                                 int numval,
                                 char *stringval,
                                 int opt_flags,
                                 int opt_type,
                                 void *from,
                                 Error *err)
{
  switch (opt_type)
  {
    case SREQ_WIN:
      switch_win(&save_curwin, &save_curtab, (win_T *)from, win_find_tabpage((win_T *)from), false) 
      set_option_value_err(key, numval, stringval, opt_flags, err);
      restore_win(save_curwin, save_curtab, true);
      break;
    case SREQ_BUF:
      switch_buffer(&save_curbuf, (buf_T *)from);
      set_option_value_err(key, numval, stringval, opt_flags, err);
      restore_buffer(&save_curbuf);
      break;
  }
}

There is not really such a thing as a "window-local" option, nvim_win_set_option(n, 'foo', 'bar') is really just nvim_buf_set_option(nvim_win_get_buf(n), 'foo', 'bar').

Note the docs claim statusline is the one and only "global-local window option" (i e it doesn't be have like any other window option), so do expect weird behaviour with it, especially in the API. It seems nvim_win_set_option(1000, 'stl', 'Hello world') also sets the buffer local value, so when you visit the buffer in a new window that hasn't seen the buffer before, the local value gets copied. It might be worth trying with some other window option, like winhl.

It might be worth trying with some other window option, like winhl.

I tried it and I see the same behaviour: the "window-local" options switches along with the buffer. It makes sense if you look at the code in my previous post: in both cases set_option_value_err is called with the same arguments, the only difference is the part of the ritual beforehand and after. For a window we switch to the window in question, thus also switching to its buffer, and for a buffer we switch straight to the buffer in question.

(I hate how Vim as taught me to press CTRL-W to delete the current word, I always end up closing a browser window after having almost finished a post)

Ahyes, it likely behaves like :setl in both cases, but for a window option it should rather work like plain :set, except maybe for stl (which will remain an unhappy child in any case)

I have now written a test for the new function and cleaned up linter complaints. Requesting consideration for merging.

History looks a bit weird. perhaps rebase the latest commit on master?

Is the history better now? GitHub shows all those other commits from master for some reason.

I think you merged instead, which doesn't remove these commits. Reset to
c55287a again and use git rebase -i master. Hopefully it would only show one commit (implement API method), but if the rest remain, just delete those lines.

I followed the instructions, but the history is still messed up. Could it be that I have messed up my master when I did git pull upstream master? I could do

git reset --hard 384770556ba02433904baf78f499b9bb48010040

on the master branch to get back to the last time before my git pull and then do things the right way (whatever the right way might be).

@HiPhish I force-pushed to your branch. I used git merge --squash to get rid of the unnecessary commits:

git checkout upstream/master
git merge --squash refs/pull/upstream/9100
git commit
git push -f https://github.com/HiPhish/neovim HEAD:api-win-set-buf

@justinmk Thank you. What is the Right Way™ of keeping up to data with master? This sort of thing keeps happening to me. Here is what I usually do:

git checkout master
git pull upstream master  # upstream is the official repository
git checkout my-feature-branch
git rebase master

@HiPhish No need to git checkout master, instead use git fetch --all (--prune is also a good idea IMO).

Here's my habit:

git fetch --all --prune
git rebase -i --autosquash upstream/master

Could also use the git ri alias from CONTRIBUTING.md.

git fetch --all --prune
git ri upstream/master

bump Anything else that needs to be done?

Merged after fixing indentation and API level. Thanks @HiPhish ,!