Anybody wants this? Otherwise I'm gonna just hardcode it for myself.
https://github.com/vim/vim/pull/16343
(7 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@3N4N pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Well, you should explain why you need this and what exactly this does. Just asking "anybody needs this?" Is not very convincing .
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Well, you should explain why you need this and what exactly this does. Just asking "anybody needs this?" Is not very convincing .
True, but I thought "GUI window padding" was intuitive enough. In any case, added more explanation now.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Thanks, that makes it a lot more clear. I think the screenshot helps very much. However I think the option should be renamed, guipad seems a bit obscure. Then I think we would want this for at least the linux GTK build as well. And then finally, does this add the padding only on the left side? Or on both sides? I think we should add it on both sides, no?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Thanks, that makes it a lot more clear. I think the screenshot helps very much.
Thank you.
However I think the option should be renamed, guipad seems a bit obscure.
Agreed, at least guipadding should be used. I just wanted to see if anyone would even want it before I started optimizing variable name.
Then I think we would want this for at least the linux GTK build as well.
Yes, I will do that. The same code should work for both w32 and x11_gtk (and haiku, motif, photon, but I don't have any way to test it). Again, wanted to check the PR's value before doing more work for no gain.
And then finally, does this add the padding only on the left side? Or on both sides? I think we should add it on both sides, no?
It does add it on both sides. Top and bottom as well. There is some thinking that needs to be done:
But wanted to see the PR's value...
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
So perhaps we can go with guipadding which takes 4 values: left:a,right:b,top:c,bot:d in pixel values, all optional. That would be similar to HTML padding setting. I think it should always apply, shouldn't depend on scrollbar or tabline.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
So perhaps we can go with
guipaddingwhich takes 4 values:left:a,right:b,top:c,bot:din pixel values, all optional. That would be similar to HTML padding setting. I think it should always apply, shouldn't depend on scrollbar or tabline.
Yes, if we have a fully-configurable option, then no need to depend on scrollbar/tabline. I'll do that.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Currently, We can create a padding on the left side by using 'foldcolumn' or 'signcolumn'.
I think these are sufficient.
set foldcolumn=1
or
set signcolumn=yes
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Currently, We can create a padding on the left side by using
'foldcolumn'or'signcolumn'. I think these are sufficient.
I did this until yesterday: had set foldcolumn=1 in my gvimrc. But the foldcolumn has a different highlight color. I used to manually configure the color (clear then link to Normal), but that limits the users who wants to use a different color for their gutter.
But yes, it works as a hack. I was just annoyed by it, specially since the TUI Vim in Windows Terminal has such a nice padding (setup by the terminal emulator) that when I switch to GVim it looks backdated. Thought: why not use the GUI capability?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
So perhaps we can go with
guipaddingwhich takes 4 values:left:a,right:b,top:c,bot:din pixel values, all optional. That would be similar to HTML padding setting. I think it should always apply, shouldn't depend on scrollbar or tabline.
As it turns out, string options are really hard to deal with. I tried to learn from listchars but the function set_chars_option is massive (240L). I guess it's justified since listchars options are kinda complicated, but in case of guipadding, it's too much work for 4 integers, specially since most people probably will use the same value for it anyway. No?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Regardless of whether or not we add this feature, I think the option name 'guimargin' would be more appropriate than guipadding.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Please check how it is done for 'diffopt' or 'messagesopt' setting (e.g. from this recent commit: 51d4d84). It's a bit of borring code to parse the option, but I think it makes sense to allow the additional flexibility this provides.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Thanks, Christian. The 'messageopt' setting implementation helped. The option parsing is now done. It's working on my end in Windows, but obviously I have to implement it for GTK and then use it for a few days to be satisfied. I also have to check that scrollbars/menubars/toolbars are working properly with this padding setting. Also a check needs to be set up so that padding cannot be negative or more than the Cols/Rows value.
In short, let me play with this for a few days. No need to run any test until then. It'll fail :")
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
@chrisbra Any feedback? There should be a check to see 0<=padding<=x, but I don't know what the value of x should be or where best to put that check.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
This should be part of did_set_guipadding. There doesn't seem to be any error-handling right now? Also we would need a test for setting those option values (including invalid ones: :set guipadding=10, :set guipadding=left:-10, :set guipadding=foobar:10 etc.)
Also we would also want an expand_set_guipadding option, for expanding the option. Again there should be a test for this.
Not sure what the upper padding-boundary should be.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
Also we would also want an expand_set_guipadding option, for expanding the option. Again there should be a test for this.
In case it wasn't clear, this function is there to support pressing tab for auto-complete. I would imagine it is a simple one-liner that simply calls expand_set_opt_string with a null-terminated char* array with the four options.
FWIW MacVim has had this feature for a long time called "text inset" but it's configured through the macOS defaults system (but not super visible to the user other than a one-liner in documentation) rather than going through Vim. I will probably make the guipadding option override the MacVim defaults if it's specified by the user.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.![]()
Also we would also want an expand_set_guipadding option, for expanding the option. Again there should be a test for this.
In case it wasn't clear, this function is there to support pressing tab for auto-complete. I would imagine it is a simple one-liner that simply calls
expand_set_opt_stringwith a null-terminated char* array with the four options.
Yes, I understood. I just got busy with my work. I'll finish it in the Summer break.
FWIW MacVim has had this feature for a long time called "text inset" but it's configured through the macOS defaults system (but not super visible to the user other than a one-liner in documentation) rather than going through Vim. I will probably make the Vim guipadding option override the MacVim defaults if it's specified by the user.
I do have a new Mac, so I can look into it when I get back to working on it. I'll keep this in mind.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.![]()
I do have a new Mac, so I can look into it when I get back to working on it. I'll keep this in mind.
Sorry I mostly quoted it as a context (I maintain MacVim which is a separate but related project from Vim so I can do that hookup on my part if this PR gets through). I don't think there's anything you need to do on your part for this PR.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.![]()
In case it wasn't clear, this function is there to support pressing tab for auto-complete. I would imagine it is a simple one-liner that simply calls
expand_set_opt_stringwith a null-terminated char* array with the four options.
Hi @ychin , I'm confused about one thing. What is this tab-completion supposed to autocomplete? For ':set mouse=' it completes the current value of 'mouse', but for 'lispoptions', it completes the possible values, not the current value. Which should 'guipadding' implement? That's one confusion.
The other confusion is: I tried to implement 'expand_set_guipadding' with 'expand_set_opt_string' following the function 'expand_set_lispoptions', but it's only completing the current value. Why am I not getting the 'expand_set_lispoptions' behavior even though the function is basically the same?
This is my current implementation of 'expand_set_guipadding':
int
expand_set_guipadding(optexpand_T *args, int *numMatches, char_u ***matches)
{
static char *(p_gpd_values[]) = {"top:", "left:", "bot:", "right:", NULL};
return expand_set_opt_string(
args,
p_gpd_values,
ARRAY_LENGTH(p_gpd_values) - 1,
numMatches,
matches);
}
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()
First, mouse is a flag list option, meaning it's a list of single-character flags. guipadding and lispoptions are string options, so it's a different category.
Either way all options auto-complete to their current value, then it will give you other options as well in the 2nd/3rd/etc choices. So if you tab complete mouse it should loop through all possible option (do you have wildmenu on?).
For expand_set_guipadding, did you actually hook it up and making sure that the function is called (e.g. in a debugger)? You need to actually hook it up in optiondefs.h. Otherwise you have just created a function.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.![]()
For
expand_set_guipadding, did you actually hook it up and making sure that the function is called (e.g. in a debugger)?
You're 100% right. I did hook it up in 'optiondefs.h', and 'make clean'-ed it for good measure, but still it wasn't working. But following your suggestion, I ran gvim in a gdb and failed to set a breakpoint for expand_set_guipadding. Then I remember I had to add the function definition in a pro file for did_set_guipadding as well. After adding the function definition, it's working as expected. Pushing now. I'll get to tests later.
Thanks,
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.![]()