46
$\begingroup$

Bug introduced in 10.0.0 and persisting through 12.0.

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."

Improve this question
$\endgroup$
21
  • 10
    $\begingroup$ I can reproduce it. I would report this problem to Wolfram support (support at wolfram.com). $\endgroup$
    – Szabolcs
    Commented Jul 11, 2014 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$
    – user246
    Commented Jul 12, 2014 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
    Commented Sep 17, 2014 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$
    – B flat
    Commented Sep 9, 2015 at 23:58
  • 1
    $\begingroup$ @QuantumDot: bug persists in 10.3. I just edited original question to indicate that. $\endgroup$
    – murray
    Commented Oct 23, 2015 at 15:09

2 Answers 2

Reset to default
14
$\begingroup$

I'm pleased to announce that this will be fixed in the next release!

I'm not a frontend developer, but my understanding of the issue is that it was a subtle interaction between the multiple undo mechanism (which is why this broke in version 10) and the input alias code, so although the behavior was simple, the fix wasn't so obvious. And I know it was frustrating for all us that it took so long to fix, but between having this bug for the last decade and not having multiple undo for the last decade, I know which one I would choose. I hope that thought offers a bit of comfort.

So, look forward to the late fall / early winter release!

Original Answer

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.

Improve this answer
$\endgroup$
7
  • 1
    $\begingroup$ Thanks for the update. I take it (55734) will receive attention at the same time as this one? $\endgroup$
    – Mr.Wizard
    Commented Jul 15, 2017 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
    Commented Jul 15, 2017 at 0:27
  • $\begingroup$ @Mr.Wizard Yes, this is the same issue. I will add an answer to that effect. $\endgroup$
    – Itai Seggev
    Commented Jul 15, 2017 at 3:52
  • 1
    $\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$
    – B flat
    Commented Mar 19, 2019 at 3:26
  • 3
    $\begingroup$ It appears this was still not fixed in Version 12. $\endgroup$
    – B flat
    Commented Apr 17, 2019 at 19:41
3
$\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.

Improve this answer
$\endgroup$

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