auctex
[Top][All Lists]

## Re: [AUCTeX] LaTeX-fill-break-at-separators (11.88.9)

 From: Mosè Giordano Subject: Re: [AUCTeX] LaTeX-fill-break-at-separators (11.88.9) Date: Mon, 30 Nov 2015 12:18:34 +0100

Hi Jean-François,

> Hi,
>
> I know this has been discussed prior to 11.88.9 release, but I have
> a confusing problem when the same source behaves differently in two
> files under the same docTeX mode
>
> ----
> \documentclass{article}% same with scrdoc
>
> \begin{document}
>
> % Test $char37$space added note on the implementation:
> % we can roughly estimate for big
>
> \end{document}
> ----
>
> For the above foo.dtx test file, if I turn on docTeX mode and do
> M-q on the paragraph, it is transformed into the expected
>
> % Test $char37$space added note on the implementation: we can roughly
> % estimate for big
>
> fill-column is set to 78
>
> and
>
> M-q (translated from <escape> q) runs the command fill-paragraph, which is
> an
> interactive compiled Lisp function in fill.el'.
>
> However the very same paragraph in my big dtx file behaves differently,
> it becomes under M-q
>
> % Test $char37 > %$space added note on the implementation: we can roughly estimate for big
>
> In both, I can check that M-q is bound to same function and that
>
> ----
> LaTeX-fill-break-at-separators is a variable defined in latex.el'.
> Its value is (\\$$\\\[) > > Documentation: > List of separators before or after which respectively a line > break will be inserted if they do not fit into one line. > > You can customize this variable. > ---- > > Indeed if I customize the variable to uncheck all items, the problem > disappears. But why was it present to start with ? > > Do you have any clue on how to debug this ? In the big bar.dtx I have > the paragraph preceded and followed by other commented paragraphs. > > I have transferred about 100 lines with 50 lines before and 50 lines > after from bar.dtx into foo.dtx, Still M-q behaves correctly in foo.dtx > but in bar.dtx I have systematically the bad break > > (I tried varying fill-column, does not change anything, except if big > enough for the whole paragraph to be on one single line) > > The dtx is very big and trying to cut down to a mwe will be time costly > > Any clue on how to debug this ? > > Also I am confused by the customize buffer for > LaTeX-fill-break-at-separators > > Opening Inline Math Switches > > This seems to indicate  and \( are treated the same ? > I thought they were not from previous thread, but I misunderstood probably > > I can reproduce the problem in foo.dtx if I check the > > Closing Inline Math Switches > > My problem is: why do I see the bad break in bar.dtx although > Closing Inline Math Switches is not checked in the customize buffer ? > > > Hide Latex Fill Break At Separators: > [ ] Opening Brace > [ ] Closing Brace > [ ] Opening Bracket > [X] Opening Inline Math Switches > [ ] Closing Inline Math Switches > [X] Opening Display Math Switch > [ ] Closing Display Math Switch > > Is it possible some other hook has changed something which does > not show up in the customize buffer ? > > ...ah ... I am starting to understand: the second  is > interpreted here as an Opening, not Closing, math switch. The prior > 50 lines were not enough to reproduce the problem. > > Well, posting anyhow. > > It is not coherently possible to know if  is opening or closing, > because  can be used for other things > > for example in this buffer the  at this location > is not at all a math shift character but a catcode 0 escape, > could it be envisioned not to apply to  what is thought out for \( ..$$ ?
>
> that would give an argument to people advocating $$: use it to > benefit from AUCTeX parsing. > > > how local is the check for  opening or closing ? So maybe it's a bug in texmathp, more than in the filling function. texmathp checks also the content of a few paragraphs before the current one, so maybe the previous paragraph in your large dtx fools texmathp. See the variable texmathp-search-n-paragraphs', what happens if you set it to 0? Fiddling with catcodes is known to make AUCTeX crazy, I think there isn't much we can really do to fix it. For anyone reading this: patches welcome ;-) Well, \(...$$ is somewhat the LaTeX preferred way for inline equations
(for example it has better error control and yes, it's much easier to
parse), even if this preference isn't enforced in anyway, with the
result that almost anybody uses $...$ also in LaTeX.

Bye,
Mosè

`