emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Andrea Lazzarini <andrea.lazzarini1@gmail.com>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: emacs-orgmode@gnu.org
Subject: Re: [FR] Enhancing footnote managment (via indirect buffer)?
Date: Tue, 23 May 2023 11:38:00 +0200	[thread overview]
Message-ID: <84F2917E-1E26-41C3-BDC4-A130A78F650A@gmail.com> (raw)
In-Reply-To: <87fs7oo031.fsf@localhost>



> 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	other threads:[~2023-05-23  9:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22  9:30 [FR] Enhancing footnote managment (via indirect buffer)? Andrea Lazzarini
2023-05-22 11:45 ` Ihor Radchenko
2023-05-22 13:58   ` Andrea Lazzarini
2023-05-22 15:30     ` Ihor Radchenko
2023-05-23  9:38       ` Andrea Lazzarini [this message]
2023-05-24 10:00         ` Ihor Radchenko
  -- strict thread matches above, loose matches on Subject: below --
2023-05-23 10:59 Payas Relekar
2023-05-24  9:03 ` Ihor Radchenko
     [not found]   ` <990C578F-176B-4166-868C-0BC59759CC19@gmail.com>
2023-05-26  9:08     ` Fwd: " Andrea Lazzarini
     [not found]       ` <877cria8f9.fsf@localhost>
2023-07-03 15:32         ` Andrea Lazzarini
2023-07-03 16:19           ` Ihor Radchenko
2023-09-02 10:09             ` Ihor Radchenko
2023-12-09 11:20               ` Ihor Radchenko
2023-05-26  9:13     ` Ihor Radchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84F2917E-1E26-41C3-BDC4-A130A78F650A@gmail.com \
    --to=andrea.lazzarini1@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=yantar92@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).