Port set-window-scroll-bars

[clample]

Resolves #1459

The implementation is very similar to the porting of set-window-fringes

[clample]

It looks like the columns and lines returned by window-scroll-bars will vary. It is calculated based on width and height of the scroll bar. For example, the test fails if I open emacs and run the test locally.

I'm not sure what the best way is to make this test lest fragile.

[shaleh]

hmmmm

[clample]

So I believe I kind of found the reason why the column value varied. When Remacs is run without a window system (in the terminal), there is no scroll bar and columns is always 0.

I haven't pinned down the exact line where this happens, but it seems to be how it works.

To work around it - I check window-system in the test.

[shaleh]

Perhaps flip the following logic? I am not sure which I prefer.

if updated_window.is_null() {
    false
} else {
    unsafe { apply_window_adjustment(updated_window) };
    true
}

[clample]

Good point, this is more readable to me than !updated_window.is_null().

I updated the PR

[shaleh]

This all looks good. Now to figure out how to test it properly....

[clample]

The failure is from regex-tests-PTESTS. I think that it might be unrelated, but I'm not sure what the root cause is.

[shaleh]

@clample this one needs a rebase.

[denis631]

@clample In the original implementation, the window is accessed via decode_live_window which checks for the selected window being nil first, if yes -> use it instead of the passed window, otherwise check the passed window for being live (otherwise throwing a "wrong type argument exception") and then use it.

Do you think this may be the case here? Seems like semantics is not preserved.
reference: window.c line:264

[shaleh]

@denis631 LispWindowLiveOrSelected is meant to encapsulate the logic of decode_live_window.
Line 2067 gets the correct Window.

[denis631]

Ohhh so the #lisp_fn macro does all the necessary transformations? It this case mapping LispObject to LispWindowLiveOrSelected? I see. Nice. Sorry for false negative

[shaleh]

@denis631 correct. The lisp_fn macro is a proc macro which creates code that looks like:

pub fn new_defun(obj1: LispObject, obj2: LispObject, .......) -> LispObject {
    let result = original_defun(obj1.into(), obj2.into(), ....);
    result.into()
}

Which is super simple. All of the error handling, checking, and the like occurs in the From implementations. The lisp_fn macro gets more complicated when the lisp function is of variable arguments. These collect the args into a Vector.

Our convention is that where a Lisp function takes optional parameters we use the Option type. In the C code this is represented with a Nil value. Essentially C's LispObject is really an Option<LispValue>.