Stephen J. Turnbull | 15 Jan 2010 17:28
Picon
Favicon

Dired 7.16 bug: dired on ~ prevents exiting XEmacs with desktop.el active

When exiting from XEmacs with desktop.el active, the desktop file in
~, and a dired buffer open on ~, attempting to exit (C-x C-c) fails
with the error

    Error in dired-find-file-place 

The dired buffer is corrupted like this:

  drwx------  3 steve users     4096 Sep  3  2008 .dbus 
  drwxr-xr-x  3 steve users     4096 May 14  2007 .emacs.d-rw-r--r-- 1 steve users 16314 Jan 16 01:16
/home/steve/.emacs.desktop 
  -rw-------  1 steve users       16 Jul 30 15:23 .esd_auth 

Restoring it with g gives:

  drwx------  3 steve users     4096 Sep  3  2008 .dbus 
  drwxr-xr-x  3 steve users     4096 May 14  2007 .emacs.d 
  -rw-r--r--  1 steve users    16314 Jan 16 01:16 .emacs.desktop 
  -rw-------  1 steve users       16 Jul 30 15:23 .esd_auth 

but C-x C-c fails in the same way.

The above report has been registered with the XEmacs tracker
(issue655).

Emacs  : XEmacs 21.5  (beta29) "garbanzo" 1444e28f1a3d [Lucid] (x86_64-unknown-linux, Mule) of Tue Nov 24
2009 on uwakimon
Package: Dired

current state:
(Continue reading)

Stephen J. Turnbull | 6 Oct 2009 13:50
Picon
Favicon

Dired 7.16 bug: dired.el conflicts with :file specs for image specifiers

David Kastrup claims in <877hvanduk.fsf@...> on
xemacs-beta:

    I think it is still impossible to use a :file specification for
    image specifiers of binary formats (jpg, png and binary pnm
    formats) in XEmacs once you have loaded dired.el.  So you have to
    use crazy workarounds or face non-working stuff.  Since that is
    not documented anywhere, you have to work with copy&paste of code
    and workarounds from others, and pray.

I haven't replicated myself, but he's usually a trustworthy observer
although a PITA to work with.

issue583 has been created on the XEmacs tracker.
Jerry James | 24 Jun 2009 16:40
Picon

Dired 7.16 bug: GNU coreutils 7.2

Please see https://bugzilla.redhat.com/show_bug.cgi?id=504422 for more
information.  Essentially, GNU coreutils 7.2 adds a new character to
the long listing produced by ls.  The mode bits are now followed by a
single character:
- A space to indicate no alternate access methods;
- A period to indicate an SELinux context, but no other alternate access
  methods
- A plus for anything else.

ACLs are considered "alternate access methods".  This extra character
breaks lots of scripts, so naturally the GNU coreutils maintainers
added a switch to suppress printing it.

Ha ha!  Just kidding!  There's no (documented, in any case) way to
turn it off.  The upshot is that dired is broken on Fedora 11.  I
would appreciate any suggestions on how to address this problem.  Here
is an example of a long listing in the new format:

[jamesjer <at> localhost TeX]$ ls -l
total 180
drwxr-xr-x. 2 jamesjer users  4096 2006-03-05 22:10 bst
-rw-r--r--. 1 jamesjer users 41216 2006-03-05 20:13 llncs.cls
-rw-r--r--. 1 jamesjer users 34028 2006-11-12 16:05 sigplanconf.cls
-rw-r--r--. 1 jamesjer users 95715 2006-11-12 16:06 sigplanconf-guide.pdf

Emacs  : XEmacs 21.5  (beta28) "fuki" [Lucid] (x86_64-redhat-linux,
Mule) of Sun Mar  8 2009 on x86-1.fedora.phx.redhat.com
Package: Dired

current state:
(Continue reading)

Thomas Mittelstaedt | 29 Nov 2008 17:20
Picon

Dired 7.16 bug: dired incorrectly displays directory name containing utf-8 character

-------- Weitergeleitete Nachricht --------
> Von: Thomas Mittelstaedt <tmstaedt@...>
> Reply-to: tmstaedt@...
> An: xemacs-beta@...
> Betreff: dired incorrectly displays directory name containing utf-8
> character
> Datum: Sat, 29 Nov 2008 04:39:17 +0100
> 
> Hallo, 
> 
> I don't know if this is a bug or if I need to set something up right.
> My home folder contains a file called 'Öffentlich', but dired displays
> it as 'Ã\226ffentlich'. I downloaded the latest dired version (7.16) and
> tried dired-mule, which did not help.
> 
> thomas
> 

-------- Weitergeleitete Nachricht --------
> Von: Stephen J. Turnbull <stephen@...>
> An: tmstaedt@...
> Kopie: xemacs-beta@...
> Betreff: Re: dired incorrectly displays directory name containing utf-8 character
> Datum: Sat, 29 Nov 2008 14:28:52 +0900
> 
> Thomas Mittelstaedt writes:
>  > And I am using a recent mercurial version of xemacs, which correctly
>  > displays unicode files otherwise.
> 
> Try M-: (setq file-name-coding-system 'utf-8) RET, then dired.  Or
(Continue reading)

Marcus Harnisch | 15 May 2008 17:39

Dired 7.16 bug: [XEmacs/WinXP native] sorting depends on --dired

Hi all

Enabling `--dired' reverses the sorting order in the dired
buffer. Data generated by ls seems to be OK. Strangely, I see that
issue only on WinXP, but not on my linux-x86_64 system.

Reproduce by:

1. open a directory using Dired

2. toggle `dired-use-ls-dired'

3. refresh dired buffer.

Regards
Marcus

Emacs  : XEmacs 21.5  (beta28) "fuki" (+CVS-20071205) [Lucid] (i586-pc-win32, Mule) of Thu Jan 24 2008 on VSHELTON-PC2
Package: Dired

current state:
==============
(setq
 dired-version "7.16"
 dired-auto-shell-command-alist nil
 dired-backup-if-overwrite nil
 dired-chown-program "/etc/chown"
 dired-cleanup-alist '(("tex" ".toc" ".log" ".aux" ".dvi")
		       ("latex" ".toc" ".log" ".aux" ".idx" ".lof" ".lot" ".glo" ".dvi") ("bibtex" ".blg" ".bbl")
		       ("texinfo" ".cp" ".cps" ".fn" ".fns" ".ky" ".kys" ".pg" ".pgs" ".tp" ".tps" ".vr" ".vrs")
(Continue reading)

glenn opdycke-hansen | 29 Dec 2007 23:30
Picon

Dired 7.15 bug: cannot view file from dired

(I was requested to run dired-report-bug,  however when I try to send
the mail, the message "`smtpmail-smtp-server' not defined" is
displayed. Therefore, I am sending this via gmail.)

I started with 21.4 (Educational Television) install of XEmacs on
winxp.  The problem does not appear with this version.
I then updated dired to 1.18 via Tools|Packages.
Now if the file has size of 999 or less in dired, then it can be
viewed.  However, if the file size is 1000 or more then viewing the
file will result in a problem when viewing the file.  For example if
the dired line is "2420 Dec 26 22:21 build.xml" then viewing the
build.xml file will bring up a window for "21 build.xml".
Also, X-d will result in "d:\hib-helloworld\Dec 26 22:" in the
minibuffer.

--glenn

Emacs  : XEmacs 21.4 (patch 21) "Educational Television" [Lucid]
(i586-pc-win32) of Sun Oct 07 2007 on VSHELTON-PC2
Package: Dired

current state:
==============
(setq
 dired-version "7.15"
 dired-backup-if-overwrite nil
 dired-chown-program "/etc/chown"
 dired-cleanup-alist '(("tex" ".toc" ".log" ".aux" ".dvi") ("latex"
".toc" ".log" ".aux" ".idx" ".lof" ".lot" ".glo" ".dvi")
		       ("bibtex" ".blg" ".bbl")
(Continue reading)

Dan Poirier | 24 Dec 2007 23:26
Picon
Favicon
Gravatar

Dired 7.14 bug: Failure to parse ls output on Mac OS X 10.5 Leopard

This is a followup to a previous report on this problem.  I never got
any response so I'm not sure if it ever got sent.  I'll paste this one
into my normal mail program to be sure.

Basically, dired in xemacs on Mac OS X 10.5 fails to load most  
directories.  The error
message is "no file on this line".

The cause appears to be a new output format for ls in Mac OS X 10.5
"Leopard".  Here's a sample:

drwx------ <at>    3 poirier  staff      102 Dec  7 06:21 .cups
drwxr-xr-x    3 poirier  staff      102 Nov 30 16:19 .eclipse
-rw-r--r--    1 poirier  staff      110 Dec 12 19:02 .eclipse_keyring
lrwxr-xr-x    1 poirier  staff       25 Dec  1 08:03 .unison -> /Users/ 
poirier/svn/unison
drwx------+   7 poirier  staff      238 Dec 24 12:40 Desktop

Note that many lines have an additional character stuck on the end of
the permissions.  Setting dired-ls-program to point to a little shell
script that ran the output of ls through "cut -c 1-10,12-" fixed it,
which I think confirms the cause.

One way to fix dired was to change the constant value 17 to 18 at two
places around line 2786 of dired.el.  (This is in
dired-manual-move-to-filename).

Unfortunately I don't know if that change would break dired on other
systems.  I suspect that it would.

(Continue reading)

Michael Sperber | 17 Dec 2007 19:35
Picon

Re: Dired 7.14 bug: Mac OS X Leopard no file on line


poirier@... writes:

> Attempting to visit some directories with dired fails with a
> message "No file on line".
>
> Mac OS X 10.5.1
>
> Xemacs from macports.org
>
> I'm *guessing* this is due to ls -l on Mac OS X 10.5.1 displaying
> an additional character after the permissions on some lines, that
> 10.4 didn't have:

Indeed.  I've checked in a fix both to Savannah and the XEmacs package
repository, which should show up soon as an XEmacs package release.
Thanks for the report!

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Joseph S D Yao | 10 Nov 2005 01:34
Favicon

Which <at> xemacs.org e-mail addresses are being used?

OK, I said I'd take care of this, and I will.  My apologies if this is
going out to too many people, but with so many mailing lists involved,
I'd rather that this get to everyone who needs to see it than miss a
number of important addressees.

We need to clean up the  <at> xemacs.org addresses being hosted on  <at> tux.org.
Right now, they are merged in with all other  <at> tux.org e-mail addresses.

The first list that follows is the list of aliases defined by the xemacs
aliases file.  As aliases, they are indistinguishable from any other
e-mail addresses coming onto this e-mail host.  One problem is, that
some of these conflict with other aliases, specifically:

MAILER-DAEMON, hostmaster, mailman, mailman-owner, postmaster, webmaster

Another problem is that non- <at> xemacs.org users are being sent SPAM to
 <at> xemacs.org mail addresses, and don't like it.

The second list below is that of the e-mail addresses in the alias
definitions who are in the  <at> xemacs.org domain.  Some of them don't even
exist!

I am going to fix the problem by making  <at> xemacs.org into a partial
virtual domain, rather than having it [as now] as another name for
 <at> tux.org.

QUESTIONS:

(1) Are all the mailing lists in List 1, below, still needed and used?
More specifically, are there any I should throw out?  [And if any of
(Continue reading)

OCallaghan, Timothy (ELS | 25 Jul 2005 10:59
Picon

RE: efs versus gnu emacs 21.3

>
> I've started looking into efs 1.20 (the latest version I could find
> online).  

I've started looking into getting some VMS patch's for the main efs. But i
was not sure where the latest version is kept, and so what to patch against.
Could anyone enlighten me please?

> If anyone has thoughts on how realistic this idea is, I'd be very
interested in hearing them.

I would guess it is possible, from my limited understanding of it. 

--
Tim O'Callaghan
Senior Software Engineer
Elsevier Bibliographic Databases 
Tel. +31 (20) 485 2116

Dale Hagglund | 22 Jul 2005 17:39
Picon

efs versus gnu emacs 21.3

I've started looking into efs 1.20 (the latest version I could find
online).  But, I use gnu emacs 21.3 and not xemacs.  When I started
trying to compile efs for gnuemacs 21.3, I immediately ran into a few
functions that were causing problems:

        user-home-directory             not in 21.3
        dired-call-process              not in 21.3
        abbreviate-file-name            fewer args in 21.3
        directory-files                 fewer args in 21.3

Before I dive in and provide replacements for these, I thought I'd ask
if anyone else had already done the work and was willing to share it?

My underlying reason for looking into efs is more complicated.  At
work, I need to work with many files on a windows file server and I
was hoping that, after getting efs working properly, it would be
reasonable to make it understand how to use smbclient to talk to
windows boxes.  smbclient is similar but not identical to ftp clients
at the command level.  If anyone has thoughts on how realistic this
idea is, I'd be very interested in hearing them.

Thanks in advance, 

Dale Hagglund.


Gmane