headers
Glenn Morris | 1 Jan 2012 03:37
Picon

bug#10320: 23.3.50; line numbering in fortran-mode

Paul Indelicato wrote:

>> Aquamacs is a distribution of GNU Emacs that is adapted for Mac users.
>> 
>> GNU Emacs 23.3.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
>>  of 2011-08-04 on braeburn.aquamacs.org - Aquamacs Distribution 2.3a
>> Copyright (C) 2011 Free Software Foundation, Inc.
>> 
> while the new one has:
>> Aquamacs is a distribution of GNU Emacs that is adapted for Mac users.
>> 
>> GNU Emacs 23.3.50.1 (i386-apple-darwin9.8.0, NS apple-appkit-949.54)
>>  of 2011-10-25 on braeburn.aquamacs.org - Aquamacs Distribution 2.4
>> Copyright (C) 2011 Free Software Foundation, Inc.

There were almost no changes in the emacs-23 branch between those two
dates, so I don't see how this can be a GNU Emacs issue.

If no-one can reproduce this issue in a stock GNU Emacs started with -Q
on a Mac, I will close this as not a bug in Emacs, but presumably
somewhere in Aquamacs.
Permalink | Reply | 0 comments |
headers
Richard Stallman | 1 Jan 2012 03:59
Picon
Picon

bug#9246: Scrolling bug with word-wrap in emacs -nw

    > There's redisplay-end-trigger-functions, but it's deprecated.  Stefan
    > expressed the desire to have a hook you want many times in the past,
    > but no one stepped forward to do the job yet.

    Actually, I'd like a pre-redisplay-hook, not a post-redisplay-hook.

Hooks in redisplay make me worry, for two reasons:

1. If used in a nontrivial way, they will make it very hard to debug.
It is hard to see what's going on if the principal objects change when
you try to look at them.

2, Why would you want them?  If you put the correct contents in the buffer,
it will display the way you want, right?

We do use redisplay hooks for fontification.  The reason is that
fontifying everything would be too slow.  Fontification doesn't
cause problem #1 because it is stable as long as the buffer's
contents don't change in other ways.

However, I think we should resist adding more redisplay hooks
unless they are very very necessary.  And when we do, we should
try to make them limited.

--

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aidan Kehoe | 1 Jan 2012 15:16
Favicon

bug#10416: 24.0.92; #'test-completion is inconsistent with symbol hash keys in COLLECTION


This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

Hello there,

Recipe to trigger the problem:

 (try-completion "del-alist" #s(hash-table size 145 test equal rehash-size 1.5 rehash-threshold 0.8
data (del-alist hello "delay-mode-hooks" everyone "delete" everyone)))
 => t ;; as expected and documented

 (all-completions "del-alist" #s(hash-table size 145 test equal rehash-size 1.5 rehash-threshold 0.8
data (del-alist hello "delay-mode-hooks" everyone "delete" everyone)))
 => ("del-alist") ;; as expected and documented

 (test-completion "del-alist" #s(hash-table size 145 test equal rehash-size 1.5 rehash-threshold 0.8
data (del-alist hello "delay-mode-hooks" everyone "delete" everyone)))
 =>
Debugger entered--Lisp error: (wrong-type-argument stringp del-alist)
  test-completion("del-alist" #s(hash-table size 145 test equal rehash-size 1.5 rehash-threshold 0.8
(Continue reading)

Permalink | Reply | 4 comments |
headers
Chong Yidong | 1 Jan 2012 16:08
Picon

bug#10417: 24.0.92; Shell completion regression for shell-completion-execonly

Suppose I have a non-executable file named screen.el in the current
directory.  With latest trunk:

emacs -q
M-: (setq shell-completion-execonly nil) RET
M-x shell RET
./scr
TAB

Emacs says "No match" in the minibuffer.  With Emacs 23, the TAB
completes "./scr" to "./screen.el", which is the expected result for
shell-completion-execonly nil.

In GNU Emacs 24.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.2.0)
 of 2011-12-30 on furball
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
configured using `configure  '--with-x-toolkit=gtk3' 'CFLAGS=-g''
Permalink | Reply | 1 comment |
headers
Michael Heerdegen | 1 Jan 2012 20:48
Picon

bug#10419: 23.3; byte-compile-file: Buffer is read-only: #<buffer *Compiler Input*>

Hi,

this is a simple issue, though some explanation is necessary.

Background: I have a large Emacs init file.  Because I often want to
have a look at function definitions in this file, I added a file local
variable binding of `buffer-read-only' to t.  This way, e.g. links
from *Help* always open it read only.  I have to explicitly toggle the
read-only flag if I want to modify the file.  This works well.

Now, imagine the following scenario: I open my init file and toggle
the read-only flag.  I make some changes.  Then, I compile it with M-x
emacs-lisp-byte-compile.  While compilation is in progress, I
recognize that I made an error while editing.  I cancel compilation by
hitting C-g.  I correct my mistake, and try to compile again with
`emacs-lisp-byte-compile'.  Then I get the following error:

    byte-compile-file: Buffer is read-only: #<buffer  *Compiler Input*>

This is the bug.

Here is why that happens.  This is the problematic piece of code in
`byte-compile-file':

    (with-current-buffer
        (setq input-buffer (get-buffer-create " *Compiler Input*"))
      (erase-buffer)
      (setq buffer-file-coding-system nil)
      ;; Always compile an Emacs Lisp file as multibyte
      ;; unless the file itself forces unibyte with -*-coding: raw-text;-*-
(Continue reading)

Permalink | Reply | 1 comment |
headers
Claudio Bley | 1 Jan 2012 21:49
Picon

bug#10420: 24.0.92; eshell diff fails with wrong argument error

Hi.

In eshell, when running the command "diff file.a file.b" I receive this
error:

Wrong type argument: stringp, #<window 46 on *Diff*≥

In GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600) of 2011-12-03

Patch attached.

- Claudio
Attachment (eshell_diff_fix.txt): text/x-diff, 2992 bytes
Permalink | Reply | 1 comment |
headers
Claudio Bley | 1 Jan 2012 21:56
Picon

bug#9087: Crash reading from minibuffer with icomplete-mode

Hi.

I'm using ido-mode and this kind of crash is bugging me almost every
single day when using the ido-find-file (C-x C-f) function.

Here's an /illuminating/ backtrace I've captured with WinDbg the other
day:

Note: most recent calls last

- thread 0

... (some calls omitted)

Ffuncall at C:\src\unix\emacs-trunk\src/eval.c:3023
funcall_lambda at C:\src\unix\emacs-trunk\src/eval.c:3205
exec_byte_code at C:\src\unix\emacs-trunk\src/bytecode.c:785
Ffuncall at C:\src\unix\emacs-trunk\src/eval.c:3023
funcall_lambda at C:\src\unix\emacs-trunk\src/eval.c:3205
exec_byte_code at C:\src\unix\emacs-trunk\src/bytecode.c:785
Ffuncall at C:\src\unix\emacs-trunk\src/eval.c:2977
Fmapc at C:\src\unix\emacs-trunk\src/fns.c:2436
mapcar1 at C:\src\unix\emacs-trunk\src/fns.c:2346
call1 at C:\src\unix\emacs-trunk\src/eval.c:2743
Ffuncall at C:\src\unix\emacs-trunk\src/eval.c:3023
funcall_lambda at C:\src\unix\emacs-trunk\src/eval.c:3205
exec_byte_code at C:\src\unix\emacs-trunk\src/bytecode.c:1837
w32_abort at C:\src\unix\emacs-trunk\src/w32fns.c:7191

- thread 2
(Continue reading)

Permalink | Reply | 41 comments |
headers
Juanma Barranquero | 1 Jan 2012 22:24
Picon
Gravatar

bug#9087: Crash reading from minibuffer with icomplete-mode

> I'm using ido-mode and this kind of crash is bugging me almost every
> single day when using the ido-find-file (C-x C-f) function.

Curious, because I also use ido-mode and I've never had the crash when
invoking ido-find-file, just with the reported recipe.

    Juanma
Permalink | Reply | 0 comments |
headers
Richard Wordingham | 1 Jan 2012 22:42

bug#7781: ispell problem with hunspell and UTF-8 file (and other, related hunspell problems)

Those who want to compile a bug fix in Hunspell for themselves can find
fixes (based on Hunspell 1.2.8 and Emacs V23) to spell check
word-separated Thai in UTF-8 from Emacs at
http://homepage.ntlworld.com/richard.wordingham/thai/hunspell-1.2.8-jrw1.1.zip
- the byte v. character count problem was just one of those met and resolved. The full list is:

On Hunspell:

Bad UTF-8 char count in pipe mode - ID: 3178449
No Encoding of Word for Suggestions in Piped Mode
(https://sourceforge.net/tracker/?func=detail&aid=3468022&group_id=143754&atid=756395)
Multidictionary guesses dictionary for suggestions
(https://sourceforge.net/tracker/?func=detail&aid=3468039&group_id=143754&atid=756395)
Hunspell 1.2.8 Groups Thai TIS-620 Chars in Lower/Upper Case Pairs
(https://bugs.launchpad.net/ubuntu/+source/hunspell/+bug/910452) (fixed
in Release 1.2.14)

On the Thai dictionary:

th_TH Affix File Inadequate for Hunspell
(https://bugs.launchpad.net/ubuntu/+source/openoffice.org-dictionaries/+bug/910447)

There is also a problem with the size of the window holding correction
in Thai (probably depending on the choice of font); the addition of
(fit-window-to-buffer) at the appropriate point in ispell.el (as in the
zip file) fixes that.

Richard.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eli Zaretskii | 1 Jan 2012 22:43
Picon

bug#9087: Crash reading from minibuffer with icomplete-mode

> From: claudio.bley <at> gmail.com (Claudio Bley)
> Date: Sun, 01 Jan 2012 21:56:11 +0100
> 
> I'm using ido-mode and this kind of crash is bugging me almost every
> single day when using the ido-find-file (C-x C-f) function.

Is the recipe just start "emacs -Q", type "M-x ido-mode RET", and then
"C-x C-f SOME-FILE RET"?  If so, it didn't crash for me when I tried
it now.
Permalink | Reply | 39 comments |

Gmane