[vim/vim] Remove redefinition of static keyword (PR #14816)

15 views
Skip to first unread message

Drew Vogel

unread,
May 20, 2024, 10:31:36 PMMay 20
to vim/vim, Subscribed

Problem: Ancient preprocessor hack could lead to very confusing build errors.
Solution: Use simpler XPM that reflects current source control approach.

My primary concern here is removing the redefinition of static. This was seemingly originally used as a workaround to GTKv1 vs GTKv2 API difference. When GTKv1 support was dropped, this redefinition should have also been abandoned in favor of declaring the XPM data static const. Those XPM files have been in version control, unchanged since 2004. Beyond being unnecessary, if one misplaces an #if or an #end this can result in very confusing "invalid storage class for function" errors because some functions will effectively be declared static const.

I've also removed this magick define/undef sequence because AFAICT it serves no purpose. If anyone knows a good reason this should remain, I'm open to keeping it but if we keep it then it's purpose should be documented. My best guess is that either at some point prior to the XPM files being put under version control they included code that interacted with that magick symbol. I consulted the v6.4 source code on the FTP archive and that version does not include any of this code so there seems to be a gap between v6.4 and the v7 sources in the git repo.


You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/14816

Commit Summary

  • ed63922 Problem: Ancient preprocessor hack could lead to very confusing build errors.

File Changes

(5 files)

Patch Links:


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/14816@github.com>

Christian Brabandt

unread,
May 22, 2024, 10:51:51 AMMay 22
to vim/vim, Subscribed

Thanks. I have no idea if this breaks for anybody. Best to include and see if anybody complains, but I doubt anybody will notice.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/14816/c2125001418@github.com>

Christian Brabandt

unread,
May 22, 2024, 10:57:31 AMMay 22
to vim/vim, Subscribed

Closed #14816 via 5090f83.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/14816/issue_event/12896072929@github.com>

Christian Brabandt

unread,
May 23, 2024, 1:07:54 AMMay 23
to vim/vim, Subscribed

This change seems to cause some warnings: https://groups.google.com/g/vim_dev/c/1QH6AEZxqRw/m/awOu4EjeDgAJ

@dvogel can you please have a look?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/14816/c2126242224@github.com>

Drew Vogel

unread,
May 23, 2024, 1:32:31 AMMay 23
to vim/vim, Subscribed

It looks like this is a case where motif and gtk have different expected
chr pointers. I'll revert the xpm file changes and cast char* to const
char* on the gtk side tomorrow.

On Thu, May 23, 2024, 12:07 AM Christian Brabandt ***@***.***>
wrote:

> This change seems to cause some warnings:
> https://groups.google.com/g/vim_dev/c/1QH6AEZxqRw/m/awOu4EjeDgAJ
>
> @dvogel <https://github.com/dvogel> can you please have a look?
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/vim/vim/pull/14816#issuecomment-2126242224>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAALFA75XQ7FTCAVYSTXPNDZDV2QXAVCNFSM6AAAAABIAW7RBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRWGI2DEMRSGQ>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/14816/c2126265990@github.com>

Reply all
Reply to author
Forward
0 new messages