using callwords when caret isn't at colum 1

[syrupcore]

If you hit tab and use a callword that has content in the "Insert after caret", the snippet is inserted at the beginning of the line and includes a pipe (|) with some portion of the snippet content missing based on the caret's current column position - 1. Here's a series of experiments inserting a snippet with "123456789" as it's content in the "Insert after caret" box. The first is with the caret in position 1 and the rest are hitting and additional space time each.

Code: Select all

123456789
|23456789
|13456789
|12456789
|12356789
|12346789


The second line is a single space so "1" is removed, the third is two spaces so "2" is removed. The | is actually ending up where the cursor is supposed to be according to the snippet. So, if you change the 123456789 snippet to be "1234" in "before caret" and "56789" to "after caret" you get:

Code: Select all

one tab: 1234|5679 with the caret blinking between 7 and 9
two spaces: 1234|5789 with the caret between 5 and 7
anything position beyond 10 columns: 1234|5678 with the caret after the 8


Your cursor ends up as equal to: whatever your starting position was + the position of the caret according to the snippet.

Couple of other scenarios I came across:
If the snippet only has content in the "before" box
or
If the snippet has a linebreak in the before or after boxes, it renders fine from any position but it is rendered starting at column 1. For instance, try it with the included javascript function() snippet.


I'm using 9.0.0.97.

Thanks,
Will

[syrupcore]

Just to add, snippets called when not on column 1 via keyboard shortcuts work just fine. Again, try the js function snippet included in the library.

Actually, the cursor returns to the 1st column in that example, no matter where you call it from. I reckon it should insert to the same column as the snippet text but I'm getting ahead myself here. :)

[Karlis]

I'm afraid I do not get it. Or it does not happen for me. Any chance of having a wink video?

[syrupcore]

Here you go.

http://luktown.org/random/blumentals_-_ ... -caret.swf

[syrupcore]

to recreate this...

1. Create a snippet with "123456789" in the "insert after" box.
2. Assign a callword to this snippet
3. In the editor, type the callword and hit ctrl+J (should render fine)
4. New line, hit space and then type the callword and hit ctrl+j (you'll be missing the 1 and there will be a | instead)
5. New line, hit two spaces and then type the callword and hit ctrl+j (you'll be missing the 2 and there will be a | instead)

Where ever the cursor is in relation to column 1, that's the number that will be replaced with a pipe. Behavior is slightly different when there's text in both the before and after boxes - give it a try. Also, when it's all in the "before" box, the snippet is rendered on column 1. It should, I think, be rendered where the caret is when it's called (which it does if you use a keyboard shortcut instead of a callword).

Will

[syrupcore]

Found it... I think. Works fine when tabbed if "constrain cursor to text" is UNchecked.

[syrupcore]

I don't know if this is related but ran into this tonight.

If you create a snippet with this in the before box

Code: Select all

<form action="form-action">
   <fieldset>
      <legend>


and this in the after box

Code: Select all

</legend>

      <label for=""></label>
      <input type="text" id="" name="" />

      <button type="submit" value=""></button>

   </fieldset>
</form>


The <legend> line comes out wacky.

Code: Select all

<lgend>|</legend> 


Doesn't matter from which column you call the snippet. This happens if the "Constrain Cursor to Text" is checked or unchecked. The snippet works fine if you use a keyboard shortcut instead of a callword.


Hope all of this stuff is helpful and not annoying.

Thanks,
Will

[syrupcore]

hello? able to recreate?

[Gatis]

Sorry for the delayed reply.
Yes, we could reproduce the problem. However, the problem could only be reproduced if the option "Constraint cursor to text" was enabled.
We need to do some more testing, but the fix seems to be alright, and it will be included in the next update.
If you, syrupcore, are willing to see if it works fine now, please drop an email at our support email address and we shall give you the test version before next update.

[syrupcore]

Thanks gatis. Email sent.

[syrupcore]

note: this has been resolved in v9.0.99

Thanks guys!