Ralf Angeli | 1 Mar 17:35 2009
Picon

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

Jobst Hoffmann | 1 Mar 18:48 2009
Picon

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
up-to-date version of AUCTeX.  So please upgrade to the version
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
in your report.

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
(Continue reading)

Ralf Angeli | 2 Mar 18:43 2009
Picon

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.

--

-- 
(Continue reading)

Ralf Angeli | 6 Mar 19:13 2009
Picon

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.

(Continue reading)

Peter Gacs | 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
up-to-date version of AUCTeX.  So please upgrade to the version
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
in your report.

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:
==============
(Continue reading)

Ralf Angeli | 12 Mar 21:57 2009
Picon

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

Oleksandr Manzyuk | 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)

Ralf Angeli | 13 Mar 18:23 2009
Picon

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

Oleksandr Manzyuk | 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
Oliver Jennrich | 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
showing the 'no entry'-sign instead of the preview for the equation
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,  
(Continue reading)


Gmane