1 Mar 17:35 2009

### Re: comment folding

* Ullrich Mönich (2009-02-26) writes:

> folding for comments seems to fail in two cases:
>
> 1) If there is a comment at the first line of the file
[...]
> 2) If the region contains
>
> text
> %
> text

Fixed in CVS.  Thanks for the report.

--

--
Ralf


1 Mar 18:48 2009

### 2008-12-29; doctex mode

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.

Be sure to consult the FAQ section in the manual before submitting
a bug report.  In addition check if the bug is reproducable with an
available from http://www.gnu.org/software/auctex/ if your
installation is older than the one available from the web site.

If the bug is triggered by a specific (La)TeX file, you should try
to produce a minimal sample file showing the problem and include it

Your bug report will be posted to the AUCTeX bug reporting list.
------------------------------------------------------------------------

The filling of doctex modes seems to be erroneous, if I append the words
"wrong filling" at the end of the line beginning with "% This..." in the
appended file doctex_tst.dtx, the result is

% This is a long, senseless sentence; the only reason of it's existence
is
% to show the wrong filling

This is not what I expect.

An additional question: I've created an auctex style file for the
support of the LaTeX-package fancyvrb following the listings.el, but the
result is not satisfying. While the indentation of the
Verbatim-environment is correct, the indentation of the VerbatimOut has


2 Mar 18:43 2009

### Re: 2008-12-29; doctex mode

* Jobst Hoffmann (2009-03-01) writes:

> The filling of doctex modes seems to be erroneous, if I append the words
> "wrong filling" at the end of the line beginning with "% This..." in the
> appended file doctex_tst.dtx, the result is
>
> % This is a long, senseless sentence; the only reason of it's existence
> is
>  % to show the wrong filling
>
> This is not what I expect.

The file contains an erroneous "." at the end of the "mode: docTeX" line
which makes at least my Emacs complain.  Not sure if this is related,
though.  Because in any case, i.e. with or without the erroneous period,
it is working fine with Emacs and XEmacs 21.4.  So it could be an issue
specific to XEmacs 21.5.  I'll have to install that to check ...

> An additional question: I've created an auctex style file for the
> support of the LaTeX-package fancyvrb following the listings.el, but the
> result is not satisfying. While the indentation of the
> Verbatim-environment is correct, the indentation of the VerbatimOut has
> two errors:

(setq LaTeX-verbatim-regexp
(concat LaTeX-verbatim-regexp "\\|VerbatimOut \\|Verbatim"))
^
Remove the blank at the marker.

--

--


6 Mar 19:13 2009

### Re: 2008-12-29; doctex mode

Please keep the mailing list copied!

* Jobst Hoffmann (2009-03-02) writes:

> Am Montag, den 02.03.2009, 18:43 +0100 schrieb Ralf Angeli:
>> * Jobst Hoffmann (2009-03-01) writes:
>>
>> > The filling of doctex modes seems to be erroneous, if I append the words
>> > "wrong filling" at the end of the line beginning with "% This..." in the
>> > appended file doctex_tst.dtx, the result is
>> >
>> > % This is a long, senseless sentence; the only reason of it's existence
>> > is
>> >  % to show the wrong filling
>> >
>> > This is not what I expect.
>>
>> The file contains an erroneous "." at the end of the "mode: docTeX" line
>> which makes at least my Emacs complain.  Not sure if this is related,
>> though.  Because in any case, i.e. with or without the erroneous period,
>> it is working fine with Emacs and XEmacs 21.4.  So it could be an issue
>> specific to XEmacs 21.5.  I'll have to install that to check ...
> Sorry for the ".", but that's not the case of the error. It is indeed
> specific to XEmacs 21.5, my 21.4 works fine, I should have tested it
> before.

The problem is not specific to AUCTeX modes.  Just fire up XEmacs 21.5
and type M-j' at the end of a commented line in the *scratch* buffer.
So this is an XEmacs issue, not one of AUCTeX.



12 Mar 01:32 2009

### 11.85; backward-kill-word problem


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.

Be sure to consult the FAQ section in the manual before submitting
a bug report.  In addition check if the bug is reproducable with an
available from http://www.gnu.org/software/auctex/ if your
installation is older than the one available from the web site.

If the bug is triggered by a specific (La)TeX file, you should try
to produce a minimal sample file showing the problem and include it

Your bug report will be posted to the AUCTeX bug reporting list.
------------------------------------------------------------------------

I am using AucTeX via Aquamacs.
In backward-kill-word (as well as aquamacs-backward-kill-word), the
space in front of the word is also killed.
This behavior happens only in the tex files, not in ordinary text
files, so it seems to be due to AucTeX.

Emacs  : GNU Emacs 22.3.1 (powerpc-apple-darwin9.6.0, Carbon Version
1.6.0)
of 2009-02-17 on lucy - Aquamacs Distribution 1.7
Package: 11.85

current state:
==============


12 Mar 21:57 2009

### Re: 11.85; backward-kill-word problem

* Peter Gacs (2009-03-12) writes:

> I am using AucTeX via Aquamacs.
> In backward-kill-word (as well as aquamacs-backward-kill-word), the
> space in front of the word is also killed.
> This behavior happens only in the tex files, not in ordinary text
> files, so it seems to be due to AucTeX.

I cannot reproduce this with Emacs and vanilla AUCTeX, so this might be
an Aquamacs feature.

--

--
Ralf


13 Mar 01:21 2009

### 11.84; Font lock

Emacs does not always fontify display math environments properly. This
typically looks as follows: I open a LaTeX file and start to browse
it. Some display formulas are not highlighted at all (except for the
opening bracket $), some are highlighted only partially. Usually, when I erase and type again the opening bracket \[, at least some parts of the formula get highlighted, and when I then move the cursor, the whole formula gets highlighted. Sometimes, trying to perform some command (like M-x something) restores the highlighting. It's probably not a bug, but it's certainly annoying. See the attached screenshots. Emacs : GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.14.3) of 2008-10-13 on rothera, modified by Debian Package: 11.84 current state: ============== (setq AUCTeX-date "2007-01-12" window-system 'x LaTeX-version "2e" TeX-style-path '("style" "auto" "/usr/share/emacs/23.0.60/site-lisp/auctex/style" "/var/lib/auctex/emacs-snapshot") TeX-auto-save t TeX-parse-self t TeX-master t TeX-command-list '(("TeX" "%(PDF)%(tex) %%S%(PDFout)%(mode)%' %t" TeX-run-TeX nil (plain-tex-mode ams-tex-mode texinfo-mode) :help "Run plain TeX")  (Continue reading) 13 Mar 18:23 2009 ### Re: 11.84; Font lock * Oleksandr Manzyuk (2009-03-13) writes: > Emacs does not always fontify display math environments properly. This > typically looks as follows: I open a LaTeX file and start to browse > it. Some display formulas are not highlighted at all (except for the > opening bracket \[), some are highlighted only partially. [...] > Emacs : GNU Emacs 23.0.60.1 (i486-pc-linux-gnu, GTK+ Version 2.14.3) > of 2008-10-13 on rothera, modified by Debian > Package: 11.84 You are using an outdated version of AUCTeX. Do you see the issue with 11.85? -- -- Ralf  14 Mar 15:36 2009 ### Re: 11.84; Font lock > You are using an outdated version of AUCTeX. Do you see the issue with > 11.85? I have upgraded to AUCTeX 11.85 and now Emacs' behaviour is more regular and tolerable: if a display formula is at the bottom of the screen, so that the opening bracket \[ is visible but the closing bracket$ is not, then the visible bracket is highlighted red and the
formula is not highlighted, see the attached screenshot. As soon as
the closing bracket becomes visible as well, the formula gets properly
highlighted.

Oleksandr

> You are using an outdated version of AUCTeX.  Do you see the issue with
> 11.85?

I have upgraded to AUCTeX 11.85 and now Emacs' behaviour is more
regular and tolerable: if a display formula is at the bottom of the
screen, so that the opening bracket $is visible but the closing bracket$ is not, then the visible bracket is highlighted red and the
formula is not highlighted, see the attached screenshot. As soon as
the closing bracket becomes visible as well, the formula gets properly
highlighted.

Oleksandr

23 Mar 15:32 2009

### 11.85; TikZ breaks preview


Remember to cover the basics.  Including a minimal LaTeX example
file exhibiting the problem might help.

The following example shows the problem. Using tikz will result in
when the pdf output is chosen.

\documentclass{article}

%\listfiles
%\usepackage{tikz}

\begin{document}
$a^2+b^2=d^2$
\end{document}

The two relevant log-files are here:

With tikz enabled:

--------------- _region_tikz.log ---------------
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
(format=prv_prrvtest 2009.3.23)  23 MAR 2009 15:21
entering extended mode
%&-line parsing enabled.
**&prv_prrvtest _region_.tex
(./_region_.tex
LaTeX2e <2005/12/01>
Babel <v3.8h> and hyphenation patterns for english, usenglishmax,