-
Notifications
You must be signed in to change notification settings - Fork 4
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 extension detection for Vale #4
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.
Just a comments. Also, could you update the README to reflect these changes? A section on flymake-vale-extension
and how the user can modify it.
@tpeacock19 thanks! I've had a go at all outstanding feedback, let me know what you think :) |
This looks great! If you don't mind squashing the commits into one and I'll merge it asap. Thanks a lot for your help. |
Use a buffer-local variable for the extension if defined - Fix unbalanced parenthesis - Use a buffer-local variable for the extension if defined Remove flymake-vale--guess-extension-from-mode Remove `with-current-buffer` and `cond` from `flymake-vale--detect-extension` Update the docstring for `flymake-vale--detect-extension` Add documentation to show how to use `flymake-vale-file-ext`
@tpeacock19 there you go, force pushed! Very welcome, it's working great for me now, and I believe |
A minor design question: has using a major mode -> extension alist been considered? |
There are two types of file extension markup scoping that Vale provides.
The first is that when there are multiple file extensions for a given major-mode there is no guarantee that we will pass the preferred extension. If this was restricted to just the modes corresponding with the built-in capabilities, then it may work. As long as we pass anything within the extension sets shown above. However, when we move into any other major modes the extensions we default to may have detrimental effects. For example, That being said, If we did want to move forward with this, I do think an alist would be the best solution. |
Thanks for that explanation. Would it be overcomplicating things if there were two extension customisation variables:
If |
I think the alist would be useful if people would like to have set defaults for a number of modes. However, I again do not think we'd have great success trying to prepopulate that list for a decent amount of modes. For example: (defcustom flymake-vale-mode-file-exts
'((org-mode . ".org")
(python-mode . ".py")
;; which one {htm,html,shtml,xhtml} ?
(html-mode . ?)
;; which one {ltx,sty,cl[so],bbl} ?
(latex-mode . ?))) |
Hmm, I think there's a bit more (defcustom flymake-vale-mode-file-exts
'(;; Prose
(org-mode . ".org")
(markdown-mode . ".md")
(gfm-mode . ".md")
(xml-mode . ".xml") ; or code?
(rst-mode . ".rst")
(adoc-mode . ".asciidoc")
;; Code
(c-mode . ".c")
(csharp-mode . ".cs")
(css-mode . ".css")
(scss-mode . ".scss")
(go-mode . ".go")
; ...
)) |
Yes, it was meant more as an example for those modes with multiple extensions. Like Also, I think it may be better to use the actual file extension over the alist. Since that removes any potential clash of expectations. |
The actual file extension is a good bet for obvious reasons 😛 but what about buffers without a corresponding file? |
I'm thinking |
That looks reasonable to me 👍 |
Use either the file name extension, or the value of
flymake-vale-file-ext
.Fixes #2.
TODO: