all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: mousebot <mousebot@riseup.net>
Cc: 63518@debbugs.gnu.org
Subject: bug#63518: 28.2; shr.el seems to break inline latex (mathjax) in html
Date: Mon, 15 May 2023 17:01:47 +0300	[thread overview]
Message-ID: <83ednh1yno.fsf@gnu.org> (raw)
In-Reply-To: <13cc2bdf-67fc-9e2f-ba01-cbf2bb3e1624@riseup.net> (message from mousebot on Mon, 15 May 2023 13:21:51 +0200)

> Date: Mon, 15 May 2023 13:21:51 +0200
> From: mousebot <mousebot@riseup.net>
> 
> The fediverse client I maintain, mastodon.el, uses shr-render-region to render individual posts. Some instances, e.g. https://mathstodon.xyz, allow users to post inline latex using mathjax notation.
> 
> When shr.el renders inline latex, it often breaks it as it fills the text. It inserts a newline in between the two characters that open an inline latex block: `\(` or `\[`. Using normal fill commands to fill text (fill-region, fill paragraph) do not split latex in this way, from what I could gather.
> 
> When digging around and debugging a little, I found that in shr-find-fill-point, the check (shr-char-kinsoku-eol-p (following-char)) in the when condition returns t when point is in between \ and ( or [, meaning that shr-find-fill-point considers that position to be a breakable point. Commenting that single check seems to largely prevent the undesired splitting. (Behaviour confirmed by my checks and also by another mastodon.el user.)
> 
> I don't really understand the significance of the checks that shr-find-fill-point runs, nor whether they can be temporarily deactivated or worked around in some other way.

That function looks for a suitable place to break the line in two.

The question is whether we can reliably determine that we are inside
inline latex, so that we augment the conditions for a break point.
Turning that off unconditionally is not an option.  Do you happen to
know about some criteria to be applied to distinguish this special
case?

Thanks.





  reply	other threads:[~2023-05-15 14:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-15 11:21 bug#63518: 28.2; shr.el seems to break inline latex (mathjax) in html mousebot
2023-05-15 14:01 ` Eli Zaretskii [this message]
     [not found]   ` <6843949b-5e22-de5e-2e6f-e9e951bbe1ff@riseup.net>
2023-05-15 14:29     ` Eli Zaretskii

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

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

  git send-email \
    --in-reply-to=83ednh1yno.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=63518@debbugs.gnu.org \
    --cc=mousebot@riseup.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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.