[Daniel Burrows <[e-mail]>] Bug#292886: Phantom spaces appearing in TeX documents; related to fill?

[Davide G. M. Salvetti]

tags 292886 + moreinfo unreproducible upstream
thanks
[Please ignore the two lines above and keep
292886-***@bugs.debian.org in cc if and when you reply.]

Hi developers,

this is another bug reported via the Debian bug tracking system. I
cannot reproduce it either on my system. On the contrary, if I have
some trailing space and hit "M-q" it gets eaten.

Daniel: can you please try and start emacs with "-q" to see if your
local setup affects this behavior or not? A minimal document
demonstrating the bug will be useful as well. Thanks.

[Ralf Angeli]

Post by Davide G. M. Salvetti
this is another bug reported via the Debian bug tracking system. I
cannot reproduce it either on my system. On the contrary, if I have
some trailing space and hit "M-q" it gets eaten.

There was a time when CVS AUCTeX added whitespace. But as he didn't
use `M-x TeX-submit-bug-report RET' one cannot judge what version of
AUCTeX he is using. The output of `C-h v AUCTeX-version RET' and `M-x
list-load-path-shadows RET' would be interesting.

Post by Davide G. M. Salvetti
A minimal document
demonstrating the bug will be useful as well.

I second that.

[David Kastrup]

Post by Ralf Angeli

Post by Davide G. M. Salvetti
this is another bug reported via the Debian bug tracking system. I
cannot reproduce it either on my system. On the contrary, if I have
some trailing space and hit "M-q" it gets eaten.

There was a time when CVS AUCTeX added whitespace. But as he didn't
use `M-x TeX-submit-bug-report RET' one cannot judge what version of
AUCTeX he is using.

Package: auctex
Version: 11.54-4
Severity: normal

That would be the current packaging. However, he also stated that he
has been seeing this problem for several weeks now, and the current
version is not that old. So it would be interesting to hear _what_
versions he might have been using a few weeks ago when the problem
purportedly started.

[Ralf Angeli]

Post by David Kastrup

Post by Ralf Angeli
There was a time when CVS AUCTeX added whitespace. But as he didn't
use `M-x TeX-submit-bug-report RET' one cannot judge what version of
AUCTeX he is using.

Package: auctex
Version: 11.54-4
Severity: normal
That would be the current packaging.

Yes, and therefore the information is completely useless. There could
be another installation which shadows the packaged version.

[Frank Küster]

Hi Daniel,

Post by Ralf Angeli

Post by David Kastrup

Post by Ralf Angeli
There was a time when CVS AUCTeX added whitespace. But as he didn't
use `M-x TeX-submit-bug-report RET' one cannot judge what version of
AUCTeX he is using.

Package: auctex
Version: 11.54-4
Severity: normal
That would be the current packaging.

Yes, and therefore the information is completely useless. There could
be another installation which shadows the packaged version.

David wrote:

,----
| However, he also stated that he
| has been seeing this problem for several weeks now, and the current
| version is not that old.
`----

Guys, did you notice that you had the bug reporter in the Cc? He used
the Debian bugtracking system, which is correct since he uses a
Debian-modified version, and Davide dediced to forward the bug to this
list, which is correct, too.

So there is no reason to talk to him in third person, or to tell him
that his information is "completely useless", when he just provided the
information that Debian (semi-automatically) asked from him.

I think this might sound aggressive to him, and will perhaps not
increase the chance to get into a constructive debugging session with
him. Note also that he may have no idea of AUCTeX, but with a
@debian.org address he can't be completely computer-illiterate...

Post by Ralf Angeli
Yes, and therefore the information is completely useless. There could
be another installation which shadows the packaged version.

I wouldn't say that it is completely useless; it has helped in many
cases in the past (this list doesn't get every Debian bug report for
AUCTEx). But indeed: It would be great if the output of
TeX-submit-bug-report could be included into the Debian bug report.

There is Debian infrastructure for this. The only thing we need is a
command (a shell command, not an emacs one) that would echo the body
part of "TeX-submit-bug-report" to stdout, i.e. without creating the
headers for the mail. Can you help us with this?

Regards, Frank

[Ralf Angeli]

Post by Frank Küster
Guys, did you notice that you had the bug reporter in the Cc? He used
the Debian bugtracking system, which is correct since he uses a
Debian-modified version, and Davide dediced to forward the bug to this
list, which is correct, too.
So there is no reason to talk to him in third person, or to tell him
that his information is "completely useless", when he just provided the
information that Debian (semi-automatically) asked from him.

Recipients listed in the Cc header are usually not the primary
addressees of a message. Please take this into consideration next
time you write things like above. And no, I don't want to discuss
this any further.

Post by Frank Küster

Post by Ralf Angeli
Yes, and therefore the information is completely useless. There could
be another installation which shadows the packaged version.

I wouldn't say that it is completely useless; it has helped in many
cases in the past (this list doesn't get every Debian bug report for
AUCTEx). But indeed: It would be great if the output of
TeX-submit-bug-report could be included into the Debian bug report.
There is Debian infrastructure for this. The only thing we need is a
command (a shell command, not an emacs one) that would echo the body
part of "TeX-submit-bug-report" to stdout, i.e. without creating the
headers for the mail. Can you help us with this?

The following should do. I don't know how to get rid of the first two
lines of output, though. Maybe by providing a function in AUCTeX
which provides the respective output.

emacs -batch -eval "(progn (require 'tex-site) (require 'latex) (require 'reporter) (let ((reporter-status-count 0) (reporter-eval-buffer (current-buffer))) (reporter-dump-state \"AUCTeX\" '(window-system LaTeX-version TeX-style-path TeX-auto-save TeX-parse-self TeX-master) nil nil)) (message (buffer-string)))"

[Frank Küster]

Post by Ralf Angeli

Post by Frank Küster
There is Debian infrastructure for this. The only thing we need is a
command (a shell command, not an emacs one) that would echo the body
part of "TeX-submit-bug-report" to stdout, i.e. without creating the
headers for the mail. Can you help us with this?

The following should do. I don't know how to get rid of the first two
lines of output, though. Maybe by providing a function in AUCTeX
which provides the respective output.
emacs -batch -eval "(progn (require 'tex-site) (require 'latex) (require 'reporter) (let ((reporter-status-count 0) (reporter-eval-buffer (current-buffer))) (reporter-dump-state \"AUCTeX\" '(window-system LaTeX-version TeX-style-path TeX-auto-save TeX-parse-self TeX-master) nil nil)) (message (buffer-string)))"

Thank you very much!

Regards, Frank

[Frank Küster]

Post by Ralf Angeli

Post by Frank Küster
There is Debian infrastructure for this. The only thing we need is a
command (a shell command, not an emacs one) that would echo the body
part of "TeX-submit-bug-report" to stdout, i.e. without creating the
headers for the mail. Can you help us with this?

The following should do. I don't know how to get rid of the first two
lines of output, though. Maybe by providing a function in AUCTeX
which provides the respective output.
emacs -batch -eval "(progn (require 'tex-site) (require 'latex) (require 'reporter) (let ((reporter-status-count 0) (reporter-eval-buffer (current-buffer))) (reporter-dump-state \"AUCTeX\" '(window-system LaTeX-version TeX-style-path TeX-auto-save TeX-parse-self TeX-master) nil nil)) (message (buffer-string)))"

Actually it comes out on stderr, but that doesn't hurt. Thank you,

Frank

[Ralf Angeli]

Post by Frank Küster

Post by Ralf Angeli

Post by Frank Küster
There is Debian infrastructure for this. The only thing we need is a
command (a shell command, not an emacs one) that would echo the body
part of "TeX-submit-bug-report" to stdout, i.e. without creating the
headers for the mail. Can you help us with this?

The following should do. I don't know how to get rid of the first two
lines of output, though. Maybe by providing a function in AUCTeX
which provides the respective output.
emacs -batch -eval "(progn (require 'tex-site) (require 'latex) (require 'reporter) (let ((reporter-status-count 0) (reporter-eval-buffer (current-buffer))) (reporter-dump-state \"AUCTeX\" '(window-system LaTeX-version TeX-style-path TeX-auto-save TeX-parse-self TeX-master) nil nil)) (message (buffer-string)))"

Actually it comes out on stderr, but that doesn't hurt.

According to the Elisp manual this is how it is supposed to be:

,----[ (info "(elisp)Batch Mode") ]
| Any Lisp program output that would normally go to the echo area,
| either using `message', or using `prin1', etc., with `t' as the stream,
| goes instead to Emacs's standard error descriptor when in batch mode.
`----

The problem with the code is that it uses internals of reporter.el.
It is therefore likely to break once reporter.el gets updated.
Unfortunately reporter.el doesn't provide a clean interface for doing
such stuff. Its functionality is more or less limited to the creation
of a mail buffer with the whole bug report as its content.

[Frank Küster]

Post by Ralf Angeli
The problem with the code is that it uses internals of reporter.el.
It is therefore likely to break once reporter.el gets updated.
Unfortunately reporter.el doesn't provide a clean interface for doing
such stuff. Its functionality is more or less limited to the creation
of a mail buffer with the whole bug report as its content.

So does this mean you would not recommend to use this code in our bug
report scripts?

TIA, Frank

[Ralf Angeli]

Post by Frank Küster

Post by Ralf Angeli
The problem with the code is that it uses internals of reporter.el.
It is therefore likely to break once reporter.el gets updated.
Unfortunately reporter.el doesn't provide a clean interface for doing
such stuff. Its functionality is more or less limited to the creation
of a mail buffer with the whole bug report as its content.

So does this mean you would not recommend to use this code in our bug
report scripts?

reporter.el doesn't seem to be one of the libraries which change
frequently. But it would be advisable to check if the code still
works with the next Emacs release once it is out.

Also, I don't know how it behaves with various types of broken
installations. For example, in case some files are not found you'll
get a message like "Cannot open load file: tex-site". I don't think
that the code will hang, but you cannot rely on it always producing
the output you can see with intact installations.

BTW, I just noticed that I forgot to include the version information
in the command I posted earlier. Here is an update:

emacs -batch -eval "(progn (require 'tex-site) (require 'latex) (require 'reporter) (let ((reporter-status-count 0) (reporter-eval-buffer (current-buffer))) (reporter-dump-state (concat \"AUCTeX \" AUCTeX-version)'(window-system LaTeX-version TeX-style-path TeX-auto-save TeX-parse-self TeX-master) nil nil)) (message (buffer-string)))"

Anyway, it is a hack. But a hack you can use until (if ever) there
will be a proper interface for dumping the state of an Elisp package.

[David Kastrup]

Post by Ralf Angeli

Post by Frank Küster

Post by Ralf Angeli
The problem with the code is that it uses internals of reporter.el.
It is therefore likely to break once reporter.el gets updated.
Unfortunately reporter.el doesn't provide a clean interface for doing
such stuff. Its functionality is more or less limited to the creation
of a mail buffer with the whole bug report as its content.

So does this mean you would not recommend to use this code in our bug
report scripts?

reporter.el doesn't seem to be one of the libraries which change
frequently. But it would be advisable to check if the code still
works with the next Emacs release once it is out.
Also, I don't know how it behaves with various types of broken
installations. For example, in case some files are not found you'll
get a message like "Cannot open load file: tex-site". I don't think
that the code will hang, but you cannot rely on it always producing
the output you can see with intact installations.
BTW, I just noticed that I forgot to include the version information
emacs -batch -eval "(progn (require 'tex-site) (require 'latex) (require 'reporter) (let ((reporter-status-count 0) (reporter-eval-buffer (current-buffer))) (reporter-dump-state (concat \"AUCTeX \" AUCTeX-version)'(window-system LaTeX-version TeX-style-path TeX-auto-save TeX-parse-self TeX-master) nil nil)) (message (buffer-string)))"
Anyway, it is a hack. But a hack you can use until (if ever) there
will be a proper interface for dumping the state of an Elisp
package.

I think it would be both more flexible and robust to just run the bug
reporting command itself (answering return to any possible prompt),
then dump the resulting mail buffer up to a possible signature. Here
would be how to do that:

yes|emacs -batch --eval '(progn(TeX-submit-bug-report)(princ(buffer-substring (point)(or(search-forward "\n-- \n" nil t)(point-max)))))' 2>/dev/null

This also appears to work for preview-report-bug. report-emacs-bug,
however, appears to get terribly confused when it tries to report the
(nonexisting) keystroke history.

[Frank Küster]

Post by David Kastrup
yes|emacs -batch --eval '(progn(TeX-submit-bug-report)(princ(buffer-substring (point)(or(search-forward "\n-- \n" nil t)(point-max)))))' 2>/dev/null

Fine.

Post by David Kastrup
This also appears to work for preview-report-bug.

Strangely it doesn't work here. Without stderr redirection, I get:

$ yes|emacs -batch --eval '(progn(preview-report-bug)(princ(buffer-substring (point)(or(search-forward "\n-- \n" nil t)(point-max)))))'Loading 00debian-vars...
Loading 20apel (source)...
Loading 20gnus-init (source)...
Loading 35elib-startup (source)...
Loading 42hyperlatex...
Loading 49url (source)...
Loading 50auctex (source)...
Loading 50bbdb (source)...
Loading 50css-mode (source)...
Loading 50dpkg-dev-el (source)...
Loading 50emacs-goodies-el (source)...
Loading 50erc (source)...
Loading 50gettext (source)...
Loading 50gnus-bonus-el (source)...
Loading 50gri (source)...
Loading 50gri-html-doc (source)...
Loading 50html-helper-mode (source)...
Loading 50maxima (source)...
Loading 50pcl-cvs-startup (source)...
Loading 50php-elisp (source)...
Loading 50preview-latex (source)...
Loading 50psgml-init (source)...
Loading 50tramp (source)...
Loading 50w3 (source)...
Loading 50w3m-el (source)...
Loading 50yorick-auto (source)...
Loading 51debian-el (source)...
Loading 51preview-latex (source)...
Loading 92bio-mode (source)...
Symbol's function definition is void: preview-report-bug
$

If I start emacs on the command line, M-x preview-report-bug works. Is
this a Debian bug?

Regards, Frank

[David Kastrup]

Post by Frank Küster

Post by David Kastrup
yes|emacs -batch --eval '(progn(TeX-submit-bug-report)(princ(buffer-substring (point)(or(search-forward "\n-- \n" nil t)(point-max)))))' 2>/dev/null

Fine.

Post by David Kastrup
This also appears to work for preview-report-bug.

$ yes|emacs -batch --eval '(progn(preview-report-bug)(princ(buffer-substring (point)(or(search-forward "\n-- \n" nil t)(point-max)))))'Loading 00debian-vars...
Loading 20apel (source)...
Loading 20gnus-init (source)...
Loading 35elib-startup (source)...
Loading 42hyperlatex...
Loading 49url (source)...
Loading 50auctex (source)...
Loading 50bbdb (source)...
Loading 50css-mode (source)...
Loading 50dpkg-dev-el (source)...
Loading 50emacs-goodies-el (source)...
Loading 50erc (source)...
Loading 50gettext (source)...
Loading 50gnus-bonus-el (source)...
Loading 50gri (source)...
Loading 50gri-html-doc (source)...
Loading 50html-helper-mode (source)...
Loading 50maxima (source)...
Loading 50pcl-cvs-startup (source)...
Loading 50php-elisp (source)...
Loading 50preview-latex (source)...
Loading 50psgml-init (source)...
Loading 50tramp (source)...
Loading 50w3 (source)...
Loading 50w3m-el (source)...
Loading 50yorick-auto (source)...
Loading 51debian-el (source)...
Loading 51preview-latex (source)...
Loading 92bio-mode (source)...
Symbol's function definition is void: preview-report-bug
$
If I start emacs on the command line, M-x preview-report-bug works. Is
this a Debian bug?

Probably. The preview-latex initialization file (and notice that you
are loading _two_ different preview-latex initialization files in the
above, quite suspicious) is supposed to define an autoload for
preview-report-bug. According to the ChangeLogs, this is supposed to
happen starting with version 0.7.6 (when the appropriate autoload
cookie has been added to Debian).

So it would appear that the preview-latex.el file which is supposed to
be generated new on each distribution, has been generated once for
Debian in some older version, and never again, but rather checked in
in the original form. Or the Debian initialization file actually is
from a time where we did not even generate autoloads automatically.
Maybe this was done to avoid enabling preview-latex without further
questions (but one could still manually disable it with
(remove-hook 'LaTeX-mode-hook #'LaTeX-preview-setup)
) if one really did not want to use the package.

The file looks somewhat like the following currently for a CVS Emacs:

;;; preview-latex.el --- automatically extracted autoloads
;;
;;; Code:


;;;### (autoloads (preview-report-bug LaTeX-preview-setup) "preview"
;;;;;; "preview.el" (16886 65165))
;;; Generated autoloads from preview.el

(autoload (quote LaTeX-preview-setup) "preview" "\
Hook function for embedding the preview package into AUCTeX.
This is called by `LaTeX-mode-hook' and changes AUCTeX variables
to add the preview functionality.

\(fn)" nil nil)
(add-hook 'LaTeX-mode-hook #'LaTeX-preview-setup)

(autoload (quote preview-report-bug) "preview" "\
Report a bug in the preview-latex package.

\(fn)" t nil)

;;;***

;; Local Variables:
;; version-control: never
;; no-byte-compile: t
;; no-update-autoloads: t
;; End:
;;; preview-latex.el ends here
(add-to-list (quote load-path) "/usr/local/emacs-21/share/emacs/site-lisp/preview")

[Frank Küster]

Post by David Kastrup

Post by Frank Küster
If I start emacs on the command line, M-x preview-report-bug works. Is
this a Debian bug?

Probably. The preview-latex initialization file (and notice that you
are loading _two_ different preview-latex initialization files in the
above, quite suspicious

This seems to be on purpose. In 50preview-latex.el, the necessary
additions to load-path are done, and this is done all the time the
package is installed. 51preview-latex.el is only used if I give a
certain answer to a debconf question, and it is responsible for (load
"preview-latex").

) is supposed to define an autoload for

Post by David Kastrup
preview-report-bug. According to the ChangeLogs, this is supposed to
happen starting with version 0.7.6 (when the appropriate autoload
cookie has been added to Debian).

You mean, added to preview-report-bug in preview-latex, not in Debian?

Post by David Kastrup
So it would appear that the preview-latex.el file which is supposed to
be generated new on each distribution, has been generated once for
Debian in some older version, and never again, but rather checked in
in the original form. Or the Debian initialization file actually is
from a time where we did not even generate autoloads automatically.

This sounds so true. However, I don't understand why this has a
different effect with emacs -batch and with interactive usage. Oh, this
is weird: When doing it interactive, 51preview-latex.el is loaded twice:

Loading 50preview-latex (source)...done
[...]
Loading 51preview-latex (source)...
Loading preview-latex...done
Loading 51preview-latex (source)...done
The Debian package supports only emacs21, not emacs-snapshot. A
preview-latex.el is created, but this is not the file autoloaded upon startup

Post by David Kastrup
;;;***

What are the page breaks for?

Regards, Frank

[Ralf Angeli]

Post by David Kastrup
I think it would be both more flexible and robust to just run the bug
reporting command itself (answering return to any possible prompt),
then dump the resulting mail buffer up to a possible signature. Here
yes|emacs -batch --eval '(progn(TeX-submit-bug-report)(princ(buffer-substring (point)(or(search-forward "\n-- \n" nil t)(point-max)))))' 2>/dev/null

This produces nothing here. Omitting the redirection of stderr I get
"Symbol's function definition is void: TeX-submit-bug-report". That's
a bit surprising because `TeX-submit-bug-report' is being autoloaded
in tex-site.el and I have `(require 'tex-site)' in my .emacs file.
The command will only give me the wanted output if I add a `(require
'tex-site)' before the call to `TeX-submit-bug-report' (and adapt the
quoting).

Using `buffer-substring' from point downwards is, by the way, a nice
idea as it allows for stripping the description at the start of the
bug report without having to deal with the internals of reporter.el.
I wonder why I didn't think of this. (c;

[Reiner Steib]

[...]

Post by Ralf Angeli

Post by David Kastrup
yes|emacs -batch --eval '(progn(TeX-submit-bug-report)(princ(buffer-substring (point)(or(search-forward "\n-- \n" nil t)(point-max)))))' 2>/dev/null

This produces nothing here. Omitting the redirection of stderr I get
"Symbol's function definition is void: TeX-submit-bug-report". That's
a bit surprising because `TeX-submit-bug-report' is being autoloaded
in tex-site.el and I have `(require 'tex-site)' in my .emacs file.

,----[ (info "(emacs)Initial Options") ]
| `-batch'
| `--batch'
| [...]
| `-batch' implies `-q' (do not load an init file). It also causes
| Emacs to exit after processing all the command options.
`----

Bye, Reiner.

[Frank Küster]

Post by Ralf Angeli

Post by David Kastrup
I think it would be both more flexible and robust to just run the bug
reporting command itself (answering return to any possible prompt),
then dump the resulting mail buffer up to a possible signature. Here
yes|emacs -batch --eval '(progn(TeX-submit-bug-report)(princ(buffer-substring (point)(or(search-forward "\n-- \n" nil t)(point-max)))))' 2>/dev/null

This produces nothing here. Omitting the redirection of stderr I get
"Symbol's function definition is void: TeX-submit-bug-report". That's
a bit surprising because `TeX-submit-bug-report' is being autoloaded
in tex-site.el and I have `(require 'tex-site)' in my .emacs file.

Strange. Does -batch imply -q?

Post by Ralf Angeli
The command will only give me the wanted output if I add a `(require
'tex-site)' before the call to `TeX-submit-bug-report' (and adapt the
quoting).

How is that done? I could use it because the preview-latex package of
Debian loads preview-latex.el only cond (eq window-system 'x), which is
not true in batch mode.

Regards, Frank

[David Kastrup]

Post by David Kastrup
I think it would be both more flexible and robust to just run the bug
reporting command itself (answering return to any possible prompt),
then dump the resulting mail buffer up to a possible signature. Here
yes|emacs -batch --eval '(progn(TeX-submit-bug-report)(princ(buffer-substring (point)(or(search-forward "\n-- \n" nil t)(point-max)))))' 2>/dev/null
This also appears to work for preview-report-bug. report-emacs-bug,
however, appears to get terribly confused when it tries to report the
(nonexisting) keystroke history.

Forget the last sentence. I looked more closely. Just write
(progn (report-emacs-bug "")(princ ...
and everything is fine. report-emacs-bug takes at least one argument.

[Frank Küster]

Hi Daniel,

Post by David Kastrup

Post by Ralf Angeli

Post by Davide G. M. Salvetti
this is another bug reported via the Debian bug tracking system. I
cannot reproduce it either on my system. On the contrary, if I have
some trailing space and hit "M-q" it gets eaten.

There was a time when CVS AUCTeX added whitespace. But as he didn't
use `M-x TeX-submit-bug-report RET' one cannot judge what version of
AUCTeX he is using.

Package: auctex
Version: 11.54-4
Severity: normal
That would be the current packaging. However, he also stated that he
has been seeing this problem for several weeks now, and the current
version is not that old. So it would be interesting to hear _what_
versions he might have been using a few weeks ago when the problem
purportedly started.

Did you only use Debian unstable, or testing, or also other versions of
AUCTeX? Can you send a mail to auc-***@sunsite.dk that was generated
using M-X TeX-submit-bug-report?

Can you reproduce the problem on a specific file, and could you try to
pin it down to a (rather) small example document you can send us?

Regards, Frank

[Daniel Burrows]

this is another bug reported via the Debian bug tracking system.  I
cannot reproduce it either on my system.  On the contrary, if I have
some trailing space and hit "M-q" it gets eaten.

Oh, I see I wasn't clear enough. You're right that the trailing space in
the *current* paragraph gets eaten. However, trailing spaces get randomly
added elsewhere in the file. And yes, I'm using the current version of
auctex; if I'd installed some other version by hand I wouldn't be sending
this to the Debian BTS.

AUCTeX-version's value is "11.54"

I believe I first noticed the appearence of odd whitespace characters about
two weeks ago, but that doesn't mean it started then. I've attached a file
that seems to trigger this: fill the first paragraph, and the second
paragraph will get trailing whitespace.

BTW, if you're going to complain about the use of the BTS to report bugs,
maybe you should include a reportbug script that tells them they ought to
report upstream bugs using whatever obscure internal Emacs tool the AUCTex
guys prefer. It would probably save a certain amount of trouble.

Thanks,
Daniel

[Ralf Angeli]

Post by Daniel Burrows
Oh, I see I wasn't clear enough. You're right that the trailing space in
the *current* paragraph gets eaten. However, trailing spaces get randomly
added elsewhere in the file. And yes, I'm using the current version of
auctex; if I'd installed some other version by hand I wouldn't be sending
this to the Debian BTS.
AUCTeX-version's value is "11.54"
I believe I first noticed the appearence of odd whitespace characters about
two weeks ago, but that doesn't mean it started then. I've attached a file
that seems to trigger this: fill the first paragraph, and the second
paragraph will get trailing whitespace.

Okay, I could reproduce it with Emacs 21.3. This is actually a very
severe bug. After the paragraph to be filled _every_ sentence ending
at the end of a line will get an extra space. It would be good to
release 11.55 in the near future.

I fixed it in CVS. A patch against 11.54 is attached.

Daniel, thanks for the report.

[David Kastrup]

Post by Ralf Angeli

Post by Daniel Burrows
two weeks ago, but that doesn't mean it started then. I've
attached a file that seems to trigger this: fill the first
paragraph, and the second paragraph will get trailing whitespace.

Okay, I could reproduce it with Emacs 21.3. This is actually a very
severe bug. After the paragraph to be filled _every_ sentence
ending at the end of a line will get an extra space. It would be
good to release 11.55 in the near future.
I fixed it in CVS. A patch against 11.54 is attached.

We are not going to make people happy with that one. Is the problem
only with 11.54? And probably all Emacs versions are affected? If
nobody protests, I'll put out 11.55 tomorrow. There will have to be
updates to version numbers in the usual places, and maybe an update of
RELEASE. I am sorry that I am not much of a help right now with the
release work as I am still working on getting preview-latex into
releasable state. Even when others do the preparation, doing the
release properly until it works completely will still take hours for
me in my experience. I am restricting the distribution of this mail
to the AUCTeX list and the CCed individuals: it appears off-topic on
the Debian bug list.

[Ralf Angeli]

Post by David Kastrup

Post by Ralf Angeli
Okay, I could reproduce it with Emacs 21.3. This is actually a very
severe bug. After the paragraph to be filled _every_ sentence
ending at the end of a line will get an extra space. It would be
good to release 11.55 in the near future.
I fixed it in CVS. A patch against 11.54 is attached.

We are not going to make people happy with that one. Is the problem
only with 11.54?

Yes.

Post by David Kastrup
And probably all Emacs versions are affected?

Every released version of Emacs and XEmacs. The only one not affected
is CVS Emacs.

Post by David Kastrup
If nobody protests, I'll put out 11.55 tomorrow. There will have to
be updates to version numbers in the usual places, and maybe an
update of RELEASE.

I'll handle these.

[Reiner Steib]

[...]

Post by David Kastrup

Post by Ralf Angeli
Okay, I could reproduce it with Emacs 21.3. This is actually a very
severe bug. After the paragraph to be filled _every_ sentence
ending at the end of a line will get an extra space. It would be
good to release 11.55 in the near future.
I fixed it in CVS. A patch against 11.54 is attached.

We are not going to make people happy with that one. Is the problem
only with 11.54? And probably all Emacs versions are affected? If
nobody protests, I'll put out 11.55 tomorrow.

I found a different (more severe [1]) fill problem, both in AUCTeX
11.54 and in CVS HEAD when using Emacs 21.3. I have sent the file in
private mail to Ralf; he will debug it.

So we should probably wait for 11.55 until Ralf finds out what's
happening and a fix is applied and tested.

[1] Filling beyond paragraph boundaries when using `M-q', losing of
comment characters.

Bye, Reiner.

[David Kastrup]

Post by Reiner Steib
[...]

Post by David Kastrup

Post by Ralf Angeli
Okay, I could reproduce it with Emacs 21.3. This is actually a very
severe bug. After the paragraph to be filled _every_ sentence
ending at the end of a line will get an extra space. It would be
good to release 11.55 in the near future.
I fixed it in CVS. A patch against 11.54 is attached.

We are not going to make people happy with that one. Is the problem
only with 11.54? And probably all Emacs versions are affected? If
nobody protests, I'll put out 11.55 tomorrow.

I found a different (more severe [1]) fill problem, both in AUCTeX
11.54 and in CVS HEAD when using Emacs 21.3. I have sent the file in
private mail to Ralf; he will debug it.

Just as a note for future releases: when updating the versions in the
AUCTeX spec file, I propose to leave "release" value on 0, and I will
update it to 1 only when I am actually doing the release. In that
way, if anybody in the wild builds an RPM from a nightly snapshot
(like last night), its version will give it away as not being the real
thing.

[Ralf Angeli]

Post by Reiner Steib
[1] Filling beyond paragraph boundaries when using `M-q', losing of
comment characters.

Here is a minimal testcase:

\documentclass{article}
\begin{document}
\section{foo"=bar}
foo"=bar
baz
\end{document}

With Emacs 21.3 place point onto the start of the line with "baz".
Type `M-: (TeX-find-opening-brace) RET'. It will return a point in
the buffer, but it should return nil.

`TeX-find-opening-brace' uses `scan-lists' with the syntax table
returned by `TeX-search-syntax-table'. The problem here is that ?\"
has string quote syntax in Emacs 21.3 which hides the closing brace of
the \section command. (You can check this by setting the syntax table
with `M-: (set-syntax-table (TeX-search-syntax-table)) RET' and typing
`C-u C-x =' on a `"' character.) In contrast to Emacs 21.3, CVS Emacs
shows "default" syntax on such a character and therefore is not
affected by the bug.

I checked in a change which sets the syntax of ?\" to punctuation
syntax. But frankly I don't know why this is necessary at all (and it
probably isn't sufficient to cover every case). According to the
descriptions of `make-syntax-table' and `make-char-table', the
statement

(make-syntax-table (make-char-table 'syntax-table))

should set up a syntax table with all entries defaulting to nil and
not inheriting from any parent. But in Emacs 21.3 it either inherits
something or `with-syntax-table' is not working correctly.

In case we cannot rely on the syntax table being empty the use of an
extra syntax table for searching parenthetical constructs is
questionable.

[Reiner Steib]

Post by Ralf Angeli

Post by Reiner Steib
[1] Filling beyond paragraph boundaries when using `M-q', losing of
comment characters.

[...]

Post by Ralf Angeli
With Emacs 21.3 place point onto the start of the line with "baz".
Type `M-: (TeX-find-opening-brace) RET'. It will return a point in
the buffer, but it should return nil. [...]

Thanks a lot for debugging and fixing this problem so quickly!

Bye, Reiner.

[David Kastrup]

Ralf Angeli <***@iwi.uni-sb.de> writes:

[...]

What with the shy regexp stuff and this mixed report, I am too stupid
to get the message. Postpone 11.55 or not?

[Ralf Angeli]

Post by David Kastrup
What with the shy regexp stuff and this mixed report, I am too stupid
to get the message. Postpone 11.55 or not?

If you can arrange it with your time, let's wait what the XEmacs
people have to say. If you don't want to wait, you can release 11.55
right away after swapping the current definition of
`LaTeX-auto-class-regexp-list' with the following (I really hate to
clutter the code with such workarounds.):

(defvar LaTeX-auto-class-regexp-list
(let ((list
'( ;; \RequirePackage[<options>]{<package>}[<date>]
("\\\\Require\\(Package\\)\\(\\[\\([^#\\.%]*?\\)\\]\\)?\
{\\([^#\\.\n\r]+?\\)}"
(3 4 1) LaTeX-auto-style)
;; \RequirePackageWithOptions{<package>}[<date>],
("\\\\Require\\(Package\\)WithOptions\\(\\){\\([^#\\.\n\r]+?\\)}"
(2 3 1) LaTeX-auto-style)
;; \LoadClass[<options>]{<package>}[<date>]
("\\\\Load\\(Class\\)\\(\\[\\([^#\\.%]*?\\)\\]\\)?\
{\\([^#\\.\n\r]+?\\)}"
(3 4 1) LaTeX-auto-style)
;; \LoadClassWithOptions{<package>}[<date>]
("\\\\Load\\(Class\\)WithOptions\\(\\){\\([^#\\.\n\r]+?\\)}"
(2 3 1) LaTeX-auto-style)
;; \DeclareRobustCommand{<cmd>}[<num>][<default>]{<definition>},
;; \DeclareRobustCommand*{<cmd>}[<num>][<default>]{<definition>}
("\\\\DeclareRobustCommand\\*?{?\\\\\\([A-Za-z]+\\)}?\
\\[\\([0-9]+\\)\\]\\[\\([^\n\r]*?\\)\\]"
(1 2 3) LaTeX-auto-optional)
("\\\\DeclareRobustCommand\\*?{?\\\\\\([A-Za-z]+\\)}?\
\\[\\([0-9]+\\)\\]"
(1 2) LaTeX-auto-arguments)
("\\\\DeclareRobustCommand\\*?{?\\\\\\([A-Za-z]+\\)}?"
1 TeX-auto-symbol))))
;; At least XEmacs 21.4.16 segfaults when it encounters shy groups.
(unless (featurep 'xemacs)
;; Patterns for commands described in "LaTeX2e font selection" (fntguide)
(add-to-list 'list '("\\\\DeclareMath\
\\(?:Symbol\\|Delimiter\\|Accent\\|Radical\\){?\\\\\\([A-Za-z]+\\)}?"
1 TeX-auto-symbol) t)
(add-to-list 'list '("\\\\\\(Declare\\|Provide\\)Text\
\\(?:Command\\|Symbol\\|Accent\\|Composite\\){?\\\\\\([A-Za-z]+\\)}?"
1 TeX-auto-symbol) t)
(add-to-list 'list '("\\\\Declare\\(?:Text\\|Old\\)FontCommand\
{?\\\\\\([A-Za-z]+\\)}?"
1 TeX-auto-symbol) t))
list)
"List of regular expressions matching macros in LaTeX classes and packages.")

[David Kastrup]

Post by Ralf Angeli

Post by David Kastrup
What with the shy regexp stuff and this mixed report, I am too stupid
to get the message. Postpone 11.55 or not?

If you can arrange it with your time, let's wait what the XEmacs
people have to say.

Ok.

[Björn Pedersen]

Post by Ralf Angeli

Post by Reiner Steib
[1] Filling beyond paragraph boundaries when using `M-q', losing of
comment characters.

\documentclass{article}
\begin{document}
\section{foo"=bar}
foo"=bar
baz
\end{document}
With Emacs 21.3 place point onto the start of the line with "baz".
Type `M-: (TeX-find-opening-brace) RET'. It will return a point in
the buffer, but it should return nil.

Xemacs-21.4.15 and CVS auctex returns nil.

Björn

[Davide G. M. Salvetti]

RA == Ralf Angeli [2005-1-31]

RA> Okay, I could reproduce it with Emacs 21.3. This is actually a very
RA> severe bug. After the paragraph to be filled _every_ sentence
RA> ending at the end of a line will get an extra space. It would be
RA> good to release 11.55 in the near future.

In the mean time, I added this patch as well to the Debian 11.54-5
package.

RA> I fixed it in CVS. A patch against 11.54 is attached.

Thanks.

[Frank Küster]

Post by Daniel Burrows
BTW, if you're going to complain about the use of the BTS to report bugs,
maybe you should include a reportbug script that tells them they ought to
report upstream bugs using whatever obscure internal Emacs tool the AUCTex
guys prefer. It would probably save a certain amount of trouble.

I'm preparing a patch for the AUCTeX package that would provide the
relevant information in the mail created by reportbug, or M-x
debian-bug.

Regards, Frank