46

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

QuantumDot
  • 19,601
  • 7
  • 45
  • 121
1110101001
  • 1,979
  • 13
  • 24
  • 10
    I can reproduce it. I would report this problem to Wolfram support (support at wolfram.com). – Szabolcs Jul 11 '14 at 22:53
  • 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. –  Jul 12 '14 at 01:24
  • This problem still seems to exist in 10.0.1 and is related to this other bug: http://mathematica.stackexchange.com/questions/55734/inputaliases-and-selectionplaceholder-issue-in-v10 – 1110101001 Sep 17 '14 at 04:01
  • I have this problem every time and it drives me up the wall. – Kellen Myers Feb 04 '15 at 23:20
  • @KellenMyers If you use it often you can do what I did and remap the escape key to input escape key + tab in keytranslations.tr as follows: Item[KeyEvent[" ", Modifiers -> {Shift}], FrontEndExecute[{FrontEndNotebookWrite[FrontEndInputNotebook[], "[AliasDelimiter]", After], FrontEnd`FrontEndToken["Tab"]}]] (I use space + shift as my escape key, change if yours is different) – 1110101001 Feb 06 '15 at 06:24
  • Perhaps one of the mathematica gurus here can come up with a more elegant solution – 1110101001 Feb 06 '15 at 06:26
  • 1
    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. – B flat Sep 09 '15 at 23:58
  • @MichaelMcCain As I commented a while back a hacky solution is to remap your escape key to input a tab after the escape so that upon expansion the cursor automatically is moved to the corrent position. – 1110101001 Sep 12 '15 at 21:33
  • Yes that does work! I'm sorry I meant to ask for a solution for auto replacements and not input aliases. It's the exact same problem. I find auto replacements are a lot quicker than pressing the escape key twice. Do you have a solution for auto replacements? Thanks in advance! – B flat Sep 14 '15 at 23:46
  • @MichaelMcCain input auto replacements seem to work fine for me, even those with selection placeholders. For example, this is my definition of forall : RowBox[{SubscriptBox["\[ForAll]", "\[SelectionPlaceholder]"], " ", "(", "\[Placeholder]", ")"}] which as expected places the cursor in the first selection placeholder. Is there a particular example of one not working for you? – 1110101001 Sep 15 '15 at 04:49
  • @murray What is the situation in Mathematica 10.3? – QuantumDot Oct 23 '15 at 04:21
  • 1
    @QuantumDot: bug persists in 10.3. I just edited original question to indicate that. – murray Oct 23 '15 at 15:09
  • I spoke with Wolfram about this issue in detail. Here in the response which doesn't make sense to me because it was supported in previous versions. The support engineer responded with.... I give up. "I spent some time with the front end developers and they felt the behavior you are seeing with the cursor outside the cell is correct. For what you want to do they suggested using a PasteButton to paste the template. What you want is not supported." – B flat Oct 23 '15 at 18:24
  • @MichaelMcCain Well that clearly defeats the purpose of the selectionplaceholder – 1110101001 Oct 24 '15 at 20:30
  • That's what I told them. Their view is that it does work. It works in an input cell. I can confirm that it does work perfectly in an input cell. Those of us that do typesetting in text cells are out of luck. It doesn't make sense as many of use text cells almost exclusively. I would encourage anyone to call into tech support and complain about this. Especially since it worked before and now it doesn't. – B flat Oct 24 '15 at 20:36
  • @MichaelMcCain I don't understand what you mean by "it works perfectly in an input cell." On my computer, the sequence [esc]intt[esc] does not lead to the cursor being placed in the first SelectionPlaceholder in an input cell. Have I misunderstood you? – QuantumDot Dec 11 '15 at 22:50
  • @QuantumDot - It works perfectly in an input cell with InputAutoReplacements. I don't care for AutoInputAliases. I was looking for a solution in a test cell, as this is where most of my typesetting appears. – B flat Dec 12 '15 at 00:17
  • I'm sorry... I mean to say text cell (not test cell). – B flat Dec 12 '15 at 00:24
  • I noticed that \SelectionPlaceHolder gets inserted as \PlaceHolder when my aliases are executed. –  Apr 14 '16 at 20:08
  • I know what you mean. After typing intt, I use shift + tab and then tab from there. – Milad P. May 30 '16 at 07:13
  • In 10.4.1, after I type [esc]intt[esc] in an Input cell, the cursor is placed immediately after the first placeholder. And surely that's improper behavior. – murray May 30 '16 at 14:52

2 Answers2

13

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.

Itai Seggev
  • 14,113
  • 60
  • 84
  • 1
    Thanks for the update. I take it (55734) will receive attention at the same time as this one? – Mr.Wizard Jul 15 '17 at 00:18
  • 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. – QuantumDot Jul 15 '17 at 00:27
  • @Mr.Wizard Yes, this is the same issue. I will add an answer to that effect. – Itai Seggev Jul 15 '17 at 03:52
  • 1
    @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: https://mathematica.stackexchange.com/questions/193524/moving-to-the-last-placeholder-with-inputautoreplacements – B flat Mar 19 '19 at 03:26
  • 3
    It appears this was still not fixed in Version 12. – B flat Apr 17 '19 at 19:41
  • @ItaiSeggev Four years and still not fixed in the version 12.2 :( – jjagmath Apr 19 '21 at 20:37
3

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.

amarojrs
  • 51
  • 4