vc making coding system nil, latexenc not protecting

vc making coding system nil, latexenc not protecting

[Karl Berry]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1699 bytes --]

Nate Eldredge (cc'd) reported a bug in emacs-22.1 when checking out
(C-x v v) an LaTeX file from RCS (exact recipe below); namely, getting
(wrong-type-argument arrayp nil)

There seem to be two problems, one in latexenc.el and one somewhere in VC.

The first is just a matter of defensive programming.  Nate tracked down
the error to the call of coding-system-base near the end of
lisp/international/latexenc.el:
                  (coding-system-base   ;Disregard the EOL part of the CS.
                   (with-current-buffer latexenc-main-buffer
                     (or coding-system-for-write buffer-file-coding-system))))

Both coding-system-for-write and buffer-file-coding-system are nil, and
thus coding-system-base throws the error.  It seems it would be
desirable to avoid the call and hence the error in this case -- if I
take out the call, for testing, everything goes through fine.  Or else
to change coding-system-base to be a no-op if its arg is nil.  I don't
know which would be better.


The second question is why both those variables are nil in the first
place.  After visiting the file, but before running CTRL-x v v,
buffer-file-coding-system is undecided-unix.  So somewhere within
vc-next-action it got set to nil.  I could not find where.  (Aside: too
bad edebug doesn't have watchpoints.)  Help?  coding-system-for-write is
always nil in this scenario, so it's not a factor.


Thanks for any help, and to Nate for his sleuthing.

Karl

Here is the recipe to reproduce the error; put the attached
template.tex,v file in the current directory first.

$ co template.tex   # with co -l, the error does not happen
$ emacs-22.1 -Q template.tex
CTRL-x v v
(observe arrayp error)


[-- Attachment #2: template.tex,v --]
[-- Type: application/octet-stream, Size: 241 bytes --]

head	1.1;
access;
symbols;
locks; strict;
comment	@% @;


1.1
date	2007.09.12.17.49.02;	author karl;	state Exp;
branches;
next	;


desc
@@


1.1
log
@Initial revision
@
text
@\documentclass[12pt]{article}

\begin{document}

\end{document}
@

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: vc making coding system nil, latexenc not protecting

[Andreas Schwab]

karl@freefriends.org (Karl Berry) writes:

> Here is the recipe to reproduce the error; put the attached
> template.tex,v file in the current directory first.
>
> $ co template.tex   # with co -l, the error does not happen
> $ emacs-22.1 -Q template.tex
> CTRL-x v v
> (observe arrayp error)

I cannot reproduce that here.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: vc making coding system nil, latexenc not protecting

[Nate Eldredge]

On Mon, 24 Sep 2007, Karl Berry wrote:

> The second question is why both those variables are nil in the first
> place.  After visiting the file, but before running CTRL-x v v,
> buffer-file-coding-system is undecided-unix.  So somewhere within
> vc-next-action it got set to nil.  I could not find where.  (Aside: too
> bad edebug doesn't have watchpoints.)  Help?  coding-system-for-write is
> always nil in this scenario, so it's not a factor.

I believe I stepped through at one point and found that it was getting set 
to nil when erase-buffer was called.  Don't have time to check right now 
but I can check it later.

-- 

Nate Eldredge
neldredge@math.ucsd.edu

Re: vc making coding system nil, latexenc not protecting

[Richard Stallman]

    I believe I stepped through at one point and found that it was getting set 
    to nil when erase-buffer was called.

It seems strange that erase-buffer clears buffer-file-coding-system.
Looking at the code of Ferase_buffer, where could it do that?

Can someone please try stepping thru Ferase_buffer and its
subroutines, and see how it happens?

Re: vc making coding system nil, latexenc not protecting

[Eli Zaretskii]

> Date: Mon, 24 Sep 2007 08:37:04 -0500
> From: karl@freefriends.org (Karl Berry)
> Cc: neldredge@math.ucsd.edu
> 
> lisp/international/latexenc.el:
>                   (coding-system-base   ;Disregard the EOL part of the CS.
>                    (with-current-buffer latexenc-main-buffer
>                      (or coding-system-for-write buffer-file-coding-system))))
> 
> Both coding-system-for-write and buffer-file-coding-system are nil, and
> thus coding-system-base throws the error.  It seems it would be
> desirable to avoid the call and hence the error in this case -- if I
> take out the call, for testing, everything goes through fine.  Or else
> to change coding-system-base to be a no-op if its arg is nil.

Why no-op? nil means undecided, AFAIK, so that's what the code should
do.  (Actually, perhaps it's better to change coding-system-base to do
that automagically, but I cannot say if this is safe without grepping
the sources for uses of coding-system-base.)

> The second question is why both those variables are nil in the first
> place.  After visiting the file, but before running CTRL-x v v,
> buffer-file-coding-system is undecided-unix.  So somewhere within
> vc-next-action it got set to nil.

That may be, but please note that there's nothing wrong with the value
of nil.

> I could not find where.  (Aside: too bad edebug doesn't have
> watchpoints.)

If you mean you want to watch buffer-file-coding-system, then it's a
buffer-specific variable, so it's stored somewhere in the buffer
structure; you could set a watchpoint on the C level.

Re: vc making coding system nil, latexenc not protecting

[Karl Berry]

    Why no-op? 

I didn't mean to imply that was the only other solution.  This is
precisely why someone who is actually familiar with coding-system-base
should make whatever change is appropriate.

    That may be, but please note that there's nothing wrong with the value
    of nil.

In that case, there is only the one bug to fix, in coding-system-base (I
guess).

Thanks,
k