Skip to content
This repository has been archived by the owner on Jan 3, 2023. It is now read-only.

\newcommand definitions #24

Open
szhorvat opened this issue Feb 12, 2015 · 9 comments
Open

\newcommand definitions #24

szhorvat opened this issue Feb 12, 2015 · 9 comments

Comments

@szhorvat
Copy link

tl; dr When \newcommand definitions take effect is somewhat unpredictable.


I'll first describe the symptoms of the problem.

Restart atom and create a new document as follows:

\[ x \]
one two
\[
\nc(m)
\]

Now open a MarkDown preview. Of course this won't render correctly, as there's no \nc command.

Now change the document like this:

\[ 
\newcommand{\nc}{\mathcal{N}}
x 
\]
one two
\[
\nc(m)
\]

The definition does exist now, but the second math section doesn't update to reflect it. I guess this is because only those sections are updated which change (which is a good thing).

Either reopening the preview or editing the second math section will fix this.

Now remove the definition ...

\[ 
x
\]
one two
\[
\nc(m)
\]

... and close and reopen the preview. Notice that the definition is still active.


None of this is really a big deal, I'm mentioning it so you can think about whether any of this can cause serious problems. It doesn't cause any problems for me.

  1. Would it make sense to include a command to rerender the whole document without having to close and reopen the preview? Is closing and reopening a good workaround?
  2. Can the preserved command definition cause any problems? It appears the only way to get rid of it is to restart Atom.
@Galadirith
Copy link
Collaborator

Thanks @szhorvat. Yeh this is a difficult one. MathJax was never really designed to be used in this dynamic way.

The definition does exist now, but the second math section doesn't update to reflect it. I guess this is because only those sections are updated which change (which is a good thing).

Yes exactly that.

Would it make sense to include a command to rerender the whole document without having to close and reopen the preview? Is closing and reopening a good workaround?

I think such a command could make sense. I tend to find that if I want to achieve that right now I would just toggle LaTeX rendering off then on with ctrl-shift-x. That just re-renders the Maths, and in fact that is really all that would be needed, re-render all Maths.

Can the preserved command definition cause any problems? It appears the only way to get rid of it is to restart Atom.

So I think the only times when it would cause problems is when you really do just want to literally display a command, rather than what it evaluates too. Your right the only way to fix that is to restart Atom. You instead just use \backslash in place of \ for such deleted macros, but restarting Atom seems like a more appropriate solution.

Removing Macro's when they're no longer defined anywhere could get messy. All previews share a single instance of MathJax, so you would have to scan all open previews for macro definitions and compare that list to MathJax's user defined macro list. Another question is then when would you perform such a scan? Every time you change an equation?

However, like you I don't see it as a show stopper (right now at least :D), but i'll continue to think on potential consequences and fixes. Thanks again @szhorvat

@leipert
Copy link
Contributor

leipert commented Aug 30, 2015

@Galadirith An easy solution would be, if we instantiate a new MathJax every time Math rendering is turned off and on:

  1. ctrl-shift-x -> Turn off math
  2. ctrl-shift-x -> Turn on math -> new MathJax -> old newcommands gone.

@Galadirith
Copy link
Collaborator

@leipert Thats a great idea and its similar to what I implemented in spec/mathjax-helper-spec.

One issue I foresee is handling when multiple previews are open as right now toggling math is a local operation but that doesn't seem like a problem that can't be handled.

@leipert leipert added this to the 2.1.0 milestone Aug 30, 2015
@leipert leipert assigned Galadirith and unassigned leipert Aug 30, 2015
@leipert
Copy link
Contributor

leipert commented Aug 30, 2015

I just moved this to your scope ;)

@Galadirith
Copy link
Collaborator

:D Great 🔭

@leipert leipert modified the milestones: 2.1.0, 2.2.0 Sep 8, 2015
@Galadirith
Copy link
Collaborator

I've removed the milestone on this issue. I haven't been able to spend any time working on this and in particular I'm not 100% clear on exactly what I would expect the behaviour to be, let alone having any candidate implementation. I'll hopefully have time to review this during our 2.3.0 cycle and will take it from there.

@Galadirith Galadirith removed this from the 2.2.0 milestone Oct 4, 2015
@szhorvat
Copy link
Author

szhorvat commented Oct 7, 2015

This is really a minor issue I think, so it should be low priority. In practice this package works very well. Thank you again for maintaining it!

@OJFord
Copy link

OJFord commented Nov 26, 2015

Actually, this can (and has for me) cause problems.

If you get the definition wrong, it then of course sticks wrong. And depending how wrong you get it, this can be rather damaging.. Unfortunately, I got the operands the wrong way around accidentally, which meant that everywhere I subsequently used \operatorname (including other definitions of course!) was overloaded with the text I'd meant to define as an operator (i.e. it was littered with NewOpNewOp and NewOpOtherOp in math font..)

I tried exactly what's suggested above - restarting the render, and reopening the preview. When neither worked I restarted Atom - and then had no LaTeX rendering at all as I've described in my comment in #147. I'm not sure that this is related though, it just compounded the issue.

It would be really useful to have a way to "re-render all". If the overhead on "turn on math" is not desired, then I'd suggest as an alternative it could be refreshed on "sync preview".

@lierdakil
Copy link
Collaborator

This should be somewhat alleviated in v3.0.1. Reopening the preview will reload MathJax, consequently resetting all caches.

@lierdakil lierdakil modified the milestone: v3.1.0 May 1, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants