Re: Carbon: Option-as-Meta Sometimes Inputs Accented Characters
On 5/12/07, Tom Tobin <[EMAIL PROTECTED]> wrote: Running exactly your test case, I can't get M-v to insert √ because the news is a read-only buffer and Emacs complains. If I instead fill up *scratch* with garbage for a few screenfuls and otherwise duplicate your steps in *scratch*, I can indeed see √ inserted from M-v. It does appear I was half-wrong about the dead keys; I *can* get non-dead-key characters to insert into the buffer, but only if one of 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. ___ 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
On 5/12/07, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> wrote: > On Sat, 12 May 2007 13:46:50 -0500, "Tom Tobin" <[EMAIL PROTECTED]> said: > Yes, I can reproduce it with a Carbon GNU Emacs build. The bug > happens whenever any two Meta keys, each bound to scroll commands, > are pressed and held down in alternation (e.g., bind M-n to > scroll-up, and then alternate in a buffer spanning several > screen-lengths between holding down M-n for a second or two, then > M-v for a second or two, then M-n again, etc.; you will see the √ > character inserted into the buffer for M-v, and the dead-key symbol > inserted for M-n.). The issue is definitely not specific to dead > keys. Still I can't reproduce it on a Carbon build with my previous patch, which is only for the dead-key cases. Could you show a concrete procedure starting from ".../Emacs.app/Contents/MacOS/Emacs -Q"? What I tried was: 1) /Applications/Emacs.app/Contents/MacOS/Emacs -Q 2) Evaluate (setq mac-option-modifier 'meta) and (global-set-key "\M-n" 'scroll-up) in *scratch*. 3) C-h n to show Emacs News. 4) Hold down Option-n for a second or two, then Option-v for a second or two, then Option-n again, etc. I'm using Mac OS X 10.4.9, PowerBook G4, US keyboard layout. Also, to make sure, please try some case that does not involve any dead-keys. Running exactly your test case, I can't get M-v to insert √ because the news is a read-only buffer and Emacs complains. If I instead fill up *scratch* with garbage for a few screenfuls and otherwise duplicate your steps in *scratch*, I can indeed see √ inserted from M-v. It does appear I was half-wrong about the dead keys; I *can* get non-dead-key characters to insert into the buffer, but only if one of 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. ___ 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
> On Sat, 12 May 2007 13:46:50 -0500, "Tom Tobin" <[EMAIL PROTECTED]> said: >> I could reproduce the Option-n case and I think the following patch >> will fix it. But the patch fixes a problem with dead-key >> processing, and I have no idea about the Option-v case. Is it >> possible for the OP to try to reproduce it with "a Carbon build >> straight from GNU Emacs CVS" (with setting mac-option-modifier to >> meta)? > Yes, I can reproduce it with a Carbon GNU Emacs build. The bug > happens whenever any two Meta keys, each bound to scroll commands, > are pressed and held down in alternation (e.g., bind M-n to > scroll-up, and then alternate in a buffer spanning several > screen-lengths between holding down M-n for a second or two, then > M-v for a second or two, then M-n again, etc.; you will see the √ > character inserted into the buffer for M-v, and the dead-key symbol > inserted for M-n.). The issue is definitely not specific to dead > keys. Still I can't reproduce it on a Carbon build with my previous patch, which is only for the dead-key cases. Could you show a concrete procedure starting from ".../Emacs.app/Contents/MacOS/Emacs -Q"? What I tried was: 1) /Applications/Emacs.app/Contents/MacOS/Emacs -Q 2) Evaluate (setq mac-option-modifier 'meta) and (global-set-key "\M-n" 'scroll-up) in *scratch*. 3) C-h n to show Emacs News. 4) Hold down Option-n for a second or two, then Option-v for a second or two, then Option-n again, etc. I'm using Mac OS X 10.4.9, PowerBook G4, US keyboard layout. Also, to make sure, please try some case that does not involve any dead-keys. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
viewing a .jpg vs. scrollbars
When viewing an image, the scrollbar does not reflect that there is more lying off the screen, as doesn't the "All" initially in the modeline. I don't know how you are going to implement horizontal scrollbars or otherwise indicate there is more to the side. At least make the mouse act like xli(1), or maybe display(1). Wheeling the mouse skips back to the top, bad. Wheeling in the other direction bangs into 'beginning of buffer', but causes a flash where a top strip of the picture becomes reverse video momentarily. emacs-version "22.0.95.1" debian emacs-snapshot 20070302-1 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ffap-list-directory prompt too like real dired
ffap-list-directory is nice but it misleadingly gives the same prompt as dired, "Dired file or URL:" ___ 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
On 5/12/07, YAMAMOTO Mitsuharu <[EMAIL PROTECTED]> wrote: > On Sat, 12 May 2007 07:51:28 +0100, David Reitter <[EMAIL PROTECTED]> said: > 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. I could reproduce the Option-n case and I think the following patch will fix it. But the patch fixes a problem with dead-key processing, and I have no idea about the Option-v case. Is it possible for the OP to try to reproduce it with "a Carbon build straight from GNU Emacs CVS" (with setting mac-option-modifier to meta)? Yes, I can reproduce it with a Carbon GNU Emacs build. The bug happens whenever any two Meta keys, each bound to scroll commands, are pressed and held down in alternation (e.g., bind M-n to scroll-up, and then alternate in a buffer spanning several screen-lengths between holding down M-n for a second or two, then M-v for a second or two, then M-n again, etc.; you will see the √ character inserted into the buffer for M-v, and the dead-key symbol inserted for M-n.). The issue is definitely not specific to dead keys. ___ 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
On 5/12/07, David Reitter <[EMAIL PROTECTED]> wrote: 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. FWIW, I'll add that I can only reproduce the problem when alternating between two scrolling keys that are *both* meta-bound. I have M-p/M-n bound to scroll-up/down, and that reproduces it easily. I can only trigger M-v when alternating between it and another scrolling meta key. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: elisp manual indent-line-function default
I will update the documentation for this. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: using rlogin from a shell window
More info. If, when it prompts for the password, I type the password and then add a carriage return (using ^Q^M) at the end of the password, then hit enter, all works as expected. This suggests it is a bug in rlogin. ___ 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
> On Sat, 12 May 2007 07:51:28 +0100, David Reitter <[EMAIL PROTECTED]>
> said:
> 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.
I could reproduce the Option-n case and I think the following patch
will fix it. But the patch fixes a problem with dead-key processing,
and I have no idea about the Option-v case. Is it possible for the OP
to try to reproduce it with "a Carbon build straight from GNU Emacs
CVS" (with setting mac-option-modifier to meta)?
YAMAMOTO Mitsuharu
[EMAIL PROTECTED]
*** emacs/src/macterm.c.~1.214.~Fri Apr 13 17:14:46 2007
--- emacs/src/macterm.c Sat May 12 19:23:49 2007
*** static Boolean mac_convert_event_ref (Ev
*** 9201,9206
--- 9201,9207
switch (GetEventKind (eventRef))
{
case kEventRawKeyDown:
+ case kEventRawKeyRepeat:
{
unsigned char char_codes;
UInt32 key_code;
*** static Boolean mac_convert_event_ref (Ev
*** 9214,9220
NULL, &key_code);
if (err == noErr)
{
! eventRec->what = keyDown;
eventRec->message = char_codes | ((key_code & 0xff) << 8);
result = 1;
}
--- 9215,9224
NULL, &key_code);
if (err == noErr)
{
! if (GetEventKind (eventRef) == kEventRawKeyDown)
! eventRec->what = keyDown;
! else
! eventRec->what = autoKey;
eventRec->message = char_codes | ((key_code & 0xff) << 8);
result = 1;
}
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.98 not starting on Solaris 10/I386
I can checkout the latest version from cvs this weekend and see wether the problem is still there. I will inform you about the result. At the moment I do not have the time and knowledge to debug this myself. Sorry! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
