Re: some emacs-21.1.1 problems

[Dr. Mirko Luedde]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.1.1 (i386-msvc-nt5.0.2195)
 of 2001-10-22 on buffy
configured using `configure --with-msvc (12.00)'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: DEU
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

Hello, 

thanks for your comments. Here's a revision of my original report
considering the information you provided or requested.

1. When starting a bash-2.05a.0(2)-release shell in an emacs-21.1.1
buffer: "readline: warning: rl_prep_terminal: cannot get terminal
settings". I installed readline-4.2.3 from cygwin.  Bash outside of
emacs doesn't show this problem.

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.

E.Zaretskii <eliz@is.elta.co.il> wrote: 
> ...
> What is the value of the TERM environment variable in the shell buffer?
> It's quite possible that the termcap/terminfo data base installed by 
> Cygwin ports simply doesn't grok the value that Emacs pushes into the 
> environment.  In other words, it could be a Cygwin bug.
> ...

# echo $TERM
emacs
# echo $TERMCAP
emacs:co#124:tc=unknown:
# cat emacs/etc/termcap.src | fgrep emacs
emacs:tc=unknown:

2. Probably related: In an ess-5.1.19 buffer when typing
e.g. "help(nls)": "ess-error: ESS process not ready. Finish your
command before trying again."

E.Zaretskii wrote:
> ...
> What is ESS?  What does it do?
> ...

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.
    
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".

E.Zaretskii wrote: 
> ...
> Please try to supply a full recipe for reproducing the problem,
> starting with "emacs -q --no-site-file", especially when the problem
> is related to a package that is not part of the standard Emacs
> distribution, such as mailcrypt.
> ...

(bash)
# cd /cygdrive/d/Tools/mailcrypt
# emacs -q --no-site-file
(emacs)
M-x load-library RET 
mailcrypt RET
M-x mc-setversion RET 
gpg RET
M-x find-file RET
Accounts.txt.gpgasc RET
M-x mc-decrypt RET
(error as described above)

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.  Using `temporary-file-directory' (or
`"/cygdrive/d/tmp"') instead of `"/tmp"' in mailcrypt.el does not
solve the problem.

5. Despite having "(setq auto-compression-mode t)", files of type
".gz" will not be unzipped in dired-mode (gunzip-1.3).

E.Zaretskii wrote: 
> ...
> Also, note that the way to turn on auto-compression mode is to type
> "M-x auto-compression-mode RET" or put "(auto-compression-mode 1)"
> in your .emacs, not set the variable.
> ...

The problem is solved. 

6. Files of type ".tar" will not be parsed correctly in dired-mode
  (untarred with GNU-tar-1.13.19, tarred with some prior version).

E.Karni wrote: 
> ...
> I'm almost sure that this has to do with your language environment
> and coding system. Try to start Emacs with LANG=C.
> ...

This doesn't help.

E.Zaretskii wrote: 
> ...
> What does ``not parsed correctly'' mean?  Please tell exactly what did 
> you type and what did Emacs do incorrectly.  It works for me, FWIW.
> ...

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
  ---------      24/9954696     347 
  -w-r-s-wx    5512/1991    1737243 EX@
  ----wxrw-   84890/2654    7560016 
  -ws-ws---      33/28736712   5440 
  ---------      37/9254       2661 ìX@
  ---r-x---       0/40      27133456

7. Not all dired-listing-switches will have effect: e.g. "-n", "-o".

E.Karni wrote: 
> ...
> I think that is because you use Emacs built-in emulation for
> `ls'. If you want to work with Cygwin `ls' (you'll see symlinks as
> such and also scripts as executable) you have to set 2 variables:
> ... 

The problem is worked-around.

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 !-)

Regards, Mirko.