headers
Eric Hanchrow | 1 Nov 2007 18:50
Gravatar

23.0.50; clone-indirect-object-other-window segfaults

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:

$ cd ...emacs-cvs/src
$ gdb emacs
DISPLAY = :0.0
TERM = screen
Breakpoint 1 at 0x80f6316: file emacs.c, line 431.
Breakpoint 2 at 0x810fd23: file sysdep.c, line 1435.
(gdb) run -Q -nw -e 'clone-indirect-buffer-other-window'
Starting program: /usr/local/src/emacs-cvs-trunk/src/emacs -Q -nw -e 'clone-indirect-buffer-other-window'
[Thread debugging using libthread_db enabled]
[New Thread -1220732608 (LWP 7514)]
[Switching to Thread -1220732608 (LWP 7514)]
Program received signal SIGSEGV, Segmentation fault.
0x0816da99 in print_object (obj=1, printcharfun=137537785, escapeflag=1) at print.c:1678
warning: Source file is more recent than executable.
1678		    }
(gdb) bt full
#0  0x0816da99 in print_object (obj=1, printcharfun=137537785, escapeflag=1) at print.c:1678
	end = <value optimized out>
	c = <value optimized out>
	i_byte = <value optimized out>
	confusing = <value optimized out>
	p = <value optimized out>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Topia | 1 Nov 2007 18:29
Picon

23.0.50; utf7-decode failed with non latin-1 charactor

I want to use imap's internationalized (japanese) folder name,
from Wanderlust. but I see error "Unable to convert from Unicode"
from utf7-u16-latin1-char-converter.

You can see with this code:
   ;; "Sent Mail" in Japanese, imap's UTF-7
   (utf7-decode "&kAFP4W4IMH8w4TD8MOs-" 'imap)

so I found problem that utf7-utf-16-coding-system is nil, because:
 * Emacs 23 has utf-16-be, but this coding system has BOM.
 * utf-16-be-nosig is not found.

I found utf-16-be without BOM version, utf-16be. evalute above code
after (setq utf7-utf-16-coding-system 'utf-16be), no error occured.

Could you modify utf7-utf-16-coding-system to add utf-16be?

 (defconst utf7-utf-16-coding-system
   (cond ((mm-coding-system-p 'utf-16-be-no-signature) ; Mule-UCS
 	 'utf-16-be-no-signature)
 	((and (mm-coding-system-p 'utf-16-be) ; Emacs 21.3, Emacs 22
 	      ;; Avoid versions with BOM.
 	      (= 2 (length (encode-coding-string "a" 'utf-16-be))))
 	 'utf-16-be)
+	((and (mm-coding-system-p 'utf-16be) ; Emacs 23?
+	      ;; Avoid versions with BOM.
+	      (= 2 (length (encode-coding-string "a" 'utf-16be))))
+	 'utf-16be)
 	((mm-coding-system-p 'utf-16-be-nosig) ; ?
 	 'utf-16-be-nosig))
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Hanchrow | 1 Nov 2007 21:19
Gravatar

Re: 23.0.50; clone-indirect-object-other-window segfaults

Note that I tried again with a more recent CVS trunk, and the problem
did not recur.
--

-- 
[Dijkstra's] great strength is that he is uncompromising.  It
would make him physically ill to think of programming in C++.
        -- Donald E. Knuth
Permalink | Reply | 0 comments |
headers
Jason Rumney | 2 Nov 2007 13:40
Picon

Re: 23.0.50; utf7-decode failed with non latin-1 charactor

Topia wrote:
> I want to use imap's internationalized (japanese) folder name,
> from Wanderlust. but I see error "Unable to convert from Unicode"
> from utf7-u16-latin1-char-converter.
>
> You can see with this code:
>    ;; "Sent Mail" in Japanese, imap's UTF-7
>    (utf7-decode "&kAFP4W4IMH8w4TD8MOs-" 'imap)
>   
There appear to be two different implementations of utf-7 in Emacs, one
in lisp/international/utf-7.el, and one in lisp/gnus/utf7.el

The former seems to work for decoding, but always returns nil on
encoding without changing the buffer contents (the correctly encoded
text is in a buffer called " *temp*" however).

The latter only seems to work on Latin-1 text (as documented in the
commentary) and returns results from the encoder that are inconsistent
with iconv.

Probably lisp/international/utf-7.el should be fixed, and the Gnus one
dropped.
Permalink | Reply | 0 comments |
headers
AriT93 | 2 Nov 2007 13:45
Picon
Favicon

23.0.50; tramp hangs on connect

With a fresh build from cvs today and the last several days tramp seems to hang
after a connection to a remote machine. Here is output from messages:
n
Tramp: Opening connection for me <at> somehost using plink...
Tramp: Waiting 60s for local shell to come up...
Tramp: Sending command `plink somehost -l me  -ssh && exit || exit'
Tramp: Waiting for prompts from remote shell
Tramp: Found remote shell prompt on `somehost'

I have changed the hostnames obviously.  This same behavior can be reproduced on
my GNU/Linux system at home.  I have tried ssh and scp methods with tramp as
well.  In each case I come seem to get into a loop after the message Tramp:
Found remote shell prompt on `somehost'.  by checking out at 10/22/2007 (cvs
update -D 10/22/2007) tramp works as expected again.  I can see from the logs
that there has been a lot of changes in that time.  Please let me know if there
is any other information or debugging steps that I can take to help.

In GNU Emacs 23.0.50.1 (i386-mingw-nt5.1.2600)
 of 2007-11-02 on SYS286558
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -IC:gnutoolsFree_libsinclude'

Important settings:
  value of $LC_ALL: C
  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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Maurizio Tomasi | 2 Nov 2007 14:57
Picon

Modifier keys not recognized in Emacs 23.0.0NS-9.0rc2 [Ubuntu Linux 7.10 using GNUstep]

I have compiled Emacs.app 23.0.0 (9.0rc2) under GNUstep (Ubuntu Linux 
7.10), and have some problems in getting my modifier keys working 
properly. Both problems do not occur with the emacs version (22.1.1) 
packaged with Ubuntu (compiled with the Gtk libraries, no GNUstep 
support). In this mail, I will refer to GNUstep Email as "Email.app".

1. THE ALT KEY

When I press "Alt+<some key>", Emacs.app does not detect the Alt key 
and inserts the plain key in the buffer (e.g. Alt-X inserts "X"). 
Pressing "C-h c" and then "Alt+<some key>" shows that only <some key> 
has indeed been detected. The Alt key seems not to work at all under 
Emacs. (Note that I configured GNUstep to use my "Windows" key as the 
command key, so there should be no conflict with GNUstep).

Note that I am able to overcome this problem by pressing "ESC <key>".

2. THE ALTGR KEY

My italian keyboard layout produces {} using key combinations with 
Shift+AltGr, e.g. to produce "}" I press Shift+AltGr+*. This is 
Ubuntu's default for italian keyboards, and it is a common setting 
among other Linux distributions as well.

These keys work fine under X and GNUstep applications (such as 
Terminal.app and GNUMail), but under Emacs.app pressing Shift+AltGr+* 
produces a plain "*" instead of "}". It is worth to note that to 
produce "]" I have to press AltGr+*, and this works perfectly even 
under Emacs.app!
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hansen | 3 Nov 2007 00:33
Picon

23.0.50; eshell/cd and multiple dots in directory name


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:

Hello,

to reproduce:

$ emacs -Q

M-x eshell RET
$ cd /tmp
$ mkdir a...b
$ cd a...b
No such directory found via CDPATH environment variable

The error is caused by a call to `eshell-expand-multiple-dots' in
`eshell/cd'.  I'm not quite sure what the use of
`eshell-expand-multiple-dots' is.  A quick grep says it's only used in
`eshell/cd'.  So I suggest the following short patch:
Attachment: text/x-patch, 1010 bytes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Stallman | 3 Nov 2007 04:58
Picon
Picon

Re: 23.0.50; utf7-decode failed with non latin-1 charactor

    There appear to be two different implementations of utf-7 in Emacs, one
    in lisp/international/utf-7.el, and one in lisp/gnus/utf7.el

    The former seems to work for decoding, but always returns nil on
    encoding without changing the buffer contents (the correctly encoded
    text is in a buffer called " *temp*" however).

    The latter only seems to work on Latin-1 text (as documented in the
    commentary) and returns results from the encoder that are inconsistent
    with iconv.

    Probably lisp/international/utf-7.el should be fixed, and the Gnus one
    dropped.

Handa, can you fix international/utf-7.el?
Permalink | Reply | 0 comments |
headers
David Hansen | 3 Nov 2007 06:30
Picon

23.0.50; `read-event' changes `current-buffer'


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:

Hello,

to reproduce:

$ emacs -Q
M-x eshell RET
$ while #'(lambda () t) { echo XXX; sleep 1}
C-x b *scratch* RET

(with-temp-buffer
  (let ((buf (current-buffer)))
    (read-event nil nil 3)
    (format ":%s: :%s:" (buffer-name buf) (current-buffer))))

C-u C-x C-e

": *temp*: :*eshell*:"

David

If Emacs crashed, and you have the Emacs process in the gdb debugger,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Giorgos Keramidas | 2 Nov 2007 22:30
Picon
Favicon
Gravatar

23.0.50; ispell replace word doesn't fully replace a word

  * Start Emacs with `emacs -q -nw'

  * In a clean text-mode buffer type `Suppoert'

  * Type M-$ to spellcheck the word

  * Emacs should suggest `Support' as choice (0)

  * Type `0' to replace the original word with choice (0)

Emacs replaces only up to the place where the point is, leaving the
following text in the buffer:

  Supportuppoert

The same process doesn't have a problem when Emacs runs as a standalone
X11 client.

In GNU Emacs 23.0.50.1 (i386-unknown-freebsd8.0, GTK+ Version 2.10.14)
 of 2007-10-26 on kobe
configured using `configure  '--prefix=/opt/emacs' '--with-x' \
  '--with-x-toolkit=gtk' '--with-xpm' '--with-jpeg' '--with-tiff' \
  '--with-gif' '--with-png''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: el_GR.ISO8859-7
  value of $LC_CTYPE: el_GR.ISO8859-7
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
(Continue reading)

Permalink | Reply | 0 comments |

Gmane