headers
ishikawa | 1 Jun 2009 09:36
Picon

bug#3438: emacs 23.0.9{,3,4} dired mode bug(?)

Hi,

Thank you for making the great package available for pre-release testing.

While I began experimenting with this alpha/beta version,
I noticed a couple of lisp .elc files were not
correctly read, but I fixed them by
byte-recompile-directory.

After a day's use, I found a deeper problem with "dired" mode.

So I am reporting it here.

It is both in 23.0.93 which I initially tried, and
23.0.94 (confirmed today).

TIA.

========================================
A dired mode bug?
----------------------------------------
emacs-version : "23.0.93.1"
emacs-version : "23.0.94.1"  Both versions suffer from the same problem.

UNEXPECTED SYMPTOM:

In dired mode, when the cursor is near the beginning of a very long filename
(as in near the
"AaAaAa..." below ,
I can't move down to the next file by "n" or "cursor down" key anymore(!).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marshall, Simon | 1 Jun 2009 13:19
Favicon

bug#3441: 23.0.94; *compilation* long lines painfully slow

Guys, this is a follow-up to
http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=2223.  It
might not have anything to do with that bug at all - I was just going
back and seeing if that bug had been fixed.

Create a Makefile with the contents:

all:
	 <at> echo [insert 5000 chars]

Run emacs -Q and do Tools > Compile... RET and I see Emacs create the
*compilation* window and insert chunks of the echo output.  23.0.94
takes 20+ seconds to complete it and is pretty much unusable during that
time.  22.3 takes 1 second.  Looking back at earlier pretests, this also
applies to 23.0.91.

Thanks, Simon.

In GNU Emacs 23.0.94.1 (sparc-sun-solaris2.8, Motif Version 2.1.0)
 of 2009-06-01 on risksun2
Windowing system distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--x-includes=/usr/openwin/include:/usr/dt/include:/usr/local/include:/u
sr/local/X11/include'
'--x-libraries=/usr/openwin/lib:/usr/dt/lib:/usr/local/lib:/usr/local/X1
1/lib' '--with-x-toolkit=motif' '--with-jpeg=no' '--with-gif=no'
'--with-tiff=no' 'CFLAGS=-g''

Important settings:
  value of $LC_ALL: nil
(Continue reading)

Permalink | Reply | 0 comments |
headers
Teemu Likonen | 1 Jun 2009 14:36
Picon
Picon
Favicon

bug#3442: 23.0.94; "C-x 5 1" (delete-other-frames) kills daemon

When Emacs daemon is running and a client frame is active, executing
delete-other-frames command (C-x 5 1) kills the daemon and makes the
Emacs session just a normal server session which requires that one frame
exists. To reproduce:

 1. Start Emacs daemon:

        emacs -Q --daemon

 2. Start a client session:

        emacsclient -c

 3. Type "C-x 5 1" and then try to close the frame with "C-x 5 0". The
    following message is displayed in the minibuffer:

        Attempt to delete the sole visible or iconified frame

 4. Forcibly close the frame with "C-x C-c" or window manager's close
    button.

 5. See the system's process list with "ps" command. There is no Emacs
    process anymore.

In GNU Emacs 23.0.94.1 (i686-pc-linux-gnu, GTK+ Version 2.12.12)
 of 2009-06-01 on mithlond
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  '--prefix=/home/dtw/local''

Important settings:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Jun 2009 16:55
Picon

Re: 23.0.93; dired encoding

> Date: Sun, 31 May 2009 23:09:52 +0800
> From: Jason Rumney <jasonr <at> gnu.org>
> Cc: emacs-pretest-bug <at> gnu.org, help-emacs-windows <at> gnu.org
> 
> Konstantin wrote:
> > On type M-x dired emacs shows \316\362\361\363\362\361\362\342\363\345\362 instead of root.
> >   
> 
> > My codepage is 1251.
> 
> 
> Would Отсутствует be correct?

Unless I'm blind, `file-attributes' does not decode the user and group
names by the locale's encoding, is that true?  It should, IMO.

If I'm right, this problem should show on other platforms as well, not
just on Windows, when the owner's or group's names include non-ASCII
characters.
Permalink | Reply | 0 comments |
headers
Drew Adams | 2 Jun 2009 00:07
Picon
Favicon

bug#3446: 23.0.94; Emacs manual: add an example of adding a dir to `load-path'

A newbie in help-gnu-emacs tried to load an init file that had
(require 'foobar) in it, and foobar.el wasn't in his load-path.

He then needed to know how to add a directory to the load-path. I
wanted to point him to the manual, to teach him to fish, but I found
nothing in the manual about this.

Everything in the manual about `load-path' just assumes you know how
to add a directory to it. A simple example in the init-file section,
would help:

(add-to-list 'load-path "/my/directory/")

And load-path should be indexed to the init-file node.

In GNU Emacs 23.0.94.1 (i386-mingw-nt5.1.2600)
 of 2009-05-24 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'
Permalink | Reply | 0 comments |
headers
Ryan Yeske | 2 Jun 2009 04:18
Picon
Gravatar

bug#3448: 23.0.93; Documentation mismatch in Message mode keybindings


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.

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

There are a couple inconsistencies between the documentation in 
(info "(message) Header Commands") and the actual bindings specified in
the code.

`C-c C-f C-o' is described as running both `message-goto-followup-to'
and `message-goto-from'. It is only runs the latter.

C-c C-f C-f is documented as running `message-goto-bcc', but C-c C-f C-f
runs the command `message-goto-followup-to'

C-c C-f C-w is what actually runs `message-goto-fcc', which was not
documented.

I assume the code is correct, and am including a patch to the
documentation (inline, at the end) to fix these inconsistencies.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
If you would like to further debug the crash, please read the file
/home/rcy/emacs/etc/DEBUG for instructions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Teemu Likonen | 2 Jun 2009 16:35
Picon
Picon
Favicon

bug#3450: 23.0.91; HELLO file: Finnish name for language is "suomi"

Here's a minor but easily fixable bug in HELLO file (C-h h). In the file
Finnish name for our language is written in capital letters but it
should be in small letters. Capital "Suomi" means our country; "suomi is
the language. I'd also write "hyvää" in small letters because it doesn't
begin a new sentence. So this would be the correct version:

Finnish (suomi)                 Hei, hyvää päivää
         ^                           ^

Yes, I'm a Finnish teacher. :-)
Permalink | Reply | 0 comments |
headers
Leo | 2 Jun 2009 17:57
Picon
Gravatar

bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode

On 2009-05-30 03:15 +0100, Jay Belanger wrote:
> I've never used temp-buffer-resize-mode before, but if it's supposed to
> make a window a better size for displaying a temporary buffer, I'm
> surprised it doesn't change anything back when the buffer is killed or
> hidden.  In this case, I'm not sure it's Calc's job to keep track of why
> it changed its window size.  Perhaps an option "Always start Calc with
> the initial window height" might be helpful.

I have started looking for a workaround to save me doing (setq
calc-window-height 7) all the time. I am thinking of using
calc-end-hook, however it is located right in the middle of calc-quit.
So I cannot use the following:

    (add-hook 'calc-end-hook
              (lambda ()
                (setq calc-window-height 7)))

But it seems to me that moving the hook to the very end of calc-quit is
better than putting it in the middle. Do you recall any reason why this
is not the case? Thank you.

--

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .: I use Emacs :.
Permalink | Reply | 0 comments |
headers
Jay Belanger | 2 Jun 2009 21:20
Picon

bug#3419: 23.0.94; calc, calendar and temp-buffer-resize-mode


Leo <sdl.web <at> gmail.com> writes:

> I have started looking for a workaround to save me doing (setq
> calc-window-height 7) all the time. I am thinking of using
> calc-end-hook, however it is located right in the middle of calc-quit.
> So I cannot use the following:
>
>     (add-hook 'calc-end-hook
>               (lambda ()
>                 (setq calc-window-height 7)))
>
> But it seems to me that moving the hook to the very end of calc-quit is
> better than putting it in the middle. Do you recall any reason why this
> is not the case? Thank you.

It is mentioned in the documentation that the hook is called early, so I
guess it was done on purpose.  I don't know why, though.

A workaround for now might be to define `my-calc' or `my-calc-dispatch'
with
(defun my-calc ()
   (interactive)
   (setq calc-window-heigth)
   (calc....))
Permalink | Reply | 0 comments |
headers
Leo | 2 Jun 2009 23:29
Picon
Gravatar

bug#3430: 23.0.94; cannot enable two minor modes in .dir-locals.el

On 2009-05-31 15:37 +0100, Leo wrote:
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> My LaTeX project setting looks like this:
>
> ((latex-mode . ((auto-fill-function . nil)
>                 (fill-column . 90)
>                 (mode . outline-minor)
>                 (mode . longlines)
>                 (coding . "latin-1"))))
>
> i.e. I want to enable two minor modes for all .TeX files among other
> things.
>
> I start with Emacs -q and open a .TeX in that project, only longlines is
> enabled. Do you think this is a bug? Thank you.
>
> This is tested on GNU Emacs 23.0.94.1 (i386-apple-darwin9.7.0, NS
> apple-appkit-949.46) of 2009-05-23 on 200.sub-75-216-116.myvzw.com
>
> Leo

Any comment on this bug? Can you reproduce it? Thank you.

Leo
Permalink | Reply | 0 comments |

Gmane