Richard M. Stallman | 1 Oct 2008 01:30
Picon
Picon

bug#1051: 23.0.60; rmail decoding bug

    Richard, please see if the patch below fixes the problem for you as
    well.

Yes, it's fixed now.

Kenichi Handa | 1 Oct 2008 02:29

bug#1051: 23.0.60; rmail decoding bug

In article <uiqsdkfmo.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:

> > It may be good to provide byte-after, following-byte, and
> > preceding-byte (all signal an error if the character is not
> > an ASCII nor eight-bit character).  What do you think?

> I agree that it would be nice to have such a feature, but perhaps a
> single API

>   (get-byte POS)

> would be enough?  This could default to point if POS is nil or
> omitted, and could even read from a string if POS is a string.

Ah!  How about something like this?

(defun get-byte (pos &optional string)
  "Return a byte at position POS of the current buffer..
If POS is nil, it defaults to point.
If the second optional arg STRING is non-nil, return a byte in
STRING at index POS.
An error is signaled if the character at POS is not ASCII
nor eight-bit character."
  ...)

---
Kenichi Handa
handa <at> ni.aist.go.jp

(Continue reading)

Stephen Berman | 1 Oct 2008 12:00
Picon

bug#1062: 23.0.60; minibuffer-completion-help incomplete

GNU Emacs 23.0.60.5 (i686-pc-linux-gnu, GTK+ Version 2.12.9) of
2008-10-01 on escher

1. emacs -Q
2. Let some directory contain the files "tested" and "Testing" and no other
   files beginning with "test" or "Test".
3. M-x set-variable RET read-file-name-completion-ignore-case RET t RET
4. C-x C-f <directory/in/step/2>/test
5. Now type TAB or "?" and a *Completions* buffer pops that shows only
   "tested" as a possible completion.  However, typing "i" next and then
   TAB does complete to "Testing".

If before doing step 4 completion-styles is set to (emacs22), then after
the first TAB or ? in step 5 the *Completions* buffer shows both
"tested" and "Testing".

The following patch makes the *Completions* buffer show all possible
completions in step 5 also with the default completion-style basic, but
I don't know if it has undesirable consequences elsewhere.

Steve Berman

*** emacs/lisp/minibuffer.el.~1.58.~	2008-09-04 16:16:19.000000000 +0200
--- emacs/lisp/minibuffer.el	2008-10-01 11:42:40.000000000 +0200
***************
*** 1316,1322 ****
                     "" (list (substring beforepoint (car bounds))
                              'point
                              (substring afterpoint 0 (cdr bounds)))))
!          (all (completion-pcm--all-completions prefix pattern table pred)))
(Continue reading)

Peter Dyballa | 1 Oct 2008 17:42
Picon
Favicon

bug#1064: 23.0.60; warnings from byte-compilation

Hello!

Here are some messages from yesterday:

In isearch-search-string:
isearch.el:2184:28:Warning: `translation-table-for-input' is an obsolete
     variable (as of Emacs 23.1).
isearch.el:2191:43:Warning: `translation-table-for-input' is an obsolete
     variable (as of Emacs 23.1).

In quoted-insert:
simple.el:685:22:Warning: `translation-table-for-input' is an obsolete
     variable (as of Emacs 23.1).

In zap-to-char:
simple.el:3127:21:Warning: `translation-table-for-input' is an obsolete
     variable (as of Emacs 23.1).
simple.el:3128:28:Warning: `translation-table-for-input' is an obsolete
     variable (as of Emacs 23.1).

In erc-dcc-server:
erc-dcc.el:345:18:Warning: `set-process-filter-multibyte' is an obsolete
     function (as of Emacs 23.1).

In quail-input-string-to-events:
quail.el:1285:29:Warning: `translation-table-for-input' is an obsolete
     variable (as of Emacs 23.1).
quail.el:1286:35:Warning: `translation-table-for-input' is an obsolete
     variable (as of Emacs 23.1).

(Continue reading)

Romain Francoise | 2 Oct 2008 20:13
Favicon
Gravatar

bug#1066: 23.0.60; (tool-bar-mode -1) in ~/.emacs has no effect with --daemon

When Emacs is started with --daemon, (tool-bar-mode -1) has no
effect when used in ~/.emacs.

To reproduce:
1. echo "(tool-bar-mode -1)" >~/.emacs
2. Start Emacs, note that it has no tool bar, exit
3. emacs --daemon
4. emacsclient -c: the frame has a tool bar when it should not

In the created frame, the first call to M-x tool-bar-mode has no
effect.  A second call finally disables the tool bar.

In GNU Emacs 23.0.60.12 (x86_64-unknown-linux-gnu, GTK+ Version 2.12.11)
 of 2008-10-02 on elegiac
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
configured using `configure  'CFLAGS=-O0 -g''

Dan Nicolaescu | 2 Oct 2008 21:47
Picon

bug#1066: 23.0.60; (tool-bar-mode -1) in ~/.emacs has no effect with --daemon

Romain Francoise <romain <at> orebokech.com> writes:

  > When Emacs is started with --daemon, (tool-bar-mode -1) has no
  > effect when used in ~/.emacs.
  > 
  > To reproduce:
  > 1. echo "(tool-bar-mode -1)" >~/.emacs
  > 2. Start Emacs, note that it has no tool bar, exit
  > 3. emacs --daemon
  > 4. emacsclient -c: the frame has a tool bar when it should not
  > 
  > In the created frame, the first call to M-x tool-bar-mode has no
  > effect.  A second call finally disables the tool bar.

Can you please test this patch:

--- faces.el.~1.425.~	2008-09-24 12:55:17.000000000 -0700
+++ faces.el	2008-10-02 12:39:46.000000000 -0700
 <at>  <at>  -2001,7 +2001,6  <at>  <at>  Value is the new frame created."
 	  ;; Make sure the tool-bar is ready to be enabled.  The
 	  ;; `tool-bar-lines' frame parameter will not take effect
 	  ;; without this call.
-	  (tool-bar-setup frame)
 	  (if (null visibility-spec)
 	      (make-frame-visible frame)
 	    (modify-frame-parameters frame (list visibility-spec)))

Eric Hanchrow | 2 Oct 2008 22:54
Gravatar

bug#1067: 23.0.60; vc-dir (git): doesn't update "branch" line


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:

* I started Emacs in a git working tree, whose checked-out branch was
  named "master":

    $ cd /usr/local/src/emacs-via-git/src
    $ git branch
    * master
    $ ./emacs -Q -nw

* I ran vc-dir by typing C-x v d, and noticed that the output was
  correct: in particular, it said "Branch : master"

* I created, and switched to, a new branch, by typing 

    M-! git checkout -b fred RET

* I "refreshed" the *vc-dir* buffer by typing g ("revert-buffer").  I
  noticed that it _still_ said "Branch : master".  This is the bug; I
  expected to see "Branch : fred".

* I killed the *vc-dir* buffer with C-x k RET, then recreated it with
  C-x v d.  This time, I saw "Branch : fred", as I expected.
(Continue reading)

Peter Dyballa | 3 Oct 2008 00:19
Picon
Favicon

bug#1069: 23.0.60; auto-mode-alist

Hello!

Due to a problem with doc-view and auto-mode-alist I sorted this  
variable's contents and found some potential flaws.

	("\\.[Pp][Rr][Oo]\\'" . idlwave-mode)		./lisp/ldefs-boot.el:14721:  
(add-to-list 'auto-mode-alist '("\\.[Pp][Rr][Oo]\\'" . idlwave-mode))
							./lisp/loaddefs.el:14736: (add-to-list 'auto-mode-alist '("\\. 
[Pp][Rr][Oo]\\'" . idlwave-mode))
	("\\.pro\\'" . idlwave-mode)			./lisp/files.el:2069:     ("\\.pro\ 
\'" . idlwave-mode)

The latter line seems superfluous.

	("\\.tgz\\'" . tar-mode)		./lisp/jka-cmpr-hook.el:289:  (list (cons  
"\\.tgz\\'" 'tar-mode) (cons "\\.tbz\\'" 'tar-mode))
	("\\.tbz\\'" . tar-mode)

Is it possible to combine the two lines into one? I also have TAR  
files compressed with bzip2 with the extension .tbz2, Mac OS X  
specific. Could it be added to the list of files for tar-mode?

--
Greetings

   Pete

Atheism is a non prophet organization.

(Continue reading)

Chong Yidong | 3 Oct 2008 01:47
Favicon

bug#1070: Looping in redisplay due to font problem

After the 2008-07-09 change to ftfont.c, Emacs can loop during redisplay
under the following conditions:

xrdb /dev/null
emacs -Q fc-list.list   [fc-list.list is attached]
<PageDown>
<PageDown>
<PageDown>
<PageDown>

Emacs begins looping while in redisplay, while displaying the text
"Corsivo" (the final letter "o" blinks rapidly).

Strangely enough, I can't reproduce this if I substitute C-v for
PageDown (?!??!).  Also, the bug doesn't show up if there is an X
resource Emacs.geometry already defined.

The problem seems to have appeared for the first time during the checkin
listed below.  My tests indicate that the other files involved this
checkin do not affect the problem.

Could you see if you can reproduce this problem, and review the code
changes to see if they may have caused it?  Thanks!

2008-07-09  Kenichi Handa  <handa <at> m17n.org>

	* ftfont.c (struct ftfont_info): New member index, delete member
	fc_charset_idx.  Make the member order compatible with struct
	xftfont_info.
	(fc_charset_table): Change charset names to registry names.
(Continue reading)

Kenichi Handa | 3 Oct 2008 03:24

bug#1071: Looping in redisplay due to font problem

In article <878wt6a7aq.fsf <at> cyd.mit.edu>, Chong Yidong <cyd <at> stupidchicken.com> writes:

> After the 2008-07-09 change to ftfont.c, Emacs can loop during redisplay
> under the following conditions:

> xrdb /dev/null
> emacs -Q fc-list.list   [fc-list.list is attached]
> <PageDown>
> <PageDown>
> <PageDown>
> <PageDown>

> Emacs begins looping while in redisplay, while displaying the text
> "Corsivo" (the final letter "o" blinks rapidly).

> Strangely enough, I can't reproduce this if I substitute C-v for
> PageDown (?!??!).  Also, the bug doesn't show up if there is an X
> resource Emacs.geometry already defined.

> The problem seems to have appeared for the first time during the checkin
> listed below.  My tests indicate that the other files involved this
> checkin do not affect the problem.

> Could you see if you can reproduce this problem, and review the code
> changes to see if they may have caused it?  Thanks!

That's a very strange phenomenon.  But, I can't reproduce
it.  When I hit PageDown four times, the top line is "Luxi
Sans:style=Regular", and "Corsivo" appears on the 9th line
(logically 8th line because of continuation).
(Continue reading)


Gmane