auctex
[Top][All Lists]
Advanced

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

Re: [AUCTeX] A problem with \parencite and fill-paragraph


From: Ikumi Keita
Subject: Re: [AUCTeX] A problem with \parencite and fill-paragraph
Date: Fri, 31 Mar 2017 00:48:53 +0900

Hi Adam and all,

>>>>> address@hidden writes:
> In auctex-mode, given
> asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf xxxx 
> \parencite{asdf}

> after calling `fill-paragraph` I get the following
> asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf
> xxxx \parencite{asdf}

> (note that xxxx gets wrapped to the new line even though it should stay
> in the same line)

Indeed.

> Here's the result when I use \cite instead of \parencite:
> asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf xxxx
> \cite{asdf}
> I guess it has something to do with the initial letters of \parencite
> which are the same as \par and \par is treated in a special way by
> fill-paragraph.

I haven't found solution to this yet, but managed to find out why this
happens.  Adam guessed correctly.  The function call chain on emacs 25.1
is as follows:
   fill-paragraph
-> LaTeX-fill-paragraph
-> LaTeX-fill-region-as-paragraph
-> LaTeX-fill-region-as-para-do
-> LaTeX-fill-move-to-break-point
-> fill-move-to-break-point
-> fill-nobreak-p

The last `fill-nobreak-p' is called with the point being just before
"\parencite" and returns t according to `(looking-at paragraph-start)'
because the regexp `paragraph-start' here matches "\par" of
"\parencite".  So the space just before "\parencite" isn't considered as
line-breakable position.

The reason that `paragraph-start' matches "\par" of "\parencite" lies in
the following part of latex.el:
----------------------------------------------------------------------
(defvar LaTeX-paragraph-commands-internal
  '("[" "]" ; display math
    "appendix" "begin" "caption" "chapter" "end" "include" "includeonly"
    "label" "maketitle" "noindent" "par" "paragraph" "part" "section"
    "subsection" "subsubsection" "tableofcontents" "newpage" "clearpage")
  "Internal list of LaTeX macros that should have their own line.")

(defun LaTeX-paragraph-commands-regexp-make ()
  "Return a regular expression matching defined paragraph commands."
  (concat (regexp-quote TeX-esc) "\\("
          (regexp-opt (append LaTeX-paragraph-commands
                              LaTeX-paragraph-commands-internal)) "\\)"))

...

(defvar LaTeX-paragraph-commands-regexp (LaTeX-paragraph-commands-regexp-make)
    "Regular expression matching LaTeX macros that should have their own line.")

(defun LaTeX-set-paragraph-start ()
  "Set `paragraph-start'."
  (setq paragraph-start
        (concat
         "[ \t]*%*[ \t]*\\("
         LaTeX-paragraph-commands-regexp "\\|"
         (regexp-quote TeX-esc) "\\(" LaTeX-item-regexp "\\)\\|"
         "\\$\\$\\|" ; Plain TeX display math (Some people actually
                     ; use this with LaTeX.  Yuck.)
         "$\\)")))
----------------------------------------------------------------------
[summary]
Since the list `LaTeX-paragraph-commands-internal' includes "par",
`paragraph-start' is set to the regexp which matches the every string
"\par" in the buffer, even if it is the first four letters of
"\parencite".

> Is there any solution (or workaround) to this problem?

A breif test suggests that this particular situation would be solved
by changing the definition of `LaTeX-paragraph-commands-regexp-make' to:
----------------------------------------------------------------------
(defun LaTeX-paragraph-commands-regexp-make ()
  "Return a regular expression matching defined paragraph commands."
  (concat (regexp-quote TeX-esc) "\\("
          (regexp-opt (append LaTeX-paragraph-commands
                                                        ;; add here \b
                              LaTeX-paragraph-commands-internal)) "\\)\\b"))
----------------------------------------------------------------------
However, it seems that this change breaks the filling of the constructs
involving "\[" and "\]".

Regards,
Ikumi Keita



reply via email to

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