8

I use Emacs in combination with AUCTeX to edit manuscripts with a lot of inline maths using $. When automatic filling (e.g., with M-q), Emacs often breaks these inline math environments at positions which disturbs the fluency of reading (e.g., in subscripts or the like).

Is there a way to tell Emacs to prefer putting the whole $…$ environment in a new line if that would prevent breaking? More specifically, if breaking in maths would occur, the whole environment should be moved to a new line which should not be broken apart.

An example:

Lorem ipsum dolor sit amet, consectetur adipisici elit, sed $a^2 + b^2 = c^2$ eiusmod tempor incidunt ut labore et dolore magna aliqua. Ut enim ad minim veniam.

should result in

Lorem ipsum dolor sit amet, consectetur adipisici elit, sed
$a^2 + b^2 = c^2$ eiusmod tempor incidunt ut labore et dolore magna
aliqua. Ut enim ad minim veniam.
Xlea
  • 495
  • 1
  • 4
  • 14

2 Answers2

5

Try:

(add-hook 'LaTeX-mode-hook
          (lambda ()
            (add-to-list 'fill-nobreak-predicate 'texmathp)))

Place it in your .emacs and restart emacs.

mk1
  • 486
  • 2
  • 5
  • Thanks, that's close! It's nice that it gathers short math environments spread over multiple lines. This comes at the cost, however, that very long lines cannot be broken _explicitely_ (I mean that the explicit breaks are deleted when pressing `M-q`). Do you know how to incorporate this. (It's tricky though; I even cannot state it more precisely in a concise way.) – Xlea Jun 12 '13 at 15:17
  • 1
    I'm not sure I understand what you mean by "explicit breaks". If you just mean positions of the text where you pressed `RET`, well, there's no way of distinguishing those from the automatic line breaks done by the emacs filling functions. You could, however, add the comment symbol `%` at the end of a line to try to prevent that line break from being changed by `M-q`. – mk1 Jun 12 '13 at 15:38
  • What I mean is that if long math (longer than one line) already is on a seperate line and broken (by whomsoever), then I do not want to pull Emacs subsequent lines up (i.e., _don't remove_ a linebreak if that would lead to too long a line). I'm already using `%` but it is not very convenient. – Xlea Jun 13 '13 at 08:20
  • 1
    I think I understand. However, what you want does not seem possible using the `fill-nobreak-predicate` variable. Before even calling the functions from this list, `M-q` already collapses the whole paragraph to a single line, making it impossible to figure out where the previous line breaks occurred. – mk1 Jun 14 '13 at 00:36
  • Thank you for this clarification. There may be a different solution, not using `fill-nobreak-predicate`, though… – Xlea Jun 14 '13 at 15:14
1

You can do something like:

(add-hook 'LaTeX-mode-hook
          (lambda ()
            (add-hook 'fill-nobreak-predicate 'my-latex-fill-nobreak)))

and then define a function my-latex-fill-nobreak which returns non-nil if you're inside a short math environment, e.g. something like:

(defun my-latex-fill-nobreak ()
  (save-excursion
    (when (search-backward "$" (- (point) 20) t)
      ;; We found a nearby $.  Now let's see if it's an opening $
      ;; rather than a closing one.  Using font-lock properties is
      ;; a hack, but it might be good enough.  Apparently (texmathp)
      ;; could be a better choice.
      (eq (get-text-property (point) 'face) 'font-latex-math-face))))
Stefan
  • 27,908
  • 4
  • 53
  • 82
  • 1
    You might use `texmathp` to detect whether point is in math mode. – mk1 Jun 11 '13 at 18:34
  • I tried to add this to ~/.emacs but that didn't seem to have any effect. – Xlea Jun 12 '13 at 15:11
  • Probably because of the unquoted $ in the regexp search. I changed it to use a non-regexp search instead, which might fix your problem. – Stefan Jun 13 '13 at 00:55
  • Thanks! It's nice that it puts long maths onto its own line. There's an issue with that, however, as it seems to erroneously put the last part (including the closing `$`) to the next line. What's more, can you explain where the threshold comes from (trial-and-error gave me something around 47 but I don't see where this comes from). – Xlea Jun 13 '13 at 08:40