Adventures with org-footnote-auto-adjust

Adventures with org-footnote-auto-adjust

[Thomas S. Dye]

Aloha all,

I keep footnotes in their own section and appreciate having them out of
the way, where I don't have to think about them.

Recently, I set #+STARTUP: fnadjust because I thought it would be nice
to have the footnotes sorted and renumbered.  This was a mistake in my
case that lost data.  I think I know how it happened, though I wasn't
really paying attention to the footnotes as I worked.

In the document I'm editing, I have sentences like this:

  If you want a list to start with a different value (e.g., 20),[fn:17]
  start the text of the item with ~[@20]~.

As a matter of style, I prefer the footnote (which contains qualifying
text, rather than a reference) be at the end of the sentence, and that
it immediately follow the period.  So, I cut and paste to get this:

  If you want a list to start with a different value (e.g., 20),
  start the text of the item with ~[@20]~.[fn:17]

Now, the next time I insert a footnote, with C-c C-x f, I get something
like this:

  If you want a list to start with a different value (e.g., 20),[fn:17]
  start the text of the item with ~[@20]~.[fn:17]

The text of the original footnote, [fn:17], is lost, though the mark
remains in the text.  If the new [fn:17] is some distance away, then the
problem of duplicate numbers isn't readily apparent in the midst of
other work.  Of course, I subsequently discovered that `~.[fn:17]'
wasn't working and put the space back in.  Now, the footnote refers to
the wrong text.

I've learned that there are certain conditions (I don't know how many)
where the space after a sentence won't accept a footnote insertion. The
example sentence is one of these. Apparently, it is the `~.' combination
that triggers the condition. Org is good enough to prohibit inserting a
new footnote into one of these "black holes" (which is how I discovered
them), but it doesn't mind if I cut and paste a footnote into one. 

I'm not certain how much mischief this might have caused. I discovered
the problem when the text of *both* footnotes in a section of the
document were incorrect.

In my case, org-footnote-auto-adjust doesn't perform any crucial
function--it just makes the Org mode buffer seem more orderly.  Given
that there are "black holes" in the buffer, whose presence have the
ability to confuse org-footnote-auto-adjust so that data are lost,
should org-footnote-auto-adjust be deprecated?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Adventures with org-footnote-auto-adjust

[Nicolas Goaziou]

Hello,

tsd@tsdye.com (Thomas S. Dye) writes:

> In the document I'm editing, I have sentences like this:
>
>   If you want a list to start with a different value (e.g., 20),[fn:17]
>   start the text of the item with ~[@20]~.
>
> As a matter of style, I prefer the footnote (which contains qualifying
> text, rather than a reference) be at the end of the sentence, and that
> it immediately follow the period.  So, I cut and paste to get this:
>
>   If you want a list to start with a different value (e.g., 20),
>   start the text of the item with ~[@20]~.[fn:17]
>
> Now, the next time I insert a footnote, with C-c C-x f, I get something
> like this:
>
>   If you want a list to start with a different value (e.g., 20),[fn:17]
>   start the text of the item with ~[@20]~.[fn:17]
>
> The text of the original footnote, [fn:17], is lost, though the mark
> remains in the text.  If the new [fn:17] is some distance away, then the
> problem of duplicate numbers isn't readily apparent in the midst of
> other work.  Of course, I subsequently discovered that `~.[fn:17]'
> wasn't working and put the space back in.  Now, the footnote refers to
> the wrong text.
>
> I've learned that there are certain conditions (I don't know how many)
> where the space after a sentence won't accept a footnote insertion.

There shouldn't be any of such conditions.

> The example sentence is one of these. Apparently, it is the `~.'
> combination that triggers the condition. Org is good enough to
> prohibit inserting a new footnote into one of these "black holes"
> (which is how I discovered them), but it doesn't mind if I cut and
> paste a footnote into one.

I fixed it. Footnote references should be allowed there.

> I'm not certain how much mischief this might have caused. I discovered
> the problem when the text of *both* footnotes in a section of the
> document were incorrect.
>
> In my case, org-footnote-auto-adjust doesn't perform any crucial
> function--it just makes the Org mode buffer seem more orderly.  Given
> that there are "black holes" in the buffer, whose presence have the
> ability to confuse org-footnote-auto-adjust so that data are lost,
> should org-footnote-auto-adjust be deprecated?

`org-footnote-auto-adjust' still does its job when, for example, a new
footnote is created or a footnote is deleted. It is fragile when
copy-pasting a footnote reference across some text.

Anyway, it should be possible to fix most of these "black holes", if
only we are aware of them.

Thanks for your report.


Regards,

-- 
Nicolas Goaziou

Re: Adventures with org-footnote-auto-adjust

[Thomas S. Dye]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> I've learned that there are certain conditions (I don't know how many)
>> where the space after a sentence won't accept a footnote insertion.
>
> There shouldn't be any of such conditions.

Great.  I'll be on the lookout and will report when I find them.

>
>> The example sentence is one of these. Apparently, it is the `~.'
>> combination that triggers the condition. Org is good enough to
>> prohibit inserting a new footnote into one of these "black holes"
>> (which is how I discovered them), but it doesn't mind if I cut and
>> paste a footnote into one.
>
> I fixed it. Footnote references should be allowed there.

Yes, I can confirm that this is fixed.  Thanks!
>
>> I'm not certain how much mischief this might have caused. I discovered
>> the problem when the text of *both* footnotes in a section of the
>> document were incorrect.
>>
>> In my case, org-footnote-auto-adjust doesn't perform any crucial
>> function--it just makes the Org mode buffer seem more orderly.  Given
>> that there are "black holes" in the buffer, whose presence have the
>> ability to confuse org-footnote-auto-adjust so that data are lost,
>> should org-footnote-auto-adjust be deprecated?
>
> `org-footnote-auto-adjust' still does its job when, for example, a new
> footnote is created or a footnote is deleted. It is fragile when
> copy-pasting a footnote reference across some text.
>

In my case, the intended effects of `org-footnote-auto-adjust' were
purely cosmetic in the Org buffer and didn't affect the output.  Is
there a situation where it does something that has an effect on output?

> Anyway, it should be possible to fix most of these "black holes", if
> only we are aware of them.

OK. Apologies for the graphic term. I hope it didn't offend. Dismay got
the better of tact, I think.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: Adventures with org-footnote-auto-adjust

[Nicolas Goaziou]

tsd@tsdye.com (Thomas S. Dye) writes:

> In my case, the intended effects of `org-footnote-auto-adjust' were
> purely cosmetic in the Org buffer and didn't affect the output.  Is
> there a situation where it does something that has an effect on
> output?

No, there is none.

> OK. Apologies for the graphic term. I hope it didn't offend. Dismay got
> the better of tact, I think.

No offence taken. I couldn't come with a better name either.


Regards,

-- 
Nicolas Goaziou