[Top][All Lists]

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

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

From: jfbu
Subject: Re: [AUCTeX] LaTeX-fill-break-at-separators (11.88.9)
Date: Mon, 30 Nov 2015 12:55:46 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

Le 30/11/2015 12:18, Mosè Giordano a écrit :
Hi Jean-François,

2015-11-30 11:46 GMT+01:00 jfbu <address@hidden>:

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


% Test $char37 $space added note on the implementation:
% we can roughly estimate for big


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


M-q (translated from <escape> q) runs the command fill-paragraph, which is
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 (\\\( \\\[)

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

  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?

Yes, thanks, the problem goes away. The original set-up was 2
for `texmathp-search-n-paragraphs'

Turns out my fifty lines before count obviously only for one paragraph

I had to grab 354 lines before the offending location to find an isolated
$ which confuses AUCTeX.

Although all the intervening macro definitions never define a paragraph,
there were a few paragraphs inside the intervening comments

Hence it seems that texmathp does not identify such paragraphs ?

Indeed if I set it to 1, the problem comes back. Only with 0 is the
problem vanquished.

It appears the whole portion of the dtx with code and comments
counts as only one paragraph ? (this represents in my use case
about 4000 lines above the offending location... (and 14000 lines after))

In most people's dtx, almost everything is written in commented
blocks apart from the code, thus the problem would be even more
acute for them, than it is in my use case, because the whole source
of the documentation in my use case is not commented out, only the
code comments are.

[this makes me think of big problems I have whenever I type a {
and do not rush to type the }, from font-locking parsing of the
document which takes seconds and paralyzes emacs -- but off topic]

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 ;-)

one would need ways to speaking directly to AUCTeX about the catcode
regime... because getting it from parsing is nay impossible, if not
re-implementing big chunks of TeX's own token parsing.

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.

I never ever used \(...\) ...

Recently I saw unanimous reproval on SE of a poor innocent bystander's
proposal to to use $$$ ... $$$ as shortcut for amsmath's align

TeX, the language, authorizes this relatively easily, but LaTeX 's
proselytes viewed it as a terrible sin. The unanimity was as impressive
as it was non-convincing.

If the point is to go farther than TeX/LaTeX in mark-up, then, isn't
it to best to switch to a real mark-up language like ReST ?

A great portion of TeX/LaTeX is about fine points of typography, but
if the goal to have a source which one can issue in dozens of formats,
then using TeX/LaTeX as primary mark-up appears illogical.

Thus all the arguments about \(..\) always appeared moot to me.

Besides LaTeX is buggy with \[..\] which is only correct with amsmath loaded



reply via email to

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