Idea: New fragment selector button "insert or elide"

[david-a-wheeler]

I can't figure out a good way to help handle parentheses in "edit" mode. I think the fundamental problem is that the editor can't know which part of the expression you care about. But there's already functionality for this - the fragment selector.

So I propose adding a new button to the fragment selector, "Insert or Elide", with icon "+A".

This would let you insert text, plus the parentheses that surround it, in a way sensitive to fragments. It would even let you insert text "on both sides", e.g., of an equation. It'd also let you elide (remove) text in a way that automatically handles parentheses.

When you click on it, it pops up a dialogue box (mockup below) that lets you insert or elide text in a fragment-aware way. The heading just says "Insert or Elide"
It then shows the field name "Initial:" followed below by a copy of whatever fragment had been selected. In this case, "A = B".

Then there are checkboxes (all checked by default):

• Insert (else elide) - normally this inserts new text, but if unchecked this will elide some text of the fragment.
• on left (else right)
• on both sides (else one side)

I am intentionally picking checkboxes and NOT dropdowns - dropdowns take longer to manipulate, and you want this selection process to be fast. There are only 2 options in each case, too, making dropdowns pointless.

This followed by:

• An editable box for the "start of parentheses" symbol, "(" by default. It can be empty. If you edit this, its corresponding "end of parentheses" symbol is updated.
• An editable box of what to insert. I drew two boxes, but I just realized that 1 are unnecessary, one will do & might be easier to use. If "insert" is not checked, this editable box disappears.
• The fixed text "initial" ("what to insert" and "initial" are swapped in position with "on left" is unchecked).
• An editable box for the "end of parentheses" symbol, ")" by default. It can be empty. Editing this doesn't change the "start of parentheses" symbol in case you're doing an unusual pair of "parentheses".

Then the fixed text "Result:"

This is followed by the calculated result based on what's above. The result is updated whenever the inputs are changed. The calculations are pretty simple, e.g.:

• Initial "A = B" with "insert" "left" "on both sides" with text "(" "1 +" ")" would produce "( 1 + A ) = ( 1 + B )".
• Initial "A = B" with "insert" "left" "NOT on both sides" with text "(" "1 +" ")" would produce "( 1 + (A = B ) )".
• Initial "A = B" with "insert" "NOT left" "on both sides" with text "(" "+ 1" ")" would produce "( A + 1 ) = ( B + 1 )".
• Initial "( A + B )" with "NOT insert" "left" "NOT on both sides" with text "(" ... ")" would produce "B".

Under this is what to do with the results (these might be icons):

• Copy - Copy to clipboard
• Cancel
• Initial - Copy the reult into a new "initial" value, for insertion inception. You might also want an "undo" button on this row.
• Paste - (only in editor) paste into the current fragment selection
• Step above / step below - create a new step using the result as the step's statement (after a copy of the original typecode).

I put this into a single dialogue box because "initial" looks handy & it'd be hard to understand if it weren't all in one dialogue box.

Here's a mock-up picture.

[david-a-wheeler]

I picked "+A" as the icon because "A+" looks like a grade, "+1" looks like a vote, and "1+" looks like a hint at "one or more" (which isn't the point). If the icon is "+A", maybe the checkbox should be "on the right" instead of "on the left".

[david-a-wheeler]

Also, in the result, the parentheses & editable box outcomes should be marked somehow, perhaps surrounded by a box (like visualization). The editable box, if empty, should still be obvious somehow (e.g., as a box or underlined empty area).

[expln]

That's a good idea. I also was thinking on implementing of different "smart" actions on selected fragments. For example, swapping left and right, applying associativity law (e.g. transforming ( a op ( b op c ) ) to ( ( a op b ) op c )), etc. The one you proposed is also very good, I will implement it too. I am also thinking if it is possible to do something very generic when users define transformation changes via regexp and/or some special language. In that case such transformations will not be hardcoded and users will be able to define custom ones without waiting for them to be implemented in mm-lamp.

[david-a-wheeler]

I also was thinking on implementing of different "smart" actions on selected fragments. For example, swapping left and right, applying associativity law (e.g. transforming ( a op ( b op c ) ) to ( ( a op b ) op c )), etc. The one you proposed is also very good, I will implement it too. I am also thinking if it is possible to do something very generic when users define transformation changes via regexp and/or some special language.

Cool, great minds think alike :-). I'm sure it's possible to define a special language, but I don't think users will want to define a language for simple cases. Having a few buttons to quickly apply "common cases" should be fine for now. After undo/redo, full unification, and a few other goodies, I imagine it'd be useful to eventually implement a full language for processing. However, I think that'd be a longer-term effort, best done after other things are addressed.

[david-a-wheeler]

I think the "basic" operations are something like:

• Insert, e.g., X => ( X + A ).
  • "Both sides", e.g., X = Y => ( X + A ) = ( Y + A )
  • left/right side
• Elide, e.g., ( X + A ) => X
  • left/right side
• Commute (swap), e.g., X = Y => Y = X
• Associate as above, e.g., ( A + ( B + C ) ) => ( ( A + B ) + C )

I think all of them would sensibly have a "both sides" option, though that doesn't mean that should be implemented.

There are a lot of ways to do this: dialogue box, menus with submenus, etc. As always, easy is good, and having some feedback of "this is what it will look like" before doing it would be helpful.

[expln]

I understand that it is better to implement something which is very specific but at least works, than something very generic which will require more time for implementation. But it is very boring for me to implement that simple and straightforward solution :) I don't want mm-lamp to turn from a hobby project to a "second job" for me :)

Currently I am considering two possible implementations. One is as you suggested when there is a dialog with few options which affect the final result. Another is a list where each list item shows a ready result (with background highlighting to understand the change faster), so users can see what is available in current context and can click it to select. Clicking one of the list items may open another dialog where the user will have to provide some additional data, for example, what new text to add, and chose how to apply the result - replace existing or add a new step below/above. I will chose which one to implement later. However, since I am considering the "customizable" version of this feature, the later approach seems more suitable.

As the language for custom transformations, I think, I will use regular JS which I will "evaluate" in a sandboxed iframe. So users will not have to learn a very specific new language. The transformations you mentioned will be available as a predefined ones in the settings. However users will be able to add their own ones if they need by adding some JS code in the settings.

[david-a-wheeler]

I understand that it is better to implement something which is very specific but at least works, than something very generic which will require more time for implementation. But it is very boring for me to implement that simple and straightforward solution :) I don't want mm-lamp to turn from a hobby project to a "second job" for me :)

You know your own motivations best, so if you want to go elaborate, enjoy!!

Currently I am considering two possible implementations. One is as you suggested when there is a dialog with few options which affect the final result. Another is a list where each list item shows a ready result (with background highlighting to understand the change faster), so users can see what is available in current context and can click it to select.

Both approaches make sense to me. To me a key would be to "only enter what you need", that is, if you're doing "( ... + 1 )" on both sides, you shouldn't need to enter "+ 1" twice. Bonus points if you can paste from the clipboard into the "main" text entry area in a dialogue box.

I suggest just letting it stew in your subconscious for a bit, sometimes the best results come from that.

In any case, I think this is all much less important than undo/redo and full unification.

[david-a-wheeler]

Another is a list where each list item shows a ready result (with background highlighting to understand the change faster), so users can see what is available in current context and can click it to select. Clicking one of the list items may open another dialog where the user will have to provide some additional data, for example, what new text to add, and chose how to apply the result - replace existing or add a new step below/above.

That's an interesting approach. As I mentioned earlier, I think this is less important than undo/redo or full unification, but it's definitely worth discussion.

That would be flexible (especially if you can easily add your own). Let's call these "tranforms" so we have a name. I was wondering how to make it so commonly-used transforms would be quick to select. Here's one idea: establish a convention where the name is a comma+space separated list of terms. The user could type into a search box, and each alphanumeric should select only the case where the first alphenum in search matched the first term alphanum in the name, the second the second, and so on. I think matching should ignore upper/lowercase to make it easier on smartphones. E.g., if you have:

• Associate, 1-sided, left
• Associate, 1-sided, right
• Associate, both sides, left
• Commute (swap), 1-sided

Then when the user enters "a" into the search bar only the "Associate" ones are displayed, then when the user makes the search "a1" then only the "Associate, 1-sided" ones are still displayed, etc. At any time the user could select an option left over, which would also show the result of that selection.

Also: I suspect the "add new step below/above" should be for the whole expression, not just the selected fragment, or at least that should be an option.

Anyway, I thought I'd share the idea.