bug-auctex
[Top][All Lists]
Advanced

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

[Bug-AUCTeX] Re: 11.85; TeX-format-filter incorrectly unbreaks lines


From: Ivan Andrus
Subject: [Bug-AUCTeX] Re: 11.85; TeX-format-filter incorrectly unbreaks lines
Date: Fri, 9 Apr 2010 12:29:29 +0200

On Apr 8, 2010, at 5:52 PM, Ralf Angeli wrote:

> Please keep the mailing list copied.  Also, I've reformatted your post
> (except for the part with the LaTeX output) since the lines were longer
> than 80 characters.

Sorry.

> * Ivan Andrus (2010-04-05) writes:
> 
>> On Apr 2, 2010, at 3:00 PM, Ralf Angeli wrote:
>> 
>>> Thanks for the suggested fix.  However, such a fix has been included in
>>> the development version of AUCTeX for nearly two years now and is also
>>> part of AUCTeX 11.86.  In case you installed 11.86, are you sure it is
>>> not shadowed by an older installation?
>> 
>> Dang.  You're absolutely right.  What's even more embarrassing is that
>> I thought I had checked that.
>> 
>> For some reason I'm still seeing the problem, so it must be caused by
>> something else.  It looks like it may be due to overfull boxes such as
>> 
>> Overfull \hbox (30.30951pt too wide) in paragraph at lines 16--20
>> \FMS/futm/m/n/10 9\FML/futmi/m/it/10 ^^N[]\T1/futs/m/n/10 
>> (\FML/futmi/m/it/10 ^^O\T1/futs/m/n/10 ) \FMS/futm/m/n/10 \203 
>> \T1/futs/m/n/10 0$ such that $(\FML/futm
>> i/m/it/10 t\T1/futs/m/n/10 , \FML/futmi/m/it/10 v[]\T1/futs/m/n/10 )
>> 
>> which would explain why it's seems sporadic.
> 
> Is this copied from the output buffer in AUCTeX or from a terminal or
> log file?  If it's from AUCTeX, perhaps the linebreaks at column 79 have
> not been removed correctly?

It's copied from the output buffer in AUCTeX.  Indeed it does not
remove (some of) the linebreaks, because the line contains
e.g. \203 which is a single character, but adds 4
to (current-column).

I changed

(when (and (= (current-column) 79)
           ...)
  (delete-char 1))

to 

(when (and (>= (current-column) 79)
           ...)
  (delete-char 1))

and that fixed the particular test case that I have.  I have no
idea what other adverse effects may show up from it however.

Perhaps it would be better to use something like

(when (and (= 79 (- (point) (line-beginning-position)))
           ...)
  (delete-char 1))

which seems to do the right thing with respect to characters
taking more than one column.

> The funny thing is that there is a regexp in `TeX-parse-error' which
> tries to deal with output containing linebreaks:
> 
> (re-search-forward "\r?\n\
> \\(?:.\\{79\\}\r?\n\
> \\)*.*\r?$")
> 
> But this should work equally well with the situation where _all_
> linebreaks were removed.


The problem seems to be that some of the lines are put back
together and some aren't.  A longer line breaks up the ability of
the regex to see that it's part of a bad box.  It either has to
check for lines that are multiples of 79 characters long, or make
sure that all the lines are pasted back together first, or that
none of them are.  I don't know which would be best, but I'm
willing to help if I knew what do (though it's probably easier
for you to just do it than to explain to me).

Right now I am using

(when (and (> (- (point) (line-beginning-position)) 0)
           (= 0 (% (- (point) (line-beginning-position)) 79))
           ...)
  (delete-char 1))

which seems to work in the very limited testing that I have done.
Though it could obviously be optimized.

Thanks,
Ivan



reply via email to

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