2
$\begingroup$

Inside Manipulate, symbols defined in controls that are created by hand with Control are given "undefined" syntax coloring. For example in 

Manipulate[
  Column[{Definition@a,Definition@b}],
  {a,0,10},
  Control@{b,0,10}]

a is correctly colored as a "variable made special by use in arguments" while b is incorrectly colored as a "global symbol that has no value assigned" (as confirmed in the "Why the Coloring?" dialog), even though both are correctly treated as defined special local variables in the same scope (as indicated by the Manipulate's output).

Why is this and how do I overcome it? Is it a bug or other limitation; a deliberate decision?

$\endgroup$
14
  • $\begingroup$ Because that's not a classic "local variable" pattern and hence isn't picked up by the FE. Put a {b, None} in front of it and it'll get colored. $\endgroup$
    – b3m2a1
    Sep 6, 2017 at 16:19
  • 2
    $\begingroup$ @raxacoricofallapatorius I am all with you on exposing bugs (see askers) but it is a matter of rules to not make a mess around. I agree something is not ok, maybe it is a bug, an omission (so a bug from users perspective) or poor documentation (additional tag is needed). Please wait for WRI clarification because if the author of an alternative parser is not 100% sure how to classify this then I don;t know if we have this solved. $\endgroup$
    – Kuba ♦
    Sep 8, 2017 at 5:39
  • 2
    $\begingroup$ Btw support can't use bug word but they will tell you that they confirm 'the problem' or 'followed the issue to the developer'. And I don't know what do you mean that description should be updated: "[...] the problem has been vetted by this community and the observed behavior is confirmed to be a bug [...] use the standard bugs header [...]" - isn't that clear? $\endgroup$
    – Kuba ♦
    Sep 8, 2017 at 5:39
  • 1
    $\begingroup$ @raxacoricofallapatorius I'd say it's less a matter of needing to tip-toe around WRI (you will find much WRI bashing around here) and more of standard procedures. I think it's worth differentiating between design flaws, of which Mathematica has numerous, and bugs, which are unintentional glitches in the program. The main difference in my mind is that the latter are known by WRI and potentially may be fixed (although this is WRI so don't hold your breath). If, for instance, I wanted to write a bug tracker, I'd want it to catch confirmed bugs, not just bad design. $\endgroup$
    – b3m2a1
    Sep 8, 2017 at 12:21
  • 1
    $\begingroup$ raxacoricofallapatorius, if you wish to dispute our current policy on the bugs tag, please make a meta post. Though you say you have reported it, don't add the tag until you get a confirmation from support in this case. For now, I'm locking this from editing until further notice. $\endgroup$
    – J. M.'s lack of A.I. ♦
    Sep 14, 2017 at 14:09

1 Answer 1

Reset to default
7
$\begingroup$

Maybe it's my turn to answer this. As the developer of the Mathematica Plugin for IntelliJ, I can explain in detail, why such highlighter bugs are often a limitation that cannot be fixed when the front end highlighting should work reasonably fast.

In this particular case, the issue might well be overlooked by WRI. If you write your Control as

Control[{b, 0, 10}]

it should be highlighted correctly but indeed it isn't.

To investigate a bit in the nature of the problem, let me give some similar examples.

Module local highlighting

Mathematica graphics

RuleDelayed variables

Mathematica graphics

With local variable

Mathematica graphics

Finally, let me give an example to understand, why highlighting in Mathematica can always be broken. What I do is, I create With in a very unusual way:

Mathematica graphics

Now take a moment to understand what is really necessary in the worst case if Mathematica wanted to get the green highlighting of x always right.

In the worst case, you are defining your specific control in a package that is loaded, maybe from a web-URL. In order to know that, Mathematica would need to evaluate your complete code. Every time! On each key stroke! That is not possible and will never be. The reason for this restriction is Mathematica's Code is Data paradigm that lets you freely redefine and build parts of the language within the language.

Therefore, the highlighter uses only a pattern match against the structure of your syntax. As soon, as the cases, the highlighter checks are different from what you have written, the highlighting will go wrong.

The situation with Control seems to be a tiny bit different. We have to admit, that there are many different patterns for a general Control. On the other hand, these cases are nothing more than the cases that are already supported by directly writing it into Manipulate without wrapping Control. This might well be just a mistake on the side of Mathematica. I believe it is possible to support the cases that are displayed in the details-section of the help page.

I might be a good idea to write a bug-report.

In general, the issue of support semantic highlighting that always works was one of the things I have had bad dreams about when I was implementing it for IntellJ and the only sensible answer is to ignore it. There is no nice and clean solution for all cases.

Improve this answer
$\endgroup$
7
  • $\begingroup$ Good points. I think the OP wanted to know why there wasn't a special pattern case for the Control spec, but you explain it. There are too many things that could be special-cased and the only proper solution would be to massively slow down the FE with hundreds and hundreds of special cases. $\endgroup$
    – b3m2a1
    Sep 7, 2017 at 5:31
  • $\begingroup$ @b3m2a1 Indeed! I was taken away by having the possibility to explain this and simply forgot to explain the particular issue the OP is having. I edited my answer and changed the beginning and the end of my text. Thanks for pointing it out. It was already about 5 in the morning and I simply missed it. $\endgroup$
    – halirutan ♦
    Sep 7, 2017 at 9:33
  • $\begingroup$ @halirutan I'm not surprised, see InputDialog which full syntax is exactly what DynamicModule's is, still no highlighting. $\endgroup$
    – Kuba ♦
    Sep 7, 2017 at 9:34
  • $\begingroup$ @b3m2a1: It's hardly as much of a special case as that. In fact I'd argue that it's the more common way of defining controls in Manipulate. And in any case, reporting "global symbol that has no value assigned" for a perfectly well defined local is a bug if anything is. $\endgroup$
    – orome
    Sep 7, 2017 at 13:52
  • 2
    $\begingroup$ @raxacoricofallapatorius Maybe it is a bug, but did you ask WRI Support? Even though the case is quite simple notice that it is Manipulate's variable but with Control it is one level deeper than other cases with local variables. So maybe this is the limit they set up due to reason halirutan mentioned. $\endgroup$
    – Kuba ♦
    Sep 7, 2017 at 19:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.