44
$\begingroup$

Bug introduced in 10.0.0 and persisting through 11.1.1 or later


In Mathematica 9, typing in an input alias such as intt would result in the keyboard cursor automatically positioned within the first SelectionPlaceholder and ready to type inside it. However, in Mathematica 10 when I type it the keyboard cursor is placed to the side of the selection placeholder.

Is anyone else experiencing this? In MMA10, how do you go creating a placeholder so that when you type the alias the keyboard cursor is already positioned within the first box?

Issue still exists in 11.1.1, similar the same bug confirmed by WRI causes InputAliases and SelectionPlaceholder issue in V10. So user defined aliases are affected too:

CreateDocument[{}, 
 InputAliases -> {"[" -> RowBox[{"〚", "\[SelectionPlaceholder]", "〛"}]}
]

Already emailed wolfram several months ago but nothing other than the standard "we'll look into it."

$\endgroup$
  • 10
    $\begingroup$ I can reproduce it. I would report this problem to Wolfram support (support at wolfram.com). $\endgroup$ – Szabolcs Jul 11 '14 at 22:53
  • $\begingroup$ I've noticed that you do this in a text cell without already being in an inline math cell you get the cursor very far to the right of the symbol with a lot of whitespace in between the symbol and the cursor. However, in an input cell or being in an inline math cell in a text cell you get the behavior you describe. I notice in this case you can press tab to have the cursor jump to the dx placeholder and pressing tab again puts the cursor in the first placeholder. $\endgroup$ – sykh Jul 12 '14 at 1:24
  • $\begingroup$ This problem still seems to exist in 10.0.1 and is related to this other bug: mathematica.stackexchange.com/questions/55734/… $\endgroup$ – 1110101001 Sep 17 '14 at 4:01
  • 1
    $\begingroup$ Anyone have a solution for this? It takes 3 key presses (left arrow twice and tab once) to move to the selection placeholder now. It use to take zero. $\endgroup$ – Michael McCain Sep 9 '15 at 23:58
  • 1
    $\begingroup$ @QuantumDot: bug persists in 10.3. I just edited original question to indicate that. $\endgroup$ – murray Oct 23 '15 at 15:09
11
$\begingroup$

Just to give everyone an update on this.

Yes, this is a real bug. We identified the cause some time ago (certainly before 11 shipped). We are still working on a solution which doesn't break other things. I have been pestering the relevant folk from time to time as it annoys me too, though we are all in agreement that this is a significant issue worthy of attention. It's just not the sort of "erase user's harddrive" level of bug which will automatically jump ahead of all other development work.

Sorry. I will update this answer once it is fixed.

$\endgroup$
  • 1
    $\begingroup$ Thanks for the update. I take it (55734) will receive attention at the same time as this one? $\endgroup$ – Mr.Wizard Jul 15 '17 at 0:18
  • $\begingroup$ I assumed that it was changed in v10 because the new behavior was deemed better. I'm glad it is a bug and the intention is to fix it. $\endgroup$ – QuantumDot Jul 15 '17 at 0:27
  • $\begingroup$ @Mr.Wizard Yes, this is the same issue. I will add an answer to that effect. $\endgroup$ – Itai Seggev Jul 15 '17 at 3:52
  • $\begingroup$ @ItaiSeggev - Do you have any updates on whether a fix is still in the works? If not, I'm looking for an alternate solution here: mathematica.stackexchange.com/questions/193524/… $\endgroup$ – Michael McCain Mar 19 at 3:26
  • 2
    $\begingroup$ It appears this was still not fixed in Version 12. $\endgroup$ – Michael McCain Apr 17 at 19:41
2
$\begingroup$

As of 11.3 this is still an issue. Following the suggestion of @KellenMyers in the comments above, I altered my KeyEventTranslations.tr file (located in "$InstallationDirectory/SystemFiles/FrontEnd/TextResources/X/" in the Linux distribution) in the following manner to obtain the desired behavior for InputAliases and InputAutoReplacements with \[SelectionPlaceholder] OR \[Placeholder] in their expressions.

Commented the default:

(*Item[KeyEvent["Escape"], "ShortNameDelimiter"], *)

and added:

Item[KeyEvent["Escape"], FrontEndExecute[{FrontEnd`NotebookWrite[FrontEnd`InputNotebook[], "\[AliasDelimiter]"],FrontEnd`FrontEndToken["Tab"]}]],

Item[KeyEvent[" ",Modifiers->{Shift}], FrontEndExecute[{FrontEnd`NotebookWrite[FrontEnd`InputNotebook[], " ", Placeholder], FrontEnd`FrontEndToken["Tab"]}]],

Note that Shift+" " is introduced to execute InputAutoReplacements with automatically selected Placeholders, whereas just " " will give the usual behavior with the cursor placed after the expression.

If the InputAlias or InputAutoReplacement expression involves more than one Placeholder, note that:

Caveat 1: these modifications will select the last one, independently of whether you use \[SelectionPlaceholder] or [Placeholder]. (In this sense the \[SelectionPlaceholder] problem is still unresolved...) Using Tab or Shift+Tab you can move as usual through the other placeholders.

Caveat 2: also, if you need to introduce esc+chars+esc combinations in one Placeholder while other Placeholders are available in the expression you will have to reposition the cursor after the first esc+, as the Tab in its definition will immediately select the next Placeholder before you can introduce the remaining chars+esc.

I should note that all my other definitions in this file of the form "Item[KeyEvent[key, Modifiers->{mods}], FEaction]" where FEaction involves \[SelectionPlaceholder] and \[Placeholder] always behaved as expected in the FE.

$\endgroup$

protected by Kuba Apr 15 '16 at 6:51

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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