7,286 reputation
2247
bio website wolfram.com
location Chesterfield, MO
age 42
visits member for 2 years, 5 months
seen 16 hours ago

I've been with Wolfram Research in some capacity since 1993, and have worked on the Mathematica front end since 1996. While Wolfram tolerates and even occasionally encourages my appearances in user forums like this one, my words (especially the stupid ones) are my own, and I don't speak for Wolfram in an official capacity.

Fun facts: I also like games of all sorts, and I'm a competitive Scrabble® player. I've written various sorts of crossword game-related utilities (some fun, some dead ends, some serious) in Mathematica, and consulted briefly on Wolfram|Alpha's word game content. I also contributed UI code to an open source crossword game simulator called Quackle which is quite the thing in the competitive player community.


Apr
10
awarded  Nice Answer
Jan
30
awarded  Yearling
Dec
25
awarded  Enlightened
Dec
25
awarded  Nice Answer
Dec
6
awarded  Nice Answer
Dec
5
awarded  Enlightened
Dec
5
awarded  Nice Answer
Nov
2
answered Add text before TraditionalForm
Nov
2
answered Time constraints on KernelExecute commands or MenuItems?
Oct
29
comment Frontend coloring of Table[x, {x, 0, x}]
That having been said, I do think that the coloring of the DynamicModule case in the answer above is correct. Yes, the code might be correct, but it is confusing and potentially error-prone. A little-understood fact about syntax coloring is that it never colors red illegal code (except after a Shift+Enter syntax fail). Take a look. Every red coloring is legal Mathematica code. But, if we've done our jobs correctly, red coloring is an indication of buggy code on the user's part. I.e., red means you hit an antipattern which often results in the code performing not as you intended.
Oct
29
comment Frontend coloring of Table[x, {x, 0, x}]
FWIW I think that we should be capturing these comparatively minor end-cases. Using the current feature set, though, implementation on WRI's end is time-consuming...too much so for the limited reward per case we capture. But I'm thinking two and three versions ahead, and I'm already laying out plans...
Oct
25
awarded  Necromancer
Oct
22
answered Notebook vs. DocumentNotebook; display a Notebook inline, like a DocumentNotebook
Sep
27
comment FrameLabel and OverTilde
@Szabolcs and et al., I find it bizarre that, with two answers up as I write this comment, one leapt straight to linear syntax/boxes and the other to fixing up ToString. Both answers are correct and sufficient, but surely a solution involving Row is easier to understand and apply to other similar problems.
Sep
17
awarded  Necromancer
Sep
17
comment Convert ImageSize to FieldSize
If you're working with Grid, then for the love of all that is good and holy, don't do it this way. Use Pane to define your constraints, and let Grid just snap itself to the Pane elements.
Sep
15
comment Module Inside ToBoxes or MakeBoxes
Incidentally, I've fixed the lack of proper syntax highlighting on Dynamic@x. In my development version, the non-DynamicModule version now highlights the x red in all appropriate places.
Sep
15
comment Manipulate and function definition
@Gabriel I'm thinking of Manipulate as a form of DynamicModule. DynamicModule does lexical scoping. It's generally a bad idea to assign a lexically scoped localized variable to a global symbol (as you are assigning h in terms of b). It's difficult to understand, it may not do what you want, and the behavior might change depending upon implementational details. Therefore, I would strongly prefer DynamicModule (and Module) variables to be passed directly as function arguments without side-effect assignments.
Sep
14
comment Module Inside ToBoxes or MakeBoxes
This is exactly what DynamicModule was designed to do, and it is exactly what I've warned against where Module is concerned. In 9.0.1, the code in your question would have colored red to warn you, except for a bug that causes it to not color for Dynamic@x (as opposed to Dynamic[x]).
Sep
14
comment Options CellLabel not showing
This is exactly the issue. The way CellLabelAutoDelete works is that it prevents the CellLabel option from being serialized (either to disk or to MathLink). Internally, the Options code has significant overlap with the serialization code and, for better or worse, the decision on how to treat CellLabel is getting caught up in that. I won't necessarily defend this as the best and most correct way of doing things, but that's why it behaves the way it does.