Lindydancer
function-signatures versus function-keywords ... overlap?
I'm no expert on Emacs font-lock implementations, but it feels to me like there's some overlap between cmake-font-lock-function-keywords-alist and cmake-font-lock-function-signatures.
I feel like function-signatures is (or would be if it was complete) a superset of the information in keywords-alist, in that if all the function-signatures were completed then all the keywords would be specified by the function signatures. Is there a reason to keep two separate settings?
This mainly came up for me because while adding keywords for my recent pull request I found myself adding the PERMISSIONS keywords for the install() command, which has syntax like:
install(... PERMISSIONS OWNER_READ OWNER_WRITE ...)
I was thinking that while PERMISSIONS is a keyword, the options such as OWNER_READ etc. might be better font-locked as a different type of thing. Maybe a property font or something like that.
So I looked further and found function-signatures where I could define the entire syntax of the function... but then I got confused about what the distinction is between these two and when one should use one versus the other, and why there are even two of them when it seems like if all functions were fully specified by function-signatures then why do we need function-keywords?
So I thought I'd ask :smile:
Hi Paul!
Now when I look back at the implementation of cmake-font-lock, I agree with you that there is a big overlap between the two data structures. I have been thinking about joining them, but haven't got around to make such a big change in a working package. I guess I ended up with two data structures since I wrote the package in phases, with the keyword list first and the more advanced signature package in a later phase.
I will keep your suggestion in mind. However, for the time being I haven't got much time to do Emacs-related work, and there are other things on my Emacs-wishlist as well.
Anyway, I really appreciate your input!
Sincerely, Anders Lindgren
Ps. I'll reply to your other pull request in its own thread.
On Sat, Mar 16, 2019 at 8:56 PM Paul Smith [email protected] wrote:
I'm no expert on Emacs font-lock implementations, but it feels to me like there's some overlap between cmake-font-lock-function-keywords-alist and cmake-font-lock-function-signatures.
I feel like function-signatures is (or would be if it was complete) a superset of the information in keywords-alist, in that if all the function-signatures were completed then all the keywords would be specified by the function signatures. Is there a reason to keep two separate settings?
This mainly came up for me because while adding keywords for my recent pull request I found myself adding the PERMISSIONS keywords for the install() command, which has syntax like: install(... PERMISSIONS OWNER_READ OWNER_WRITE ...) I was thinking that while PERMISSIONS is a keyword, the options such as OWNER_READ etc. might be better font-locked as a different type of thing. Maybe a property font or something like that.
So I looked further and found function-signatures where I could define the entire syntax of the function... but then I got confused about what the distinction is between these two and when one should use one versus the other, and why there are even two of them when it seems like if all functions were fully specified by function-signatures then why do we need function-keywords?
So I thought I'd ask 😄
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Lindydancer/cmake-font-lock/issues/8, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBjQGEejbUBF2xHlJem9VmxCodahDMhks5vXUxVgaJpZM4b3_98 .
Yeah, it does seem like a big change. CMake is kind of interesting because so much of the language structure can be usefully predefined. I've been playing a lot with using company mode, etc. which provide auto-complete capabilities, and it seems to me that in addition to font-lock a complete definition of the structure of the various built-in functions could easily lend itself to being used by the various auto-complete Emacs libraries, which would be really, really cool: offering up possible next things to type in pop-ups with autocompletion.
Or said differently, the content of the cmake-font-lock-function-signatures variable (after being filled out and completed) could serve as a basic set of data used to drive a lot of different CMake editing features, not just font-locking.
Just random thoughts; like you I have no time to push these ideas further. Maybe someone else will come along looking for a fun Elisp project!
Hi!
I haven't got around to use company mode much, but it sounds like an interesting idea.
One line of thoughts that I've had is to highlight CMake function calls that doesn't match a valid signature. CMake itself is notoriously bad at detecting such cases, and Emacs could really help here.
-- Anders
On Mon, Mar 18, 2019 at 10:39 PM Paul Smith [email protected] wrote:
Yeah, it does seem like a big change. CMake is kind of interesting because so much of the language structure can be usefully predefined. I've been playing a lot with using company mode, etc. which provide auto-complete capabilities, and it seems to me that in addition to font-lock a complete definition of the structure of the various built-in functions could easily lend itself to being used by the various auto-complete Emacs libraries, which would be really, really cool: offering up possible next things to type in pop-ups with autocompletion.
Or said differently, the content of the cmake-font-lock-function-signatures variable (after being filled out and completed) could serve as a basic set of data used to drive a lot of different CMake editing features, not just font-locking.
Just random thoughts; like you I have no time to push these ideas further. Maybe someone else will come along looking for a fun Elisp project!
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Lindydancer/cmake-font-lock/issues/8#issuecomment-474111988, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBjQNOIojPwrqwYrU34EPq5e7-lcb23ks5vYAd3gaJpZM4b3_98 .