Re: Carbon: resize event from accessibility API

[David Reitter]

Pedro,
please download the Aquamacs nightly build in about 10 hours, which  
should include the patch, and get back to us regarding whether this  
works. (The build should contain the patch then.)


Thanks
- David

On 21 May 2007, at 13:18, YAMAMOTO Mitsuharu wrote:


Does this change work?




smime.p7s
Description: S/MIME cryptographic signature
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon: resize event from accessibility API

[David Reitter]

Begin forwarded message:

From: Pedro Pinto <[EMAIL PROTECTED]>
Date: 18 May 2007 22:11:38 BDT
To: [EMAIL PROTECTED]
Subject: [Aquamacs-bugs] (no subject)

Enter your bug report here.

Hi there,


Aquamacs seems to react poorly when told to resize one of its windows
through the accessibility API. To reproduce this bug run the
UIElementInspector app (http://developer.apple.com/samplecode/
UIElementInspector/index.html) using it to set change AXSize property
of the Aquamacs window. The window bill resize, but the scrollbars
and general layout will not be redrawn to fit the new size.

-pp


In GNU Emacs 22.0.50.1 (i386-apple-darwin8.6.1)
  of 2006-06-26 on plume.sr.unh.edu - Aquamacs Distribution 0.9.9d
X server distributor `Apple Computers', version 10.4.9
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
   value of $LC_ALL: nil
   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
   value of $LANG: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
   icomplete-mode: t
   display-time-mode: t
   iswitchb-mode: t
   global-auto-revert-mode: t
   smart-frame-positioning-mode: t
   aquamacs-styles-mode: t
   recentf-mode: t
   encoded-kbd-mode: t
   osx-key-mode: t
   mac-inline-input-method-mode: t
   delete-selection-mode: t
   pc-selection-mode: t
   cua-mode: t
   tooltip-mode: t
   tool-bar-mode: 0
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:


Recent messages:
Loading /Users/pedro/emacs-site-lisp/pp-customizations/ruby-pp.el
(source)...done
Loading /Users/pedro/emacs-site-lisp/pp-customizations/scheme-pp.el
(source)...done
Loading ido...done
Loading icomplete...done
Loading /Users/pedro/Library/Preferences/Aquamacs Emacs/
customizations.el (source)...done
Loading /Users/pedro/Library/Preferences/Aquamacs Emacs/frame-
positions.el (source)...done
For an introduction to Aquamacs Emacs, type Apple-?.  Copyright (C)
2006 Free
Software Foundation, Inc., & D. Reitter. No Warranty. You may
redistribute
Aquamacs under the GNU General Public License. Type C-h C-c to view.
Loading emacsbug...done


Pedro Pinto
CTO
Quarksoft, LLC
6580 Via del Oro
San Jose, CA  95119
(408) 334-4719
[EMAIL PROTECTED]
http://www.quarksoftllc.com





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Carbon: Option-as-Meta Sometimes Inputs Accented Characters

[David Reitter]

On 13 May 2007, at 04:49, Tom Tobin wrote:


the keys used in the scrolling *is* a dead-key (i.e., I can insert √
on M-v if I have M-n bound to scroll-up and alternate between the
two).  Your patch is probably the correct solution, as it ultimately
does seem to be a result of the dead-key not being caught.


Yamamoto Mitsuharu: I've now applied your patch, and I can no longer
replicate the buggy behavior.


OK, fine. I presume that patch isn't going to make it into the 22  
branch?


- D

___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon: Option-as-Meta Sometimes Inputs Accented Characters

[David Reitter]

On 12 May 2007, at 05:58, Tom Tobin wrote:


I'm using the Aquamacs nightlies (Intel), and have Option set to act
as Meta (no accented characters).  When I use and hold down a meta-key
combo (say, M-v to scroll the page), Aquamacs will often let the
equivalent accented character slip through (e.g., √ for M-v).  So far,
I've only been able to reproduce this behavior if the command in
question involves scrolling; the quickest way to reproduce it is to
scroll up and down quickly in alternation, holding down each
respective key for a few seconds each time.



Can anyone reproduce this? This is a build from the 22 branch, with  
`mac-option-modifier' set to `meta'.


What I can reproduce is holding down M-n: when input just once, it  
just brings up an echo area message saying that it's not bound. But  
when held down (which causes the input to repeat), it'll input the  
tilde dead key (˜) just like when the option modifier is passed to  
the system.
NB Switching off `mac-input-method-mode' (a patch in Aquamacs)  
doesn't change anything, and the problem shows up in a (Carbon) build  
straight from the GNU Emacs CVS as well. But I can't reproduce the M- 
v problem.




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

longlines-auto-wrap: doc string wrong, or bug?

[David Reitter]

This is in a build from the EMACS_BASE_22 branch:

It appears that `longlines-auto-wrap' as a variable can't be set  
directly - at least to no effect. I have to explicitly do (longlines- 
auto-wrap 0) to turn it off.


Is there a reason why this isn't a minor mode so that M-x longlines- 
auto-wrap would toggle?


I got confused about this because the doc string of `longlines-mode'  
explicitly mentions the variable rather than the function (and the  
doc string of the variable doesn't mention it either): "If the  
variable `longlines-auto-wrap' is non-nil, lines are automatically  
wrapped whenever the buffer is changed." This way, the doc string is  
wrong (or this is a genuine bug).


I only figured this out after looking at longlines.el directly. I  
think that's a bit much to ask from an end user.


I found out about this problem when I did a search-replace for ^J^J -- 
> ^J to get rid of empty lines in between paragraphs. Unfortunately,  
this didn't work. Is there a better way to insert a hard newline? I  
tried to yank the hard newlines directly from the buffer into the  
minibuffer when doing M-x search-replace, but that didn't work and  
produced the same effect with longlines-auto-wrap. Is this possible  
at all?



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Euro sign bound, Pound sign not bound. (Bug?)

[David Reitter]

On 6 May 2007, at 15:18, Stefan Monnier wrote:

Depends.  First and foremost it depends on what are "€" and "£",  
since there

are many different such values, all displayed identically.  Check the
multibyteness of those strings, as well as the result of string-to- 
char:


   (let ((str "€"))
 (list (multibyte-string-p str) (string-to-char str) (key- 
binding str)))


(t 342604 self-insert-command)


   (let ((str "£"))
 (list (multibyte-string-p str) (string-to-char str) (key- 
binding str)))


(t 2211 nil)

Interestingly:

(key-binding [2211] t)  -> self-insert-command
(key-binding [342604] t)  -> self-insert-command
or generically: (key-binding (vector (string-to-char "£")) t)  ->  
self-insert-command

(key-binding "£" t)  -> nil

So, it seems to be a problem with the string specification of the key.

Richard Stallman wrote:


I guess this means there is some other map involved, which key-binding
does not check for.  Maybe key-translation-map?  Maybe a binding for a
generic character?


Neither key is defined in `key-translation-map', and I don't know how  
what defines a "generic character".


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Euro sign bound, Pound sign not bound. (Bug?)

[David Reitter]

The following strikes me as strange:

(key-binding "€") ;; (Euro character) returns 'self-insert-command, but
(key-binding "£") ;; (Pound character) returns nil

Is this a bug?

Similarly, in `isearch', when `overriding-terminal-local-map' is  
defined,


(lookup-key overriding-terminal-local-map "£") ;; returns nil
(lookup-key overriding-terminal-local-map "€")  ;; returns `isearch- 
printing-char' (as expected)


Normal `isearch' works, though.


I am trying to find out what command is bound to a key such as "£" or  
"€" - usually that will be `self-insert-command', but I also need to  
cover cases like in isearch. This is what I'm doing:


(defun emmkm-key-binding (key)
  (or
   (if overriding-terminal-local-map
   (lookup-key overriding-terminal-local-map key)
 (key-binding key))
   ;; not all keys are bound to self-insert-command -- e.g. the  
pound sign.

   'self-insert-command))

... and it can't find the key binding during isearch.

Thanks for your help.


In GNU Emacs 22.0.99.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2007-04-30 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 1.0rc4
Windowing system distributor `Apple Inc.', version 10.4.9
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  TeX-PDF-mode: t
  shell-dirtrack-mode: t
  smart-frame-positioning-mode: t
  aquamacs-styles-mode: t
  recentf-mode: t
  emulate-mac-us-keyboard-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  longlines-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  mac-input-method-mode: t
  tool-bar-mode: 0
  mouse-wheel-mode: t
  use-hard-newlines: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
  
   
   
  " M-@ " 
C-x C-e  C-x C-e  SPC ; ; SPC s e l f - i
n s e r t - c o m m a n d  SPC ; ; SPC n i l 
  ; ; SPC
A-s C-g   
  A-x 
   SPC
A-s   
 A-v
  
 A-f   A-f 
   
 A-w A-f   A-s 
   SPC A-s C-x v v
A-w C-x v =   
   
  
   A-w 
A-s C-x v v A-w C-x v =   
  
   
   A-s  
 A-w C-x v =   A-w
   
   
   
A-c  A-v   
   
  A-c  
  A-v 
   A-c
  A-v  
  
  
  A-c 
   
  A-v   C-x
C-e   A-w C-x C-w C-g C-x C-e
   A-w 
  
   A-c
  A-f  : A-v 
   A-w C-h v i s
e a r  -  m a   
k
  
  
   A-w 
   
 A-c   
 

Recent messages:
Press C-c C-c when you are done editing.
Enter a change comment.  Type C-c C-c when done
Wrote /Users/dr/src/macosx/emulate-mac-keyboard-mode.el
Mark set [4 times]
Entering debugger...
Quit
Entering debugger... [2 times]
Making completion list...
Quit
Loading emacsbug...done


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: python(pdb) & gud: "stop" causes uncaught exception

[David Reitter]

On 26 Apr 2007, at 07:36, Nick Roberts wrote on emacs-devel:

Yes, I've seen this too.  I couold make the "stop" button invisible  
for pdb but
the underlying is with comint-stop-subjob which is on the menubar  
of the GUD

buffer and C-c C-z.


I see you've done that.
We still need a way to interrupt a running python program...

All comint-stop-subjob does is send SIGINT to the process.  When a  
program runs
under GDB, SIGINT is intercepted by GDB and not normally passed on  
to the
program, but pdb doesn't seem to do this. If you run a pythons  
script under pdb
from the command line and type ^C then you should get the same  
result that you

see in Emacs.


There is a project called "pydb" which seems to improve upon PDB:

http://bashdb.sourceforge.net/pydb/

They claim to have "gdb-style signal handling".
It comes with an Emacs mode:

http://wiki.showmedo.com/index.php/PythonBernsteinPydbIntro

Unfortunately, comint-stop-subjob doesn't do much - pydb just prints  
"program received SIGINT", but doesn't interrupt the program.


It seems like it is set up to handle the signal:

(Pydb) handle SIGINT
SignalStop  Print   Stack   PassDescription
SIGINTYes   Yes No  No  Interrupt

... but it doesn't do this. I don't understand why. I'm cc'ing the  
appropriate mailing list - maybe they can shed some light on this.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

python(pdb) & gud: "stop" causes uncaught exception

[David Reitter]

Pressing the "stop" button in gud with pdb running (gud-stop-subjob)  
causes an unhandled python exception (stack trace below).


Emacs then pops up cmd.py on line 151, near "except ImportError",  
which is at the end of the following:


finally:
if self.use_rawinput and self.completekey:
try:
import readline
readline.set_completer(self.old_completer)
except ImportError:
pass

I've got Python 2.4.1 installed, and the `python.el' from the GNU  
Emacs CVS (the one which was just taken out / put back in?) is in use.





/Users/dr/Temp/empty.py(0)?()->None
(Pdb)Traceback (most recent call last):
  File "/usr/local/lib/python2.4/pdb.py", line 1060, in main
pdb._runscript(mainpyfile)
  File "/usr/local/lib/python2.4/pdb.py", line 985, in _runscript
self.run(statement, globals=globals_, locals=locals_)
  File "/usr/local/lib/python2.4/bdb.py", line 366, in run
exec cmd in globals, locals
  File "", line 1, in ?
  File "empty.py", line 0, in ?
  File "/usr/local/lib/python2.4/bdb.py", line 52, in trace_dispatch
return self.dispatch_return(frame, arg)
  File "/usr/local/lib/python2.4/bdb.py", line 85, in dispatch_return
self.user_return(frame, arg)
  File "/usr/local/lib/python2.4/pdb.py", line 141, in user_return
self.interaction(frame, None)
  File "/usr/local/lib/python2.4/pdb.py", line 158, in interaction
self.cmdloop()
  File "/usr/local/lib/python2.4/cmd.py", line 130, in cmdloop
line = raw_input(self.prompt)
KeyboardInterrupt
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> /usr/local/lib/python2.4/cmd.py(151)cmdloop()
-> pass
(Pdb)






In GNU Emacs 22.0.99.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2007-04-24 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 1.0rc4
Windowing system distributor `Apple Inc.', version 10.4.9
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Python

Minor modes in effect:
  smart-frame-positioning-mode: t
  aquamacs-styles-mode: t
  shell-dirtrack-mode: t
  recentf-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  mac-input-method-mode: t
  tool-bar-mode: 0
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:



 
 
 
 
 
 
 
 
 

   
   
   







 
 


 
 
 
 
 
 





 

 p a i r s   


   
   
   
   
   
  
   
   
  
   
   t SPC a n d SPC 
A-s


  

Recent messages:
Command: step [4 times]
Command: next [10 times]
Command: continue
Command: next
Command: down
Command: step
Command: next [4 times]
Command: up
Wrote /Users/dr/PhD/dual-path/tag-besyn-messages.py
Loading emacsbug...done


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: crash in Fgarbage_collect -> mem_find

[David Reitter]

Konrad, please see below - can you help?

Begin forwarded message:


From: [EMAIL PROTECTED] (Kim F. Storm)
Date: 13 April 2007 12:25:48 BDT
To: David Reitter <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Subject: Re: crash in Fgarbage_collect -> mem_find

David Reitter <[EMAIL PROTECTED]> writes:


I can't reproduce this. As you might know, this is a Mac/Carbon CVS
build (April 4) with patches , none of which should affect garbage
collection.
I don't have more information, but maybe the stack trace provided is
helpful enough.


It is only useful in the sense that it tells us that it crashed
during garbage collection (in mem_find).

This also happened to me last week on GNU/Linux -- so it could be
the same bug.  Do you remember what you had been doing for the last
5-10 minutes before the crash?

--
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk





___
emacs-pretest-bug mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

crash in Fgarbage_collect -> mem_find

[David Reitter]

I can't reproduce this. As you might know, this is a Mac/Carbon CVS  
build (April 4) with patches , none of which should affect garbage  
collection.
I don't have more information, but maybe the stack trace provided is  
helpful enough.


Begin forwarded message:


From: Konrad Podczeck <[EMAIL PROTECTED]>
Date: 13 April 2007 10:28:19 BDT
To: [EMAIL PROTECTED], Reitter David  
<[EMAIL PROTECTED]>

Subject: Aquamacs crashed

Hi David,

I had a window splitted in two parts. Mouse-2 clicking on the  
border between the two subwindows gave a crash,

with nigthly build from April 4. Below the crash report.

Cheers

Konrad

Date/Time:  2007-04-13 11:02:17.749 +0200
OS Version: 10.4.9 (Build 8P2137)
Report Version: 4

Command: Aquamacs Emacs
Path:/Applications/TeX/Aquamacs Emacs.app/Contents/MacOS/ 
Aquamacs Emacs

Parent:  WindowServer [60]

Version: Aquamacs 1.0rc2, GNU Emacs 22 (1.2a)

PID:231
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_INVALID_ADDRESS (0x0001) at 0xe30c

Thread 0 Crashed:
0   org.gnu.AquamacsEmacs   0x000cc3f5 mem_find + 47 (alloc.c:3601)
1   org.gnu.AquamacsEmacs   0x000cca4e lisp_free + 44 (alloc.c:893)
2   org.gnu.AquamacsEmacs 	0x000d0246 Fgarbage_collect + 1511  
(alloc.c:2266)
3   org.gnu.AquamacsEmacs 	0x00116fcc Fbyte_code + 7660 (bytecode.c: 
714)
4   org.gnu.AquamacsEmacs 	0x000e5c23 funcall_lambda + 200 (eval.c: 
3189)

5   org.gnu.AquamacsEmacs   0x000e6106 Ffuncall + 452 (eval.c:3054)
6   org.gnu.AquamacsEmacs 	0x00116dfe Fbyte_code + 7198 (bytecode.c: 
679)
7   org.gnu.AquamacsEmacs 	0x000e5c23 funcall_lambda + 200 (eval.c: 
3189)

8   org.gnu.AquamacsEmacs   0x000e6106 Ffuncall + 452 (eval.c:3054)
9   org.gnu.AquamacsEmacs 	0x00116dfe Fbyte_code + 7198 (bytecode.c: 
679)
10  org.gnu.AquamacsEmacs 	0x000e5c23 funcall_lambda + 200 (eval.c: 
3189)

11  org.gnu.AquamacsEmacs   0x000e6106 Ffuncall + 452 (eval.c:3054)
12  org.gnu.AquamacsEmacs 	0x00116dfe Fbyte_code + 7198 (bytecode.c: 
679)
13  org.gnu.AquamacsEmacs 	0x000e5c23 funcall_lambda + 200 (eval.c: 
3189)

14  org.gnu.AquamacsEmacs   0x000e6106 Ffuncall + 452 (eval.c:3054)
15  org.gnu.AquamacsEmacs 	0x000e7636 run_hook_with_args + 167  
(eval.c:2656)

16  org.gnu.AquamacsEmacs   0x000e62ab Ffuncall + 873 (eval.c:2978)
17  org.gnu.AquamacsEmacs 	0x00116dfe Fbyte_code + 7198 (bytecode.c: 
679)

18  org.gnu.AquamacsEmacs   0x000e57ee Feval + 1039 (eval.c:2338)
19  org.gnu.AquamacsEmacs 	0x000e7d7d internal_lisp_condition_case  
+ 432 (eval.c:1426)
20  org.gnu.AquamacsEmacs 	0x00115d34 Fbyte_code + 2900 (bytecode.c: 
869)
21  org.gnu.AquamacsEmacs 	0x000e5c23 funcall_lambda + 200 (eval.c: 
3189)

22  org.gnu.AquamacsEmacs   0x000e6106 Ffuncall + 452 (eval.c:3054)
23  org.gnu.AquamacsEmacs 	0x00116dfe Fbyte_code + 7198 (bytecode.c: 
679)
24  org.gnu.AquamacsEmacs 	0x000e5c23 funcall_lambda + 200 (eval.c: 
3189)

25  org.gnu.AquamacsEmacs   0x000e6106 Ffuncall + 452 (eval.c:3054)
26  org.gnu.AquamacsEmacs 	0x000e4644 internal_condition_case_2 +  
258 (eval.c:1580)

27  org.gnu.AquamacsEmacs   0x000161df safe_call + 145 (xdisp.c:2344)
28  org.gnu.AquamacsEmacs   0x00016216 safe_call1 + 37 (xdisp.c:2362)
29  org.gnu.AquamacsEmacs 	0x00016a0b handle_fontified_prop + 262  
(xdisp.c:3273)

30  org.gnu.AquamacsEmacs   0x00019667 handle_stop + 116 (xdisp.c:3047)
31  org.gnu.AquamacsEmacs 	0x0001c70a next_element_from_buffer +  
309 (xdisp.c:6244)
32  org.gnu.AquamacsEmacs 	0x0001a8e0 get_next_display_element + 38  
(xdisp.c:5501)
33  org.gnu.AquamacsEmacs 	0x00023213 display_line + 381 (xdisp.c: 
15960)

34  org.gnu.AquamacsEmacs   0x00024505 try_window + 164 (xdisp.c:13563)
35  org.gnu.AquamacsEmacs 	0x0002c7dd redisplay_window + 7780  
(xdisp.c:13187)
36  org.gnu.AquamacsEmacs 	0x0002e644 redisplay_window_0 + 44  
(xdisp.c:11784)
37  org.gnu.AquamacsEmacs 	0x000e41e7 internal_condition_case_1 +  
251 (eval.c:1529)
38  org.gnu.AquamacsEmacs 	0x0002212d redisplay_windows + 137  
(xdisp.c:11763)
39  org.gnu.AquamacsEmacs 	0x0003038c redisplay_internal + 3578  
(xdisp.c:11323)
40  org.gnu.AquamacsEmacs 	0x000309e7 redisplay_preserve_echo_area  
+ 110 (xdisp.c:11574)
41  org.gnu.AquamacsEmacs 	0x00082d1a read_char + 1799 (keyboard.c: 
2675)
42  org.gnu.AquamacsEmacs 	0x00084b65 read_key_sequence + 2118  
(keyboard.c:9147)
43  org.gnu.AquamacsEmacs 	0x000863d1 command_loop_1 + 475  
(keyboard.c:1621)
44  org.gnu.AquamacsEmacs 	0x000e4526 internal_condition_case + 245  
(eval.c:1481)
45  org.gnu.AquamacsEmacs 	0x00078b09 command_loop_2 + 68  
(keyboard.c:1333)
46  org.gnu.AquamacsEmacs 	0x000e4417 internal_catch + 171 (eval.c: 
1222)
47  org.gnu.AquamacsEmacs 	0x000788e3 command_loop + 170  
(keyboard.c:1312)
48  org.gnu.AquamacsEmacs 	0x00078997 recursive_edit_1 + 140  
(keyboard.c:1009)
49  org.gnu.AquamacsEmacs 	0x00078a86 Frecursive_edit + 139  
(keyboard.c:1071)

50  org.gnu.AquamacsEmacs   0x00077c6b main + 2311 (emacs.c:1765)
51  org.g

Re: Carbon Emacs won't start when installed in certain paths

[David Reitter]

On 10 Apr 2007, at 03:59, YAMAMOTO Mitsuharu wrote:


I think he is using Carbon Emacs with "self-contained" setting which
puts subdirectories for runtime (lisp, etc, libexec, ...) below the
Emacs.app directory so as to make the application bundle relocatable.


Yes, that's correct.


That requires some changes here and there.  Though I just tried that,
it may not be exhaustive and I'm not sure if it is safe to use
ENCODE_FILE in init_callproc.  Also, this kind of changes may not be
appropriate at this stage.


I tried your patch and unfortunately, it does not fix the startup  
problem.

Error messages are the same.

The good news is that I can start up an Emacs with -Q and -nw (as  
before, complaining about encoded-kb), but then, `load-file' works  
with a file that resides inside the offending path, which it didn't  
before. 
 



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Carbon Emacs won't start when installed in certain paths

[David Reitter]

On 9 Apr 2007, at 20:35, Stefan Monnier wrote:


So try it with -Q.


OK, same story, see below.

This said, I wouldn't be surprised if building (and/or installing)  
doesn't
work correctly in a directory whose complete filename contains  
spaces and/or

non-ascii letters.


Spaces are definitely fine.

Among other things, I seem to remember a problem where some  
hardcoded file
names are created at dump time before the utf-8 coding system  
exists, so
when they get used later on, they may suffer some problems.  Please  
try and
diagnosticate as much as you can, and we'll then add a note about  
it in
PROBLEMS (at least, if that's the problem I'm thinking of, the  
solution is

not immediate).


When started with -nw, loading of "encoded-kb" fails, yet Emacs  
starts up. It is marginally usable - files can be opened (find-file)  
just fine from the path with the non-ASCII characters. However,  
calling "load-file" manually won't work (with one of those paths).
In a successfully started Emacs (-Q), files from the special path can  
be opened (find-file) and sourced (load-file) perfectly, even though  
the *Completions* buffer and the entry in *Messages* will not display  
the right characters. I've tried this with a directory named "Täst",  
which shows up in Emacs as in the attached screenshot.






lucy:/Applications dr$ mv Emacs.app Pour\ De\314\201veloppement/
lucy:/Applications dr$ cd Pour\ De\314\201veloppement/
lucy:/Applications/Pour Développement dr$ ls
Aquamacs Emacs Yesterday.app Emacs.app
lucy:/Applications/Pour Développement dr$ open Emacs.app/
lucy:/Applications/Pour Développement dr$ Emacs.app/Contents/MacOS/ 
Emacs -Q
Warning: arch-dependent data dir (/usr/local/libexec/emacs/22.0.96/ 
powerpc-apple-darwin7.9.0/) does not exist.
Warning: arch-independent data dir (/usr/local/share/emacs/22.0.96/ 
etc/) does not exist.

Cannot open load file: term/mac-win

Start with -nw:

(Emacs.app/Contents/MacOS/Emacs -debug-init)
set-keyboard-coding-system: Cannot open load file: encoded-kb

___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Crash in redisplay_internal -> note_mode_line_or_margin_highlight

[David Reitter]

This crash occurred with a (slightly modified) CVS version  
(2007-04-04), Carbon build.


I was trying out tabbar.el (providing tabbar-mode) using PNG files  
for `tabbar-home-button-enabled-image' and the other tabbar buttons.
I think I clicked on the "mode" (leftmost) button before this  
happened, but I'm not sure.


Unfortunately I cannot reproduce this crash. I can provide the tabbar  
code used if necessary - but it's not a recipe for a crash.


The stack trace is below.




Date/Time:  2007-04-09 08:42:13.677 +0100
OS Version: 10.4.9 (Build 8P135)
Report Version: 4

Command: Aquamacs Emacs
Path:/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs
Parent:  WindowServer [67]

Version: Aquamacs 1.0rc2, GNU Emacs 22 (1.2a)

PID:882
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_INVALID_ADDRESS (0x0001) at 0x027f5fe0

Thread 0 Crashed:
0   org.gnu.AquamacsEmacs	0x000418d8  
note_mode_line_or_margin_highlight + 1364 (xdisp.c:22582)
1   org.gnu.AquamacsEmacs	0x00041c58 note_mouse_highlight + 424  
(xdisp.c:22731)
2   org.gnu.AquamacsEmacs	0x00140860 XTframe_up_to_date + 120  
(macterm.c:2120)
3   org.gnu.AquamacsEmacs	0x0002d490 redisplay_internal + 4000  
(xdisp.c:11372)
4   org.gnu.AquamacsEmacs	0x0002d8c8 redisplay_preserve_echo_area  
+ 100 (xdisp.c:11576)
5   org.gnu.AquamacsEmacs	0x00081fc0 read_char + 1204 (keyboard.c: 
2671)
6   org.gnu.AquamacsEmacs	0x0008b048 read_key_sequence + 1888  
(keyboard.c:9154)
7   org.gnu.AquamacsEmacs	0x0007fb0c command_loop_1 + 1048  
(keyboard.c:1625)
8   org.gnu.AquamacsEmacs	0x000eba1c internal_condition_case +  
336 (eval.c:1482)
9   org.gnu.AquamacsEmacs	0x0007f308 command_loop_2 + 64  
(keyboard.c:1332)
10  org.gnu.AquamacsEmacs	0x000eb3cc internal_catch + 264 (eval.c: 
1222)
11  org.gnu.AquamacsEmacs	0x0007f2a4 command_loop + 216  
(keyboard.c:1300)
12  org.gnu.AquamacsEmacs	0x0007ebf8 recursive_edit_1 + 172  
(keyboard.c:1010)
13  org.gnu.AquamacsEmacs	0x0007ed94 Frecursive_edit + 224  
(keyboard.c:1071)

14  org.gnu.AquamacsEmacs   0x000edec0 Ffuncall + 852 (eval.c:2995)
15  org.gnu.AquamacsEmacs	0x0011ba9c Fbyte_code + 2324  
(bytecode.c:680)

16  org.gnu.AquamacsEmacs   0x000ed110 Feval + 1128 (eval.c:2336)
17  org.gnu.AquamacsEmacs   0x000e9de4 Fprogn + 60 (eval.c:447)
18  org.gnu.AquamacsEmacs	0x000503dc Fsave_window_excursion + 100  
(window.c:6664)
19  org.gnu.AquamacsEmacs	0x0011c3dc Fbyte_code + 4692  
(bytecode.c:841)
20  org.gnu.AquamacsEmacs	0x000ee4d8 funcall_lambda + 632 (eval.c: 
3189)

21  org.gnu.AquamacsEmacs   0x000ee05c Ffuncall + 1264 (eval.c:3054)
22  org.gnu.AquamacsEmacs   0x000ed574 Fapply + 588 (eval.c:2486)
23  org.gnu.AquamacsEmacs   0x000ed9a0 apply1 + 104 (eval.c:2751)
24  org.gnu.AquamacsEmacs	0x000e9b28 call_debugger + 372 (eval.c: 
304)
25  org.gnu.AquamacsEmacs	0x000ec54c find_handler_clause + 468  
(eval.c:1920)

26  org.gnu.AquamacsEmacs   0x000ebf54 Fsignal + 532 (eval.c:1675)
27  org.gnu.AquamacsEmacs   0x000ec094 xsignal + 16 (eval.c:1723)
28  org.gnu.AquamacsEmacs   0x000ec0e8 xsignal2 + 0 (eval.c:1745)
29  org.gnu.AquamacsEmacs   0x000ec730 Fcommandp + 0 (eval.c:2024)
30  org.gnu.AquamacsEmacs   0x000f8a7c Frequire + 732 (fns.c:3602)
31  org.gnu.AquamacsEmacs   0x000ed110 Feval + 1128 (eval.c:2336)
32  org.gnu.AquamacsEmacs   0x000eded4 Ffuncall + 872 (eval.c:2998)
33  org.gnu.AquamacsEmacs	0x0011ba9c Fbyte_code + 2324  
(bytecode.c:680)
34  org.gnu.AquamacsEmacs	0x000ee4d8 funcall_lambda + 632 (eval.c: 
3189)

35  org.gnu.AquamacsEmacs   0x000ee05c Ffuncall + 1264 (eval.c:3054)
36  org.gnu.AquamacsEmacs	0x0011ba9c Fbyte_code + 2324  
(bytecode.c:680)
37  org.gnu.AquamacsEmacs	0x000ee4d8 funcall_lambda + 632 (eval.c: 
3189)

38  org.gnu.AquamacsEmacs   0x000ee05c Ffuncall + 1264 (eval.c:3054)
39  org.gnu.AquamacsEmacs	0x000e9448 Fcall_interactively + 4928  
(callint.c:860)
40  org.gnu.AquamacsEmacs	0x0008ca0c Fcommand_execute + 644  
(keyboard.c:10050)
41  org.gnu.AquamacsEmacs	0x00080838 command_loop_1 + 4420  
(keyboard.c:1894)
42  org.gnu.AquamacsEmacs	0x000eba1c internal_condition_case +  
336 (eval.c:1482)
43  org.gnu.AquamacsEmacs	0x0007f308 command_loop_2 + 64  
(keyboard.c:1332)
44  org.gnu.AquamacsEmacs	0x000eb3cc internal_catch + 264 (eval.c: 
1222)
45  org.gnu.AquamacsEmacs	0x0007f260 command_loop + 148  
(keyboard.c:1315)
46  org.gnu.AquamacsEmacs	0x0007ebf8 recursive_edit_1 + 172  
(keyboard.c:1010)
47  org.gnu.AquamacsEmacs	0x0007ed94 Frecursive_edit + 224  
(keyboard.c:1071)

48  org.gnu.AquamacsEmacs   0x0007d864 main + 3232 (emacs.c:1765)
49  org.gnu.AquamacsEmacs   0xa060 _start + 392 (crt.c:267)
50  dyld0x8fe01048 _dyld_start + 60

Thread 1:
0   libSystem.B.dylib   0x9001fa0c select + 12
1   com.apple.CoreFoundation0x907f1

Carbon Emacs won't start when installed in certain paths

[David Reitter]

Emacs (recent CVS build, Carbon) will not start when installed in  
directories with certain file names.
For example when I install the .app bundle in /Applications/Pour  
Développement, it refuses to run. When started from a terminal, the  
error messages I'm getting are


lucy:/Applications/Pour Développement dr$ Aquamacs\ Emacs\  
Yesterday.app/Contents/MacOS/Aqu*
Warning: arch-dependent data dir (/usr/local/libexec/emacs/22.0.96/ 
powerpc-apple-darwin7.9.0/) does not exist.
Warning: arch-independent data dir (/usr/local/share/emacs/22.0.96/ 
etc/) does not exist.

Cannot open load file: term/mac-win


(Not that the first two warnings are normal.)

This error obviously occurs before loading any user-specific  
settings, so I'm not sending the Emacs debug log.


N.B.: This build is compiled on OS X 10.3.9. I am testing on 10.4.9  
(PPC). The filesystem is the normal Mac filesystem (Mac OS Extended,  
Journaled).


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: x-display-list on the Mac

[David Reitter]

On 24 Mar 2007, at 11:37, YAMAMOTO Mitsuharu wrote:


Sure, that would make it a bit more consistent. However, the -mm-
functions weren't really my concern.


I've heard that preview-latex uses these functions to display images
in real size.


... in which case pixel and millimeter dimensions should refer to the  
same display area indeed.



Yes.  Xinerama also supports such configurations.



As I mentioned earlier, the concept you want
has another name "framebuffer" in the X11 (Xinerama) world, and I
think the right thing is to support them in a consistent way on the
relevant platforms.


Yes, that would be good - perhaps in Emacs 22.2 or 23.

I've been using the attached patch to make `mac-display-available- 
pixel-bounds' available, which will take the Dock and menu bar into  
account when reporting the size of the display. If window managers  
support it, a cross-platform version of this would be useful, too,  
after the release.






available-screen.patch
Description: Binary data


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: x-display-list on the Mac

[David Reitter]

On 24 Mar 2007, at 10:21, YAMAMOTO Mitsuharu wrote:


Right, but if you have one X11 screen on two monitors, it should
return the total width.  This seems to not be the case when
compiling for native OSX.


OK, how about this?  x-display-mm-{width,height} are changed so as to
keep the dpi values of the main display.


Sure, that would make it a bit more consistent. However, the -mm-  
functions weren't really my concern.
Placing frames is a difficult thing if one doesn't know what the  
available screen area is (screen as in total screen, not in the X  
sense).


What complicates matters is that multiple monitors may be arranged so  
that the total desktop area is not rectangular. Just having  
information about total width and height won't be enough. (And I  
presume that is not a Mac only issue.)


Can the notion of "display" (X) approximate each monitor? In a  
situation with two monitors, one could have x-display-list return  
three displays: a main one ("Mac"), and then "1" and "2" or so for  
the other two, separately. Then, x-display-mm/pixel-width/height  
could either return the dimensions of the total area, or of only one  
of the screens.


This does not yet reflect the fact that the small displays  
(representing monitors) can be positioned anywhere on the big screen  
- maybe a function `x-display-origin' could return the coordinates  
for each small display.




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

file-remote-p malfunctions at site-start (file-name-handler-alist init)

[David Reitter]

If a site-start.el file is created with the following contents:

(print file-name-handler-alist)
(print (file-remote-p "/ssh:[EMAIL PROTECTED]:/home/dreitter/test2"))

the output of the last expression is nil for me.
It should (correctly) be non-nil.


The reason for that is that `file-name-handler-alist' does not  
contain handlers for tramp file names when the site-start file is  
loaded - at a later point, the appropriate handlers are added.


The practical relevance is that when users (or site or distribution  
admins) load and turn on recentf-mode from a site-start file together  
with a `file-remote-p' predicate in `recentf-keep', then all recent- 
file entries containing a tramp path will be purged. That's very  
inconvenient.


The problem would go away if `file-name-handler-alist' was correctly  
initialized before site-start files are executed. Additionally,  
please consider defining the handler function for tramp files  
somewhere outside of tramp so that `file-remote-p' doesn't cause  
tramp to load just because it is checked for some file.






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
/Applications/Emacs.app/Contents/Resources/etc/DEBUG for instructions.


In GNU Emacs 22.0.96.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
of 2007-03-22 on rodrigues.inf.ed.ac.uk
Windowing system distributor `Apple Inc.', version 10.4.9
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:

  

Recent messages:

(("\\.Z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.bz2\\(~\\|\\.~[0-9]+~\\)?\\'\\|\ 
\.tbz\\'\\|\\.tgz\\'\\|\\.g?z\\(~\\|\\.~[0-9]+~\\)?\\'\\|\\.dz\\'" .  
jka-compr-handler) ("\\`/:" . file-name-non-special))


nil

For information about the GNU Project and its goals, type C-h C-p. [2  
times]

Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done
Loading encoded-kb...done



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

x-display-list on the Mac

[David Reitter]

(x-display-screens) returns 1, and (x-display-list) returns only  
("Mac"), despite me running two monitors with the desktop spanning  
across them. That's odd - I would expect to see both displays listed.


Also, (x-display-pixel-width) returns 1280, which is the width of the  
display on the left (main screen). How would I find out the total  
desktop area and the screen a particular frame is on? Can I address  
the different displays (or screens?) somehow?


For what it's worth, my X-ordinates range from [0;2560], but in  
situations where the main display is on the right hand side, they are  
[-1280; 1280] (last time I checked).


(I am trying to maximize a frame on the display that it's currently on.)

D



In GNU Emacs 22.0.96.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2007-03-23 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 1.0rc1
Windowing system distributor `Apple Inc.', version 10.4.9
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  smart-frame-positioning-mode: t
  aquamacs-styles-mode: t
  recentf-mode: t
  emulate-mac-german-keyboard-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  mac-input-method-mode: t
  tool-bar-mode: 0
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-x C-f P h D / t h e s  a c t  
 C-h f x - d i s   p  l 
   
   C-x C-e 
C-h f d  x p  - d p 
i s p 
   
   A-c
  A-n A-v ) C-x C-e 
   
  A-c  
   


Recent messages:
For an introduction to Aquamacs Emacs, type Apple-?.  Copyright (C)  
2006 Free
Software Foundation, Inc., & D. Reitter. No Warranty. You may  
redistribute

Aquamacs under the GNU General Public License. Type C-h C-c to view.
Loading vc-cvs...done
Making completion list...
("Mac")
Making completion list...
Mark set
1
Loading emacsbug...done


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: menu events get ignored when multi-line echo area message is displayed

[David Reitter]

On 16 Mar 2007, at 08:17, YAMAMOTO Mitsuharu wrote:


Thanks for minimizing the problematic case.  This is because
show_help_echo called from menu_target_item_handler (in macmenu.c)
indirectly calls redisplay_internal in the above case, and then
set_frame_menubar (in macmenu.c) clears f->menu_bar_items_used.


Nice, that was quick. I tried your patch: it works.

Thanks
- D

smime.p7s
Description: S/MIME cryptographic signature
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: scrolling up via mouse drag doesn't work

[David Reitter]

On 14 Mar 2007, at 11:00, YAMAMOTO Mitsuharu wrote:


When a tool-bar is displayed, scrolling works as intended.


Thanks for the report.  Could you try the patch below?


Thank you, your patch works fine.

Scrolling this way isn't as smooth as it is when you push an arrow  
button -  I wonder if something could be done about this.


D






smime.p7s
Description: S/MIME cryptographic signature
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

menu events get ignored when multi-line echo area message is displayed

[David Reitter]

Start emacs -Q. Evaluate the following two forms with C-x C-e:

(defun display-startup-echo-area-message-2 ()
(message "%s" "one
two"))

(display-startup-echo-area-message-2)


A message should appear in the echo area. Then, select  "Help" ->  
"Copying Conditions" (with the mouse).

Result for me is that the license file is NOT displayed.

Note that it works if the message displayed has only one line.


This is a test case of a more general bug where the first selection  
of any (?) menu item is ignored after a multi-line message has been  
displayed.
It has been reported by several Aquamacs users, but the above code  
reproduces the bug with an unpatched GNU Emacs (Carbon).





In GNU Emacs 22.0.95.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2007-03-14 on rodrigues.inf.ed.ac.uk
Windowing system distributor `Apple Inc.', version 10.4.9
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  smart-frame-positioning-mode: t
  aquamacs-styles-mode: t
  recentf-mode: t
  emulate-mac-german-keyboard-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  mac-input-method-mode: t
  tool-bar-mode: 0
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
no n e : 
"C-x C-e  
 C-x C-e   

  C-x C-e 
   
 t w o  t h r e e   
C-x C-e   
 C-x C-e   
   A-c
   
  
   
  A-'  
  
  
  
  A-s  
   


Recent messages:
one
two
three
"one
two
three"
Auto-saving...done
byte-code: Beginning of buffer [4 times]
Wrote /Users/dr/.emacs
Loading emacsbug...done







___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

scrolling up via mouse drag doesn't work

[David Reitter]

In a buffer with more than one page of text, move point to the end.
Turn off tool-bar-mode if it isn't turned off. Display only one  
window in the frame.


Then click and drag the mouse over the upper boundary of the window  
(and frame). This should cause Emacs to scroll the buffer, analogous  
to what it does when clicking and dragging over the bottom of the  
window.


However, it doesn't scroll.

When a tool-bar is displayed, scrolling works as intended.

I have produced this bug with a new build (CVS from last night,  
Carbon) as well.





In GNU Emacs 22.0.93.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2007-02-14 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.9
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: identity

Recent input:
  M-v C-y  
C-y C-y C-y C-y   
   
   
   
   
   
   
   
  
   
   
 

Recent messages:
(/Applications/Emacs.app/Contents/MacOS/Emacs)
For information about the GNU Project and its goals, type C-h C-p. [2  
times]

Loading encoded-kb...done
call-interactively: Beginning of buffer
Mark set [5 times]
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done


--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and  
support the Aquamacs Project!







___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: double-clicking on closing paren - wrong region marked

[David Reitter]

On 12 Mar 2007, at 04:24, Richard Stallman wrote:


What do you think it should do in such a case,
where scrolling happens validly and correctly
(and you expected it)
while mouse-1 is held down?


If mouse did not move?  A click.

That surprises me.  Does anyone else agree?
Does anyone disagree?


I think it would be a drag, for example in cases where the mouse  
wheel is used to scroll while mouse-1 is held down, or in when the  
mouse is moved to a window boundary and back, causing scrolling.


I cannot think of a case where scrolling would be legitimate and  
expected when there is just a short click with no movement or other  
events in between mouse-1-down and mouse-1-up.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: double-clicking on closing paren - wrong region marked

[David Reitter]

On 7 Mar 2007, at 09:11, Richard Stallman wrote:

Enter the below text into a vanilla buffer. It consists of a  
rather

long expression (3415 characters, I believe), which is all in one
line (rather than nicely formatted). Add a few extra lines to the
expression.

That is not a precise specification.  I tried this, and it worked
fine, but I have no way of telling whether this is because it doesn't
fail for me, or because it depends on how you "add a few extra lines".

"Enter the below text into a vanilla buffer" is not precise either.

Please send a _precise_ bug report.


Well, I'll try again. Copy the expression at the end of this e-mail  
into the clipboard.


/Applications/Emacs.app/Contents/MacOS/Emacs -Q

Press C-y RET RET RET.

Move mouse pointer over last closing paren in the buffer. Double-click.

The result is exactly as in the screenshot attached. What happens  
after the double-click is that the whole visible buffer contents are  
visually marked as region, then the buffer scrolls up one line, and  
then the region is changed to what is shown in the screenshot  
attached. Note that at the end, the mouse pointer is over the  
"." (period) at which the region begins.


Note that the text being copied into the buffer is on one long line;  
if your e-mail client breaks the lines, it might not work.


I afraid can't any more precise than this.










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
/Applications/Emacs.app/Contents/Resources/etc/DEBUG for instructions.


In GNU Emacs 22.0.93.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
of 2007-02-14 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.8
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: identity

Recent input:
C-y 
   


Recent messages:
(Emacs.app/Contents/MacOS/Emacs -Q)
For information about the GNU Project and its goals, type C-h C-p.
Loading encoded-kb...done
Mark set
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done





 '(smart-frame-prior-positions (quote  
(("customizations.el.dr" (left . 5) (top . 87) (width . 80) (height .  
40)) ("customizations.el" (left . 633) (top . 67) (width . 80)  
(height . 40)) ("scroll-bar.el.gz" (left . 25) (top . 67) (width .  
80) (height . 43)) ("aquamacs-frame-setup.el" (left . 633) (top . 47)  
(width . 80) (height . 43)) ("mailme-new.pl" (left . 616) (top . 47)  
(width . 80) (height . 43)) ("mailme.pl" (left . 45) (top . 47))  
("macfns.c" (left . 684) (top . 43) (width . 80) (height . 43))  
("toolbar-png.patch" (left . 5) (top . 64) (width . 80) (height .  
43)) ("available-screen.patch" (left . 529) (top . 44) (width . 80)  
(height . 43)) (".emacs" (left . 632) (top . 28) (width . 80)  
(height . 43)) ("aquamacs.el" (left . 24) (top . 48) (width . 80)  
(height . 43)) (".htaccess" (left . 489) (top . 444))  
("nightlies.shtml" (left . 5) (top . 77) (width . 80) (height . 43))  
("thankyou.html" (left . 5) (top . 77) (width . 80) (height . 43))  
("download.shtml" (left . 616) (top . 67) (width . 80) (height . 43))  
("downloads.cache" (left . 5) (top . 77) (width . 80) (height . 43))  
("support.shtml" (left . 5) (top . 77) (width . 80) (height . 43))  
("features.html" (left . 5) (top . 77) (width . 80) (height . 43))  
("documentation.html" (left . 616) (top . 67) (width . 80) (height .  
43)) ("development.html" (left . 5) (top . 77)) ("latex.html" (left .  
5) (top . 67) (width . 80) (height . 43)) ("index.shtml" (left . 5)  
(top . 67) (width . 80) (height . 43)) ("donations.shtml" (left . 45)  
(top . 47) (width . 80) (height . 43)) ("frame.el.gz" (left . 604)  
(top . 71) (width . 80) (height . 43)) ("simple.el.gz" (left . 87)  
(top . 109)) ("itm_style.css" (left . 237) (top . 46) (width . 99)  
(height . 46)) ("index.en.html" (left . 5) (top . 60) (width . 80)  
(height . 43)) ("templates/index.en.html" (left . 640) (top . 60)  
(width . 77) (height . 43)) ("index.html" (left . 32) (top . 80)  
(width . 80) (height . 43)) ("syn-priming.tex" (left . 5) (top . 59)  
(width . 80) (height . 43)) ("CHANGELOG" (left . 24) (top . 28))  

double-clicking on closing paren - wrong region marked

[David Reitter]

Enter the below text into a vanilla buffer. It consists of a rather  
long expression (3415 characters, I believe), which is all in one  
line (rather than nicely formatted). Add a few extra lines to the  
expression.


Then double-click on the last closing paren ). The wrong region will  
be marked - I get a region from the paren to the end of the buffer,  
or a region from somewhere within the expression to the end. It  
appears to interact with the position of the paren inside the window  
- i.e. whether you scroll up or down a bit does matter. The wrong  
region usually ends at the position where the mouse cursor is _after  
scrolling.


Reproducible in vanilla CVS Emacs 22 (Carbon).

 '(smart-frame-prior-positions (quote  
(("customizations.el.dr" (left . 5) (top . 87) (width . 80) (height .  
40)) ("customizations.el" (left . 633) (top . 67) (width . 80)  
(height . 40)) ("scroll-bar.el.gz" (left . 25) (top . 67) (width .  
80) (height . 43)) ("aquamacs-frame-setup.el" (left . 633) (top . 47)  
(width . 80) (height . 43)) ("mailme-new.pl" (left . 616) (top . 47)  
(width . 80) (height . 43)) ("mailme.pl" (left . 45) (top . 47))  
("macfns.c" (left . 684) (top . 43) (width . 80) (height . 43))  
("toolbar-png.patch" (left . 5) (top . 64) (width . 80) (height .  
43)) ("available-screen.patch" (left . 529) (top . 44) (width . 80)  
(height . 43)) (".emacs" (left . 632) (top . 28) (width . 80)  
(height . 43)) ("aquamacs.el" (left . 24) (top . 48) (width . 80)  
(height . 43)) (".htaccess" (left . 489) (top . 444))  
("nightlies.shtml" (left . 5) (top . 77) (width . 80) (height . 43))  
("thankyou.html" (left . 5) (top . 77) (width . 80) (height . 43))  
("download.shtml" (left . 616) (top . 67) (width . 80) (height . 43))  
("downloads.cache" (left . 5) (top . 77) (width . 80) (height . 43))  
("support.shtml" (left . 5) (top . 77) (width . 80) (height . 43))  
("features.html" (left . 5) (top . 77) (width . 80) (height . 43))  
("documentation.html" (left . 616) (top . 67) (width . 80) (height .  
43)) ("development.html" (left . 5) (top . 77)) ("latex.html" (left .  
5) (top . 67) (width . 80) (height . 43)) ("index.shtml" (left . 5)  
(top . 67) (width . 80) (height . 43)) ("donations.shtml" (left . 45)  
(top . 47) (width . 80) (height . 43)) ("frame.el.gz" (left . 604)  
(top . 71) (width . 80) (height . 43)) ("simple.el.gz" (left . 87)  
(top . 109)) ("itm_style.css" (left . 237) (top . 46) (width . 99)  
(height . 46)) ("index.en.html" (left . 5) (top . 60) (width . 80)  
(height . 43)) ("templates/index.en.html" (left . 640) (top . 60)  
(width . 77) (height . 43)) ("index.html" (left . 32) (top . 80)  
(width . 80) (height . 43)) ("syn-priming.tex" (left . 5) (top . 59)  
(width . 80) (height . 43)) ("CHANGELOG" (left . 24) (top . 28))  
("cua-base.el" (left . 641) (top . 120) (width . 80) (height . 43))  
("pc-select.el.gz" (left . -655) (top . -64) (width . 80) (height .  
43)) ("pager.el" (left . 33) (top . 179) (width . 80) (height . 43))  
("cmds.c" (left . 33) (top . 120) (width . 80) (height . 43)) ("hlt- 
naacl06.tex" (left . 24) (top . 28) (width . 80) (height . 43))  
("custom.el.gz" (left . 5) (top . 67)) ("itm.pl" (left . 5) (top .  
45) (width . 80) (height . 40)) ("stats2.R" (left . 45) (top . 25)  
(width . 158) (height . 39)) ("TODO" (left . 616) (top . 25) (width .  
80) (height . 40)) ("find-repetitions.py" (left . 62) (top . 42)  
(width . 170) (height . 41)) ("parse-maptask.py" (left . 25) (top .  
45) (width . 132) (height . 40)) ("find-repetitions." (left . 633)  
(top . 25) (width . 78) (height . 40)) ("testimonials.txt" (left . 5)  
(top . 67) (width . 80) (height . 40)) ("backup-HD-to-Space" (left .  
616) (top . 47) (width . 80) (height . 40))  
("backup_excludes_users.txt" (left . 616) (top . 47) (width . 80)  
(height . 40)) ("backup_excludes.txt" (left . 209) (top . 56)  
(width . 80) (height . 40)) ("aquamacs-menu.el" (left . 633) (top .  
67) (width . 80) (height . 38)) ("mac-extra-functions.el" (left .  
633) (top . 47) (width . 80) (height . 40)) ("thesis- 
plan.tex" (left . 633) (top . 67) (width . 80) (height . 40))  
("osx_defaults.el" (left . 25) (top . 67) (width . 80) (height .  
40 t)




In GNU Emacs 22.0.94.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2007-03-02 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 1.0rc1
X server distributor `Apple Computers', version 10.4.8
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  smart-frame-positioning-mode: t
  aquamacs-styles-mode: t
  recentf-mode: t
  emulate-mac-german-keyboard-mode: t
  encoded-kbd-mode: t
  osx-key-mode: 

Re: Carbon: scroll bar rendering problem

[David Reitter]

On 3 Mar 2007, at 00:58, YAMAMOTO Mitsuharu wrote:


(Cocoa) Emacs.app seems to do something uncommon to other
platform/toolkit ports with respect to the scroll bar width and the
frame internal border width in order to get rid of the gap between the
rightmost scroll bars and the right edge of the frame.  But that also
introduces some display glitches that are not seen on other platforms
(try C-x 3 or (set-frame-parameter nil 'internal-border-width 10)).


It seems that the gap appears on the left side of the buffer instead,  
which is much nicer. I see a scrolling glitch with C-x 3, but apart  
from that, nothing out of the ordinary (Emacs.app 9.0 pre-3).  There  
is still the vertical gap between the tool-bar and the scroll-bar,  
but that's another story and presumably easy to fix.


Would this be hard to do? (Andy said he was going to take a quick  
look at the code.)





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Doubleclick on words: word boundaries not correctly detected

[David Reitter]

When double-clicking on the substring "TeX" in the word "XɘTeX",   
only "TeX" is marked, even though XɘTeX is clearly a word delimited  
by whitespace.


It appears that the algorithm that recognizes word boundaries does  
not think "ɘ" is a letter.




Enter your bug report here.


In GNU Emacs 22.0.94.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2007-02-28 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 1.0rc1
X server distributor `Apple Computers', version 10.4.8
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  shell-dirtrack-mode: t
  smart-frame-positioning-mode: t
  aquamacs-styles-mode: t
  recentf-mode: t
  emulate-mac-german-keyboard-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  mac-input-method-mode: t
  tool-bar-mode: 0
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
  
  
  
  
  
  
   
  
  
  
   
  
   
  
   
   
   
  
   
   
   

   
t
  A-z A-z  
   
A-c   

Recent messages:
Loading vc...done
Quit
Mark saved where search started
Mark set
Mark saved where search started
Undo...
Undo!
Undo...
Undo!
Loading emacsbug...done




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: pre-command-hook not run for DEL

[David Reitter]

On 26 Feb 2007, at 19:41, Stefan Monnier wrote:


!   (run-hooks 'pre-command-hook)
!   (call-interactively this-command))


Can you say "yuck"?

BTW, please put this out-of-line (i.e. in its own function).  The  
code is

sufficiently messy and unreadable as is.


It appears that the above is a workaround rather than a fix of the  
underlying issue.


Does `delete-region' have to be called from mouse.el?
Would it be possible to activate a keymap (cf. `cua--region-keymap')  
or to call `delete-region'  in `backward-delete-char' (or friends)  
instead of having a special case in `mouse-show-mark'?


Maybe in 22.2, and the workaround as above for 22.1?




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

batch-update-autoloads / update-directory-autoloads problem

[David Reitter]

This may just be a problem with some external package, or with  
`update-directory-autoloads', which uses `source-directory' to  
determine the autoloads file, which it shouldn't do if the function  
is to be used outside of the Emacs build process.


In his case, the directory in source-directory does not exist because  
the binary is not run on the machine that Emacs was compiled on.


Begin forwarded message:


From: Christian Lynbech <[EMAIL PROTECTED]>
Date: 25 February 2007 16:23:04 GMT
To: Development of Aquamacs Emacs <[EMAIL PROTECTED]>
Subject: [Aquamacs-devel] batch-update-autoloads problem
Reply-To: Development of Aquamacs Emacs <[EMAIL PROTECTED]>

I am trying to install a package (LiveJournal emacs client) that calls
upon `batch-update-autoloads' to generate the package specific
autoloads. However, it bails out with the error below.

For the experiment, I have first set this:

(setq generated-autoload-file "ljupdate.el"
  command-line-args-left '("."))

but as witnessed by the error below, it talks about an ljupdate.el
inside of "/Users/dr" which I would guess refers to Davids
userid. There is no abvious setting inside of autoload.el itself
reflecting the problem.

Changing the value of `generated-autoload-file' to an absolute path
circumvented the problem but this is not how the makefile in question
was written, so I think this should be fixed.

Debugger entered--Lisp error: (file-error "Opening output file"  
"no such file or directory" "/Users/dr/Aquamacs/emacs/lisp/ 
ljupdate.el")
  write-region(";;; ljupdate.el --- automatically extracted  
autoloads\n;;\n;;; Code:\n\n\f\n;; Local Variables:\n;; version- 
control: never\n;; no-byte-compile: t\n;; no-update-autoloads: t 
\n;; End:\n;;; ljupdate.el ends here\n" nil "/Users/dr/Aquamacs/ 
emacs/lisp/ljupdate.el")
  autoload-ensure-default-file("/Users/dr/Aquamacs/emacs/lisp/ 
ljupdate.el")
  update-directory-autoloads("/Users/clynbech/Tools/UPSTREAM/ 
ljupdate/")
  apply(update-directory-autoloads "/Users/clynbech/Tools/ 
UPSTREAM/ljupdate/")

  batch-update-autoloads()
  eval((batch-update-autoloads))
  eval-expression((batch-update-autoloads) nil)
  call-interactively(eval-expression)






___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon: scroll bar rendering problem

[David Reitter]

This one is specific to the Carbon port, I believe:

Begin forwarded message:


From: "andy.somogyi" <[EMAIL PROTECTED]>
Date: 25 February 2007 02:39:50 GMT
To: [EMAIL PROTECTED]
Subject: [Aquamacs-bugs] Aquamacs scroll bar rendering problem.

Hello

Aquamacs seems to have a rendering problem with the right scroll bar.
In Aquamacs, the right scroll bar is rendered about 10 - 15 pixels in
from the right edge of the window. In the other Mac Emacs version
such as Emacs.app, the right scroll bar is rendered correctly, flush
with the right edge of the window.


This is very annoying and depends on the font used in the window.
Monaco 12pt is problematic, for example, and so is Lucida Sans  
Typewriter 12pt. The same font in 14pt however almost works - the  
scrollbar is much closer to the right edge of the frame.



Also, the toolbar section of the window is about 2-3 pixels narrower
than the right edge of the window and title bar.


Note that we have (setq tool-bar-border 5), which causes this. It  
would look much better if the scroll-bar extended to the edge of the  
tool-bar, ignoring the border.




In GNU Emacs 22.0.94.1 (i386-apple-darwin8.8.1, Carbon Version 1.6.0)
  of 2007-02-23 on plume.sr.unh.edu - Aquamacs Distribution 1.0rc1
X server distributor `Apple Computers', version 10.4.8
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
   value of $LC_ALL: nil
   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
   value of $LANG: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: LaTeX

Minor modes in effect:
   delete-selection-mode: t
   show-paren-mode: t
   pc-selection-mode: t
   cua-mode: t
   smart-frame-positioning-mode: t
   aquamacs-styles-mode: t
   recentf-mode: t
   encoded-kbd-mode: t
   osx-key-mode: t
   longlines-mode: t
   tooltip-mode: t
   mac-input-method-mode: t
   tool-bar-mode: 0
   mouse-wheel-mode: t
   use-hard-newlines: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
 
 
 
 
 
 
 
 
 
 
 
 
 
 





Recent messages:
Loading /Applications/Aquamacs Emacs.app/Contents/Resources/site-lisp/
edit-modes/auctex/style/pdfsync.elc...done
Loading /Applications/Aquamacs Emacs.app/Contents/Resources/site-lisp/
edit-modes/auctex/style/listings.elc...done
Loading /Applications/Aquamacs Emacs.app/Contents/Resources/site-lisp/
edit-modes/auctex/style/inputenc.elc...done
Loading /Applications/Aquamacs Emacs.app/Contents/Resources/site-lisp/
edit-modes/auctex/style/article.elc...done
Applying style hooks... done
Sorting environment...
Removing duplicates... done
Loading tex-bar...done
Applying style hooks... done
Loading emacsbug...done







___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Copy & Paste in CUA with whole buffer

[David Reitter]

Copying & Pasting of the whole buffer in CUA mode will paste the  
wrong clipboard contents.


- Enter CUA mode
- Select complete buffer
- Copy
- Select complete buffer
- Paste

The result is an old clipboard entry being copied into the buffer,  
but not the text copied when "Copy" was selected.
The desired result in this case should be that the buffer contents  
don't change at all.


The reproduce:

(progn
  (cua-mode 1)
  (call-interactively' mark-whole-buffer) ;; C-x h
  (call-interactively 'clipboard-kill-ring-save) ;; click on copy icon
  (call-interactively 'mark-whole-buffer) ;; C-x h
  (call-interactively 'cua-paste))  ;; click on paste icon



In GNU Emacs 22.0.93.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2007-02-14 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.8
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  cua-mode: t
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-eM-w 
C-h
f( c a l l - i n
t e r a c t i v e k l y   
l y SPC '
C-x C-e   

   
 C-y ' SPC   C-y SPC
'C-y SPC
'   C-x C-e C-_ 
   C-x 0 
   
   


Recent messages:
recursive-edit: The mark is not set now, so there is no region
Type C-x 4 C-o RET to restore the other window.
Mark set [4 times]
Entering debugger...
Mark set [8 times]
nil
Undo!
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

pre-command-hook not run for DEL

[David Reitter]

Don't know if this is a bug - or if I'm making a mistake:

When the mark is active and a region is selected, pressing DEL (e.g.,  
backward-delete-char-untabify) does not cause the functions in `pre- 
command-hook' to be run. I would expect them to be run, since DEL is  
supposed to be bound to an interactive command (see also the  
documentation of `pre-command-hook').


I used this code to find out what's happening:

(setq dbg-log nil)
(defun test ()
  (setq dbg-log (cons this-command dbg-log)))
(add-hook 'pre-command-hook 'test)

After evaluating this, and selecting a region with the mouse, and  
pressing DEL (Backspace, actually), the text in the region is  
deleted. But inspection of `dbg-log' shows that pre-command-hook  
wasn't run.

When there is no region, it works as expected.

When calling M-x delete-backward-char, `pre-command-hook' is not run,  
and the region content isn't deleted either.


I'm not running cua-mode or delete-selection-mode or anything like that.

Am I missing something?


In GNU Emacs 22.0.93.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2007-02-14 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.8
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: identity

Recent input:
C-x C-e C-x C-e 
C-x C-eC-x
C-eC-h v d b
g - l o g
 C-x C-e   
  C-h v   
   c u a - m o d
e C-x C-e
p 
d e l e t e - s e l e c t i o n - m o d e C-x C-e 
   

Recent messages:
test
(test)
nil
Loading help-fns...done
Loading pp...done
Type C-x 1 to remove help window.
nil [3 times]
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done







___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Carbon: Unicode keyboard layouts does not work properly

[David Reitter]

On 19 Feb 2007, at 01:24, YAMAMOTO Mitsuharu wrote:


Actually, I'm not sure why the current code does not work.  But the
Keyboard Layout Services API, which is available on Mac OS X 10.2 and
later, seems to solve the problem.  Could you try the following patch?


Thank you, this did the job for me.

- David







smime.p7s
Description: S/MIME cryptographic signature
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Carbon: Unicode keyboard layouts does not work properly

[David Reitter]

On 19 Feb 2007, at 01:24, YAMAMOTO Mitsuharu wrote:

On Sun, 18 Feb 2007 13:09:42 +, David Reitter  
<[EMAIL PROTECTED]> said:



The symptom I am experiencing is that trying to invoke the emacs
command of `insert-parentheses´ I want to press Meta+Shift+8. When
using the danish latin keyboard layout, I get what I want
(ie. "M-(") but with a unicode keyboard layout, emacs claims I am
pressing "M-*" as it would have been on an american keyboard.


Thanks for the report.  I could reproduce it.

Actually, I'm not sure why the current code does not work.  But the
Keyboard Layout Services API, which is available on Mac OS X 10.2 and
later, seems to solve the problem.  Could you try the following patch?



I've installed the patch in the Aquamacs CVS - Christian, please try  
it out and report back, it should be available in tomorrow's nightly  
build.






___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon: Unicode keyboard layouts does not work properly

[David Reitter]

Bug report from Christian Lynbech  (christian #\@ defun #\. dk),  
pertaining to current Carbon Emacsen:



I have been tracking a really annoying problem relating to keyboard
layouts and the meta key.

There appears to be a problem in relation to unicode keymaps, but only
when they deviate from the american layout. In the following I have
used the standard danish (latin) layout and the extended norwegian
(unicode) layout, both part of the default set of layouts. To the best
of my knowledge, the problem does not as such follow the specific
layouts but only whether its latin or unicode (and different from the
US layout).

In the scandinavian keyboard layouts, the characters on top of the
numerical keys deviates slightly wrt. to the american layout. In
particular, on danish (and norwegian) keyboards, the symbol on top of
'8' is a "(" while on the US keyboard it is a "*".

The symptom I am experiencing is that trying to invoke the emacs
command of `insert-parentheses´ I want to press Meta+Shift+8. When
using the danish latin keyboard layout, I get what I want (ie. "M-(")
but with a unicode keyboard layout, emacs claims I am pressing "M-*"
as it would have been on an american keyboard.

In this test I used latest nightly snapshot of Aquamacs without any
.emacs and thus with Alt as meta key but there is no difference when
using the Command key as Meta.

This problem exists in several OSX-based emacs's including Aquamacs
(both 0.9.9d and snapshot), GNU Emacs 22.0.9x (both from porkrind and
aquamacs.org) and Carbon Emacs (Jan 2007 version) but NOT in EmacsApp
(from http://emacs-app.sourceforge.net/) which is based on Emacs 23,
whether or not that is the relevant difference.

Using Peter Maurers Key Codes application, I get the following
trace. The trace contains four key presses, that of Shift+8 and
that of Shift+Alt+8, first for the danish (latin) layout and then
again for the extended norwegian (unicode) layout, and sure enough the
modifier codes are slightly different depending on whether the latin
or unicode layout was used:


Key Codes 1.0 (c) Peter Maurer 2005

Key Down
Characters: (
Unicode:40 / 0x28
Keys:   ⇧(
Key Code:   28 / 0x1c
Modifiers:  131074 / 0x20002

Key Down
Characters: {
Unicode:123 / 0x7b
Keys:   ⇧⌥(
Key Code:   28 / 0x1c
Modifiers:  655394 / 0xa0022

Key Down
Characters: (
Unicode:40 / 0x28
Keys:   ⇧(
Key Code:   28 / 0x1c
Modifiers:  131330 / 0x20102

Key Down
Characters: {
Unicode:123 / 0x7b
Keys:   ⇧⌥(
Key Code:   28 / 0x1c
Modifiers:  655650 / 0xa0122




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: CUA/delete-selection-mode and remapped keys incompatibility

[David Reitter]

On 9 Feb 2007, at 22:30, Kim F. Storm wrote:


It does not apply to just self-insert-command.  What if you also
created slime-kill-line, slime-yank, slime-next-word, etc.  None of
these would call self-insert-command, but they would still have to be
marked suitably to interact seamlessly with CUA and d-s-m.


I see.


The problem is that if the writer of slime mode is not aware of the
necessity to interact with CUA or delete-selection-mode, documenting
the interface wouldn't really help (until some user complains of stuff
not working with e.g. CUA)...


To make people aware, there should be a section detailing what it  
takes to implement interactive commands that operate on a buffer.  
Maybe this already exists somewhere...


To sum up:

- You require that every externally supplied interactive command  
needs to be encoded to work with CUA and d-s-m, with a sensible  
default set.


- This also means that replacing `self-insert-command' with one's own  
function in some keymap and calling self-insert-command from that  
function will not yield the same result. This is counter-intuitive.


It doesn't seem like we can come up with a technical solution. I  
don't want to keep anyone from working on the release, so I'll shut  
up here. I suggest proper documentation of this class of cases though.


D




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: CUA/delete-selection-mode and remapped keys incompatibility

[David Reitter]

On 9 Feb 2007, at 15:12, Stefan Monnier wrote:


The implementation I'm imagining would be basically as follows:
cua-mode (and delete-selection-mode) add a (global) before-change- 
function
which outputs this warning.  This would be modular and catch all  
cases I can

think of, but maybe it would catch more than we'd want.


Why do you want to bother the end user with such a warning?

As of now, the developer of a package such as SLIME would have a look  
at what a key is bound to. They find `self-insert-command' and then  
construct a function that calls this function with the same argument.  
If they are clever, they might even use "call-interactively".


At that point, they believe that self-insert-command when called from  
their function does exactly the same thing as when called (really)  
interactively. This is a reasonable assumption in a functional  
environment. And in fact, people write such code, as demonstrated. (I  
believe the real issue has to do with `last-command'...)


The immediate solution to this is to document the necessary  
annotation of functions in the right place. Where? Maybe along with  
`self-insert-command' - I don't really know.







___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: CUA/delete-selection-mode and remapped keys incompatibility

[David Reitter]

On 8 Feb 2007, at 20:18, Kim F. Storm wrote:


This is not a bug in cua or delete-selection-mode.

If you define a new command like that, you also have to make it
CUA/delete-selection-mode compatible by tagging it like this:

(put 'slime-space 'delete-selection t)


Thanks Kim.

1. Where is this `delete-selection' attribute documented? I've  
searched the elisp reference, I've checked the docstring of `self- 
insert-command', I've googled it - couldn't find it documented.


2. This appears a bit un-modular, since an externally supplied major  
mode like SLIME has to worry about how CUA and delete-selection-mode  
are implemented. It appears to be the right way to distinguish  
commands that overwrite the selection (in these minor modes) from  
others. But shouldn't calling self-insert-command (as slime-space  
does) already take care of it? Wouldn't a `self-insert-command-hook'  
be better than counting on pre-command-hook, which doesn't get called  
e.g. if self-insert-command is not called interactively?


Something like that would be more compatible with modes that do what  
SLIME does.


D




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

CUA/delete-selection-mode and remapped keys incompatibility

[David Reitter]

I noticed an incompatibility of CUA mode and some minor modes.
If the mode maps a key to a function that self-inserts the key again  
(it commonly does something useful in addition to that), then the CUA  
mode of interaction is not respected in that the text in the current  
region is not replaced, as it should.


Example:

(defun slime-space (n)
  (interactive "p")
  (self-insert-command n))

(global-set-key " " 'slime-space)

(cua-mode 1)


After executing the above, input arbitrary text and mark it as the  
region. Then hit the Space key. This will add insert a space at the  
point rather than replacing the region. Replacing the region would be  
the correct behavior in CUA mode. The same applies to delete- 
selection-mode.



A quick look into `delete-selection-pre-hook' shows that it expects a  
`delete-selection' attribute to be set for the current command, which  
is `slime-space' and not `self-insert-command' when it the hook  
function is called.


Changing the above `slime-space' to use `call-interactively' doesn't  
help - it seems that the pre-command-hook isn't run again in such a  
case.





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
/Applications/Aquamacs Emacs.app/Contents/Resources/etc/DEBUG for  
instructions.



In GNU Emacs 22.0.93.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
of 2007-02-08 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.8
configured using `configure  '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  cua-mode: t
  tooltip-mode: t
  mac-input-method-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
' s l i m e - s p a c e ) C-x C-e
a s d a s d a s d   
 SPC  
   C-x C-e 
   
SPC   
 SPC   
 SPC  
  SPC 
   x
x
  C-x C-e  
  x 
  
   
   
   
   

Recent messages:
(/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs -Q)
Loading encoded-kb...done
Mark set
Cua mode enabled
Mark set
Type C-x 1 to remove help window.
slime-space
Symbol's function definition is void: slime-space
slime-space [2 times]
Loading emacsbug...done



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Manual: indexes are missing links

[David Reitter]

On 19 Dec 2006, at 22:54, Juri Linkov wrote:


 This has nothing to do with the new format, which actually is
fully supported.  Not highlighting index menu is an old feature.
I guess the reason for it was to reduce the time of preparing
usually very large index nodes.


Even the variable index is just around 700 lines long - it might be a  
good idea to rethink the decision from back then. On today's  
machines, making those links clickable shouldn't take very long, and  
certainly not as long as it takes for the user to go a) unterstand  
how the index (doesn't) work, b) go back to the main contents page  
and c) find and select the appropriate chapter.




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Manual: indexes are missing links

[David Reitter]

Shouldn't each index (Option, Command, Concept, etc.) in the manual  
(via info) use links rather than just text?

The right column appears as plain text for me.

(To reproduce: C-h r, click on "Concept Index". I'm using a current  
CVS build on OS X.)





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: mouse click into window doesn't always select frame

[David Reitter]

On 11 Dec 2006, at 08:01, YAMAMOTO Mitsuharu wrote:


It seems like a problem that is specific to the Mac Carbon port.
Please try the following patch.  If there's no problem with this for a
few days, I'll install it.


Your patch works as advertised and I it doesn't seem to cause any  
problems for me.

Thanks for providing this!





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: mouse click into window doesn't always select frame

[David Reitter]

On 11 Dec 2006, at 08:01, YAMAMOTO Mitsuharu wrote:

On Sun, 10 Dec 2006 20:06:23 -0500, Richard Stallman  
<[EMAIL PROTECTED]> said:



Please clearly state exactly what input events are needed to make
the problem happen.


It seems like a problem that is specific to the Mac Carbon port.
Please try the following patch.  If there's no problem with this for a
few days, I'll install it.


Thanks, I'll have a look at this and report back.

D



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

minibuffer -> C-h m

[David Reitter]

C-x C-f to get a minibuffer, then C-h m (or the equivalent from the  
Help menu).


"Lisp nesting exceeds..."

(the first time I did it, the error message wasn't even displayed -  
ist just loaded help-mode and was quiet then.)





In GNU Emacs 22.0.91.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2006-12-04 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.8
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  mac-input-method-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
C-x C-f
   
C-g   C-x C-f  
C-g
  

Recent messages:
(/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs -Q)
Loading encoded-kb...done
Loading help-mode...done
fill-minibuffer-function: Variable binding depth exceeds max-specpdl- 
size

Quit
fill-minibuffer-function: Variable binding depth exceeds max-specpdl- 
size

Quit
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Arabic - moving cursor over text shifts characters

[David Reitter]

When I copy&pasted a bit of arabic script into a current CVS Emacs  
(Carbon port), things seemed fine until I moved the cursor to the  
left over the text - which seemed to change (rearrange) the  
characters displayed. This can be seen in the screenshots attached.  
The second one shows the display after pasting, the third one shows  
what's displayed after moving the cursor over the text.

The first screenshot shows what the original (on a website) looked like.

Characters seem to be shifted to the right.

I don't know what the significance of this is - I don't read arabic.  
I haven't changed the display to right-to-left (and I wouldn't know  
how to do that).













In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0)
 of 2006-10-23 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 0.9.9d
X server distributor `Apple Computers', version 10.4.8
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  delete-selection-mode: t
  show-paren-mode: t
  pc-selection-mode: t
  cua-mode: t
  smart-frame-positioning-mode: t
  aquamacs-styles-mode: t
  recentf-mode: t
  emulate-mac-german-keyboard-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  tooltip-mode: t
  mac-input-method-mode: t
  tool-bar-mode: 0
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
   
   
   
   
   
   
   
   
   
A-a  A-v A-z  A-v 
   
 

 

Recent messages:
byte-code: Beginning of buffer
call-interactively: Buffer is read-only: #
Making completion list...
Buffer is read-only: #
Quit
Mark set [9 times]
Undo...
Undo!
Mark set
Loading emacsbug...done
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Carbon: window close via accessibility API is broken

[David Reitter]

On 6 Sep 2006, at 01:50, YAMAMOTO Mitsuharu wrote:

On Tue, 05 Sep 2006 09:37:15 +0900, YAMAMOTO Mitsuharu  
<[EMAIL PROTECTED]> said:



It can be handled with Carbon events in kEventClassWindow.
kEventWindowClose for the Close button.  kEventWindowGetIdealSize
and kEventWindowBoundsChanged for the Maximize button.  The former
is easy to handle and I'll install a handler.  But the latter is not
so straightforward and it may conflict with the existing code
because kEventWindowBoundsChanged is called in various situations.


Here's a patch for the zoom button (sorry, it was not the Maximize
button).


Yes, this does the job nicely for Maximize.
AXPress on Close and Minimize works, too.

Thanks on behalf of those who need it!

- David





smime.p7s
Description: S/MIME cryptographic signature
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon: window close via accessibility API is broken

[David Reitter]

Emacs (Carbon port) seems to have trouble with Accessibility API events.

- AXPress action on the Closer button of a frame doesn't do anything
- AXPress action on Minimize seems to work
- AXPress action on Maximize produces garbage, with the window width  
being wrong. Subsequent manual redraws or scrolling lead to worse  
garbage. (I can make a screenshot available if needed.)


I'm attaching a user's bug report (below) with regard to AXPress on  
the Closer, which I can reproduce as described by him.


I looked into the reference documents he mentions but I couldn't see  
what events we're waiting for, and why this click on the window  
closer needs to be dealt with separately (does it?).


Thanks
- David


Begin forwarded message:


From: Alexis Gallagher <[EMAIL PROTECTED]>
Date: 4 September 2006 16:23:23 BDT
To: David Reitter <[EMAIL PROTECTED]>
Subject: Re: [Aquamacs-bugs] window close via accessibility API is  
broken


David,

Yes. I mispoke to call them the "Cocoa accessibilty event actions".  
They are not Cocoa-specific. Both Carbon and Cocoa apps can support  
the accessibility api and in theory they both should. In practice,  
much of this support comes automatically in Cocoa. It requires a  
bit of work in Carbon, where it is therefore often neglected.


Here are two relevant pages for understanding how it's supposed to  
work:


This Apple developer document "Getting Started with Accessibility",  
especially the subsection "Developing an application", links out to  
the differences between Cocoa and Carbon support:


http://developer.apple.com/referencelibrary/GettingStarted/ 
GS_Accessibility/


Another relevant page for background is the section "The Mac OS X  
Accessibility Protocol" in the "Accessibility Overview" document:


http://developer.apple.com/documentation/Accessibility/Conceptual/ 
AccessibilityMacOSX/index.html#//apple_ref/doc/uid/TP40001078


Before filing the bug, I pulled the source from cvs and tried to to  
understand where the relevant changes would go. But C is not my  
strong suit, I've never touched a project of that size before, and  
I got lost pretty quickly. Also I had some kind of problem with the  
build script. So I thought it'd wiser just to document the bug as  
accurately as possible. I hope this helps.


cheers,
alexis

On 4 Sep 2006, at 15:39, David Reitter wrote:


Alexis,

is this API supposed to be supported by Carbon applications as well?

Aquamacs isn't Cocoa-based, yet.

- David

On 4 Sep 2006, at 15:19, Alexis Gallagher wrote:


I believe Aquamacs does not correctly support the Cocoa
accessibiltity event actions for closing a window.

I noticed this because I use a program called "Witch", a Preference
Pane which offers enhanced keyboard controls for switching between
applications and menus (http://www.petermaurer.de/nasi.php?
section=witch). This app uses the accessibility API to send apps
instructions to close individual windows. I have encoutered only two
apps don't respond to those commands correctly: Firefox and  
Aquamacs.

This is a known issue in Firefox. It seems worth reporting it for
Aquamacs as well.

You can verify this behavior by using the Accessibility Inspector
tool to artificially generate an AXPress event on the close  
button of

an Aquamacs window.  Here's how.

1) Open two frames in Aquamacs
2) Open the Accessibility Inspector (/Developer/Applications/
Utilities/Accessibility Tools/Accessibility Inspector.app)
3) Place the mouse pointer over an Aquamacs window's close button
4) Type CMD-F7 to lock on that UIElement wih Accessibility Inspector
5) Hit the Perform button, which will generate an AXPress action on
the close button through the accessibility API
6) Notice that the Aquamacs window fails to close, which it  
should do.


Since I don't know if the bug tracking machinery can take
attachments, I am hosting a screenshot which demonstrates the exact
behavior at the following address: http://www.alexisgallagher.com/
aquamacsshot.jpg



In GNU Emacs 22.0.50.1 (i386-apple-darwin8.6.1)
  of 2006-06-27 on plume.sr.unh.edu - Aquamacs Distribution 0.9.9d
X server distributor `Apple Computers', version 10.4.7
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
   value of $LC_ALL: nil
   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
   value of $LANG: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
   iswitchb-mode: t
   shell-dirtrack-mode: t
   smart-frame-positioning-mode: t
   aquamacs-styles-mode: t
   recentf-mode: t
   encoded-kbd-mode: t
   osx-key-mode: t
   mac-inline-input-method-mode: t
   show-paren-mode: t
   delete-selecti

Re: proxy icon and moved files

[David Reitter]

On 22 Aug 2006, at 08:49, YAMAMOTO Mitsuharu wrote:


The proxy icon is set by giving the corresponding alias record to
SetWindowProxyAlias.  But the correspondence between file name and
alias record seems to be not persistent.  Actually, the latter takes
care of renaming.


So if you keep alias records, then you refer to the files by FSRef,  
correct?
Could standard tracking of file changes (e.g. user changes file name  
or moves the file in Finder, Emacs updates its records automatically)  
then be easily implemented?



Could you try the following patch?  It tries to see if the alias
record that is currently set is updated by the current file name.


I tried it and it seems to work - I can't reproduce the problem anymore.
Thanks!




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

proxy icon and moved files

[David Reitter]

Dragging and dropping the Carbon proxy icon to a Finder window  
sometimes saves the backup file (foo.txt~) instead of the actual file.


I could reproduce this with a current build. I tried to locate the  
code that handles these things, but it's not immediately evident why  
a local copy of the file name for the frame is kept in macterm.c  
(file_name) and why it isn't updated correctly (if that is the cause).



Begin forwarded message:


the icon on the top of the frame is a nice and welcomed feature but
sometimes weird behavior occurs. After you modify and save a file, if
you drag & drop the icon you are dragging the backup copy of the file
(the one ending in ~) not the actual file. On my box I can reproduce
the bug systematically as follows:
$ touch foo.txt && open -a "Aquamacs Emacs" foo.txt
(edit and save)
(drag & drop the icon, e.g. copy to Desktop: will copy foo.txt~)






In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
  of 2006-06-27 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution  
0.9.9d

X server distributor `Apple Computers', version 10.4.7
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
   value of $LC_ALL: nil
   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
   value of $LANG: nil
   locale-coding-system: iso-8859-1
   default-enable-multibyte-characters: t

Major mode: PDFLaTeX/F

Minor modes in effect:
   reftex-mode: t
   TeX-fold-mode: t
   shell-dirtrack-mode: t
   TeX-PDF-mode: t
   smart-frame-positioning-mode: t
   aquamacs-styles-mode: t
   recentf-mode: t
   encoded-kbd-mode: t
   osx-key-mode: t
   mac-inline-input-method-mode: t
   show-paren-mode: t
   delete-selection-mode: t
   pc-selection-mode: t
   cua-mode: t
   tooltip-mode: t
   tool-bar-mode: 0
   mouse-wheel-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   unify-8859-on-encoding-mode: t
   utf-translate-cjk-mode: t
   auto-compression-mode: t
   column-number-mode: t
   line-number-mode: t
   transient-mark-mode: t

Recent input:
t e s t 
 C-d  
 C-x C-s   


 SPC  C-x C-s  


   
   
   


   C-x C-f b
i b m o 
 SPC  C-x C-s  SPC
 C-x C-s   

Recent messages:
Sending...done
Saving file /Users/paolo/Documents/Research/Papers/Journals/Molecules-
Bioinformatics/paper.tex...
Wrote /Users/paolo/Documents/Research/Papers/Journals/Molecules-
Bioinformatics/paper.tex
Sending...done
Type `C-c C-l' to display results of compilation.
Sending...done
LaTeX: successfully formatted {7} pages.
Wrote /Users/paolo/Documents/Research/Papers/Journals/Molecules-
Bioinformatics/molecules.bib
Saving file /Users/paolo/Documents/Research/Papers/Journals/Molecules-
Bioinformatics/paper.tex...
Wrote /Users/paolo/Documents/Research/Papers/Journals/Molecules-
Bioinformatics/paper.tex




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

ACL / Listener -> Hang (Carbon port)

[David Reitter]

Emacs hangs (no C-g possible) when "create new listener" from the  
Allegro Common Lisp package is selected - I can't verify /  
investigate further as I don't have Allegro Common Lisp. The package  
seems non-standard, but I don't see how an elisp package can legally  
bring Emacs to a halt (with C-g not working).


The version he is using is a patched GNU Emacs CVS derviate (CVS as  
of 2006-04-10), Carbon port, running on an Intel Mac with OS X.
I don't believe any of the extensions to GNU Emacs present in his  
build can account for the hang this user is seeing.


Please talk to Maria directly to investigate.


Begin forwarded message:

From: "Maria dos Remedios Cravo" <[EMAIL PROTECTED]>
Date: 19 June 2006 09:46:33 BDT
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [Aquamacs-bugs] Bug report

Enter your bug report here.
When the "Create new listener" option in "ACL" menu is used, Aquamacs
does not respond anymore, and has to be forced to quit.

In GNU Emacs 22.0.50.1 (i386-apple-darwin8.6.1)
 of 2006-04-10 on plume.sr.unh.edu - Aquamacs Distribution 0.9.9c
X server distributor `Apple Computers', version 10.4.6
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Inferior Common Lisp

Minor modes in effect:
  display-time-mode: t
  smart-frame-positioning-mode: t
  aquamacs-styles-mode: t
  recentf-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  mac-inline-input-method-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  tool-bar-mode: 0
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
   
  
  
  
  
  
  
   
 

Recent messages:
Software Foundation, Inc., & D. Reitter. No Warranty. You may  
redistribute

Aquamacs under the GNU General Public License. Type C-h C-c to view.
Trying to start connection...done.
View mode: type C-h for help, h for commands, q to quit.
Loading subst-ksc...done
Loading subst-gb2312...done
Loading subst-big5...done
Loading subst-jis...done
Note: file is write protected
Loading emacsbug...done






Begin forwarded message:


From: "Maria dos Remedios Cravo" <[EMAIL PROTECTED]>
Date: 24 June 2006 11:19:37 BDT
To: "David Reitter" <[EMAIL PROTECTED]>
Subject: Re: ACL / Listener -> Hang

David

I'm not using slime or any other interaction package. I'm using
Allegro Common Lisp, from Franz Lisp, and the .emacs file is as
follows:
;; 
;;;

(add-to-list 'load-path "~/acl80_express/eli")

(setq fi:auto-fill t)


(autoload 'fi:common-lisp "fi-site-init" "Emacs/Lisp interface to  
Allegro CL" t)

(autoload 'fi:common-lisp-mode "fi-site-init" "Emacs/Lisp interface to
Allegro CL" t)


(add-hook 'fi:lisp-mode-hook
 ;; define some useful bindings for Lisp evaluation
 '(lambda ()
   (let ((map (current-local-map)))
 (define-key map [linefeed]
   '(lambda ()
  (interactive)
  (fi:lisp-compile-last-sexp)
  (forward-sexp)))
 (define-key map [S-linefeed] 'fi:lisp-eval-or-compile- 
region)

 (define-key map [C-linefeed]
'fi:lisp-eval-or-compile-current-buffer))
   (put 'if 'fi:lisp-indent-hook 1)))

(autoload 'turn-on-acldoc-mode "acldoc" nil t)

;;(add-hook 'fi:lisp-mode-hook
 ;; define some useful bindings for Lisp evaluation
;;  '(lambda ()
;;(turn-on-acldoc-mode)))

(add-hook 'fi:common-lisp-mode-hook
 ;; define some useful bindings for Common Lisp editing
 '(lambda ()
   (setq imenu-create-index-function
 'imenu-example--create-lisp-index)))


(defun nacl ()
 (interactive)
 (setq-default fi:common-lisp-image-name "~/acl80_express/alisp")
 (setq-default fi:common-lisp-image-file "~/acl80_express/alisp.dxl")
 (fi:common-lisp))

(custom-set-variables
'(TeX-print-command "dvips %s"))
(custom-set-faces)


(setq rmail-preserve-inbox t)
;; 
;;;


This makes emacs enter the lisp mode, and make

Re: Comparing 2 (or 3) directories: problems with file selector dialog (Carbon port)

[David Reitter]

On 13 Jun 2006, at 14:36, Juri Linkov wrote:

This is from a user. He selects "Compare directories" by mouse  
(in  the
ediff menu), which causes a file selection dialog to appear in   
the Carbon

port (since the last input was a non-keyboard event).
Unfortunately, it looks like directory selection is not enabled for
this dialog.

I verified this with a recent version.


Is this Mac-specific?  I can't reproduce this on GNU/Linux with GTK.
Dired-compare-directories uses read-directory-name, so perhaps
read-directory-name doesn't work on Mac.


read-directory-name works as intended.
Michael Kifer send a few e-mails and I thought he would deal with it.

This is about ediff-directories, not dired-copmare-directories.
The latter works fine, the former uses `ediff-read-file-name'.

- D



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: vertical-motion fails when tab in line

[David Reitter]

On 11 Jun 2006, at 10:30, Ralf Angeli wrote:


* David Reitter (2006-06-11) writes:


To reproduce, take a scratch buffer, enter a few lines of text wich
will be wrapped and contain one (or more?) tabs. Place cursor near
the end of a wrapped line, but not too far towards the end, and call
M-: (vertical-motion 1).

Tried this in Aquamacs (based on very recent GNU CVS) and as well
with a vanilla CVS build (Carbon port on OS X) with a fixed-width  
font.


Unreproducible with

emacs -Q -eval '(progn (insert "\t" (make-string 50 ?x) "\t" (make- 
string 50 ?x)) (goto-char 85) (vertical-motion 1))'


It won't reproduce with this for me either.

But this one does it:

emacs -Q -eval '(progn (insert "\t" (make-string 50 ?x) " " (make- 
string 50 ?x)) (set-frame-parameter nil (quote width) 60) (goto-char  
54) (vertical-motion 1))'



In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
of 2006-05-06 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.6
configured using `configure '--without-x' '--prefix=/usr/local''




smime.p7s
Description: S/MIME cryptographic signature
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Comparing 2 (or 3) directories: problems with file selector dialog (Carbon port)

[David Reitter]

This is from a user. He selects "Compare directories" by mouse (in  
the ediff menu), which causes a file selection dialog to appear in  
the Carbon port (since the last input was a non-keyboard event).
Unfortunately, it looks like directory selection is not enabled for  
this dialog.


I verified this with a recent version.

Please respond to the OP directly in case of questions.


Begin forwarded message:


From: Olivier Marti <[EMAIL PROTECTED]>
Date: 23 May 2006 16:56:39 BDT
To: [EMAIL PROTECTED]
Subject: [Aquamacs-bugs] Comparing 2 (or 3) directory is impossible.

Enter your bug report here.

I've tried to compare two directories. Aquamacs open the dialog  
window of the Finder to open a file. It is possible to select a  
file, but not a directory ! The workaround is to select a file in  
each directory. Which is not a very elegant method ..


Best regards (and bravo for Aquamacs !!)

Olivier



In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
 of 2006-04-10 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution  
0.9.9c

X server distributor `Apple Computers', version 10.3.9
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Major mode: Change Log

Minor modes in effect:
  smart-frame-positioning-mode: t
  aquamacs-styles-mode: t
  recentf-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  mac-inline-input-method-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  tool-bar-mode: 0
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent input:
   
  
  
  
  
  
  
  
   
  

   
  
  
   
   
 

Recent messages:
Loading add-log...done
Loading lazy-lock...done
Package lazy-lock is obsolete
Loading ediff...done
Quit
Load .emacs
Loading /Users/marti/.emacs...
Restarting server
Loading /Users/marti/.emacs...done
Loading emacsbug...done

--
Olivier Marti  mailto:[EMAIL PROTECTED]
Laboratoire des Sciences du Climat et de l'Environnement
Tel : +33 1 69 08 77 27 - Fax : +33 1 69 08 30 73






___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

vertical-motion fails when tab in line

[David Reitter]

There's a bug in `vertical-motion' which will cause it to move the  
point not to the beginning of the next (visual) line when called with  
argument 1, but just a few characters to the right in the current  
line. This occurs iff there is a Tab in the line, as illustrated by  
the two screenshots attached.


The first screenshot shows the point at the leftmost character in the  
second visual line of a wrapped line. (could be a few characters to  
the right.)





Then we call (vertical-motion 1). The point doesn't move to where it  
should (see screenshot 2).





Another call to (vertical-motion 1) finally moves the cursor to the  
right position.


To reproduce, take a scratch buffer, enter a few lines of text wich  
will be wrapped and contain one (or more?) tabs. Place cursor near  
the end of a wrapped line, but not too far towards the end, and call  
M-: (vertical-motion 1).


Tried this in Aquamacs (based on very recent GNU CVS) and as well  
with a vanilla CVS build (Carbon port on OS X) with a fixed-width font.


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: comint / gdb file name completion with spaces in its path

[David Reitter]

On 26 May 2006, at 00:35, Nick Roberts wrote:


It seems that `comint-dynamic-complete-filename' is used, and that
this function fails to do its job for filenames with spaces in them.

I verified that this is indeed the case with a current CVS Emacs.


You previously reported the same problem with find-file and that was
changed.  Right?


Yes, I produced a patch for this. It's a separate keymap for  
filenames, which doesn't link space to `complete-word'.



I think this case is more difficult because:

Run gdb (like this): gdb --annotate=3 /Applications/System  
Preferences...


also uses spaces that aren't part of the filename.


Would it be possible to ask for parameters and filenames separately?

That's because it's parsed in gud-common-init with split-string,  
not in a

shell.


A shell with completion would automatically quote the filename if  
that is necessary. Maybe this can be done as well when interactively  
prompting for the gdb arguments?
The tokenizer you mention would have to be able to deal with quoted  
arguments.


- D




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

comint / gdb file name completion with spaces in its path

[David Reitter]

This is from a user;
the complaint is that file name completion doesn't work after M-x gdb.

It seems that `comint-dynamic-complete-filename' is used, and that  
this function fails to do its job for filenames with spaces in them.


I verified that this is indeed the case with a current CVS Emacs.

Begin forwarded message:


From: "SourceForge.net" <[EMAIL PROTECTED]>
Date: 24 May 2006 20:59:41 BDT
To: [EMAIL PROTECTED]
Subject: [Aquamacs-bugs] [ aquamacs-Bugs-1494562 ] M-x gdb doesn't  
work to a binary with spaces in its path


Bugs item #1494562, was opened at 2006-05-24 12:59
Message generated for change (Tracker Item Submitted) made by Item  
Submitter

You can respond by visiting:
https://sourceforge.net/tracker/? 
func=detail&atid=740475&aid=1494562&group_id=138078


Please note that this message will contain a full copy of the  
comment thread,

including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: M-x gdb doesn't work to a binary with spaces in its path

Initial Comment:
Start AquaMacs ... then M-x gdb

First, try and use completion to get to the binary /Applications/ 
System

Preferences/Contents/MacOS/System Preferences.  It won't work.  I've
tried various quotings in the minibuffer without luck.  I am able  
to run
gdb by starting without a file option.  In gdb running file ".../ 
path to

binary".


[EMAIL PROTECTED]
 



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Crash in foreach_window_1 (delete-frame)

[David Reitter]

I had this crash the other day. I had a frame with a Completions  
buffer (lower window in 2-window config.) open, and wanted to delete  
the frame.
Can't reproduce, but maybe someone can tell from looking at the stack  
trace below.


This is a Carbon port (CVS 13 May 06) build with a number of patches  
- none of them to delete-frame though. I thought I'd point out what  
line 6818 of window.c is in the build.

Is w->hchild corrupted?

Please ignore if this is not enough information.



foreach_window_1 (w, fn, user_data)
 struct window *w;
 int (* fn) P_ ((struct window *, void *));
 void *user_data;
{
  int cont;

  for (cont = 1; w && cont;)
{
*** line 6818***  if (!NILP (w->hchild))
cont = foreach_window_1 (XWINDOW (w->hchild), fn, user_data);
  else if (!NILP (w->vchild))
cont = foreach_window_1 (XWINDOW (w->vchild), fn, user_data);
  else
cont = fn (w, user_data);

  w = NILP (w->next) ? 0 : XWINDOW (w->next);
}

  return cont;
}





Date/Time:  2006-05-13 16:39:12.453 +0100
OS Version: 10.4.6 (Build 8I127)
Report Version: 4

Command: Aquamacs Emacs
Path:/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs
Parent:  WindowServer [78]

Version: Aquamacs 0.9.9, GNU Emacs 22 (1.2a)

PID:405
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_INVALID_ADDRESS (0x0001) at 0x110bc0d0

Thread 0 Crashed:
0   org.gnu.AquamacsEmacs  	0x0004f5d8 foreach_window_1 + 52  
(window.c:6818)
1   org.gnu.AquamacsEmacs  	0x0004f60c foreach_window_1 + 104  
(window.c:6821)
2   org.gnu.AquamacsEmacs  	0x0004f60c foreach_window_1 + 104  
(window.c:6821)
3   org.gnu.AquamacsEmacs  	0x0004566c  
window_from_coordinates + 120 (window.c:949)
4   org.gnu.AquamacsEmacs  	0x0001e3b0 remember_mouse_glyph +  
60 (xdisp.c:2061)
5   org.gnu.AquamacsEmacs  	0x0013f83c note_mouse_movement +  
332 (macterm.c:4321)
6   org.gnu.AquamacsEmacs  	0x0014780c XTread_socket + 2228  
(macterm.c:10366)
7   org.gnu.AquamacsEmacs  	0x00085dc4 read_avail_input + 140  
(keyboard.c:6751)
8   org.gnu.AquamacsEmacs  	0x00085fbc handle_async_input +  
48 (keyboard.c:6898)

9   org.gnu.AquamacsEmacs   0x000f175c Fdelq + 280 (fns.c:1724)
10  org.gnu.AquamacsEmacs  	0x00015ab0 Fdelete_frame + 884  
(frame.c:1284)
11  org.gnu.AquamacsEmacs  	0x000e9860 Feval + 1072 (eval.c: 
2246)

12  org.gnu.AquamacsEmacs   0x000e65c0 Fif + 72 (eval.c:381)
13  org.gnu.AquamacsEmacs  	0x000e9848 Feval + 1048 (eval.c: 
2243)

14  org.gnu.AquamacsEmacs   0x000e66b8 Fprogn + 60 (eval.c:433)
15  org.gnu.AquamacsEmacs  	0x000eac50 funcall_lambda + 740  
(eval.c:3082)
16  org.gnu.AquamacsEmacs  	0x000ea900 apply_lambda + 252  
(eval.c:3014)
17  org.gnu.AquamacsEmacs  	0x000e9a00 Feval + 1488 (eval.c: 
2300)

18  org.gnu.AquamacsEmacs   0x000e65c0 Fif + 72 (eval.c:381)
19  org.gnu.AquamacsEmacs  	0x000e9848 Feval + 1048 (eval.c: 
2243)
20  org.gnu.AquamacsEmacs  	0x000e819c  
internal_lisp_condition_case + 524 (eval.c:1420)
21  org.gnu.AquamacsEmacs  	0x000e7f7c Fcondition_case + 76  
(eval.c:1360)
22  org.gnu.AquamacsEmacs  	0x000e9848 Feval + 1048 (eval.c: 
2243)

23  org.gnu.AquamacsEmacs   0x000e66b8 Fprogn + 60 (eval.c:433)
24  org.gnu.AquamacsEmacs  	0x000e9848 Feval + 1048 (eval.c: 
2243)

25  org.gnu.AquamacsEmacs   0x000e65c0 Fif + 72 (eval.c:381)
26  org.gnu.AquamacsEmacs  	0x000e9848 Feval + 1048 (eval.c: 
2243)

27  org.gnu.AquamacsEmacs   0x000e66b8 Fprogn + 60 (eval.c:433)
28  org.gnu.AquamacsEmacs   0x000e7844 Flet + 556 (eval.c:1054)
29  org.gnu.AquamacsEmacs  	0x000e9848 Feval + 1048 (eval.c: 
2243)

30  org.gnu.AquamacsEmacs   0x000e66b8 Fprogn + 60 (eval.c:433)
31  org.gnu.AquamacsEmacs  	0x000eac50 funcall_lambda + 740  
(eval.c:3082)
32  org.gnu.AquamacsEmacs  	0x000ea900 apply_lambda + 252  
(eval.c:3014)
33  org.gnu.AquamacsEmacs  	0x000e9a00 Feval + 1488 (eval.c: 
2300)

34  org.gnu.AquamacsEmacs   0x000e65c0 Fif + 72 (eval.c:381)
35  org.gnu.AquamacsEmacs  	0x000e9848 Feval + 1048 (eval.c: 
2243)

36  org.gnu.AquamacsEmacs   0x000e66b8 Fprogn + 60 (eval.c:433)
37  org.gnu.AquamacsEmacs  	0x000eac50 funcall_lambda + 740  
(eval.c:3082)
38  org.gnu.AquamacsEmacs  	0x000ea750 Ffuncall + 1200  
(eval.c:2957)

39  org.gnu.AquamacsEmacs   0x000ea13c call1 + 40 (eval.c:2687)
40  org.gnu.AquamacsEmacs  	0x000f49a8 mapcar1 + 560 (fns.c: 
3143)

41  org.gnu.AquamacsEmacs   0x000f4ca4 Fmapc + 52 (fns.c:3231)
42  org.gnu.AquamacsEmacs  	0x000e9860 Feval + 1072 (eval.c: 
2246)

43  org.gnu.AquamacsEmacs   0x000e66b8 Fprogn + 60 (eval.c:433)
44  org.gnu.AquamacsEmacs  

french keyboard / encoded-kbd-mode

[David Reitter]

There is a problem with reducing keyboard events with certain modifiers.
E.g. in the Carbon port, set mac-option-modifier to 'meta and select  
a french keyboard layout.

Here, the - key (US keyboard) is normally ).

)   ->  )
S-) ->  °   (degree sign - correct)
Opt-)   ->  M-) (correct)
S-Opt-) ->  M-¡   (incorrect, should be M-°)

I had a look at the code, but couldn't immediately make out the culprit.

Yamamoto M. pointed out that...


(encode-coding-string "¡" 'iso-8859-1)
=> "\241"
(encode-coding-string "°" 'mac-roman)
=> "\241"


When encoded-kbd-mode is turned off, Opt-) gives the incorrect ¡.

In a similar context:


The code of ¤(0xA4) corresponds to that of § in mac-roman encoding.
So it seems that back-translation itself does work, but
encoded-kbd-mode does not translate a key input with modifiers.


If I can help debug this in some way, please let me know.




In GNU Emacs 22.0.50.3 (powerpc-apple-darwin8.6.0)
of 2006-05-07 on lucy
X server distributor `Apple Computers', version 10.4.6
configured using `configure '--enable-carbon-app''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  line-number-mode: t



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Carbon / tool-bar: changes in size temporarily

[David Reitter]

Works fine for me. thank you.

- D

On 23 Apr 2006, at 23:31, Kim F. Storm wrote:



I just installed changes in emacs CVS to fix this problem - which
is also seen on X when changing fonts to e.g. Courier 24 and/or  
Courier 18


Fixing that bug revealed another bug which could cause the
toolbar icons to appear twice in the line -- I fixed that too.

Please see if the problem has been fixed for you.


David Reitter <[EMAIL PROTECTED]> writes:


In the Carbon port, when a large font (e.g. Monaco 18) is selected
for a frame, the tool-bar becomes (visually) much higher (I guess 3
lines high). However, when you toggle the visibility of the tool-bar,
for example with the following code

(modify-frame-parameters nil '((tool-bar-lines . 0)))
(modify-frame-parameters nil '((tool-bar-lines . 1)))

the tool-bar shrinks back to a visually much more appealing height -
that is, about 2 lines high.

It would be consistent if the tool-bar resized directly to the lowest
multiple of line height that is larger than the maximal icon height
when the font is changed. That would be 2 lines in this case.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: setting cursor-type in init file doesn't set it in *scratch*

[David Reitter]

On 20 Apr 2006, at 15:26, Kim F. Storm wrote:


David Reitter <[EMAIL PROTECTED]> writes:


Shouldnt setting the cursor-type with a (setq cursor-type '(bar .1))


Try:

(setq cursor-type '(bar . 1))


That was not the problem. - just a missing space in my message.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

setting cursor-type in init file doesn't set it in *scratch*

[David Reitter]

Shouldnt setting the cursor-type with a (setq cursor-type '(bar .1))  
set the cursor-type for *scratch*, because that is the selected  
buffer at the time?


Instead, when I have the above statement in .emacs or a site-init  
file,  `cursor-type' is magically set back to t or whatever is the  
default for the variable.


That means, `set-default' works as expected for the variable; so does  
adding it to initial-frame-alist.


This is a current vanilla Emacs 22 from CVS, Carbon port.




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Send Bug Report is worse

[David Reitter]

On 3 Apr 2006, at 15:29, Jason Rumney wrote:


David Reitter wrote:
Lennart Borgman proposed to do this on Windows systems. That's  
because apparently, long mailto:// URLs aren't supported well.  
Lennart, do you think we can be more specific here and only enable  
it when it's really needed, e.g. on old Windows installations?
I don't think the need for this is limited to old installations.  
Windows has a 1024 byte limit to command-lines in general AFAIK.


OK, the limitation is due to ShellExecute (which is what's obviously  
used on Windows, see `w32-shell-execute').


The mailto:// business in mailclient is a kludge, lacking a cross- 
platform API.


The correct way to send an e-mail on Windows would be the mail API  
("MAPI").
There is already an implementation of this available, even though  
goes through Visual Basic:


http://www.emacswiki.org/cgi-bin/wiki/w32-send-mapi.el

One could take such a piece of code and implement an interface on the  
C side to avoid the VB script. We could integrate that with  
mailclient, and everyone would be happy.




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Send Bug Report is worse

[David Reitter]

On 3 Apr 2006, at 08:48, Reiner Steib wrote:


On Mon, Apr 03 2006, Richard Stallman wrote:


This message:

 "*** E-Mail body has been placed on clipboard, please paste
 them here! ***"

I don't see that message when I use it.  It must be specific to some
aspect of your configuration.  Where does it come from?


The message comes from `mailclient-send-it' which is the default
`send-mail-function' on some platforms:


This method of transferring the body to the mail client is (by  
default) only used on Windows, where the default of `mailclient-place- 
body-on-clipboard-flag' is non-nil.


http://lists.gnu.org/archive/html/emacs-devel/2005-08/msg00660.html

Lennart Borgman proposed to do this on Windows systems. That's  
because apparently, long mailto:// URLs aren't supported well.  
Lennart, do you think we can be more specific here and only enable it  
when it's really needed, e.g. on old Windows installations?


I agree the message needs to be revised syntactically, I'll do that  
when improving the default for `mailclient-place-body-on-clipboard- 
flag'.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

crash in xdisp.c: show_mouse_face

[David Reitter]

A user reported a crash under the circumstances described below.
This is the Carbon port of GNU Emacs from March 28, with some patches  
(none to xdisp.c).
Please see the stack trace below, and ask Phil directly in case there  
are questions - I don't have more information.



Begin forwarded message:


From: Phil <[EMAIL PROTECTED]>
Date: 31 March 2006 20:54:56 BDT
To: David Reitter <[EMAIL PROTECTED]>
Subject: Re: [Aquamacs-bugs] Aquamacs crash report

I'm running Slime under Aquamacs and it had just popped up it's  
debugger reporting a REPL error.   About one to two seconds later,  
Aquamacs crashed.  This is a periodic problem but not easily  
reproducible as I can relaunch Aquamacs and immediately generate  
the error in my REPL session without crashing Aquamacs again.  It's  
entirely possible that Slime is directly related to the problem but  
since Aquamacs crashes, I'm not sure how to determine this.


Whether or not Aquamacs crashes does not appear to be related to a  
specific duration (Aquamacs can be running for minutes or days) or  
usage (what was happening at the time of the crash can be repeated  
after a restart without causing another crash).  I've tried killing  
running Lisp processes to see if this would result in Slime causing  
Aquamacs to crash but it correctly determines that the process is  
gone and life goes on in Aquamacs.  Any suggestions on how I might  
go about capturing additional data that would be helpful in  
narrowing this down?


On Mar 31, 2006, at 4:31 AM, David Reitter wrote:


On 31 Mar 2006, at 10:23, Phil wrote:





OK, can you tell us what you were doing when / just before the  
crash occurred?

Can you reproduce it?





Date/Time:  2006-03-31 04:08:53.678 -0500
OS Version: 10.4.5 (Build 8H14)
Report Version: 4

Command: Aquamacs Emacs
Path:/Users/Shared/Apps/Aquamacs Emacs.app/Contents/MacOS/ 
Aquamacs Emacs

Parent:  WindowServer [12894]

Version: Aquamacs 0.9.9, GNU Emacs 22 (1.2a)

PID:15187
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_PROTECTION_FAILURE (0x0002) at 0x00e8

Thread 0 Crashed:
0   org.gnu.AquamacsEmacs 	0x0003f8a4 show_mouse_face + 472 (xdisp.c: 
21513)
1   org.gnu.AquamacsEmacs 	0x0003f958 clear_mouse_face + 76 (xdisp.c: 
21534)
2   org.gnu.AquamacsEmacs 	0x00040c30 note_mouse_highlight + 228  
(xdisp.c:22330)
3   org.gnu.AquamacsEmacs 	0x0013dc88 XTframe_up_to_date + 120  
(macterm.c:1940)
4   org.gnu.AquamacsEmacs 	0x0002c7cc redisplay_internal + 3944  
(xdisp.c:8)

5   org.gnu.AquamacsEmacs   0x00080a40 read_char + 1132 (keyboard.c:2558)
6   org.gnu.AquamacsEmacs 	0x000896b4 read_key_sequence + 1952  
(keyboard.c:8913)
7   org.gnu.AquamacsEmacs 	0x0007e6ac command_loop_1 + 1084  
(keyboard.c:1547)
8   org.gnu.AquamacsEmacs 	0x000e96cc internal_condition_case + 336  
(eval.c:1474)
9   org.gnu.AquamacsEmacs 	0x0007e00c command_loop_2 + 64 (keyboard.c: 
1335)

10  org.gnu.AquamacsEmacs   0x000e9070 internal_catch + 264 (eval.c:1211)
11  org.gnu.AquamacsEmacs 	0x0007df64 command_loop + 148 (keyboard.c: 
1318)
12  org.gnu.AquamacsEmacs 	0x0007d938 recursive_edit_1 + 172  
(keyboard.c:1008)
13  org.gnu.AquamacsEmacs 	0x0007dae0 Frecursive_edit + 224  
(keyboard.c:1069)

14  org.gnu.AquamacsEmacs   0x0007c598 main + 3232 (emacs.c:1792)
15  org.gnu.AquamacsEmacs   0xa060 _start + 392 (crt.c:267)
16  dyld0x8fe01048 _dyld_start + 60

Thread 0 crashed with PPC Thread State 64:
  srr0: 0x0003f8a4 srr1:  
0x0200d930vrsave: 0x
cr: 0x44042242  xer: 0x0004   lr:  
0x0003f6e4  ctr: 0x0004573c
r0: 0x   r1: 0xbfffde70   r2:  
0x44042248   r3: 0x00374d40
r4: 0x   r5: 0x0138   r6:  
0x023bbe40   r7: 0x0001c320
r8: 0xfff2   r9: 0x0033f6e4  r10:  
0x0233  r11: 0x
   r12: 0x023bbe44  r13: 0x00374ce8  r14:  
0x00375350  r15: 0x003752f4
   r16: 0x0033b870  r17: 0x0001  r18:  
0x0004  r19: 0x
   r20: 0x0033b870  r21: 0x0033b870  r22:  
0x023bd634  r23: 0x023bbe40
   r24: 0x00340b54  r25: 0x  r26:  
0x  r27: 0x023bbe40
   r28: 0x03027260  r29: 0x0033f91c  r30:  
0x00374d40  r31: 0x0003f6e4


Binary Images Description:
0x1000 -   0x17efff org.gnu.AquamacsEmacs Aquamacs 0.9.9, GNU  
Emacs 22 (1.2a)	/Users/Shared/Apps/Aquamacs Emacs.app/Contents/MacOS/ 
Aquamacs Emacs

  0x66f000 -   0x69afff libncurses.5.dylib  /usr/lib/libncurses.5.dylib
0x8fa79000 - 0x8fd27fff com.apple.QuickTime 7.0.4	/System/Library/ 
Frameworks/QuickTime.framework/Versions/A/QuickTime

0x8fe0 - 0x8fe54fff dyld 44.2  

Re: Carbon: mac-pass-command-to-system disfunctional

[David Reitter]

On 31 Mar 2006, at 09:29, YAMAMOTO Mitsuharu wrote:



(setq mac-pass-command-to-system nil)
Press Command-h.



You should get a "A-h is undefined" message (or similar).


I tried the testcase with the Carbon port, but I got this error
provided I've set `mac-command-modifier' to `alt'.


Turns out, this was most likely due to a version of mac-inline-patch  
which hadn't been adapted yet to the December change for  
Vmac_pass_command_to_system. Sorry about that, and thanks for testing.




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon / tool-bar: changes in size temporarily

[David Reitter]

In the Carbon port, when a large font (e.g. Monaco 18) is selected  
for a frame, the tool-bar becomes (visually) much higher (I guess 3  
lines high). However, when you toggle the visibility of the tool-bar,  
for example with the following code


(modify-frame-parameters nil '((tool-bar-lines . 0)))
(modify-frame-parameters nil '((tool-bar-lines . 1)))

the tool-bar shrinks back to a visually much more appealing height -  
that is, about 2 lines high.


It would be consistent if the tool-bar resized directly to the lowest  
multiple of line height that is larger than the maximal icon height  
when the font is changed. That would be 2 lines in this case.



Begin forwarded message:


From: Konrad Podczeck <[EMAIL PROTECTED]>
Date: 29 March 2006 21:01:02 BDT
To: David Reitter <[EMAIL PROTECTED]>, aquamacs- 
[EMAIL PROTECTED]

Subject: Three bugs with 0.9.9


(2) There is some strange behaviour of the toolbar now. Example: I  
start Aquamacs and open a texfile, initially displayed in Monaco  
14. I change the font to TimesNewRoman 18, and as a byproduct the  
height of the toolbar drastically increases. I  invoke the button  
for toggling the appearance of the toolbar twice, and now the  
height of the toolbar is smaller, and in fact smaller then it was  
initially when I opened the file in Monaco 14. I didn't observe  
such behaviour in earlier versions of Aquamacs.
 



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon: mac-pass-command-to-system disfunctional

[David Reitter]

Seems like mac-pass-command-to-system is broken.

Testcase:

(setq mac-pass-command-to-system nil)
Press Command-h.

You should get a "A-h is undefined" message (or similar).

This works in a version compiled around 20-Dec-2005, but not in a  
recent version, where Command-H is still passed to the system and  
hides the application.


Is there a chance the following change has to do with it?

revision 1.147
date: 2005-12-19 08:30:56 +;  author: mituharu;  state: Exp;   
lines: +71 -60

...
(mac_pass_command_to_system, mac_pass_control_to_system): New
boolean variables renamed from Lisp_Object ones




Begin forwarded message:


From: Konrad Podczeck <[EMAIL PROTECTED]>
Date: 31 March 2006 00:09:50 BDT
To: David Reitter <[EMAIL PROTECTED]>, aquamacs- 
[EMAIL PROTECTED]

Subject: Another 0.9.9 bug

I just detected (actually with 0.9.9a) that turning off "Mac Pass  
Command To System" in the Aquamacs customization buffer does not  
give the intended effect anymore. Fatal for some of my personal key- 
bindings.
 



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon port: Russian language selected

[David Reitter]

Does anyone know what this could be?
I can't reproduce it myself, but a user reported an immediate exit  
upon startup with an output (presumably to stdout) "Invalid coding  
system: mac-cyrillic".


System Preferences->International->Language has "Russian" (in  
cyrillic) on top, i.e. as preferred language.


This is a recent CVS build of the Carbon port (without X) as usual  
(albeit in the Aquamacs distribution, with all extra packages etc.  
disabled).


Thanks
David


Begin forwarded message:


From: Vladimir Lech <[EMAIL PROTECTED]>
Date: 16 March 2006 21:31:39 GMT
To: David Reitter <[EMAIL PROTECTED]>
Subject: Re: Aquamacs crushed

Hi David,
Thanks for your letter.

On 16 mars 06, at 23:02, David Reitter wrote:


Hi Vlad,

On 16 Mar 2006, at 20:43, Vladimir Lech wrote:


Hello,

I like Aquamacs but I cannot use if I set up language to Russian  
in System Preferences.
It crashes with "Invalid coding system: mac-cyrillic" message in  
console.log.


Thanks for your help.
Vlad



- what exactly do set to Russian in the System Preferences? Input  
Language? Application Languages?


Mac OS X 10.4.5
System Preferences->International->Language->Russian at the upper  
position.

It works well with French Language as well.


- can you try this with the latest build, available from

xxx


Yes, I've just tried with the same result.



I think we haven't had many Russian users so far, but it's the  
first time I hear about this bug.


I use emacs for many years.

Thanks :-)






___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

select-window (C-c M-j) doesn't give input focus to target (*R*) [Carbon GNU Emacs]

[David Reitter]

I understand that, in ESS-mode, C-c M-j (and friends) are supposed to  
select the *R* window and the buffer shown therein, so the input  
focus is in that window in the end.
ESS selects the appropriate frame (`select-frame') and window  
(`select-window') to do so in the function `ess-show-buffer'.


In current CVS versions of GNU Emacs (head, Carbon port) and ESS  
5.2.8, this doesn't work. The *R* window is selected by `ess-show- 
buffer' (as I have verified, both visually and by evaluating  
(selected-window)), but the input focus (cursor is solid block, not  
frame) remains on the original window. As soon as keyboard input is  
made, the source window gets selected again (visibly).


To reproduce:
Arrange two frames: one showing just a buffer in R-mode, the other  
one showing the *R* process buffer. Enter some R code into the first  
buffer. Try to evaluate a line from within the first buffer by typing  
C-c M-j. This reliably produces the bug.


Additional info:
There has been a change to the behavior of display-buffer (doesn't  
select target frame any more) a few weeks ago, which should have  
brought the display-buffer in line with its documentation.


I'm not sure if this is a problem with ESS or with (Carbon) Emacs -  
please excuse the cross-posting.






In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
of 2006-03-14 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.5
configured using `configure '--without-x' '--prefix=/usr/local''


Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: ESS[S]

Minor modes in effect:
  encoded-kbd-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  line-number-mode: t

Recent input:
r e  p o
r e
   r e p o r t - e
s s 

  e s s - b u   

  r e   
 C-h v e s s - v  s   
   
  
  
   
x r e p o r t - e m  

Recent messages:
Finished evaluation
Loading line: x ...
Starting evaluation...
Finished evaluation
Making completion list... [3 times]
Quit
Loading pp...done
Type C-x 1 to remove help window.
mwheel-scroll: End of buffer [2 times]
Loading emacsbug...done



smime.p7s
Description: S/MIME cryptographic signature
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Slider draw bug in Carbon port

[David Reitter]

The bug that causes the slider to be drawn in a wrong position is  
still present. I've reported this earlier. It's hard to say when  
exactly it occurs, but I see it fairly often.

It usually goes away after a redraw.





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon crashes in mac_handle_mouse_event

[David Reitter]

A user reported crashes, consistently in mac_handle_mouse_event.

Begin forwarded message:

From: Jose Figueroa-O'Farrill <[EMAIL PROTECTED]>
Date: 5 March 2006 18:23:25 GMT
To: David Reitter <[EMAIL PROTECTED]>
Subject: Crash reporter log
Reply-To: [EMAIL PROTECTED]


Hi David,

José> There were a couple of Aquamacs crashes recently and I suppose
José> that the damage was done during one of these crashes -- even
José> though I "M-x recover-session" whenever this happens.

José> The reason for the crashes, by the way, is always the same.  I
José> leave the powerbook unattended for a while (minutes), the
José> trackpad seems to freeze, and when I touch it again, if the
José> focus is on an Aquamacs frame, it will crash.

David> Regarding those crashes you mention - that's rather important.  
Can
David> you send a crash reporter log? Without such a log, I can't do  
much

David> about it.

It happened again.  I was away from the keyboard for half an hour and
when I came back I put my fingers on the trackpad and Aquamacs Emacs
crashed.  I'm attaching the Crash reporter log file.  It contains
several such crashes.

Thanks, José


Content-Description: CrashReporter Log for Aquamacs Emacs
Content-Disposition: inline;
filename="Aquamacs Emacs.crash.log"
Content-Transfer-Encoding: 7bit

**


Host Name:  castalia
Date/Time:  2006-03-05 18:10:07.002 +
OS Version: 10.4.5 (Build 8H14)
Report Version: 4

Command: Aquamacs Emacs
Path:/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs
Parent:  WindowServer [62]

Version: Aquamacs 0.9.8, GNU Emacs 22 (1.2a)

PID:5182
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_PROTECTION_FAILURE (0x0002) at 0x000c

Thread 0 Crashed:
0   org.gnu.AquamacsEmacs 	0x0014772c mac_handle_mouse_event + 132  
(macterm.c:9060)
1   com.apple.HIToolbox   	0x9318dff4 DispatchEventToHandlers 
(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
2   com.apple.HIToolbox   	0x9318d74c SendEventToEventTargetInternal 
(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372
3   com.apple.HIToolbox   	0x9318d5c8  
SendEventToEventTargetWithOptions + 40
4   com.apple.HIToolbox   	0x9322baf4 HIObject::HandleEvent 
(OpaqueEventHandlerCallRef*, OpaqueEventRef*) + 160
5   com.apple.HIToolbox   	0x931a2210 AppleWindowDef::HandleEvent 
(OpaqueEventHandlerCallRef*, OpaqueEventRef*) + 1960
6   com.apple.HIToolbox   	0x9318e3ac HIObject::EventHook 
(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 136
7   com.apple.HIToolbox   	0x9318dff4 DispatchEventToHandlers 
(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 692
8   com.apple.HIToolbox   	0x9318d74c SendEventToEventTargetInternal 
(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372

9   com.apple.HIToolbox 0x931944ec SendEventToEventTarget + 40
10  com.apple.HIToolbox   	0x932209a0 HandleMouseEventForWindow 
(OpaqueWindowPtr*, OpaqueEventRef*, unsigned short) + 284
11  com.apple.HIToolbox   	0x93383730 HandleMouseEvent 
(OpaqueEventRef*) + 368
12  com.apple.HIToolbox   	0x93194858 ToolboxEventDispatcherHandler 
(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) + 496
13  com.apple.HIToolbox   	0x9318e244 DispatchEventToHandlers 
(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) + 1284
14  com.apple.HIToolbox   	0x9318d74c SendEventToEventTargetInternal 
(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) + 372

15  com.apple.HIToolbox 0x931944ec SendEventToEventTarget + 40
16  org.gnu.AquamacsEmacs 	0x00148220 XTread_socket + 344 (macterm.c: 
9706)
17  org.gnu.AquamacsEmacs 	0x00086474 read_avail_input + 140  
(keyboard.c:6732)
18  org.gnu.AquamacsEmacs 	0x00086240 get_input_pending + 148  
(keyboard.c:6620)
19  org.gnu.AquamacsEmacs 	0x0008b5cc detect_input_pending_run_timers  
+ 76 (keyboard.c:9976)
20  org.gnu.AquamacsEmacs 	0x001217b0 wait_reading_process_output +  
2380 (process.c:4599)
21  org.gnu.AquamacsEmacs 	0x00082d64 kbd_buffer_get_event + 268  
(keyboard.c:3945)

22  org.gnu.AquamacsEmacs   0x0008120c read_char + 3224 (keyboard.c:2870)
23  org.gnu.AquamacsEmacs 	0x000895f8 read_key_sequence + 1952  
(keyboard.c:8893)
24  org.gnu.AquamacsEmacs 	0x0007e64c command_loop_1 + 1084  
(keyboard.c:1543)
25  org.gnu.AquamacsEmacs 	0x000e9590 internal_condition_case + 336  
(eval.c:1466)
26  org.gnu.AquamacsEmacs 	0x0007dfac command_loop_2 + 64 (keyboard.c: 
1331)

27  org.gnu.AquamacsEmacs   0x000e8f34 internal_catch + 264 (eval.c:1211)
28  org.gnu.AquamacsEmacs 	0x0007df04 command_loop + 148 (keyboard.c: 
1314)
29  org.gnu.AquamacsEmacs 	0x0007d8d8 recursive_edit_1 + 172  
(keyboard.c:1004)
30  org.gnu.AquamacsEmacs 	0x0007da80 Frecursive_edit + 224  
(keyboard.c:1065)

31  org.gnu.AquamacsEmacs   0x0007c538 main + 3232 (emacs.c:1792)
32  org.gnu.AquamacsEmacs   0xa060 _start + 392 (crt.c:267)
33  dyld

Re: Customize browser: Attempt to change text outside editable field

[David Reitter]

On 13 Feb 2006, at 04:40, Richard M. Stallman wrote:


Using the customize browser, I selected an option (mouse-1). A new
window was opened, showing the customization buffer [was:  
frame]. Then, I clicked on another
option (in the first window). This did not have the desired  
effect.

Instead, I am getting "
cond: Text is read-only: "Attempt to change text outside editable
field".

Could you please give me a precise test case?  What were the commands,
what were the arguments, where did you click?


I'm unable to reproduce this despite numerous attempts. Everything  
works fine now; maybe it has been fixed in the last days. If it  
occurs again, I'll try to provide a few more specific steps.





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Carbon: display-buffer can leave wrong frame with input focus

[David Reitter]

On 9 Feb 2006, at 08:04, YAMAMOTO Mitsuharu wrote:


 Could you try the following patch that prevents raise-frame from
giving focus to a raised frame that is already visible?  Note that a
newly created or previously iconified frame still gets focus when the
frame is popped up by display-buffer, but this behavior is also
observed with some X11 window managers.


Works as intended. The fact that newly opened frames get the focus  
seems  inconsistent, however. From a user's perspective, the same  
sequence of inputs will not lead to the same results, depending on  
whether the other frame happens to get focus or not. I think it'd be  
better if the newly opened frame never gets focus - even if the  
window manager initially gives it focus. That would implement the  
documentation of display-buffer more closely:  "Make buffer appear in  
some window but don't select it."





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon: display-buffer can leave wrong frame with input focus

[David Reitter]

The below issue is reproducible in a plain GNU Emacs (Carbon). Note  
that the X11 version is reported to work fine, but not Carbon Emacs.
This might not be considered a bug by some of you (for example  
because the window manager selects the new frame), but I still think  
synchronizing the behavior of the X11 version and the Carbon  
implementation could be advantageous.



Begin forwarded message:


From: Mark Russell <[EMAIL PROTECTED]>
Date: 9 December 2005 18:48:52 GMT
To: [EMAIL PROTECTED]
Subject: [Aquamacs-bugs] display-buffer can leave wrong frame with  
input focus


display-buffer leaves the wrong frame selected in the following  
situation:


- You have a frame selected

- You call display-buffer on a buffer which is listed in  
special-display-buffer-names

  (and not displayed in the frame you currently have selected)

This creates a new frame to display the buffer (if it is not  
displayed already)
and leaves that frame selected.  Any subsequent input goes to the  
buffer in that frame, but the documentation for display-buffer says  
that it does not select the buffer.


To reproduce the bug, load the following code:

(setq special-display-buffer-names '("*test-buffer*"))

(defun test-display-buffer ()
  "Test frame focus by visiting a buffer in an unsplittable  
window"

  (interactive)
  (display-buffer (get-buffer-create "*test-buffer*")))

In one frame say M-x test-display-buffer.  A new frame will appear  
displaying *test-buffer* and the input focus will be left there.   
This also happens in Carbon emacs, but under X11 emacs the new  
frame is created, but the input focus remains in the original  
frame, which I believe is the correct behavior).


I tripped over this using the compile library, where the call of  
display-buffer in compilation-goto-locus causes the input focus to  
alternate between the compilation error messages window and the  
source file window each time you use next-error (I have  
"*compilation*" listed in special-display-buffer-names).  This  
makes stepping through a stack trace almost unusable for me.  As a  
workaround I replaced the display-buffer call in compilation-goto- 
locus with get-buffer-window, but I think the display-buffer  
behavior is the actual bug.


Mark Russell

In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
 of 2005-12-02 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 0.9.7
Distributor `Apple Computers', version 10.4.3
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Major mode: CPerl

Minor modes in effect:
  smart-frame-positioning-mode: t
  recentf-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t


Recent messages:
Auto-saving...
Mark saved where search started
Quit [2 times]
ad-Orig-error: Moved back before first error
Undo...
Undo!
Undo...
Undo!
Loading browse-url...done
Auto-saving...








___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Customize browser: Attempt to change text outside editable field

[David Reitter]

Using the customize browser, I selected an option (mouse-1). A new  
window was opened, showing the frame. Then, I clicked on another  
option (in the first window). This did not have the desired effect.  
Instead, I am getting "
cond: Text is read-only: "Attempt to change text outside editable  
field".


It doesn't seem to matter which Options I select. When I first set  
the point into the first window (with the browser), selecting it, I  
don't get the error.


Unfortunately, "Enter Debugger on Error" doesn't work in this case,  
so no stack trace for you.






In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
 of 2006-02-08 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 0.9.8
X server distributor `Apple Computers', version 10.4.4
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Custom

Minor modes in effect:
  one-buffer-one-frame-mode: t
  smart-frame-positioning-mode: t
  recentf-mode: t
  emulate-mac-us-keyboard-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
   
   
   
   
   

  
   
   

   


Recent messages:
Creating customization items ...done
Resetting customization items...done
Creating customization setup...done
cond: Text is read-only: "Attempt to change text outside editable  
field" [2 times]

Creating customization items...
Creating customization items ...done
Resetting customization items...done
Creating customization setup...done
cond: Text is read-only: "Attempt to change text outside editable field"
Loading emacsbug...done


--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and  
support the Aquamacs Project!







___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

tramp mode: login failed / accept-process-output

[David Reitter]

Tramp mode fails to open a file with "Login failed" due to a
timeout. I interrupted it; the trace stack is below.

I tried troubleshooting this a bit, to no avail.
It works fine on localhost (Mac OS X) and on another server (FreeBSD).

The problematic network of machines uses

GNU bash, version 3.00.14(1)-release (i686-redhat-linux-gnu)
Copyright (C) 2004 Free Software Foundation, Inc.

I don't know what else to test for - please let me know and I'll do  
that.





  accept-process-output(#[EMAIL PROTECTED]> 1 nil)
  tramp-accept-process-output(#[EMAIL PROTECTED]> 1)

  byte-code("=8c6=8c7=8c8 $=89B\f?=850=8c9
=8ca\"=88=8cb
!=8cc>=84!=8cd=8ce!=88db=88=8cfy=88=8d0!=89=82 
\f=8c7=87" [timeout with-timeout-tag with-timeout-timer with- 
timeout-timers found proc run-with-timer nil with-timeout-handler  
tramp-accept-process-output 1 process-status (run open) error  
"Process has died" -1 looking-at end-of-output with-timeout-value] 6)

  tramp-wait-for-output(10)
  tramp-maybe-open-connection(nil "ssh2" "dreitter" "ssh.inf.ed.ac.uk")
  tramp-send-command(nil "ssh2" "dreitter" "ssh.inf.ed.ac.uk" "cd ~;  
pwd" t)
  tramp-handle-expand-file-name("/ssh2:[EMAIL PROTECTED]:PhD/ 
stats/find-repetitions.py" nil)
  apply(tramp-handle-expand-file-name ("/ 
ssh2:[EMAIL PROTECTED]:PhD/stats/find-repetitions.py" nil))
  tramp-sh-file-name-handler(expand-file-name "/ 
ssh2:[EMAIL PROTECTED]:PhD/stats/find-repetitions.py" nil)
  apply(tramp-sh-file-name-handler expand-file-name ("/ 
ssh2:[EMAIL PROTECTED]:PhD/stats/find-repetitions.py" nil))
  tramp-file-name-handler(expand-file-name "/ 
ssh2:[EMAIL PROTECTED]:PhD/stats/find-repetitions.py" nil)
  expand-file-name("/ssh2:[EMAIL PROTECTED]:PhD/stats/find- 
repetitions.py")
  find-file-noselect("/ssh2:[EMAIL PROTECTED]:PhD/stats/find- 
repetitions.py" nil nil t)
  find-file("/ssh2:[EMAIL PROTECTED]:PhD/stats/find- 
repetitions.py" t)

  call-interactively(find-file)


In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
 of 2006-01-20 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 0.9.8
X server distributor `Apple Computers', version 10.4.4
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Debugger

Minor modes in effect:
  TeX-PDF-mode: t
  one-buffer-one-frame-mode: t
  smart-frame-positioning-mode: t
  recentf-mode: t
  emulate-mac-us-keyboard-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
d r e i t t e r @ i n f  f  
 s s h . i n f . e d . a c . u k / 
:  : P h D / s t a t s  / s t 
  f i n d - r e p e t i t i o
n s . p y
"*Messages*" C-x C-f   C-x C-f  

  C-x C-f   
 

Recent messages:
tramp: Waiting for prompts from remote shell
tramp: Waiting 60s for prompt from remote shell
Quit
tramp: Opening connection for [EMAIL PROTECTED] using ssh2...
tramp: Waiting for prompts from remote shell
tramp: Waiting 60s for prompt from remote shell
Quit
Debug on Quit enabled
Entering debugger...
Loading emacsbug...done


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

frame-local variables / parameters not set by make-frame

[David Reitter]

`make-frame' takes an argument with a list of parameters to create  
the frame with.
However, non-standard frame parameters don't seem to be set, even  
when declared with `make-variable-frame-local'.
That's a bit odd. I would expect `make-frame' to set all parameters,  
whether they are standard or self-defined, and whether they act as  
frame-local variables or not.


`modify-frame-parameters', does it like that and provides useful  
functionality.



To give an example when this is needed: I store an extra frame  
parameter called `fit-frame', which is evaluated by my own `frame- 
creation-function', automatically fitting the frame using Drew Adams'  
frame fitting package. This way I can steer the frame fitting to  
apply only to certain frames.




Example:

(make-variable-frame-local 'dr)

(make-frame '((dr . t ) (height . 20) (width . 30)))

(frame-parameter nil 'dr) ;; --> ought to be t, but is nil

(modify-frame-parameters nil '((dr2 . t ) (dr . t)))

(frame-parameter nil 'dr) ;; is t as expected
(frame-parameter nil 'dr2) ;; is t, too - even if it wasn't made local


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

ediff-directories doesn't respect mouse-1-follows-link

[David Reitter]

When clicking on a file pair in a buffer produced by ediff- 
directories, mouse-1 doesn't do anything. It should open the  
respective file instead. I have `mouse-1-follows-link' enabled (I  
only have one mouse button on my laptop) and I believe this setting  
should be respected (whether you call the clickable file entries in  
the buffer a "link" internally or not).


This is the latest CVS version that I'm using.

smime.p7s
Description: S/MIME cryptographic signature
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: size of the slider bar

[David Reitter]

On 25 Dec 2005, at 20:06, Richard M. Stallman wrote:


  The length of the slider bar, the blue bar that slides inside

the scroll bar track (I'm not sure about the terminology) changes
randomly as you scroll up and down the text. I'm sure you know that
the ratio of the length of this bar to the total length of the scroll
bar must represent the ratio between the number of lines in the  
window

to the number of lines in the file.


That would take too long, for large files; he would not like this  
either,

but he has not realized this would be the price of what he wants.


I'm aware of that and I told him so.

The current situation isn't as bad as it was (Carbon port), so I  
don't think it's a pressing problem right now (but in the long run).


For Emacs 23, you may want to consider one of the following solutions:

1) Keep an index with line numbers for every 5000th character in a  
buffer and use the index to get a good approximate translation from  
char-position to line number (or char-position to pixel height count,  
i.e. lines x char-height) by using the index and counting the  
remaining few lines. The index could be updated through one mean or  
the other, but it's enough to keep it approximately right.
This solution is likely to make sense if the slider size isn't the  
only thing it's good for.


2) Do not change the slider size WHILE it is being dragged, because  
that is confusing from an UI point of view. I think it would be less  
confusing to adapt it AFTER dragging.


I'm sorry I can't implement either of them lacking knowledge about  
Emacs internals and time. 



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Fwd: size of the slider bar

[David Reitter]

We've discussed this before and I've replied to the report below  
already. Yet I would like to forward it to this list so people know  
that users are complaining about this.


Begin forwarded message:


From: Bardia Sadri <[EMAIL PROTECTED]>
Date: 24 December 2005 22:53:42 GMT+01:00
To: [EMAIL PROTECTED]
Subject: [Aquamacs-bugs] size of the slider bar

Symptoms:

This is a bug every single version of emacs on Mac OS X suffers
from. The length of the slider bar, the blue bar that slides inside
the scroll bar track (I'm not sure about the terminology) changes
randomly as you scroll up and down the text. I'm sure you know that
the ratio of the length of this bar to the total length of the scroll
bar must represent the ratio between the number of lines in the window
to the number of lines in the file. So, the ratio, and therefore the
length of this bar, must remain the same so long as neither the number
of lines in the file nor the height of the window are changed.


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
/Applications/Aquamacs Emacs.app/Contents/Resources/etc/DEBUG for  
instructions.



In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
 of 2005-12-21 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution 0.9.8
X server distributor `Apple Computers', version 10.4.3
configured using `configure '--without-x' '--prefix=/usr/local''
 



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Carbon: scrollbar in wrong position

[David Reitter]

On 28 Nov 2005, at 15:19, David Reitter wrote:


N.B., the height of the frame is not an exact multiple of the line  
height, even when resizing the frame (see second screenshot). This  
might be considered a separate bug, if it is a bug and not intended  
- I don't know if this has to do with the strange slider position.


I could just reproduce the issue with "good" frame height, so the two  
problems seem to be independent.





___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon: scrollbar in wrong position

[David Reitter]

This occurs reproducibly right after visiting a file (in a new  
buffer, i.e. find-file-other-frame) - see the first screenshot. At  
the same time, the slider occurs in the right position up on the  
scrollbar. The situation persists until the relevant portion of the  
window is redrawn.  (The build is using toolkit scrollbars.)
It looks like as if the slider was drawn at a wrong position and  
drawn again later on.


Both problems (the one above and the one below) also occur after I  
start out with the buffer loaded and with rather plain frame  
parameters (fixed with Monaco font) and switch to Lucida14.
It also occurs when switching back to Monaco, and the frame is  
redrawn with the larger width.


It also occurs reliably when I resize the frame in fundamental-mode.

My build settings are:

-DUSE_TOOLKIT_SCROLL_BARS -DUSE_TRANSPARENCY -DUSE_ATSUI  -DSYNC_INPUT

Various fontsets are loaded.

I haven't been able to determine which configuration makes the bug  
appear. I'm happy to try out things, but I'd need some ideas about  
where to start!






Btw, where in the code is the horizontal position of the slider defined?
I would like to move it to the right boundary where it is in all my  
other applications.


N.B., the height of the frame is not an exact multiple of the line  
height, even when resizing the frame (see second screenshot). This  
might be considered a separate bug, if it is a bug and not intended -  
I don't know if this has to do with the strange slider position.



___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Emacs hang (100%CPU) on saving a root-owned + r/o file

[David Reitter]

This was reported by an Aquamacs user.

I can reliably reproduce this with various recent CVS builds with -Q  
(Carbon port on OS X).

I stopped it with C-g, the stack trace is below.

---
Alastair Rankine:
http://sourceforge.net/tracker/index.php? 
func=detail&aid=1362636&group_id=138078&atid=740475


100% CPU when attempting to save a file owned by root
To reproduce:

1. Open a file that is owned by root (eg
/etc/httpd/httpd.conf)
2. type ^x^q to toggle readonly mode
3. Make a trivial change
4. Save
5. Answer y to the prompt "file x is write-protected;
try to save anyway? (y or n)"

Emacs goes into 100% CPU usage.

Enclosed is a sample of the app when it is in this
state, courtesy of the Activity Monitor. (recursive
call to mark_object?)

This is with "bare" Aquamacs 0.9.6, no customization
file, no init file.


=


Debugger entered--Lisp error: (quit)
  copy-file("/etc/httpd/httpd.conf" "/etc/httpd/httpd.conf~" t t excl)
  byte-code("¬√ƒè?	∆?%?á" [from-name to-name nil (delete-file to- 
name) ((file-error)) copy-file t excl] 6)
  backup-buffer-copy("/etc/httpd/httpd.conf" "/etc/httpd/ 
httpd.conf~" 420)

  byte-code("Ñc   Ñc\nÉ∆«\n»\"WÑc… !!Éc\fÉ)À!ÃVÑc
Ñ3®ÉmÕ!
ÑTŒ8®Ö_®Ö_Œ8XÖ_œ8Ü_–!?)Ém—\n#àÇz“”#à\nB∆á" [file- 
precious-flag backup-by-copying modes real-file-name backup-by- 
copying-when-linked backup-by-copying-when-mismatch 0 logand 3072  
file-writable-p file-name-directory file-nlinks 1 file-attributes 2 9  
file-ownership-preserved-p backup-buffer-copy rename-file t backup-by- 
copying-when-privileged-mismatch attr backupname setmodes] 4)
  byte-code("Ö	∆=Ñ	«=Ö	Ü»… \n\"!À!«ÃÕè?	 
É:É:«ŒœèàAâÑ.*á" [targets delete-old-versions real-file-name  
buffer-file-name modes buffer-backed-up t nil y-or-n-p format "Delete  
excess backup versions of %s? " file-modes (byte-code "Ñc	Ñc 
\nÉ∆«\n»\"WÑc… !!Éc\fÉ)À!ÃVÑc

Ñ3®ÉmÕ!
ÑTŒ8®Ö_®Ö_Œ8XÖ_œ8Ü_–!?)Ém—\n#àÇz“”#à\nB∆á" [file- 
precious-flag backup-by-copying modes real-file-name backup-by- 
copying-when-linked backup-by-copying-when-mismatch 0 logand 3072  
file-writable-p file-name-directory file-nlinks 1 file-attributes 2 9  
file-ownership-preserved-p backup-buffer-copy rename-file t backup-by- 
copying-when-privileged-mismatch attr backupname setmodes] 4) ((file- 
error ...)) (byte-code "[EMAIL PROTECTED]" [targets delete-file] 2) ((file- 
error)) setmodes] 5)

  backup-buffer()
  basic-save-buffer-2()
  basic-save-buffer-1()
  basic-save-buffer()
  save-buffer(1)
  call-interactively(save-buffer)




smime.p7s
Description: S/MIME cryptographic signature
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

allout-auto-save-hook-handler: Invalid function

[David Reitter]

I can reproduce the below bug in a GNU Emacs (-Q) by filling a  
scratch buffer, then


M-x allout-mode
C-x C-s (some filename)


Begin forwarded message:


From: Gerry Brush <[EMAIL PROTECTED]>
Date: 20 November 2005 19:55:15 GMT
To: [EMAIL PROTECTED]
Subject: [Aquamacs-bugs] allout-auto-save-hook-handler: Invalid  
function


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 [EMAIL PROTECTED]  
mailing list and possibly to the gnu.emacs.bug news group.


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


Nothing special.  I was editing a very simple outline using the  
allout-mode.  From the start of running the mode I received these  
(and more) errors.  The flashing of the errors at the bottom of the  
frame was fairly intense so I abandoned the use of the mode.


allout-auto-save-hook-handler: Invalid function: (macro . #[nil  
"" [allout-mode] 1 ("/Users/gbrush/Applications/Aquamacs/Aquamacs  
Emacs.app/Contents/Resources/lisp/allout.elc" . 33844)]) [135 times]
allout-write-file-hook-handler: Invalid function: (macro . #[nil  
"" [allout-mode] 1 ("/Users/gbrush/Applications/Aquamacs/Aquamacs  
Emacs.app/Contents/Resources/lisp/allout.elc" . 33844)])
allout-auto-save-hook-handler: Invalid function: (macro . #[nil  
"" [allout-mode] 1 ("/Users/gbrush/Applications/Aquamacs/Aquamacs  
Emacs.app/Contents/Resources/lisp/allout.elc" . 33844)]) [2623 times]

ad-Orig-kill-line: End of buffer
allout-auto-save-hook-handler: Invalid function: (macro . #[nil  
"" [allout-mode] 1 ("/Users/gbrush/Applications/Aquamacs/Aquamacs  
Emacs.app/Contents/Resources/lisp/allout.elc" . 33844)]) [13 times]

Quit







In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
 of 2005-11-19 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution  
0.9.7beta

Distributor `Apple Computers', version 10.3.9
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Major mode: Text

Minor modes in effect:
  flyspell-mode: t
  desktop-save-mode: t
  dot-mode: t
  one-buffer-one-frame-mode: t
  smart-frame-positioning-mode: t
  recentf-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
 
 
 
 
 
 
 
 
 
 
 
 

  >   

A-s

 

Recent messages:
allout-auto-save-hook-handler: Invalid function: (macro . #[nil  
"" [allout-mode] 1 ("/Users/gbrush/Applications/Aquamacs/Aquamacs  
Emacs.app/Contents/Resources/lisp/allout.elc" . 33844)])

Quit
allout-auto-save-hook-handler: Invalid function: (macro . #[nil  
"" [allout-mode] 1 ("/Users/gbrush/Applications/Aquamacs/Aquamacs  
Emacs.app/Contents/Resources/lisp/allout.elc" . 33844)]) [2 times]

Quit [2 times]
allout-auto-save-hook-handler: Invalid function: (macro . #[nil  
"" [allout-mode] 1 ("/Users/gbrush/Applications/Aquamacs/Aquamacs  
Emacs.app/Contents/Resources/lisp/allout.elc" . 33844)]) [2 times]

Quit
allout-auto-save-hook-handler: Invalid function: (macro . #[nil  
"" [allout-mode] 1 ("/Users/gbrush/Applications/Aquamacs/Aquamacs  
Emacs.app/Contents/Resources/lisp/allout.elc" . 33844)]) [89 times]

Auto-saving...done
Mark set
Wrote /Users/gbrush/Documents/Presentations/SAB05/text



---
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
__
https://lists.sourceforge.net/lists/listinfo/aquamacs-bugs




___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

CVS checkin with longlines mode

[David Reitter]

When editing a CVS-controlled file in Outline-mode with longlines  
switched on, the hard line-breaks are somehow destroyed as soon as  
the file is committed to CVS. After committing, the buffer is re- 
filled, with most linebreaks gone. I noticed that line-breaks go away  
after long lines, but not after several short lines. This might be  
coincidental, of course.


I can supply the file and further configuration information if needed.





In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
 of 2005-11-18 on rodrigues.inf.ed.ac.uk - Aquamacs Distribution  
0.9.7beta

Distributor `Apple Computers', version 10.4.3
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Major mode: Outline

Minor modes in effect:
  one-buffer-one-frame-mode: t
  smart-frame-positioning-mode: t
  longlines-mode: t
  recentf-mode: t
  encoded-kbd-mode: t
  osx-key-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  pc-selection-mode: t
  cua-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  mouse-wheel-mode: t
  use-hard-newlines: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
  
   
  
  

  
  
  
  A-c  
  
   A-v A-s 
 A-s C-x v v u p d C-c C-c A-z 
 SPC SPC A-z A-z A-z  
SPC A-z A-z A-z A-z A-z A-w SPC SPC   A-s
  C-x v v t e s t C-c C-c 
 A-z   
 SPC A-z   

Recent messages:
Wrote /Users/dr/Projects/Aquamacs/aquamacs/TODO
Mark set
Press C-c C-c when you are done editing.
Enter a change comment.  Type C-c C-c when done
Checking in /Users/dr/Projects/Aquamacs/aquamacs/TODO...done
Undo...
Undo!
Auto-saving...done
Undo...
Undo!


___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon with -nw: kCGErrorRangeCheck / Abort trap

[David Reitter]

The Carbon port starts up in TTY mode when given the -nw parameter.

When logged in as non-console user, i.e. remotely, the process crashes.

To reproduce:

ssh [EMAIL PROTECTED]
(...)
lucy:/Volumes/Sista/Applications/Emacs.app/Contents/MacOS test$ ./ 
Emacs  -nw
kCGErrorRangeCheck : Window Server communications from outside of  
session allowed for root and console user only
INIT_Processeses(), could not establish the default connection to the  
WindowServer.

Fatal error (6)Abort trap


One error occurs during bootstrapping (calls to temacs) when run as a  
user who is not root and isn't a locally logged in user, i.e. when  
building Emacs on  a server. Here, kCGErrorRangeCheck appears (but  
not the INIT_Processes one, I believe) and it doesn't lead to an abort.



This is a vanilla CVS build with  ./make-package --self-contained -- 
build-in-place

 

smime.p7s
Description: S/MIME cryptographic signature
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Crash during access_keymap

[David Reitter]

On 13 Nov 2005, at 06:39, YAMAMOTO Mitsuharu wrote:


  So, if there's a non-pure object that is only pointed to by pure
  objects, which may happen if the assumption for the pure storage is
  violated, then the object is reachable but get collected.


OK, that makes sense.
Do you know if this is documented somewhere?
I've read the info nodes about pure storage etc., and it doesn't say  
anything about what to look for in code, or if there is a way to test  
for the effect while loading. Maybe on a port that implements memory  
protection?


I mostly just preload code, but define a setup function in each  
package that is run at runtime. But from what you are saying, I am  
getting that vectors are allocated when the file is loaded, and not  
copied when a function is called. But if the code used (vector 0 0 0  
0 0) instead of [0 0 0 0 0], the vector would be allocated at runtime  
and we don't run into such trouble. Does this apply only to vectors?  
(Since vectors seem immutable to me, this all would make sense...)


Any pointers to documentation would be greatly appreciated - I'm  
happy to read whatever there is.


Thanks
- David


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Crash during access_keymap

[David Reitter]

On 12 Nov 2005, at 05:48, YAMAMOTO Mitsuharu wrote:


Still I can't see the "commandp" problem with the CVS version.  If it
only occurs on some distributions of modified Carbon Emacs, it is
difficult for me to help directly, sorry.

One thing I can think of is heap corruption caused by missing
BLOCK_INPUTs.  If -DSYNC_INPUT suppresses the error, it might be due
to this. (See the thread starting from
http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00074.html)


I've been using SYNC_INPUT for a couple of weeks, and I'm still  
getting the error.
It's interesting that we don't have any other signs of memory  
corruption - always the global keymap, and it seems like mode keymaps  
are not affected. If the access_keymap crash is due to the same  
issue, it's another pointer to keymaps.


I've had the bug occur reproducibly when loading a large .elc at some  
point  - but I can't repeat this :-(


Looking at the C-level patches that Aquamacs and Carbon Emacs Package  
have in common:


- transparency
- toolbar-button

Both patches don't do anything unless their respective functionality  
is used, as far as I can tell.


I suspect it's rather due to the higher memory management  
requirements - the distributions load more packages.


I tried experimenting with garbage collection settings. While a  
forced GC makes the bug go away in situations where I can reproduce  
it for a while, neither a high gc-cons-threshold nor a GC call after  
initialization will reliably make the bug go away.


Is the bug only in the Carbon port for sure, or is it just that it  
happens to surface there and that the CVS version Carbon port has a  
particularly wide circulation and high requirements given the  
distributions that people use?







___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Carbon / reported font width wrong?

[David Reitter]

In the Carbon port (current CVS), fontset-info or frame-char-width  
report wrong pixel widths for fonts.
In the example below, two fontsets are created. The I set the frame  
font (to load the font) and compare reported character width with  
(frame-char-width).


From my understanding of the documentation, the two should be the  
same - but they differ.


Please correct me if my understanding is wrong and this is not a bug.  
In that case it'd be helpful to know how to determine the height and  
normal width of characters in a fontset before the fontset is  
actually loaded. The reason why I'd like to do this is to change the  
font of a given frame without changing its pixel size (or at least  
with only minimal changes in pixel size). For this, I need to  
calculate the new (character-based) width and height using the old  
ones and the old and new font character dimensions.


Thanks
D

---

(defun create-aquamacs-fontset (maker name weight variety style  
sizes  &optional fontsetname)
  "Create a mac fontset with the given properties (leave nil to  
under-specify).
SIZES is a list of integers, indicating the desired font sizes in  
points.
Errors are signalled with ``signal-font-error'', unless ''ignore-font- 
errors''

is non-nil. (This function is part of Aquamacs and subject to change.)"
  (message (concat "Defining fontset: " (or fontsetname name)))
  (condition-case e
  (dolist (size sizes)

(create-fontset-from-mac-roman-font
 (format "-%s-%s-%s-%s-%s-*-%s-*-*-*-*-*-mac-roman"
 (or maker "*")
 (or name "*")
 (or weight "*")
 (or variety "*")
 (or style "*")
 size
 )
 nil
 (concat (or fontsetname name) (int-to-string size))
 )
)
(error (signal-font-error e)))

)

(create-aquamacs-fontset
"apple" "lucida grande*" "medium" "r" "normal" '(9 10 11 12 13 14 16  
18) "lucida" )

(create-aquamacs-fontset
"apple" "monaco*" "medium" "r" "normal" '(9 10 11 12 13 14 16 18)  
"monaco" )



(set-frame-font "fontset-lucida13")
(fontset-info "fontset-lucida13")
;; "SIZE is the maximum bound width of ASCII font in the fontset,"
;; first element of vector is 15 (width in pixels)
(frame-char-width)


(set-frame-font "fontset-monaco12")
(fontset-info "fontset-monaco12")
;; width reported is 8
(frame-char-width)
;; real width is 7


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

OS X: Character Palette input doesn't work

[David Reitter]

In the Carbon port, one cannot use the "Character Palette" to input  
characters into Emacs.


The original report came from an Aquamacs user.


It's easy to insert a
Unicode character in a window from a Keyboard Viewer (e.g. a
cyrillic character from an Ukrainian keyboard) but I cannot insert a
Unicode character from the Character Palette. The "Insert" button
remains grayed out.


I confirmed this for a very recent Emacs CVS version.
The "Insert" function of Character Palette is disabled while in  
Emacs. All other applications are happy to take input from it.


I couldn't find out what the cause of the problem is - I was looking  
for issues with the Carbon event handling and a missing event handler  
for some text input event.






___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Mac port: startup failure when in non-ASCII path

[David Reitter]

Emacs (Carbon port) is unable to deal with path names that contain  
non-ASCII characters.


Symptoms:

If a (self-containing) Emacs.app is put in

/Applications/Emacs ƒ/

or

/Applications/Emacs ö/


Emacs won't start up. Starting the binary inside the bundle directly  
yields the error message


Cannot open load file: term/mac-win

which becomes

Cannot open load file: disp-table

when started  with -batch.

This is last night's Emacs CVS (and an older compile as well),  
running on OS X 10.4.3.


Note that the first option for the directory name (ƒ) is actually a  
not untypical choice for Mac users (for history reasons). An actual  
Aquamacs user has reported a startup failure, which turned out to be  
due to his choice of path name.


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Crash during access_keymap

[David Reitter]

I was trying to visit a file (emacs-lisp-mode) by doing C-x C-f and  
entering a file name.


This usually happens right after "Loading vc-cvs" is displayed.

This is after starting up. This is with a recent Aquamacs build (on  
Darwin / OS X), based on the current Emacs CVS. I can't reproduce it  
with Emacs CVS or starting up Aquamacs with -Q, sorry.


This also occurs sporadically after loading the file.
I have set garbage-collection-messages to t, and gc-cons-threshold to  
400 and I noticed that the error occurs usually after a garbage  
collection has been completed ("...done"). I wonder why gcs happen  
anyways with a gc-cons-threshold that high.


Manually running (garbage-collect) won't provoke the bug.

Unfortunately, this problem cannot be reliably reproduced.
Sorry if this isn't enough to reproduce (I realize it probably  
isn't), but maybe the stack trace below gives some indication.

The always occurs during access_keymap.

If this is the same bug with corruption of keymaps that everybody is  
complaining about: please please find&fix it. This occurs not only in  
Aquamacs, but also in recent Carbon Emacs Package builds.
I've already spent hours on tracing this and finding a workaround,  
and I haven't gotten far with this. Thanks.


---

Date/Time:  2005-11-08 00:20:02.616 +
OS Version: 10.4.3 (Build 8F46)
Report Version: 3

Command: Aquamacs Emacs
Path:/Applications/Aquamacs Emacs.app/Contents/MacOS/Aquamacs Emacs
Parent:  WindowServer [104]

Version: Aquamacs 0.9.7, GNU Emacs 22 (1.2a)

PID:18607
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:  KERN_INVALID_ADDRESS (0x0001) at 0x025ee7a8

Thread 0 Crashed:
0   org.gnu.AquamacsEmacs   0x0008d070 access_keymap + 428 (keymap.c:579)
1   org.gnu.AquamacsEmacs 	0x00084954 menu_bar_items + 472  
(keyboard.c:7019)
2   org.gnu.AquamacsEmacs 	0x00028e94 update_menu_bar + 504 (xdisp.c: 
9086)
3   org.gnu.AquamacsEmacs 	0x00028bf8 prepare_menu_bars + 356  
(xdisp.c:8974)
4   org.gnu.AquamacsEmacs 	0x0002b718 redisplay_internal + 1000  
(xdisp.c:10659)

5   org.gnu.AquamacsEmacs   0x0007ecdc read_char + 1112 (keyboard.c:2540)
6   org.gnu.AquamacsEmacs 	0x00087654 read_key_sequence + 1932  
(keyboard.c:8859)
7   org.gnu.AquamacsEmacs 	0x0007ca10 command_loop_1 + 1056  
(keyboard.c:1530)
8   org.gnu.AquamacsEmacs 	0x000e5e70 internal_condition_case + 320  
(eval.c:1466)
9   org.gnu.AquamacsEmacs 	0x0007c3a8 command_loop_2 + 64 (keyboard.c: 
1318)

10  org.gnu.AquamacsEmacs   0x000e584c internal_catch + 248 (eval.c:1211)
11  org.gnu.AquamacsEmacs 	0x0007c300 command_loop + 144 (keyboard.c: 
1301)
12  org.gnu.AquamacsEmacs 	0x0007bce8 recursive_edit_1 + 168  
(keyboard.c:991)
13  org.gnu.AquamacsEmacs 	0x0007be80 Frecursive_edit + 220  
(keyboard.c:1052)

14  org.gnu.AquamacsEmacs   0x0007a980 main + 3128 (emacs.c:1783)
15  org.gnu.AquamacsEmacs   0xa060 _start + 392 (crt.c:267)
16  dyld0x8fe01048 _dyld_start + 60

Thread 0 crashed with PPC Thread State 64:
  srr0: 0x0008d070 srr1:  
0x0200f930vrsave: 0x
cr: 0x44004242  xer: 0x0004   lr:  
0x0008cf30  ctr: 0x
r0: 0x0005   r1: 0xbfffde30   r2:  
0x005fced4   r3: 0x025ee7ad
r4: 0x04009f99   r5: 0x0002   r6:  
0x   r7: 0x0001
r8: 0x00da2758   r9: 0x0003  r10:  
0x000efbe8  r11: 0x0001
   r12: 0x00084b64  r13: 0x002bc265  r14:  
0x008013d2  r15: 0x005f9580
   r16: 0x008013d2  r17: 0x005fc6d4  r18:  
0x0001  r19: 0x005f9270
   r20: 0x005fc530  r21: 0x005fc6dc  r22:  
0x005fb33c  r23: 0x005fc51c
   r24: 0x00174784  r25: 0x0002  r26:  
0x04009e91  r27: 0x005f936c
   r28: 0x04000221  r29: 0xbfffdf58  r30:  
0x025ee7a8  r31: 0x0008ced4


Binary Images Description:
0x1000 -   0x175fff org.gnu.AquamacsEmacs Aquamacs 0.9.7, GNU  
Emacs 22 (1.2a)	/Applications/Aquamacs Emacs.app/Contents/MacOS/ 
Aquamacs Emacs

  0x908000 -   0x933fff libncurses.5.dylib  /usr/lib/libncurses.5.dylib
  0xc32000 -   0xc63fff liblame3.92.dylib 	/Library/Application  
Support/DivXNetworks/liblame3.92.dylib
  0xca -   0xca3fff libMPAEncode0.1.dylib 	/Library/Application  
Support/DivXNetworks/libMPAEncode0.1.dylib
  0xca7000 -   0xcb9fff libdpv10.dylib 	/Library/Application Support/ 
DivXNetworks/libdpv10.dylib
  0xf05000 -   0xfcefff com.divxnetworks.DivXCodec 5.2	/Library/ 
QuickTime/DivX 5.component/Contents/MacOS/DivX 5
0x108d000 -  0x10edfff libdpus10.dylib 	/Library/Application Support/ 
DivXNetworks/libdpus10.dylib
0x2295000 -  0x229bfff com.apple.DictionaryServiceComponent 1.0.0	/ 
System/Library/Components/DictionaryService.component/Conten

Re: Mouse wheel doesn't work on XP

[David Reitter]

 is undefined
 is undefined
 is undefined



same on the Carbon port, and it's been like that for a few days.
The mouse wheel events aren't bound to anything.

mouse-wheel-mode is on, and toggling it doesn't help.

Couldn't find a recent change that caused the problem.



-- Dave


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: flyspell + longlines: hang/wait

[David Reitter]

On 1 Nov 2005, at 18:59, Kim F. Storm wrote:

Thanks for the explanations.


The next step would be to allow for wrap-column to follow the width
of the window (probably easy)


What do you mean?


analogous to longlines-wrap-follows-window-size.

The following does the job for me:

(add-hook 'window-size-change-functions
  (defun follow-size (frame)
(set-window-wrap-column nil (window-width) t)))


I would imagine this "follow window size" mode is how most people  
would use it.

One could allow for something like

(set-window-wrap-column nil 'window-width t)

to indicate that lines should end at the maximal length in the  
window, whatever that is.




 It supports variable width fonts -- it is just the wrap-column that
is set in units of the default frame font.


You're right. Works like a charm!


This can be done in lisp - there are packages that does this for
continuation lines already.  Can't remember its name right now.
The relevant function to use is "vertical-motion".


OK, but how to keep track of the horizontal cursor position?
The current previous-line and friends (actually, line-move-1) doesn't  
really work well for variable-width fonts, because it always tries to  
jump to the same character position, which can be far to the left or  
to the right. For example, position the cursor at the end of line 1  
in the following example, then go down.


1: ii*
2: OO*

You end up at the end of line 2, and not after the 4th or 5th O, as  
you would expect in a variable-width font setting.


By the way, I just noticed that with window-wrap-column turned on  
(and not wrapping anything in the above two lines), I cannot jump  
down from 1 to 2 - the point always ends up in the line afterwards.  
Let me know if I should investigate further in case you can't reproduce.



___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: flyspell + longlines: hang/wait

[David Reitter]

On 1 Nov 2005, at 11:20, Kim F. Storm wrote:


"Richard M. Stallman" <[EMAIL PROTECTED]> writes:


So in my mind, DTWW is not an alternative to e.g. editing with
longlines mode, but on the other hand, I don't understand why you
oppose DTWW support in Emacs.

I oppose it as an alternative to longlines mode.
I don't necessarily oppose it as a way of continuing lines,
but I want to make sure it does not grow into an alternative
to longlines mode.


I never intended it to be an alternative to longlines mode.  That is
specifically why I have NOT made any attempt to make line-move and
friends treat DTWW differently from normal continued lines.

However, this is probably not the right time to add DTWW ...


Experimenting with it anyways.

Your patch works well, except that wrap-column behaves like default- 
wrap-column: I need to set it and create a new buffer for it to come  
into effect. It should affect the current buffer when it is changed.
The next step would be to allow for wrap-column to follow the width  
of the window (probably easy) and to support - at least in the case  
of (eq wrap-colum 'max) (i.e. follow the window) - variable-width fonts.


Having functions to move up and down "into" a wrapped line would be  
something that would be a great help in Emacs 22. If they're not  
bound to up/down by default, the functions can't break much. (if I  
had the technical knowledge about Emacs' display engine, I would  
write a patch - sorry!)






___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: flyspell + longlines: hang/wait

[David Reitter]

On 31 Oct 2005, at 21:10, Miles Bader wrote:


obviously you'd need some change to line-move to do
"display-based" movement instead of logical movement (but maybe this
would be a good feature to have anyway -- many users prefer this
behavior generally).


Most definitely. I'm usually rather unhappy when I, due the jump- 
several-visual-lines behavior, have to move the point to where I need  
it to be, often with the mouse...




BTW, I should note that there's nothing stopping DTWW proponents from
maintaining a separate DTWW branch/patch to get more experience with
the issue (I maintain my own Emacs branches too)!  Real honest-to-god
data is a great advantage in any debate...


Yes, I've done that for my branch now which is used by a bunch of  
beta-testers.

Let's see.



___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: flyspell + longlines: hang/wait

[David Reitter]

On 30 Oct 2005, at 01:30, Miles Bader wrote:


The "opposition" such as it is, seems just as religious in its zeal.


Recently, we have arrived at a few good non-religious arguments.

On the "pro DTWW" side, there's speed, line-number referencing  
(compiler errors e.g.), collaborative editing with others (who prefer  
different line length, but need to read/edit my text), variable needs  
in terms of frame width (when we use  the most common form of system- 
level UI, a multi-window desktop).


On the "no DTWW" side, RMS has made a very good point: GNU tools are  
based on the assumption of relatively short lines. Display-time word  
wrapping does away with single line-feeds as end-of-line markers, and  
something like the output of "grep" isn't too useful any more.


I for my part, don't use grep or more on my LaTeX files very often.  
But that'll be different for different people, and I respect that.
I hope that eventually, tools like grep, wc and more will move on,  
recognizing that there isn't one standard 65 or 80 character wide  
terminal any more...



As a _user_, I generally support display-time word-wrapping (call it
"DTWW"), because have to deal with editing such text too, and
traditionally it's been a pain to do that with Emacs (though
longlines-mode has done a great job with everything I've thrown at it
so far).


I see longlines as a good workaround. The bugs with variable width  
fonts should be fixed and some essential things should be  
reimplemented in C (sorry, can't do it, otherwise I'd prepare a patch  
today).



As an Emacs hacker, though, my concern with DTWW is what interaction
it would have with the assumptions made by lisp code; supporters seem
to generally assume that the only modification required will be some
support in `line-move' to make C-n/C-p move by physical lines instead
of logical lines when DTWW is turned on in a buffer.


You'll never know until you've tried it out.


___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Re: Carbon port - mouse wheel broken

[David Reitter]

On 29 Oct 2005, at 15:23, David Reitter wrote:


some recent change broke mouse wheel support in the Carbon port.
I get a lot of "[double|triple]wheel-{up|down} undefined" messages.

this happens with trackpad two-finger scrolling and with an  
external mouse.


potentially useful additional information:

When I do M-x mouse-wheel-mode,  I get the following error:

Lisp error: (wrong-type-argument sequencep shift)
  append(shift (mouse-5))
  #[(amt) "¬√:Ö@C\"!á" [amt up vector append] 4]((shift .  
1.5))
  mapcar(#[(amt) "¬√:Ö@C\"!á" [amt up vector append] 4]  
(1 (shift . 1.5) (control . 0.01)))

  mouse-wheel-mode(toggle)
  call-interactively(mouse-wheel-mode)
  execute-extended-command(nil)
  call-interactively(execute-extended-command)





___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

yank in search minibuffer doesn't yank

[David Reitter]

Yank in the search mini-buffer doesn't work.

Test case: select some text to copy it, then do C-s C-y.
Result: the text from point to the end of the current line gets  
pasted into the minibuffer, but not the saved text.





In GNU Emacs 22.0.50.1 (powerpc-apple-darwin7.9.0)
of 2005-10-29 on rodrigues.inf.ed.ac.uk
X server distributor `Apple Computers', version 10.4.2
configured using `configure '--without-x' '--prefix=/usr/local''

Important settings:
  value of $LC_ALL: nil
  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
  value of $LANG: nil
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  encoded-kbd-mode: t
  recentf-mode: t
  tooltip-mode: t
  auto-compression-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  line-number-mode: t

Recent input:
   M-v 
  C-y
 
 
 
   
   C-y 
C-s C-yC-s C-h k C-y 
   
C-s C-y


Recent messages:
For information about the GNU Project and its goals, type C-h C-p.
Loading encoded-kb...done
call-interactively: Beginning of buffer
Mark set [2 times]
Mark saved where search started
Loading help-mode...done
Loading help-fns...done
Type C-x 1 to remove help window.  C-M-v to scroll the help.
Mark saved where search started
Loading emacsbug...done




___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug