headers
Eugene Kurbatov | 1 Aug 2004 11:22
Picon

(no subject)


Hello!  My Dired don't use values of the ls-lisp-dirs-first and
ls-lisp-verbosity variables to produce list that I wish.  It only did it if I
call customization group 'Dired' (menu bar Options/Customize Emacs/Specific
Group) and than make refresh with 'g'.  It's strange isn't it?

This is the part of my ~/.emacs:
;; ...
(custom-set-variables
;; ...
 '(ls-lisp-dirs-first t)
 '(ls-lisp-verbosity (quote (uid gid)))
;; ...
)

Thank you.

Emacs  : GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-03-22 on raven, modified by Debian
Package: dired-x

current state:
==============
(setq
 dired-bind-vm nil
 dired-vm-read-only-folders nil
 dired-bind-jump t
 dired-bind-info t
 dired-bind-man t
 dired-find-subdir nil
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Schierl | 1 Aug 2004 21:24
Picon
Picon

M-x shell does not work on Windows when default-directory too long

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
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 emacs-pretest-bug <at> gnu.org mailing list.

[cc to bug-gnu-emacs since the bug occurs as well:
In GNU Emacs 21.3.1 (i386-msvc-windows98.3000)
 of 2003-03-28 on buffy]

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

Start Emacs with -q.

Open an existing file with a long path (e.g.
"c:/temp/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/foo.txt"). 

Press M-x shell RET

A shell window will appear but there is nothing in it - no prompt no
nothing. Entered Commands will not have any effects.

--Or:--

Evaluate the following code and run M-x shb.

(defvar shb-procname shell-file-name)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jason Rumney | 1 Aug 2004 22:23
Picon

Re: M-x shell does not work on Windows when default-directory too long

Michael Schierl <schierlm-usenet <at> gmx.de> writes:

> Start Emacs with -q.
>
> Open an existing file with a long path (e.g.
"c:/temp/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/deepdir/foo.txt"). 
>
> Press M-x shell RET
>
> A shell window will appear but there is nothing in it - no prompt no
> nothing. Entered Commands will not have any effects.

> 		       "COMSPEC=C:\\WINDOWS\\COMMAND.COM"))

Thank you for your report. Unfortunately COMMAND.COM is not Free
Software, so the Emacs developers cannot do anything about its
limitations. I tried to reproduce this with CMD.EXE (the native shell
of NT and its derivatives), and it does not happen, so it would appear
that COMMAND.COM is the source of the problem.
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 2 Aug 2004 06:03
Picon

Re: (no subject)

> From: Eugene Kurbatov <eugenero <at> mail.ru>
> Date: Sun, 01 Aug 2004 15:22:45 +0600
> 
> Hello!  My Dired don't use values of the ls-lisp-dirs-first and
> ls-lisp-verbosity variables to produce list that I wish.  It only did it if I
> call customization group 'Dired' (menu bar Options/Customize Emacs/Specific
> Group) and than make refresh with 'g'.  It's strange isn't it?
> 
> This is the part of my ~/.emacs:
> ;; ...
> (custom-set-variables
> ;; ...
>  '(ls-lisp-dirs-first t)
>  '(ls-lisp-verbosity (quote (uid gid)))
> ;; ...
> )
> 
> 
> Thank you.
> 
> 
> 
> Emacs  : GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
>  of 2002-03-22 on raven, modified by Debian
> Package: dired-x

Emacs doesn't use ls-lisp on GNU/Linux systems, so any user options
that pertain to the ls-lisp package will not have any effect.

ls-lisp is for systems that lack the `ls' program (MS-Windows etc.).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yves Martin | 2 Aug 2004 09:32
Picon

CPU consumption with large TAGS file


   Hello,

 I have a trouble with emacs since a long time:
 - symptom: CPU consumption of 80/90 % just three minutes after emacs
   was minimized (desktop changed with GNOME/Sawfish)
 - when emacs get focus back, the CPU come back to 0 %...

 and I just find out where it comes from:
 - I just started emacs and the problem appears with only one buffer
   opened: my TAGS file (14 Mb)

 Is it a known issue ? If yes, what to do to get ride of that problem ?

 If not ? How can I help to send a better diagnostic ?

 Thank you in advance for your help
 Regards,
--

-- 
Yves Martin
Permalink | Reply | 1 comment |
headers
Yves Martin | 2 Aug 2004 12:02
Picon

Re: CPU consumption with large TAGS file

Yves Martin <ymartin <at> nospam.fr> writes:

>  Is it a known issue ? If yes, what to do to get ride of that problem ?
>  If not ? How can I help to send a better diagnostic ?

 I forgot an important info:
 GNU Emacs 21.3.2 (i386-mandrake-linux-gnu, X toolkit, Xaw3d scroll
 bars) of 2004-02-12 on ke.mandrakesoft.com, modified by Mandrake

 Regards,
--

-- 
Yves Martin
Permalink | Reply | 0 comments |
headers
Kevin Rodgers | 2 Aug 2004 17:35
Picon
Favicon

Re: (no subject)

Eli Zaretskii wrote:
 > Emacs doesn't use ls-lisp on GNU/Linux systems, so any user options
 > that pertain to the ls-lisp package will not have any effect.
 >
 > ls-lisp is for systems that lack the `ls' program (MS-Windows etc.).

 From ls-lisp.el:
;; This file redefines the function `insert-directory' to implement it
;; directly from Emacs lisp, without running ls in a subprocess.  It
;; is useful if you cannot afford to fork Emacs on a real memory UNIX,
;; under VMS or other non-UNIX platforms if you don't have the ls
;; program, or if you want a different format from what ls offers.
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Perhaps that's what Eugene wants.

Setting those 2 variables (ls-lisp-dirs-first and ls-lisp-verbosity)
via custom-set-variables doesn't actually cause ls-lisp to be loaded,
so maybe he just needs to explicitly load it.

--

-- 
Kevin Rodgers
Permalink | Reply | 0 comments |
headers
Davin Pearson | 4 Aug 2004 11:57
Picon
Picon

BUG: hexl-mode displays file incorrectly

To: bug-gnu-emacs <at> gnu.org
Subject: hexl-mode bug
--text follows this line--
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.

In GNU Emacs 20.7.1 (i386-*-nt5.1.2600)
 of Wed Jun 14 2000 on buffy
configured using `configure NT'

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

Reading the file hexl-bug.dat (attached to this email)
generates the following output:

00000000: 2881 ff29                                (..)

But (as you will see if you look at hexl-bug.dat)
the actual file is only 3 bytes long and contains,
in order the following 3 chars: 0x28, 0xff, and 0x29.

Recent input:
down-mouse-1 mouse-1 C-f z tab l tab return C-s m o
z down-mouse-1 mouse-movement mouse-1 kp-enter down-mouse-1
mouse-movement mouse-1 kp-enter down-mouse-1 mouse-movement
mouse-1 kp-enter down-mouse-1 mouse-movement mouse-1
kp-enter down-mouse-1 mouse-movement mouse-1 menu-bar
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tomas Abrahamsson | 4 Aug 2004 20:27
Picon
Picon
Picon
Favicon

Contribution: new version of artist


Hi,

	I'd like to contribute a new version of Artist:
version 1.2.5. (The version included in emacs-21.3 is 1.2.4.)

I added tool selection via the mouse-wheel. (Function
provided by Andreas Leue <al <at> sphenon.de>)

The source code is available here:
   http://www.lysator.liu.se/~tab/artist/artist-1.2.5/artist.el

The full package:
   http://www.lysator.liu.se/~tab/artist/artist-1.2.5.tar.gz

The home page:
   http://www.lysator.liu.se/~tab/artist/

/Tomas
Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 4 Aug 2004 18:28
Picon

Re: BUG: hexl-mode displays file incorrectly

> Date: Wed, 04 Aug 2004 21:57:25 +1200
> From: Davin Pearson <dmp36 <at> student.canterbury.ac.nz>
> 
> In GNU Emacs 20.7.1 (i386-*-nt5.1.2600)
>  of Wed Jun 14 2000 on buffy
> configured using `configure NT'
> 
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
> 
> Reading the file hexl-bug.dat (attached to this email)
> generates the following output:
> 
> 00000000: 2881 ff29                                (..)
> 
> But (as you will see if you look at hexl-bug.dat)
> the actual file is only 3 bytes long and contains,
> in order the following 3 chars: 0x28, 0xff, and 0x29.

Thanks, this bug is solved in Emacs 21.x.
Permalink | Reply | 0 comments |

Gmane