Footnote reference changes form

This is a new bug since the update to 2.4. I have my prefs set to mark footnotes with an asterisk. When I drag a footnote from the comments & footnote list to a new location in the text, instead of creating a new asterisk at the new location, as it did in the previous version, the ref in the text now expands to include the whole word (the default behavior). Thanks.

I can’t reproduce this - it works fine for me in 2.4.1. Can you please provide the exact steps?
Thanks,
Keith

Hi Keith
I’ve attached a tester scrivener file so you can see what’s up. There’s a single footnote therein; if you take the ref itself (not the marker) and drag it to a new location you get a copy of the note, and the reference is applied not to an asterisk but to the entire word. There’s a screenshot in the sv file that will show you what’s up.
Thanks.
tester2.scriv.zip (127 KB)

The test project is working correctly, since it’s not set to use a footnote marker in the Project > Text Preferences.

All the best,
Keith

HI Keith,

It is set correctly in the project as I sent it to you–see the screenshot. I’ve got this as the default setting for all of my SV projects; where is this default setting stored? Perhaps a new default is imposed when the file is opened elsewhere. In any case, it’s still misbehaving!
Thanks.

Out of interest, I tried this with the example project and one of my own, and I get the same behaviour as mortimer reports. It’s not something I’ve ever tried to do before, so I can’t say if it’s new. Now that we’re here, however, I note that dragging the footnote from the inspector to a new place in the main editor window duplicates the footnote. I would have expected it to move the marker while retaining the original footnote instead of duplicating, but that’s just my personal expectation. Not a big deal.

Martin.

Oops, sorry, you’re right. I tested on my own latest build, not on 2.4.1. For the 2.5 update, I have fixed the bug Martin reports whereby dragging footnotes from the inspector copies them rather than moves them. This is most likely what is causing the behaviour that Mortimer is seeing, too. So, fixed for 2.5, thanks!