Re: some emacs-21.1.1 problems

[Eli Zaretskii]

> From: "Dr. Mirko Luedde" <Mirko.Luedde@Computer.Org>
> Date: Tue, 20 Nov 2001 08:56:06 +0100 (CET)
> 
> E.Karni <ehud@unix.simonwiesel.co.il> wrote:
> > ...
> > It is known problem the NTEmacs does not have the necessary terminal 
> > mechanism for Cygwin (i.e. you get the "standard input is not a tty"
> > error).
> > ...
> 
> It worked with prior versions of NTemacs/cygwin. Probably the problem
> occurs since the latest readline version.

Did you upgrade both Cygwin and Emacs?  If so, could it be that the
changes responsible for this problem are in Cygwin rather than in
Emacs?

> ESS is an emacs package that provides a frontend to the R statistics
> system, a free software clone of ATT's S and S-plus, see
> http://cran.r-project.org/. R is listed under the http://www.gnu.org
> software page.  ess-5.1.19 was working with emacs-20.7 and R-1.3.1.
> With emacs-21.1.1 everything seems to be working fine except for the
> "help" command. Probably "help" does some different kind of
> interaction with the buffer than the other commands do.

Could you please find out what does the "help" command do that is
special?

> 3. With mailcrypt-3.5.6, gnupg-1.0.6: when decrypting a buffer:
> "start-process: Removing old name: no such file or directory,
> d:/tmp/mailcrypt-gpg-stderr-764AJM".
[...]
> J.Rumney <jasonr@altavista.net> wrote:
> > ...
> > Often problems finding temporary files are caused by packages that
> > use a hard-coded "/tmp" instead of `temporary-file-directory'.
> > Indeed, I just downloaded mailcrypt-3.5.6 and it does just that.
> > This bug is probably also responsible for the security alert about
> > using mailcrypt on NT that is reported on
> > http://mailcrypt.sourceforge.net/
> > ...
> 
> Doing a "cd /tmp" in bash works, as does a "Ctrl-x d /tmp RET" and
> "Ctrl-x d d:/tmp RET" in emacs.

So the directory "d:\tmp" does exist on that system, yes?

>From the error message, it sounds like the problem happens in the
delete-file primitive, but I cannot figure out how is start-process
related to that.  Can you?

Can you run Emacs under a debugger?  If so, please put a breakpoint
in the function report_file_error, and when that breakpoint is hit
due to this problem, please tell what is the C-level backtrace at
that point.

> The problem is not easily reproducible with some test directories I
> tried it out. But it always occurs when looking at a tar of my whole
> filetree. However, tarring and untarring works fine, it is only that
> "M-x find-file" goes wild on the bad ".tar" files:
> 
> (... lines ok up to here ...) 
>  -rw-r--r--Administrator/513        3994 
> Business/Infrastructure/2001-09-19_Note_IT_issues.txt
>  -rw-r--r--Administrator/513        7896 
> Business/Infrastructure/2001-10-11_Template_Anforderungskatalog.tex
>  drwxr-xr-xAdministrator/513           0 
> Business/Infrastructure/2001-10-12_Anforderungskatalog_ChemoSelect_Software/
>   ---------   Jeder/0           132 ././@LongLink
>  -r-s--s-wx133612885/1265003271906864 
> Business/Infrastructure/2001-10-12_Anforderungskatalog_ChemoSelect_Software/2001-10-12_Anforderungs

Sounds like the problem is with the @LongLink thingy, which is a GNU
Tar specific way of handling extremely long file names.

Are you saying that Tar mode in Emacs 20 worked with these names?

> E.Zaretskii wrote:
> > ...
> > That's because the Windows port uses a Lisp emulation of the `ls'
> > program.  The documentation string of the insert-directory lists the
> > switches that are supported by the emulation; -n and -o are not
> > among them.
> > ...
> 
> The documentation for the dired-listing-switches variable says: 
> > ...
> > May contain all other options that don't contradict `-l';
> > ...
> However, it doesn't say, the options will be effective !-)

I added a note about systems which use ls-lisp.