[dev] footnotes improvements

[dev] footnotes improvements

[Nicolas Goaziou]

Hello,

I'd like to submit a branch for testing:

          git://github.com/ngz/org-mode-lists.git footnote-fix

Here are the changes so far:

- recognize and export inlined footnotes holding links in their definition,
- recognize and export two or more footnotes in a row,
- don't chock at footnotes or partial footnotes inside comments in Org buffer,
- export calls to already defined footnotes in LaTeX,
- export footnotes before first heading (LaTeX),
- export footnotes when selecting a subtree not holding their
  definition (LaTeX),
- fontify more consistently footnotes in the org buffer (only labels
  are "fontified" or fn in the case of an anonymous footnote).

The following snippet demonstrates most of these changes:

----------------------------------------------------------------------
#+title: Footnotes test

Some text before first headline[fn:1].

* First headline

# [fn::fake footnote

  Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
  eiusmod tempor incididunt ut labore et dolore magna
  aliqua[fn::inline1][1].

* Second headline

  Duis aute irure dolor in reprehenderit in voluptate velit esse
  cillum dolore eu fugiat nulla pariatur[fn:inlabel:an inline
  footnote][fn:inlabel2:[[http://www.google.com][google]] this].

  Call an already defined inline footnote[fn:inlabel].

* Footnotes

[fn:1] first footnote.

[1] End of first section.
------------------------------------------------------------------------

There are probably mischievous bugs. So, thanks in advance for any
feedback.

Regards,

-- 
Nicolas Goaziou

Re: [dev] footnotes improvements

[Christian Moe]

Hi,

Nice! Tested only your snippet.


* HTML: works!

One question: As is, adjoining footnotes `2' and `3' read as `23'. 
Could/should the footnote export know to put a comma between them:`2,3'?

For HTML purposes, I think not necessarily, the separator could be 
flexibly added with CSS like:

: #+style: <style>sup + sup .footref:before {content: ", "}</style>


*  Latex: backtrace:

Debugger entered--Lisp error: (void-variable footnote-section-tag-regexp)
   org-export-latex-preprocess((:for-backend latex :emph-multiline t 
:add-text nil :comments nil :skip-before-1st-heading nil 
:LaTeX-fragments nil :timestamps t :footnotes t))
   org-export-preprocess-string(#("#+title: Footnotes test\n\nSome 
text before first headline[fn:1].\n\n" 0 8 (fontified nil 
font-lock-fontified t) 8 9 (fontified nil) 9 23 (fontified nil 
font-lock-fontified t) 23 56 (fontified nil) 56 57 (fontified nil) 57 
61 (fontified nil help-echo "Footnote reference") 61 62 (fontified 
nil) 62 65 (fontified nil)) :for-backend latex :emph-multiline t 
:add-text nil :comments nil :skip-before-1st-heading nil 
:LaTeX-fragments nil :timestamps t :footnotes t)
   org-export-latex-first-lines((:latex-image-options "width=10em" 
:exclude-tags ("noexport") :select-tags ("export") 
:publishing-directory nil :timestamp nil :expand-quoted-html t 
:html-table-tag "<table border=\"2\" cellspacing=\"0\" 
cellpadding=\"6\" rules=\"groups\" frame=\"hsides\">" :xml-declaration 
(("html" . "<?xml version=\"1.0\" encoding=\"%s\"?>") ("php" . "<?php 
echo \"<?xml version=\\\"1.0\\\" encoding=\\\"%s\\\" ?>\"; ?>")) 
:html-postamble auto :html-preamble t :html-extension "html" 
:inline-images maybe :convert-org-links t :agenda-style "" 
:style-extra "" :style "" :style-include-scripts t 
:style-include-default t :table-auto-headline t :tables t 
:time-stamp-file t :creator-info t :email-info nil :author-info t 
:email "CM@Celebrian-2.local" ...) nil nil)
   org-export-as-latex(nil)
   call-interactively(org-export-as-latex)
   org-export(nil)
   call-interactively(org-export nil nil)


Yours,
Christian


On 5/11/11 9:02 PM, Nicolas Goaziou wrote:
> Hello,
>
> I'd like to submit a branch for testing:
>
>            git://github.com/ngz/org-mode-lists.git footnote-fix
>
> Here are the changes so far:
>
> - recognize and export inlined footnotes holding links in their definition,
> - recognize and export two or more footnotes in a row,
> - don't chock at footnotes or partial footnotes inside comments in Org buffer,
> - export calls to already defined footnotes in LaTeX,
> - export footnotes before first heading (LaTeX),
> - export footnotes when selecting a subtree not holding their
>    definition (LaTeX),
> - fontify more consistently footnotes in the org buffer (only labels
>    are "fontified" or fn in the case of an anonymous footnote).
>
> The following snippet demonstrates most of these changes:
>
> ----------------------------------------------------------------------
> #+title: Footnotes test
>
> Some text before first headline[fn:1].
>
> * First headline
>
> # [fn::fake footnote
>
>    Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do
>    eiusmod tempor incididunt ut labore et dolore magna
>    aliqua[fn::inline1][1].
>
> * Second headline
>
>    Duis aute irure dolor in reprehenderit in voluptate velit esse
>    cillum dolore eu fugiat nulla pariatur[fn:inlabel:an inline
>    footnote][fn:inlabel2:[[http://www.google.com][google]] this].
>
>    Call an already defined inline footnote[fn:inlabel].
>
> * Footnotes
>
> [fn:1] first footnote.
>
> [1] End of first section.
> ------------------------------------------------------------------------
>
> There are probably mischievous bugs. So, thanks in advance for any
> feedback.
>
> Regards,
>

Re: [dev] footnotes improvements

[Aankhen]

Hi Christian,

On Thu, May 12, 2011 at 12:49, Christian Moe <mail@christianmoe.com> wrote:
> Nice! Tested only your snippet.
>
>
> * HTML: works!
>
> One question: As is, adjoining footnotes `2' and `3' read as `23'.
> Could/should the footnote export know to put a comma between them:`2,3'?
>
> For HTML purposes, I think not necessarily, the separator could be flexibly
> added with CSS like:
>
> : #+style: <style>sup + sup .footref:before {content: ", "}</style>

From the point of view of semantics, it’d be better to separate them
in the content itself.  For my part, I like Wikipedia’s ‘[1][2]’
style.  ‘1, 2’ sounds even better to me, if it can be done.

Aankhen

Re: [dev] footnotes improvements

[Nicolas Goaziou]

Hello,

Christian Moe <mail@christianmoe.com> writes:

> * HTML: works!
>
> One question: As is, adjoining footnotes `2' and `3' read as `23'.
> Could/should the footnote export know to put a comma between
> them:`2,3'?
>
> For HTML purposes, I think not necessarily, the separator could be
> flexibly added with CSS like:
>
> : #+style: <style>sup + sup .footref:before {content: ", "}</style>

Probably, but I didn't change HTML exporter. I just made it compatible
with the changes applied to the LaTeX one.

>
> *  Latex: backtrace:
>

[...]

Oops I had commented (require footnote) to see what happened and forgot
to uncomment it again. This should be fixed now.

Thanks for testing this.


-- 
Nicolas Goaziou

Re: [dev] footnotes improvements

[Christian Moe]

On 5/12/11 12:04 PM, Nicolas Goaziou wrote:
> Hello,
>
> Christian Moe<mail@christianmoe.com>  writes:
>
>> * HTML: works!
>>
>> One question: As is, adjoining footnotes `2' and `3' read as `23'.
>> Could/should the footnote export know to put a comma between
>> them:`2,3'?
>>
>> For HTML purposes, I think not necessarily, the separator could be
>> flexibly added with CSS like:
>>
>> : #+style:<style>sup + sup .footref:before {content: ", "}</style>
>
> Probably, but I didn't change HTML exporter. I just made it compatible
> with the changes applied to the LaTeX one.

Anyway, the footnote markers are run together in LaTeX, too. So I 
think a (customizable?) separator would be a reader-friendly 
complement to this new adjacent footnote capability.

>>
>> *  Latex: backtrace:
>>
>
> [...]
>
> Oops I had commented (require footnote) to see what happened and forgot
> to uncomment it again. This should be fixed now.

Yes, now it works.

Did I mention how great it is that we can finally put links in inline 
footnotes?

Yours,
Chrsitian

Re: [dev] footnotes improvements

[Nicolas Goaziou]

Hello,

Christian Moe <mail@christianmoe.com> writes:

> Anyway, the footnote markers are run together in LaTeX, too. So
> I think a (customizable?) separator would be a reader-friendly
> complement to this new adjacent footnote capability.

I've added three customizable variables for that:
- org-export-latex-footnote-separator (defaults to "\textsuperscript{,}\\,")
- org-export-html-footnote-separator (defaults to "<sup>, </sup>")
- org-export-docbook-footnote-separator (defaults to "<superscript>,
  </superscript>")

Would that make it?

I also fixed the ascii exporter which I had forgotten in the changes.

Regards,

-- 
Nicolas Goaziou

Re: [dev] footnotes improvements

[Matt Lundin]

Hi Nicolas,

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

> I'd like to submit a branch for testing:
>
>           git://github.com/ngz/org-mode-lists.git footnote-fix
>
> Here are the changes so far:
>
> - recognize and export inlined footnotes holding links in their definition,
> - recognize and export two or more footnotes in a row,
> - don't chock at footnotes or partial footnotes inside comments in Org buffer,
> - export calls to already defined footnotes in LaTeX,
> - export footnotes before first heading (LaTeX),
> - export footnotes when selecting a subtree not holding their
>   definition (LaTeX),
> - fontify more consistently footnotes in the org buffer (only labels
>   are "fontified" or fn in the case of an anonymous footnote).
>

Thanks for these changes! They are great.

First, a general consideration: my vote would be for highlighting the
entire footnote label, including the brackets. IMO, leaving the brackets
in the default face makes it more difficult to scan the buffer.
(Similarly, I think it might be nice to fontify the entire contents of
inline footnotes.)

Secondly, although the following issue is not explicitly addressed by
your patch, I thought I'd bring it up now, as the footnotes export
mechanism is fresh in your mind.

Square brackets containing digits inside of footnotes cause some issues.
The primary use for such brackets would be to include LaTeX cite macros
inside of footnotes. I imagine this might be tricky to fix, as [25]
looks exactly like a footnote label. Here is a test case:

--8<---------------cut here---------------start------------->8---
* Headline

This is the first footnote.[fn:5896a172] Another footnote.[fn::A
footnote with a LaTeX citation.\cite[25]{bookid}] Another
footnote.[fn:1e633fdb] Inline footnote with a link.[fn::[[http://www.orgmode.org][Org-mode]]] An
inline footnote with square brackets [fn:: [John] Smith]

[fn:5896a172] Here is my footnote. 

[fn:1e633fdb] Footnote with a link. [[http://www.orgmode.org][Org-mode]]
--8<---------------cut here---------------end--------------->8---
v
1. The cite macro inside the inline footnote interferes with the
   fontification of the buffer. Only the first two footnote labels are
   highlighted. Everything else, including the footnote references, are
   not fontified. I know that your changes did not explicitly address
   cite macros inside a footnote, but any square brackets inside a
   footnote will cause fontification to fail. Are these explicitly
   prohibited in inline footnotes? Is there an escape character.

2. During export to LaTeX, the curly brackets are escaped within the
   footnote:

--8<---------------cut here---------------start------------->8---
This is the first footnote.\footnote{Here is my footnote. } Another footnote.\footnote{A
footnote with a LaTeX citation.\cite[25]\{bookid\} } Another
footnote.\footnote{Footnote with a link. \href{http://www.orgmode.org}{Org-mode} } Inline footnote with a link.\footnote{\href{http://www.orgmode.org}{Org-mode} } An
inline footnote with square brackets \footnote{[John] Smith }
--8<---------------cut here---------------end--------------->8---

3. Html export adds a superscript to the brackets containing digits
   (i.e., it treats them as a footnote within a footnote)

--8<---------------cut here---------------start------------->8---
<p class="footnote"><sup><a class="footnum" name="fn.2" href="#fnr.2">2</a></sup> A
footnote with a LaTeX citation.\cite<sup><a class="footref" name="fnr.25" href="#fn.25">25</a></sup>{bookid}
</p>
--8<---------------cut here---------------end--------------->8---

Thanks for considering these issues.

Best,
Matt

Re: [dev] footnotes improvements

[Christian Moe]

Hi,

That should do it, all right.

Yours,
Christian

On 5/14/11 10:44 AM, Nicolas Goaziou wrote:
> Hello,
>
> Christian Moe<mail@christianmoe.com>  writes:
>
>> Anyway, the footnote markers are run together in LaTeX, too. So
>> I think a (customizable?) separator would be a reader-friendly
>> complement to this new adjacent footnote capability.
>
> I've added three customizable variables for that:
> - org-export-latex-footnote-separator (defaults to "\textsuperscript{,}\\,")
> - org-export-html-footnote-separator (defaults to "<sup>,</sup>")
> - org-export-docbook-footnote-separator (defaults to "<superscript>,
>    </superscript>")
>
> Would that make it?
>
> I also fixed the ascii exporter which I had forgotten in the changes.
>
> Regards,
>

Re: [dev] footnotes improvements

[Nicolas Goaziou]

Hello,

Matt Lundin <mdl@imapmail.org> writes:

> First, a general consideration: my vote would be for highlighting the
> entire footnote label, including the brackets. IMO, leaving the brackets
> in the default face makes it more difficult to scan the buffer.
> (Similarly, I think it might be nice to fontify the entire contents of
> inline footnotes.)

I tend to disagree here:

- if we fontify the whole contents, it may override any special
  fontification inside the inlined footnote (i.e. links, emphasis).
  Moreover, it would look ugly with multi-lines footnotes (white spaces
  at the beginning of the line are also fontified).

- if we fontify the label and the brackets, it might be difficult to
  distinguish when two or more footnotes are bound together. In the case
  of a single inline footnote, the closing bracket would look silly when
  fontified alone in the middle of the text.

- fontifying only labels is enough to spot quickly a footnotes, and is
  useful when you want to reuse an already defined label.

That being said, I agree that the actual fontification process needs to
be tweaked a bit more (i.e. is buggy and not in is final state). Let me
improve this during the next week, then, if needed, we will discuss
again about it.

> Square brackets containing digits inside of footnotes cause some issues.
> The primary use for such brackets would be to include LaTeX cite macros
> inside of footnotes. I imagine this might be tricky to fix, as [25]
> looks exactly like a footnote label.

[25] isn't recognized as a footnote label, as LaTeX macros have
precedence over footnotes (`org-footnote-at-reference-p' dismisses any
footnote matching a part of a LaTeX macro). The problem is that, at the
moment, footnote contents are not protected from further processing.
Alas, unprotected macros are not seen as macros by LaTeX exporter. One
solution would be to protect the contents, but I have first to look at
the HTML exporter, as the reason might be different there.

There is also a problem to fix with lists within footnotes, as my
workaround for that problem doesn't work anymore with the changes
I made.

Again, I will have a look at all of this during the week to come. Stay
tuned !

Regards,

-- 
Nicolas Goaziou

Re: [dev] footnotes improvements

[Matt Lundin]

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

>> First, a general consideration: my vote would be for highlighting the
>> entire footnote label, including the brackets. IMO, leaving the brackets
>> in the default face makes it more difficult to scan the buffer.
>> (Similarly, I think it might be nice to fontify the entire contents of
>> inline footnotes.)
>
> I tend to disagree here:
>
> - if we fontify the whole contents, it may override any special
>   fontification inside the inlined footnote (i.e. links, emphasis).
>   Moreover, it would look ugly with multi-lines footnotes (white spaces
>   at the beginning of the line are also fontified).

Yes, I can see how overriding the fontification of links might be an
issue. FWIW, auctex/font-latex provides a nice example of the behavior I
have in mind. The face inside of the footnote macro overrides some
faces, but not others. Leading whitespace indented, multi-line footnotes
is not fontified.

> - if we fontify the label and the brackets, it might be difficult to
>   distinguish when two or more footnotes are bound together. In the case
>   of a single inline footnote, the closing bracket would look silly when
>   fontified alone in the middle of the text.
>
> - fontifying only labels is enough to spot quickly a footnotes, and is
>   useful when you want to reuse an already defined label.

Could we perhaps provide an option to fontify the brackets, if only to
preserve the traditional behavior? I use footnotes that look like
this.[fn:6592605c] I find them much easier to scan visually when the
brackets and "fn:" are also highlighted.

> That being said, I agree that the actual fontification process needs to
> be tweaked a bit more (i.e. is buggy and not in is final state). Let me
> improve this during the next week, then, if needed, we will discuss
> again about it.
>
>> Square brackets containing digits inside of footnotes cause some issues.
>> The primary use for such brackets would be to include LaTeX cite macros
>> inside of footnotes. I imagine this might be tricky to fix, as [25]
>> looks exactly like a footnote label.
>
> [25] isn't recognized as a footnote label, as LaTeX macros have
> precedence over footnotes (`org-footnote-at-reference-p' dismisses any
> footnote matching a part of a LaTeX macro). The problem is that, at the
> moment, footnote contents are not protected from further processing.
> Alas, unprotected macros are not seen as macros by LaTeX exporter. One
> solution would be to protect the contents, but I have first to look at
> the HTML exporter, as the reason might be different there.

Indeed. It was the html exporter that treated the brackets as a
footnote. The LaTeX exporter, by contrast, escaped the curly brackets.

> Again, I will have a look at all of this during the week to come. Stay
> tuned !

Thanks!
Matt

Re: [dev] footnotes improvements

[Samuel Wales]

Looking forward to these fixes.  Thanks.

For me, fontifying the whole inline footnote would be useful.  Just
the brackets might be better if the whole footnote would obscure
emphasis.

Samuel

-- 
The Kafka Pandemic:
  http://thekafkapandemic.blogspot.com/2010/12/welcome-to-kafka-pandemic-two-forces_9182.html
I support the Whittemore-Peterson Institute (WPI)
===
I want to see the original (pre-hold) Lo et al. 2010 NIH/FDA/Harvard MRV paper.

Re: [dev] footnotes improvements

[Nicolas Goaziou]

Hello,

I've updated some changes that should hopefully fix most issues reported
in this thread. git pull -f may be required.

The footnotes are completely fontified again.

Again, feedback is more than welcome.

Regards,

-- 
Nicolas Goaziou

Re: [dev] footnotes improvements

[Samuel Wales]

I am eagerly awaiting these.  Just curious for the git experts: are
there git tricks to make it so we don't have to maintain a clone but
instead a local branch?

Re: [dev] footnotes improvements

[suvayu ali]

Hi Samuel,

On Thu, May 26, 2011 at 1:56 PM, Samuel Wales <samologist@gmail.com> wrote:
> I am eagerly awaiting these.  Just curious for the git experts: are
> there git tricks to make it so we don't have to maintain a clone but
> instead a local branch?
>

$ cd org-mode/
$ git remote add nicolas git://orgmode.org/org-mode.git
$ git remote update nicolas

This should do it. :)

And you can check the state of the local and remote branches with git log:

$ git log --oneline --graph --decorate --all

Hope this helps.

PS: Note that every time Nicolas rebases his branch, you have force
update your copy.

-- 
Suvayu

Open source is the future. It sets us free.

Re: [dev] footnotes improvements

[Nicolas Goaziou]

Hello,

I've made some additional changes to the footnote branch, and fixed
a merge conflict due to a recent patch.

Since Org 7.6 is about to be released, I'd appreciate if someone using
footnotes could test it and report back the results here. If some
serious problem arises, its integration will be delayed until 7.7.

Thank you for any help,

Regards,

-- 
Nicolas Goaziou

Re: [dev] footnotes improvements

[Christian Moe]

Hi,

I get merge conflicts (see below), and this is not a good time to work 
on improving my git skills (deadlines looming). If there's something 
simple you can tell me to do, I'll try it. Otherwise I'll have to pass 
on the testing, sorry.

Yours,
Christian


git checkout footnote-fix
git pull
remote: Counting objects: 78, done.
remote: Compressing objects: 100% (21/21), done.
remote: Total 69 (delta 56), reused 61 (delta 48)
Unpacking objects: 100% (69/69), done.
 From git://github.com/ngz/org-mode-lists
  + fab506e...0431c5f footnote-fix -> ngz/footnote-fix  (forced update)
    d6aba4d..2422172  master     -> ngz/master
Auto-merging lisp/org-docbook.el
CONFLICT (content): Merge conflict in lisp/org-docbook.el
Auto-merging lisp/org-exp.el
CONFLICT (content): Merge conflict in lisp/org-exp.el
Auto-merging lisp/org-footnote.el
CONFLICT (content): Merge conflict in lisp/org-footnote.el
Auto-merging lisp/org-html.el
CONFLICT (content): Merge conflict in lisp/org-html.el
Auto-merging lisp/org-latex.el
CONFLICT (content): Merge conflict in lisp/org-latex.el
Auto-merging lisp/org.el
CONFLICT (content): Merge conflict in lisp/org.el
Automatic merge failed; fix conflicts and then commit the result.


On 6/27/11 8:29 PM, Nicolas Goaziou wrote:
 > Hello,
 >
 > I've made some additional changes to the footnote branch, and fixed
 > a merge conflict due to a recent patch.
 >
 > Since Org 7.6 is about to be released, I'd appreciate if someone using
 > footnotes could test it and report back the results here. If some
 > serious problem arises, its integration will be delayed until 7.7.
 >
 > Thank you for any help,
 >
 > Regards,
 >

Re: [dev] footnotes improvements

[Nicolas Goaziou]

Hello,

Thanks for trying this.

Christian Moe <mail@christianmoe.com> writes:

> git pull

It should be git pull -f : I had to rebase.

Regards,

-- 
Nicolas Goaziou

Re: [dev] footnotes improvements

[Christian Moe]

Hi,

Tested on the test document you supplied earlier. Everything checks out.

Yours,
Christian


On 6/27/11 8:29 PM, Nicolas Goaziou wrote:
> Hello,
>
> I've made some additional changes to the footnote branch, and fixed
> a merge conflict due to a recent patch.
>
> Since Org 7.6 is about to be released, I'd appreciate if someone using
> footnotes could test it and report back the results here. If some
> serious problem arises, its integration will be delayed until 7.7.
>
> Thank you for any help,
>
> Regards,
>

Re: [dev] footnotes improvements

[Bastien]

Hi Nicolas,

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

> I've made some additional changes to the footnote branch, and fixed
> a merge conflict due to a recent patch.
>
> Since Org 7.6 is about to be released, I'd appreciate if someone using
> footnotes could test it and report back the results here. If some
> serious problem arises, its integration will be delayed until 7.7.

Thanks a lot for this -- I did some preliminary testing and things 
work smoothly so far.

-- 
 Bastien

Re: [dev] footnotes improvements

[Samuel Wales]

Work well on 22.  Really appreciate it.  There are a lot of glitches
with font lock of inline footnotes, not consistent.  Even with the
glitches I prefer the font lock.

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
I support the Whittemore-Peterson Institute (WPI)
===
Bigotry against people with serious diseases is still bigotry.

Re: [dev] footnotes improvements

[Bastien]

Samuel Wales <samologist@gmail.com> writes:

> Work well on 22.  Really appreciate it.  There are a lot of glitches
> with font lock of inline footnotes, not consistent.  Even with the
> glitches I prefer the font lock.

When you have some time, don't hesitate to point at those glitches. 
A screenshot would be useful here.

Thanks,

-- 
 Bastien

Re: [dev] footnotes improvements

[Nicolas Goaziou]

Hello,

Samuel Wales <samologist@gmail.com> writes:

> Work well on 22.  Really appreciate it.  There are a lot of glitches
> with font lock of inline footnotes, not consistent.  Even with the
> glitches I prefer the font lock.

I think I have corrected a few glitches with font locking of inline
footnotes. Your "a lot" makes me think it isn't enough yet, though...

Regards,

-- 
Nicolas Goaziou

Re: [dev] footnotes improvements

[Samuel Wales]

Hi Nicolas,

On 2011-06-30, Nicolas Goaziou <n.goaziou@gmail.com> wrote:
> I think I have corrected a few glitches with font locking of inline
> footnotes. Your "a lot" makes me think it isn't enough yet, though...

They are really good now.

There was an interaction with comments and different extents were
colored within inline footnotes.  The first is fixed.  The second is
either very infrequent or fixed.

Single letters in normal text sometimes display the footnote face,
more around footnotes than in other places, but I have seen this type
of thing in other contexts than footnotes.  Sometimes simply the arrow
key changes the face.  I doubt it's worth trying to fix them unless
you know the display code.

Also, this isn't a glitch, but I wonder if it makes sense to turn off
mouse hover for inline definitions (not calls).  Clicking merely goes
to the beginning, removing the ability to place point.

Also, did we already talk about emphasis and link coloring and reject them?

These fixes are great.

Samuel

-- 
The Kafka Pandemic: http://thekafkapandemic.blogspot.com
I support the Whittemore-Peterson Institute (WPI)
===
Bigotry against people with serious diseases is still bigotry.