Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
From: Richard Stallman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Date: Tue, 26 Dec 2006 12:22:34 -0500 ** Most important: - Alt-Tab, Alt-Shift-Tab - Ctrl-Esc, Ctrl-Shift-Esc - Ctrl-Alt-Delete - Ctrl-Tab, Ctrl-Shift-Tab - Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-Z - Ctrl-A - Alt-Space - Esc - Tab, Shift-Tab That is really disastrous. I am surprised anyone can find Emacs useful on Windows if it interferes with such important keys. People find Emacs useful on Windows because, with the exception of the first 5, ALL of these keys are available in Emacs. Lennart is simply mistaken. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Eli Zaretskii wrote: From: Richard Stallman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Date: Tue, 26 Dec 2006 12:22:34 -0500 ** Most important: - Alt-Tab, Alt-Shift-Tab - Ctrl-Esc, Ctrl-Shift-Esc - Ctrl-Alt-Delete - Ctrl-Tab, Ctrl-Shift-Tab - Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-Z - Ctrl-A - Alt-Space - Esc - Tab, Shift-Tab That is really disastrous. I am surprised anyone can find Emacs useful on Windows if it interferes with such important keys. People find Emacs useful on Windows because, with the exception of the first 5, ALL of these keys are available in Emacs. Lennart is simply mistaken. Or, perhaps, you are misunderstanding what I wrote. But I admit I was not very clear. I wanted to point out that we should mention these clashes with the UI guidelines on w32. That would make it easier for new users IMO. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Date: Wed, 27 Dec 2006 12:02:14 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wanted to point out that we should mention these clashes with the UI guidelines on w32. Done. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Eli Zaretskii wrote: Date: Wed, 27 Dec 2006 12:02:14 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wanted to point out that we should mention these clashes with the UI guidelines on w32. Done. Thanks, but where? I just grabbed the latest CVS but I think it still seems hard to find. The node in info mentioned in the subject line focus on how to fix things within Emacs. A new user first have to know the clashes IMO. Then he/she can start to search for solutions (or adapt ;-). I still believe a node about Emacs and the Platform GUI (or whatever the name should be) would be good for new users (and for developers too, to help think about the subject). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Date: Wed, 27 Dec 2006 14:56:51 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Eli Zaretskii wrote: Date: Wed, 27 Dec 2006 12:02:14 +0100 From: Lennart Borgman (gmail) [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org I wanted to point out that we should mention these clashes with the UI guidelines on w32. Done. Thanks, but where? In the section that is in the subject, where else? That section is about keyboard peculiarities on Windows, so it sounds pretty much obvious to me that the right place is there. I just grabbed the latest CVS but I think it still seems hard to find. Where did you look? The text I added is right in the second paragraph of the section. I still believe a node about Emacs and the Platform GUI (or whatever the name should be) would be good for new users (and for developers too, to help think about the subject). I don't mind, but Richard and Jan are still discussing that, and the Windows related peculiarities are a somewhat different issue. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Eli Zaretskii wrote: Where did you look? The text I added is right in the second paragraph of the section. Thanks, I see it now. It is good, but it is too terse I believe. However placing it at the beginning of the node as you did is a good idea. I still believe a node about Emacs and the Platform GUI (or whatever the name should be) would be good for new users (and for developers too, to help think about the subject). I don't mind, but Richard and Jan are still discussing that, and the Windows related peculiarities are a somewhat different issue. Ok. Yes, IMO we should divide between the platform GUI mismatch and how to try to solve it. With reference links between of course. My reason for this is too hard to understand especially for beginners otherwise. In other words: there must be an overview before the details. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python-mode.el doesn't associate python-mode with .PY files
I'm browsing some old Python sources on a CD, and they're all opening in fundamental-mode instead of python-mode. All the filenames on the CD are in uppercase. Perhaps python-mode.el could be modified to recognise .PY files as well as .py files as containing Python code? That's not a bug, that's a feature! But you can work around it in your ~/.emacs: (setq auto-mode-alist (cons '(\\.PY\\' . python-mode) auto-mode-alist)) It's at the very best a misfeature. Far from a feature. See sample patch below to fix this problem. Stefan --- orig/lisp/files.el +++ mod/lisp/files.el @@ -2234,15 +2234,22 @@ (setq name (file-name-sans-versions name)) (while name ;; Find first matching alist entry. - (let ((case-fold-search - (memq system-type '(vax-vms windows-nt cygwin - (if (and (setq mode (assoc-default name auto-mode-alist -'string-match)) - (consp mode) - (cadr mode)) - (setq mode (car mode) - name (substring name 0 (match-beginning 0))) - (setq name))) +(if (and (setq mode + (or (unless (memq system-type '(vax-vms windows-nt cygwin)) + ;; First match case-sensitively if the + ;; system is case-sensitive. + (let ((case-fold-search nil)) + (assoc-default name auto-mode-alist + 'string-match))) + ;; Fallback to case-insensitive match. + (let ((case-fold-search t)) + (assoc-default name auto-mode-alist +'string-match + (consp mode) + (cadr mode)) +(setq mode (car mode) + name (substring name 0 (match-beginning 0))) + (setq name)) (when mode (set-auto-mode-0 mode keep-mode-if-same) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ffap not UTF-8 ready
Dan Jacobson wrote: ffap is not UTF-8 ready, I put the cursor on ./首頁 or whatever and it acts like the file Doesn't exist. This was discussed back in October, but the agreed-upon solution was never implemented: http://lists.gnu.org/archive/html/emacs-devel/2006-10/msg00037.html -- Kevin ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Dired:: mouse 1: visit this file in other window
Richard Stallman wrote: Perhaps there is a compelling reason to provide this new capability to the left mouse button, such as an attempt to accommodate those with a 2-button mouse. The compelling reason is compatibility with lots of other applications. For that reason, the changes you've proposed simply won't do. They would break the compatibility we are trying to achieve I understand. But it would be nice if one small customization option for this feature were added. Among the many applications I use, which follow links with a single mouse-1 click, I recently observed that they fall into two groups, each handling this behavior in one of two slightly different ways: (1) Follow link whenever mouse-1 is clicked while it is over link, with no exceptions; or (2) Follow link when mouse-1 is clicked while it is over link ONLY IF the window is the current selected window, otherwise, simply select the window. Emacs 22 implements the first as its default behavior. But I, and I suspect others, would prefer to have the option to customize Emacs to exhibit the second behavior. (By the way, in Emacs, I'm using selected window to mean the Emacs window with the active cursor.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: python-mode.el doesn't associate python-mode with .PY files
Stefan Monnier [EMAIL PROTECTED] writes: It's at the very best a misfeature. Far from a feature. See sample patch below to fix this problem. This code is exactly what we need! It is simple, localized, easy to document, and have no really severe effects if it guesses wrong - as the worst effect of a wrong choice is to not to enter fundamental-mode (which is usually pretty useless). In contrast, the recognize images by file contents approach has already required three rounds of bug-fixing ... and there's no guarantee that there are not more surprises... I strongly support installing this, _and_ reverting the recent image-mode related patches which would no longer be needed with this patch. Stefan --- orig/lisp/files.el +++ mod/lisp/files.el @@ -2234,15 +2234,22 @@ (setq name (file-name-sans-versions name)) (while name ;; Find first matching alist entry. - (let ((case-fold-search -(memq system-type '(vax-vms windows-nt cygwin - (if (and (setq mode (assoc-default name auto-mode-alist - 'string-match)) -(consp mode) -(cadr mode)) - (setq mode (car mode) - name (substring name 0 (match-beginning 0))) - (setq name))) +(if (and (setq mode + (or (unless (memq system-type '(vax-vms windows-nt cygwin)) + ;; First match case-sensitively if the + ;; system is case-sensitive. + (let ((case-fold-search nil)) + (assoc-default name auto-mode-alist + 'string-match))) + ;; Fallback to case-insensitive match. + (let ((case-fold-search t)) + (assoc-default name auto-mode-alist +'string-match + (consp mode) + (cadr mode)) +(setq mode (car mode) + name (substring name 0 (match-beginning 0))) + (setq name)) (when mode (set-auto-mode-0 mode keep-mode-if-same) -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
People find Emacs useful on Windows because, with the exception of the first 5, ALL of these keys are available in Emacs. Do you mean these: ** Most important: - Alt-Tab, Alt-Shift-Tab - Ctrl-Esc, Ctrl-Shift-Esc - Ctrl-Alt-Delete As far as I know, the only one of those which Emacs actually expects to use is M-TAB. Is M-TAB the only such problem on MS Windows? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Or, perhaps, you are misunderstanding what I wrote. But I admit I was not very clear. I wanted to point out that we should mention these clashes with the UI guidelines on w32. We spit on Windows' guidelines. Emacs came first! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [bug] Gnus weird behavior
Can you install your patch in the Emacs sources? If so, please do. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: read-file-name misbehavior
Thansk for reporting this. I will add something to etc/NEWS. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [bug] Gnus weird behavior
On Tue, Dec 26 2006, Daiki Ueno wrote: In [EMAIL PROTECTED] Leo [EMAIL PROTECTED] wrote: To reproduce: - go to the article buffer - click the right arrow in the toolbar Backtrace: , | Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil) | gnus-summary-next-article(nil) | call-interactively(gnus-summary-next-article) ` The cause of the problem seems that gnus-article-mode uses gnus-summary-mode's tool-bar-map and a few commands in it expect to be called from the summary buffers. [...] Here is a patch. Would you please install your patch in the v5-10 branch? Or do you or anyone else see a problem with it or a better fix? Index: lisp/gnus/gnus-sum.el === RCS file: /sources/emacs/emacs/lisp/gnus/gnus-sum.el,v retrieving revision 1.96 diff -c -r1.96 gnus-sum.el --- lisp/gnus/gnus-sum.el 12 Dec 2006 16:12:12 - 1.96 +++ lisp/gnus/gnus-sum.el 26 Dec 2006 01:12:40 - @@ -7333,6 +7333,9 @@ If SUBJECT, only articles with SUBJECT are selected. If BACKWARD, the previous article is selected instead of the next. (interactive P) + ;; Make sure we are in the summary buffer. + (unless (eq major-mode 'gnus-summary-mode) +(set-buffer gnus-summary-buffer)) (cond ;; Is there such an article? ((and (gnus-summary-search-forward unread subject backward) Bye, Reiner. -- ,,, (o o) ---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Richard Stallman wrote: Or, perhaps, you are misunderstanding what I wrote. But I admit I was not very clear. I wanted to point out that we should mention these clashes with the UI guidelines on w32. We spit on Windows' guidelines. Emacs came first! Could one say that the dinosaurouses did not really fit into the new UI guidelines on the earth? Except for those that adopted and became birds of course. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
(replace-regexp-in-string ...) gets a weird result.
--text follows this line-- Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: == *Test Cases:* * -- * * (defun test (f) (prin1 (replace-regexp-in-string %[a-zA-Z0-9][a-zA-Z0-9] (lambda (arg) (let ((str (make-string 1 0))) (aset str 0 (string-to-number (substring arg 1) 16)) str)) f nil t)))* * (test %C8%EB) ;;case 1 (test %c8%eb) ;;case 2* * - * in each test case, the lambda function will be called twice and the return value is in the following table: - %C8 %EB case 1\310 \353 case 2\310 \353 -- both get the same result, but the return value of the (replace-regexp-in-string ...) is different: -- case1 \310\313 case2 \310\353 -- === 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 d:/ntemacs23/etc/DEBUG for instructions. In GNU Emacs 23.0.0.1 (i386-mingw-nt5.1.2600) of 2006-12-22 on MACROSS-GG9FRPF X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.2)' 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: ENU value of $XMODIFIERS: nil locale-coding-system: cp936 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: show-paren-mode: t encoded-kbd-mode: t tooltip-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 global-auto-composition-mode: t auto-composition-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent input: help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu re port-emacs-bug Recent messages: (D:\ntemacs23\bin\emacs.exe) Loading encoded-kb...done Toggling tool-bar-mode off; better pass an explicit argument. Loading paren...done Loading edmacro...done Loading cl-macs...done For information about the GNU Project and its goals, type C-h C-p. 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: python-mode.el doesn't associate python-mode with .PY files
On 12/27/06, Kim F. Storm [EMAIL PROTECTED] wrote: In contrast, the recognize images by file contents approach has already required three rounds of bug-fixing ... and there's no guarantee that there are not more surprises... Well, I think that's not entirely fair. Patches for that approach have conflated several different things: - The possibility of adding matcher functions to `magic-mode-alist'. That's good IMO. - Fixes to regexps in `image-type-header-regexps'. These are good too. ^P[1-6] matching PBM files would be over-eager even if `image-type-from-buffer' were not added to `magic-mode-alist'. - Adding `image-type-from-buffer' to `magic-mode-alist'. That's not good because there is one type of file (postscript) whose interpretation is ambiguous under that function. The right approach would be to add to `magic-mode-alist' a function specifically designed to detect images; it should also take into account `image-type-available-p' (it never makes sense to identify a .ps file as an image on Windows, for example, as the Windows port does not support postscript images). - Modifying `image-type-header-regexps' to support NOT-ALWAYS. Not good IMO because it adds interface complexity just to fix one case. I strongly support installing this, _and_ reverting the recent image-mode related patches which would no longer be needed with this patch. Not entirely true. Someone noted that he wanted Emacs to autodetect JPEG thumb files that had no recognizable extension, for example. That's not fixed by Stefan's patch (which I think is good, BTW). I think a good approach would be to add Stefan patch, remove the NOT-ALWAYS stuff and fix `magic-mode-alist' to use a function specifically designed to detect image types. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
make-frame doesn't create frame parameters it is passed
emacs -Q 1. make-frame does not respect frame parameters that are not known: (make-frame '((foo . 45))) The manual seems to support this, saying: The set of possible parameters depends in principle on what kind of window system Emacs uses to display its frames. *Note Window Frame Parameters::, for documentation of individual parameters you can specify. Why doesn't make-frame just create all parameters you give it? Programs can add any parameters they want using modify-frame-parameters, so why are only some parameters respected by make-frame? 2. In particular, if you want to add a frame-local variable, you can't just do this: (make-frame-local-variable 'foo) (make-frame '((foo . 45)...)); with lots of other frame parameters. Instead, you must do something like this: (make-frame-local-variable 'foo) (modify-frame-parameters (make-frame '(...)) ; with the other frame paramters '((foo . 45))) I'd call this non-respect of arbitrary frame parameters by make-frame a bug. If you don't agree, please consider my suggestion as an enhancement request: Change make-frame so that it adds all frame parameters the user specifies. In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-11 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' 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: ENU locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Emacs-Lisp 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: help-echo help-echo help-echo help-echo switch-frame help-echo help-echo help-echo switch-frame help-echo down-mouse-1 mouse-movement mouse-1 down-mouse-1 mouse-1 return ( m o d i f y - f r a m e - p a r e m e backspace backspace backspace a m e t e r s SPC n i l SPC down-mouse-1 mouse-movement mouse-movement drag-mouse-1 down-mouse-2 mouse-2 down-mouse-1 mouse-1 C-d 5 5 5 C-e backspace ) C-x C-e down M-x p p - e v a l - l a s t return help-echo down-mouse-1 mouse-1 down-mouse-1 mouse-1 help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Mark set foo #frame [EMAIL PROTECTED] 0x140fa00 ((parent-id) (display . ) (visibility . t) (icon-name) (window-id . 2426810) (top . 116) (left . 88) (buffer-list #buffer *scratch* #buffer *Minibuf-1*) (unsplittable) (minibuffer . #window 7 on *Minibuf-0*) (modeline . t) (width . 80) ...) [2 times] Loading pp...done Loading help-mode...done Quit [3 times] Mark set nil Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: cursor-color frame parameter cannot equal background-color
Put these sexps in buffer *scratch*: 1. (setq default-frame-alist '((foreground-color . Blue) (mouse-color . Red) (cursor-color . Red))) 2. (modify-frame-parameters (selected-frame) '(;;(background-color . Black) (cursor-color . Black))) Eval #1. C-x 5 2 to create a new frame. The new frame's cursor color is Red Eval #2 (in the new frame). The new frame's cursor is now black - no problem. Delete the new frame. Uncomment the background-color in #2. Eval #1 again and C-x 5 2 to create a new frame. Eval #2 (in the new frame). The new frame's cursor is still red - the spec change had no effect in this regard. This is the main bug. It is not a bug, it is intentionally coded in x_set_cursor_color. It is trying to avoid making the cursor invisible because of a careless choice of colors. Actually, since I filed that bug, I found a way around it. However, I still would prefer that there be some way to prevent x_set_cursor_color or whatever from being so smart in particular contexts. AFAIK, there is nothing preventing you from setting the foreground and background colors to be the same. I would prefer the same for the cursor, foreground, background, and pointer colors. At least let Lisp programs override this prohibition somehow. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Character shown as \377 in *Shell* on w32
In *Shell* using cmdproxy.exe on w32 a character shows up as \377: 2006-12-10 16:14 6\377588\377879 emacs.exe To reproduce emacs -Q M-x shell C:\emacs\bin dir In GNU Emacs 22.0.91.1 (i386-mingw-nt5.1.2600) of 2006-12-10 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Character shown as \377 in *Shell* on w32
Date: Thu, 28 Dec 2006 04:22:40 +0100 From: Lennart Borgman [EMAIL PROTECTED] In *Shell* using cmdproxy.exe on w32 a character shows up as \377: 2006-12-10 16:14 6\377588\377879 emacs.exe I cannot reproduce this with your recipe. What is shown by DIR outside Emacs on this line? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
From: Richard Stallman [EMAIL PROTECTED] CC: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Date: Wed, 27 Dec 2006 16:16:27 -0500 People find Emacs useful on Windows because, with the exception of the first 5, ALL of these keys are available in Emacs. Do you mean these: ** Most important: - Alt-Tab, Alt-Shift-Tab - Ctrl-Esc, Ctrl-Shift-Esc - Ctrl-Alt-Delete As far as I know, the only one of those which Emacs actually expects to use is M-TAB. Is M-TAB the only such problem on MS Windows? Yes. And the same happens with other window managers on Posix systems, so I think this issue should be described as a general problem with window managers. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Eli Zaretskii [EMAIL PROTECTED] writes: to use is M-TAB. Is M-TAB the only such problem on MS Windows? Yes. And the same happens with other window managers on Posix systems, so I think this issue should be described as a general problem with window managers. Yeah, all the window managers I use steal M-TAB too (and the function they use it for is very useful, so I think it's fair to let them have it). -Miles -- [|nurgle|] ddt- demonic? so quake will have an evil kinda setting? one that will make every christian in the world foamm at the mouth? [iddt] nurg, that's the goal ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
