Re: Concerns

The change for dealing with "return" will be placed in the latest 
distribution once my public key is updated by savannah's cron job (~ 
2000 GMT)

Here are the questions I feel qualified to try and answer.

> 1) The default installation does not set the selection coding system.
> So, pasting non-ASCII characters generates coding errors.
> The following .emacs entry solves the problem only partially, because 
> the selection coding system actually depends on what is selected, but 
> it works for most European applications:
> (if (eq window-system 'mac)
>     (progn
>       (setq selection-coding-system 'mac-roman)
>       ))
>
> (Setting the selection coding system should also obviate the need for 
> the \r-to-\n replacement loop, no?)

I'll defer to Andrew on this one.  Emacs is going through an internal 
change from mule to unicode which should solve most of these problems.  
When that gets a little closer to working, I was going to switch emacs 
to being a "unicode" app.  All text coming from the outside would be in 
unicode instead of the current script.  Then all of these problems will 
be fixed.

> 3)       (setq mac-wheel-button-is-mouse-2 nil)
>
> (The meaning is inverted in Mac OS X: setting it to nil means that the 
> wheel button is the mouse)

I'm not sure I follow.  The Mac treats the mouse-wheel-button as mouse 
button 4 (After the left and right click).  The default is t to follow 
the convention for NT emacs (and because for most mice the wheel button 
is in the middle).  If it is set to nil, the wheel button is treated as 
mouse-3 and the right-click is treated as mouse-2.



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf