emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FR] Enhancing footnote managment (via indirect buffer)?


From: Andrea Lazzarini
Subject: Re: [FR] Enhancing footnote managment (via indirect buffer)?
Date: Tue, 23 May 2023 11:38:00 +0200


> Il giorno 22 mag 2023, alle ore 17:30, Ihor Radchenko <yantar92@posteo.net> 
> ha scritto:
> 
> Andrea Lazzarini <andrea.lazzarini1@gmail.com> writes:
> 
>> Eldoc (or tooltips) could be great for previewing: I'm going to give them a 
>> try
>> and to see how they might be integrated in an academic writing workflow.
>> I wander if they would maintain buffer-specific highlighting though...
> 
> AFAIK, Eldoc expects a function that will return the string to be
> displayed. You can use `font-lock-ensure' to fontify the footnote
> definition you need to display. Then, the copied string will hold the
> fontification as it would be in Org mode buffer.
> 

Ok, very good. This is my first attempt at it and, apparently, it works.

(setq eldoc-echo-area-use-multiline-p nil)

(defun org-footnote-eldoc-function (callback &rest _ignored)
  "Return the definition of the footnote at point for Eldoc."
  (when (org-footnote-at-reference-p)
    (let* ((footnote-label (car (org-footnote-at-reference-p)))
           (footnote-definition (org-footnote-get-definition footnote-label))
           (start-def (nth 1 footnote-definition))
           (end-def (nth 2 footnote-definition)))
      (when footnote-definition
        (font-lock-ensure start-def end-def)
        (format "%s"  (buffer-substring start-def end-def))))))

(defun org-footnote-enable-eldoc ()
  "Enable Eldoc support for Org Mode footnotes."
  (add-hook 'eldoc-documentation-functions #'org-footnote-eldoc-function nil t))

(add-hook 'org-mode-hook #'org-footnote-enable-eldoc)

I now wonder if there is a way to prevent changing 
eldoc-echo-area-use-multiline-p
to nil globally to prevent footnotes from appearing there and not only in the
eldoc-doc-buffer.

Provided this might be considered useful, where could such a feature be
implemented? I checked org-eldoc.el, but it looks like it aims at
providing programming documentation inside org-mode rather than
implementing specific org-oriented features.


>>> "Eeasier Footnote Deletion": How is it different from `org-footnote-delete'?
>>> 

>> That was nothing more than a simple wrapper for org-footnote-delete, which
>> is not an interactive function: btw, I am curious to know if there is a 
>> reason for
>> that. Why should users re-implement org-footnote-delete with wrappers if 
>> they want to use it interactively?
> 
> I see nothing in git history and mailing list.
> I think that it makes sense to convert org-footnote-delete into
> interactive function.

That would be great.

I've fiddled with org-edit-special and I see it has a major flaw, at least in 
my opinion.
It inserts all changes without keeping track of the undos, as opposed to the 
indirect
buffer solution, which also had the advantage of doing everything from a single 
buffer:
it operates as some sort of 'window' on a part of the file, rather than feeling 
as some
sort of out-of-the-normal operation. Aren't there other possibile use cases for 
indirect
buffers in org mode? Why are they considered inferior to other solutions? I ask 
just
for my understanding.

(A combination of eldoc + org-edit-special might be rather affecting on the
seamlessness of the workflow, but this is of course my simple personal opinion).


> Il giorno 22 mag 2023, alle ore 13:45, Ihor Radchenko <yantar92@posteo.net> 
> ha scritto:
> 
> This sounds like something we can extend `org-forward-element' and
> `org-backward-element' with - it may not only jump to the next element,
> but also jump to the next element of the same type. Jumping to next/previous
> footnote might will useful as a separate command as well though, as a
> complement to the existing `org-next-item', `org-next-link',
> `org-next-block', etc.


Functions that make navigation between similar elements easier would simply be 
great.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]