#54 Fix some math support

Merged
hz merged 1 commits from :math into master 7 months ago
hz commented 9 months ago

These changes (suggested by Erik) affect the way that math environments are handled. In particular, this PR adds:

  • Support for top-level math environments without $ or $$: equation, equation*, align, align*, eqnarray, eqnarray*
  • Support for (...) and [...] for entering math mode (not anymore, since part of the markdown spec is that those sequences are used for escaping parentheses and square brackets).
These changes (suggested by Erik) affect the way that math environments are handled. In particular, this PR adds: * Support for top-level math environments without `$` or `$$`: `equation`, `equation*`, `align`, `align*`, `eqnarray`, `eqnarray*` * ~~Support for `(...)` and `[...]` for entering math mode~~ (not anymore, since part of the markdown spec is that those sequences are used for escaping parentheses and square brackets).
hz added the
bug
label 9 months ago
hz added the
enhancement
label 9 months ago

Changes are looking good! Perhaps we should add some tests to catsoop/test/markdown_tests.py like nesting:

egin{align}
  x & 	ext{if $y$} \
  y & 	ext{else}
end{align}
Changes are looking good! Perhaps we should add some tests to `catsoop/test/markdown_tests.py` like nesting: ```markdown egin{align} x & ext{if $y$} \ y & ext{else} end{align} ```
hz commented 9 months ago
Owner

Good call. A quick manual test suggests that this works fine, but I’ll definitely add some test cases before this goes in.

Good call. A quick manual test suggests that this works fine, but I'll definitely add some test cases before this goes in.
hz commented 8 months ago
Owner

@edemaine, I put in a few changes here. I’ve done some testing (and added some tests to test_markdown.py) and I’m pretty happy with where things are now, but it’s not perfect. I could use a second opinion on any/all of the following if you have the time 😄

  1. I removed (...) and [...] since they are part of the Markdown spec as escaped versions of ()[], which is useful, for example, in links that use those characters. I’m not actually sure how I feel about that since it wouldn’t be hard to use an explicit <a> tag in the case where you want to link to something with those characters in it...

  2. I adopted a heuristic similar to one from Pandoc (discussed very briefly here) for deciding when a dollar sign should be treated as entering math mode, and when it shouldn’t, in an attempt to avoid accidentally entering math mode when it isn’t actually desired. In short:

    • the opening dollar sign can’t be preceded by `` or by a digit, nor can it be followed by a space
    • the closing dollar sign can’t be preceded by whitespace or followed by a digit
  3. I still can’t handle certain complicated inputs like $x = ext{the $n$th root of $y$}$ because of the simple regex-based parsing I’m doing, but it seems hard to handle that case without changing a lot about the way I’m doing my parsing. Maybe we should make sure that the above can be written using <math>...</math> tags, which would at least provide a day to do that if someone wanted to.

@edemaine, I put in a few changes here. I've done some testing (and added some tests to `test_markdown.py`) and I'm pretty happy with where things are now, but it's not perfect. I could use a second opinion on any/all of the following if you have the time :smile: 1. I removed `(...)` and `[...]` since they are part of the Markdown spec as escaped versions of `()[]`, which is useful, for example, in links that use those characters. I'm not actually sure how I feel about that since it wouldn't be hard to use an explicit `<a>` tag in the case where you want to link to something with those characters in it... 1. I adopted a heuristic similar to one from Pandoc ([discussed very briefly here](https://talk.commonmark.org/t/mathjax-extension-for-latex-equations/698/7)) for deciding when a dollar sign should be treated as entering math mode, and when it shouldn't, in an attempt to avoid accidentally entering math mode when it isn't actually desired. In short: * the opening dollar sign can't be preceded by `` or by a digit, nor can it be followed by a space * the closing dollar sign can't be preceded by whitespace or followed by a digit 1. I still can't handle certain complicated inputs like `$x = ext{the $n$th root of $y$}$` because of the simple regex-based parsing I'm doing, but it seems hard to handle that case without changing a lot about the way I'm doing my parsing. Maybe we should make sure that the above can be written using `<math>...</math>` tags, which would at least provide a day to do that if someone wanted to.
hz closed this pull request 7 months ago
The pull request has been merged as 13c0970f4c.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.