-
Notifications
You must be signed in to change notification settings - Fork 163
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
completing-read gfm code languages #54
completing-read gfm code languages #54
Conversation
add defconst markdown-gfm-recognized-languages, generated from scripts/scripts/get-recognized-gfm-languages
add defcustoms for insertion of additional languages, and use linguist-recognized languages, along with user-specified options, to provide a list of languages to completing-read
Fantastic—thanks for working on this. I don't have any performance issues on my end (nor do I use helm). Looks great to me so far. I will test it a bit more before merging. |
One small thing I noticed regarding capitalization: For the first fenced code block in a file, the capitalization in the pre-specified language list seems to dominate what is typed by the user. For example, if I type "Fortran" as the language name the empty code block will be inserted as
while I would have expected
I won't have time to poke around the code until later today at the earliest, but I'll take a look. |
completing-read gfm code languages
Yeah, check out my response in #59. |
For what it's worth, I didn't really notice any performance issues and I use helm as well. |
Cool! Guess my laptop is just slow. |
Fixes #38.
Does a few other things (although I swept the truly extraneous stuff to #53):
defcustom
s for additional languages for gfm to complete outside of the given set, and also one to toggle whether or not to useelectric-backquote
at all.markdown-regex-gfm-code-block-open/close
into a single regex, and uses that for highlighting. It was impossible to detect which line was supposed to contain a valid language otherwise.completing-read
input.markdown-replace-regexp-in-string
.Concerns:
I use helm, so it's always somewhat slower to load than the default, but 335 candidates is proving to be pretty slow to bring up (and it's not the
cl-find
call, that only takes about .05 seconds once byte-compiled according to(benchmark)
). So I was thinking many of the languages in linguist are pretty nonimportant, and I tried selecting about 100 of them which had names I could recognize, but that didn't seem to improve it for me at all, so I think it's just that helm'scompleting-read
is slow. Let me know if you have those performance concerns and we can probably just triage the languages (although it'd have to be a pretty heavy triage since 100 candidates is still taking just over a third of a second to bring up the completions buffer).