Snippets not expanding in NValt - if first character [Fixed 3.2.1 b763 pre-release]

[Mikeatalfred]

Hi

Snippets work great all over macOS including NValt - except as the first input/first-line-first-characters in a note in NValt. This might seem like an edge case but my problem is that I use NValt for journaling and always insert new journal entries at the top of the journal, starting with todays date by using a snippet. This bug can be reproduced every time, and the work-around is to enter any character and then the snippet, then to remove the extra character. Please note that snippets work fine anywhere else in NValt. Thanks /Mike

[deanishe]

Working fine for me. What version of nvALT are you using and what exactly is the snippet? Does the same snippet work in other apps?

 

Please also follow the instructions in the bug report sticky and supply the version of Alfred and OS X/macOS you're running.

Edited December 2, 2016 by deanishe

[Mikeatalfred]

Hi @deanishe, 

Thank you for your reply and input - and you are right, it works fine if you create a new document. So I have to update the bug description, it is a repeatable bug if you try to expand the snippet in an existing text-file in the top left position of the document. So for example: in NValt create a new note, call it test; insert random text; got to top of document; insert a new line (cr); move to the top left position in the document; write snippet - it does not expand the first time

/Mike

Versions:
NValt 2.2.7 (125)
macOS 10.12.1 (16B2555
Alfred 3.2 Build 759
 

Snippet:
Keyword: ddate Snippet: {date}

[deanishe]

Confirmed.

 

Also tested with Typinator snippet expander, which works as expected. Seems to be an Alfred-specific issue.

[Andrew]

@Mikeatalfred try selecting "Expand snippets mid-string" in Alfred's Features > Snippets > [cog] > Options. Alfred may be misinterpreting keystrokes before the snippet as being part of the same word, so not expanding. Mid-string turns off this check.

 

Cheers,

Andrew

[deanishe]

I have that option turned on. Makes no difference.

 

Indeed, I think I've figured out how to provoke the behaviour in any app. It seem that Alfred doesn't handle the DELETE key properly (not BACKSPACE).

 

Pressing DELETE causes Alfred to stop recognising snippet keywords until you've typed as many characters as times you pressed DELETE or enter a "separator" like SPACE, ENTER etc.

 

So, if you delete a selection using DELETE (as I habitually do), Alfred will not expand snippets. If you use BACKSPACE (as people with little keyboards that have no DELETE key presumably do), it works as expected.

Edited December 2, 2016 by deanishe

[Andrew]

@deanishe thanks for working that out - I'll get that sorted in the next release

[Mikeatalfred]

Hi @Andrew,

As @deanishe I also have the Mid-string expansion enabled but the problem is still there. But I understand you're already addressing this.

Thanks /Mike 

[deanishe]

1 hour ago, Mikeatalfred said:

Hi @Andrew,

As @deanishe I also have the Mid-string expansion enabled but the problem is still there. But I understand you're already addressing this.

Thanks /Mike 

 

Not sure this is precisely the same issue as what I found. Which keys are you pressing exactly?

 

It seems that Alfred also gets confused if you use arrow keys (without any modifiers) to move around in text and it stops recognising snippet keywords until you type a character/separator/BACKSPACE. I suspect you're hitting ↑ (UP arrow), and that's what's causing Alfred to get confused.

 

If that is the case, Using ⌘↑ (instead of just ↑) should avoid the issue. Also, hitting BACKSPACE (even if there's nothing to delete) gets Alfred working properly again.

[Mikeatalfred]

My normal behaviour is this: I go to the top of the file by ⌘-↑, Enter, ↑, and then enter the snippet text as the first text in my new entry. And when this doesn't work, I delete the snippet text by hitting destructive backspace and then the snippet again. And this time it works.

 

It is a bit tricky with modifier keys plus arrow keys since most are assigned to window management, but alt-↑ seems unassigned and when using it the snippet expands as expected. So I'd say this aligns with what you say.

 

 

[Andrew]

@deanishe I'm trying to reproduce this just in TextEdit and an unable to reproduce using the delete key (older wide Apple keyboard) or arrow keys.

 

1. I'm typing some text, selecting all using cmd+a, pressing 'delete', then snippets are working as expected.

2. I'm typing some text, using up arrow, typing a snippet keyword and it works as expected

3. I'm trying @Mikeatalfred's cmd+up, enter, up, typing a snippet keyword and it works.

 

hmm :/

 

If you try in TextEdit, what behaviour do you see?

[Mikeatalfred]

@Andrew, maybe you want @deanishe to answer but this is how I reproduce the same error in TextEdit

 

1. I create a new note (cmd+n)

2. I insert two lines of random text

3. I press cmd+up_arrow (to go to the top left position in the note)

4. I press enter to get a new line at top

5. I press up_arrow to go to the top line

6. I write my snippet ("ddate" which should expand to {date}) and it does not expand

 

However, if you don't follow this exactly the snippet expands, for example if I only do 1. and 6. it works. Also, when I jumped between this post and TextEdit to write this post, it worked in some situations. 

[Andrew]

@Mikeatalfred perfect thanks for that! It looks like this issue could actually be macOS Sierra related (my iMac / dev machine is still on El Capitan). Your exact reproducible case works on my iMac but not on my MacBook - I should be able to get this sorted now cheers!

[Andrew]

I can see what is happening, and it's a combination of Alfred trying to be as efficient as possible (fast rejecting certain scenarios to prevent the Alfred Text Service from using any more CPU than absolutely necessary) and a (probable) macOS bug where the fn key is being passed through as an active mod in the reproducible case above.

 

Essentially, when following this case, macOS is reporting that the fn key is still depressed when you type the first 'd' of 'ddate', and Alfred is rejecting this.

 

I've removed this particular 'efficiency' fast fail in the Alfred Text Service and it fixes this issue - I'll be doing a pre-release of 3.2.1 reasonably soon where you'll see the fix

 

Thanks for your help!

 

Cheers,

Andrew

[deanishe]

FWIW, I'm on El Cap.

[Andrew]

@deanishe hm ok - well either way, I suspect it will be fixed for both. I could only reproduce it in Sierra

[Andrew]

Would you two mind updating to the 3.2.1 pre-release and let me know if you see an improvement in the behaviour?

 

Cheers,

Andrew

[Mikeatalfred]

@Andrew, hi! Tried 3.2.1 shortly and I couldn't provoke the bug. Good work!

[deanishe]

Same here. Appears to completely fixed.

[Andrew]

Excellent, thanks for your help chaps

 

Andrew