[Top][All Lists]

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

Re: revert-buffer fails on cvs controlled .tex file

From: Dan Nicolaescu
Subject: Re: revert-buffer fails on cvs controlled .tex file
Date: Mon, 03 Dec 2007 14:35:34 -0800

Richard Stallman <address@hidden> writes:

  > Would someone please fix this, then ack?
  > Message-ID: <address@hidden>
  > Date: Sat, 1 Dec 2007 16:52:05 -0500
  > From: "David Rideout" <address@hidden>
  > To: address@hidden
  > MIME-Version: 1.0
  > Content-Type: text/plain; charset=ISO-8859-1
  > Content-Disposition: inline
  > Subject: revert-buffer fails on cvs controlled .tex file
  > Please write in English if possible, because the Emacs maintainers
  > usually do not have translators to read other languages for them.
  > Your bug report will be posted to the address@hidden mailing list,
  > and to the gnu.emacs.bug news group.
  > Please describe exactly what actions triggered the bug
  > and the precise symptoms of the bug:
  > First I launch emacs, loading a cvs controlled .tex file 'turtles.tex':
  > emacs -q -no-site-file turtles.tex
  > The status bar reads 'CVS:1.35', so emacs recognizes this file as controlled
  > by cvs.
  > Then I enter M-x revert-buffer.  I answer 'yes' to the prompt, and get an
  > error:
  > coding-system-get: Wrong type argument: arrayp, nil
  > The file does not revert.

I cannot reproduce this. 
Does the turtles.tex file have any local variables that deal with the
coding system? 

  > If Emacs crashed, and you have the Emacs process in the gdb debugger,
  > please include the output from the following gdb commands:
  >     `bt full' and `xbacktrace'.
  > If you would like to further debug the crash, please read the file
  > /usr/share/emacs/22.1/etc/DEBUG for instructions.
  > In GNU Emacs 22.1.1 (i386-redhat-linux-gnu, GTK+ Version 2.10.14)
  >  of 2007-11-06 on xenbuilder2.fedora.redhat.com
  > Windowing system distributor `The X.Org Foundation', version 11.0.10300000
  > configured using `configure  '--build=i386-redhat-linux-gnu'
  > '--host=i386-redhat-linux-gnu' '--target=i386-redhat-linux-gnu'
  > '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr'
  > '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
  > '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
  > '--libexecdir=/usr/libexec' '--localstatedir=/var'
  > '--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
  > '--infodir=/usr/share/info' '--with-pop' '--with-sound' '--with-gtk'
  > 'build_alias=i386-redhat-linux-gnu' 'host_alias=i386-redhat-linux-gnu'
  > 'target_alias=i386-redhat-linux-gnu' 'CFLAGS=-DMAIL_USE_LOCKF
  > -DSYSTEM_PURESIZE_EXTRA=16777216 -O2 -g -pipe -Wall
Hmm, this looks like a huge waste, I'll report it to Fedora.

reply via email to

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