-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[plugin system] Add defineSymbol to the main katex object #1263
Conversation
CLA signature looks good 👍 |
Codecov Report
@@ Coverage Diff @@
## master #1263 /- ##
=======================================
Coverage 82.44% 82.44%
=======================================
Files 60 60
Lines 3880 3880
Branches 651 651
=======================================
Hits 3199 3199
Misses 578 578
Partials 103 103
Continue to review full report at Codecov.
|
Thank you for the pull request! Could you separate code style fixes to another PR? |
@ylemkimon I dropped the cleanup commit |
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.
It seems like there are still lots of formatting changes. I think this could (should?) be split into two separate PRs. One for exposing defineSymbol
and one for adding and exposing addFontMetrics
.
src/PluginManager.js
Outdated
const compiler = { | ||
defineSymbol, | ||
defineFunction, | ||
addFontMetrics, |
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.
Why not just expose these functions directly on the katex
object? There isn't really a concept of plugins internally. I think defineSymbol
is relatively stable, but defineFunction
requires access to a lot of internal classes to be useful.
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.
These functions are basically internal utilities of KaTeX. I thought having an additional abstraction layer in API makes room for future breaking changes without breaking the API.
I did not think exposing them to normal users was a good idea on the other hand advanced users can use them without defining a new javascript class (plugin) so I'll directly expose them as you're OK with it.
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.
We can expose them with a __
underscore prefix to indicate that they should be used with caution.
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 refactored the code.
Please checkout my following comment.
d64faca
to
53f31c8
Compare
|
/** | ||
* adds a new symbol to internal symbols table | ||
*/ | ||
__defineSymbol: defineSymbol, |
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.
perfect
src/symbols.js
Outdated
@@ -19,7 19,7 @@ | |||
|
|||
import type {Mode} from "./types"; | |||
|
|||
type Font = "main" | "ams"; | |||
type Font = string; // can be "main" | "ams" | any other injected font by plugins |
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.
I'm uncertain that any value that isn't "main"
or "ams"
would actually work correctly. If we allow any string, there should be a test in katex-spec.js that verifies that other values work.
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.
It will not work until user defines a font-face
and adds appropriate font metrics to use a new font.
I will revert this as we have to deal with this issue in #1269. These types are not much useful for katex users until we add katex libdef to flow-typed project or use something like .js.flow files when they got stable.
After deleting this I don't think we need any new tests in this PR.
I'm not sure if this is the PR for it, but it occurs to me that exposing defineMacro (for global macros, as an alternative to passing them in) could also be handy. |
Exposing |
This PR serves as a complement to PR KaTeX#1232 by supporting some letters that are omitted from the Unicode range 1D400–1D7FF.
* Include Bold-Italic fonts for \boldsymbol Fix KaTeX#1228 * Update screenshots
* README: Add size badge Add a size badge showing size of gzipped katex.min.js * update-sri: Add code to replace size badge in readme * Change to use badge from shields.io instead My bad for assuming that badgesize.io supports https. Change to use the badge from shields.io which supports https. * More Unicode letters (KaTeX#1260) This PR serves as a complement to PR KaTeX#1232 by supporting some letters that are omitted from the Unicode range 1D400–1D7FF. * Include Bold-Italic fonts for \boldsymbol (KaTeX#1257) * Include Bold-Italic fonts for \boldsymbol Fix KaTeX#1228 * Update screenshots * README: Add size badge Add a size badge showing size of gzipped katex.min.js * update-sri: Add code to replace size badge in readme * Change to use badge from shields.io instead My bad for assuming that badgesize.io supports https. Change to use the badge from shields.io which supports https. * Use badgesize.io with https
* Fix space width in \texttt Fix KaTeX#1255 via KaTeX/katex-fonts#41. Also fix width metrics via KaTeX/katex-fonts#42. * Improve test * Update screenshots
@kevinbarabash everything is fixed, I think we are ready to merge. |
@@ -19,7 19,7 @@ | |||
|
|||
import type {Mode} from "./types"; | |||
|
|||
type Font = "main" | "ams"; | |||
type Font = "main" | "ams" |
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.
I'm surprised that this passed the linter.
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.
LGTM
I need to read up on this more, but it sounds like you can define an index.js.flow file.
My hope is that we can reduce the need for CSS in general in the future. It limits our ability to support other rendering backends in the future like canvas or SVG. Obviously with the case of adding support for additional fonts some CSS has to be defined somewhere in order to define new font faces. I think what you did is fine.
Being able to try out different plugins would be awesome. I'd try making that work first in the dev server environment. One thing I'd like to investigate before introducing React for the test app is look at restructuring this repo to be a mono-repo. See #1411 for details about moving to a mono-repo. |
Discussed in #762
I did not add anything to contribution guidelines as this is still in beta but I think it is ready to be merged.
I will also add a plugin template to the project when the API is finalized.
Please check out the
PluginManager
class as it contains the main logic. Then you can check out a KaTeX plugin in action: persian-katex-plugin.Here are some things that I was not sure about or I needed your guidance to implement:
flow types
to plugins. Do you have any suggestions?KaTeX.css
.I used this approach as I wasn't sure if it is OK to change the old behaviour.
React App
like the one used in persian-katex-plugin opens up whole new possibilities e.g. we can have buttons to apply different plugins to the library and check out their effect. I'm ready to implement that if you are OK.yarn.lock
as there is no harm for it to be there plus it provides faster and safer installation for people who use yarn and most known libraries usually have it in addition topackage-lock.json
: just removed yarn.lock from this PRdefineSymbol
andaddFontMetrics
. I'm not sure if we need to expose anything more thandefineFunction
to other plugins as I haven't used it yet: we will not expose defineFunction in this PRAll the current tests are passing.
I will also add more tests for the plugin system (and squash the commits) when we finalize the API.