Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vim #defines leak out to rest of app #225

Open
city41 opened this issue Sep 21, 2020 · 2 comments
Open

vim #defines leak out to rest of app #225

city41 opened this issue Sep 21, 2020 · 2 comments
Labels
enhancement New feature or request

Comments

@city41
Copy link
Contributor

city41 commented Sep 21, 2020

Is your feature request related something that is currently hard to do? Please describe.
vim contains very "generic" defines such as #define OK 1. When using vim as a library, these defines can leak out to the rest of the app and cause some grief.

Describe the solution you'd like
I am unsure of a truly good solution. But maybe libvim.h should not include vim.h, which pulls in all of vim, but rather pull in a more strategic set of files?

Another possible solution is to namespace these defines, like #define VIM_OK 1 but can certainly understand why changing vim's code is not so great.

And of course, another solution is just ignore this problem. I suppose it depends on how far libvim gets used. If it really only ever powers Oni, then this might not matter.

Describe alternatives you've considered
I have used #undef after #includeing libvim.h, which patches the problem. But since I don't know what defines vim has made, I am unsure when/if this will bite me again in the future.

@city41 city41 added the enhancement New feature or request label Sep 21, 2020
@city41
Copy link
Contributor Author

city41 commented Sep 21, 2020

In my particular case, #define OK 1 and #define NORMAL 0x01 both caused unexpected changes in my app, which has enums like enum { NORMAL, VERBOSE }

@bryphe
Copy link
Member

bryphe commented Oct 23, 2020

Good catch @city41 - thanks for all the details!

But maybe libvim.h should not include vim.h, which pulls in all of vim, but rather pull in a more strategic set of files?

I agree - I think this is the correct solution. The vim.h pulls in a lot of defines, which aren't really necessary - we mainly use to pull some types from structs.h that are shared. I think what would be preferable is to move these shared types to something like libvim_common.h that both vim.h and libvim.h include - that would give us a more minimal set of defines that are more scoped to libvim's API.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants