-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add font-lock for el-patch-def* forms #38
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to do this on a per-macro basis inside el-patch-deftype
, so that syntax highlighting works for all functions, including user-defined ones?
I think this would be best implemented by introducing a new optional key for el-patch-deftype-alist
(say :font-lock
) which is a function that takes e.g. the name of the macro and then sets up the font-lock appropriately. Then we can have pre-defined functions for the two cases you have here (just like we have el-patch-classify-variable
and el-patch-classify-function
), and encourage their use.
Yea that makes sense. I'm leaving for a vacation now for 10 days so I'll cook something afterwards. |
Sounds good. Enjoy your trip! |
Hey @raxod502 I've done some changes, is this in line with what you invisioned? I'll add a documentation entry after the review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the most part, this looks great. Thanks for incorporating my feedback.
@@ -651,48 +675,55 @@ DEFINITION is a list starting with `defun' or similar." | |||
(el-patch-deftype defconst | |||
:classify el-patch-classify-variable | |||
:locate el-patch-locate-variable | |||
:font-lock #'el-patch-fontify-as-variable |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For consistency, I'd like these to be unquoted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. I personally prefer as little magic as possible especially with macros, so I pass quoted or unquoted based on how it is used later. But consistency almost always trumps purity :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think you are right about preferring quoted, and if I were designing this macro again then I would do it your way. It's not a good enough reason to break backwards compatibility, though :P
This thread is being closed automatically by Tidier because it is labeled with "waiting on response" and has not seen any activity for 90 days. But don't worry—if you have any information that might advance the discussion, leave a comment and the thread may be reopened :) |
Hey, I completely forgot about this not being merged, as I use it in my config since forever. I've updated the |
(seems like github doesn't re-check my repo if this is closed, maybe reopening will make it refresh... as of now it still shows the old patch) |
Unfortunately, it seems like it's not possible to re-open the pull request, because I have since deleted the |
Fixes #35