Re: M-\ does not work with prefix argument as documented
Kevin Rodgers [EMAIL PROTECTED] writes: Dieter Wilhelm wrote: Kevin Rodgers [EMAIL PROTECTED] writes: Dieter Wilhelm wrote: ... Thank you for installing your patch. (You did install it, didn't you?) No, I don't have that permission. But RMS posted a similar patch, so I assume that was committed. The main difference was that my patch Yes it was installed. included changes to the doc string and the manual. Yes I realised that and I wondered why he didn't use your patch, maybe he has just overlooked it, I'll ask. ... What I need to know is how could I distinguish in the function whether the user gave a prefix argument '1' or whether it was the default argument '1'? The default argument would mean kill on both sides, the same numerical value would mean just kill to the right. Is it possible to intercept the argument before the (interactive *p) form is evaluated? I think that would be a poor interface: for any command foo that takes a numeric argument, `M-x foo' and `M-1 M-x foo' ought to mean the same thing. Maybe it would be consistent with most Emacs commands with numerical arguments but I don't think of it as a poor interface, because we're gaining an additional choice and I've also an Emacs example where this is practised: C-l (recenter). But yes, you can examine the value of current-prefix-arg, which will be nil in the `M-x foo' case. Great, thank you! I didn't know the variable. -- Best wishes H. Dieter Wilhelm Darmstadt, Germany ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
Eli Zaretskii wrote: Date: Tue, 19 Dec 2006 01:23:18 +0100 From: Lennart Borgman [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org I believe the problem is in comint-dynamic-complete-as-filename. The let variable dirsuffix has a hardcoded /. Maybe a fix could look like this (dirsuffix (cond ((not comint-completion-addsuffix) ) ((not (consp comint-completion-addsuffix)) (if (w32-shell-dos-semantics) \\ /)) but I am not sure at all. Even if this is correct however I think that shell-file-name and explicit-shell-file-name must be made buffer local in the interactive shell buffers. (And did I not mention before that w32-shell-dos-semantics needs to test explicit-shell-file-name too?) I really don't think we should try to open this can of worms now. Let's wait until after the release. As I said this is clearly a bug. Could you please comment on my tentative solution? What do you think can go wrong? My solution also includes adding to shell-mode two lines that makes shell-file-name and explicit-shell-file-name buffer local: (make-local-variable 'list-buffers-directory) (make-local-variable 'explicit-shell-file-name) (make-local-variable 'shell-file-name) I believe steps similar to those are necessary to a solution. This must be done in one form or the other. It might not be sufficient and it might introduce other similar bugs, but that is in my opinion not enough to avoid them, not even now. I will add the above to my patched version, as usual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: scroll-other-window scrolls wrong window for vc-revert-buffer
Richard Stallman [EMAIL PROTECTED] writes: But I don't see it would help in the case of (defalias 'y-or-n-p 'yes-or-no-p) That's the case where nothing works, because y-or-n-p doesn't obey any key-bindings... I don't think we need to regard misbehavior in the case of such drastic user reprogramming as a bug in Emacs itself. Actually, the thing that doesn't work is: (defalias 'yes-or-no-p 'y-or-n-p) Really, what I think is a problem with y-or-n-p is that suppose you have some command which you want the user to confirm (with a simple Y or N), then there's no way for the user to do anything sensible (such as inspect what he's about to confirm) until he has answered the question. This kind of eagerness is a bug IMO. My example was just an example of why, eg. C-x v u MUST use yes-or-no-p rather than y-or-n-p. This difference in functionality isn't clear from the documentation. It only something about using echo-area vs. minibuffer. The doc for y-or-n-p says it uses query-replace-map, so maybe one way to handle at least the case above is to add scroll-up/scroll-down bindings in that map, and let y-or-n-p DTRT for those ...? -- 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: image.el doesn't associate image-mode with .JPG files
On 12/19/06, Kim F. Storm [EMAIL PROTECTED] wrote: Installed. Great. BTW, as `magic-mode-alist' takes precedence over `auto-mode-alist', perhaps we should make some of the regexps in `image-type-header-regexp' somewhat less trigger-happy. I'm thinking mostly of the one for pbm, which matches any file that starts with P[1-6]. I propose the following patch (which also modifies the regexp for PNG to use the full PNG header, according to spec). /L/e/k/t/u Index: lisp/image.el === RCS file: /cvsroot/emacs/emacs/lisp/image.el,v retrieving revision 1.63 diff -u -2 -r1.63 image.el --- lisp/image.el 21 Apr 2006 20:56:06 - 1.63 +++ lisp/image.el 19 Dec 2006 10:40:53 - @@ -36,9 +36,9 @@ (defconst image-type-header-regexps '((\\`/[\t\n\r ]*\\*.*XPM.\\*/ . xpm) -(\\`P[1-6] . pbm) +(\\`P[1-6][[:space:]]+\\(?:#.*[[:space:]]+\\)*[0-9]+[[:space:]]+[0-9]+ . pbm) (\\`GIF8 . gif) -(\\`\211PNG\r\n . png) +(\\`\x89PNG\r\n\x1a\n . png) (\\`[\t\n\r ]*#define . xbm) -(\\`\\(MM\0\\*\\|II\\*\0\\) . tiff) +(\\`\\(?:MM\0\\*\\|II\\*\0\\) . tiff) (\\`[\t\n\r ]*%!PS . postscript) (\\`\xff\xd8 . (image-jpeg-p . jpeg))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sound problem with SUSE x86_64
The output of the pkg-config --cflags alsa is just a single space. -tom Jan Djärv [EMAIL PROTECTED] 12/18/2006 04:33 PM To Tom Wurgler [EMAIL PROTECTED] cc emacs-pretest-bug@gnu.org, [EMAIL PROTECTED] Subject Re: Sound problem with SUSE x86_64 Tom Wurgler skrev: I have SuSE Linux Enterprise 9.1 X86_64. If I just configure with only a prefix, when I run make it fails to compile sound.c, because if can't find asoundlib.h. If I hardcode the path to the file, all compiles fine and sound files play. I changed src/sound.c: #ifdef HAVE_ALSA #include asoundlib.h comment this /* #include /usr/include/alsa/asoundlib.h */ uncomment this #endif Is this just my setup or did configure not find the file correctly? What is the output of % pkg-config --cflags alsa ? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
TRAMP: error when completing filename
run: emacs -Q type: C-x C-f /a:/ TAB see backtrace (I loaded the source of tramp.el to get a better backtrace): Debugger entered--Lisp error: (wrong-number-of-arguments (lambda (filename directory) Like `file-name-completion' for tramp files. (unless (tramp-tramp-file-p directory) (error tramp-handle-file-name-completion invoked on non-tramp directory `%s' directory)) (with-parsed-tramp-file-name directory nil (try-completion filename (mapcar (lambda (x) (cons x nil)) (file-name-all-completions filename directory) 3) tramp-handle-file-name-completion( /a:/ file-exists-p) apply(tramp-handle-file-name-completion ( /a:/ file-exists-p)) (if fn (apply (cdr fn) args) (tramp-run-real-handler operation args)) (let ((fn ...)) (if fn (apply ... args) (tramp-run-real-handler operation args))) (progn (let (...) (if fn ... ...))) (unwind-protect (progn (let ... ...)) (set-match-data save-match-data-internal (quote evaporate))) (let ((save-match-data-internal ...)) (unwind-protect (progn ...) (set-match-data save-match-data-internal ...))) (save-match-data (let (...) (if fn ... ...))) (let ((tramp-locker t)) (save-match-data (let ... ...))) (progn (setq tramp-locked t) (let (...) (save-match-data ...))) (unwind-protect (progn (setq tramp-locked t) (let ... ...)) (setq tramp-locked tl)) (let ((tl tramp-locked)) (unwind-protect (progn ... ...) (setq tramp-locked tl))) tramp-sh-file-name-handler(file-name-completion /a:/ file-exists-p) apply(tramp-sh-file-name-handler file-name-completion ( /a:/ file-exists-p)) (cond ((and completion ...) (tramp-run-real-handler operation args)) ((and completion ... ...) t) (foreign (apply foreign operation args)) (t (tramp-run-real-handler operation args))) (let* ((v ...) (multi-method ...) (method ...) (user ...) (host ...) (localname ...)) (cond (... ...) (... t) (foreign ...) (t ...))) (with-parsed-tramp-file-name filename nil (cond (... ...) (... t) (foreign ...) (t ...))) (let* ((filename ...) (completion ...) (foreign ...)) (with-parsed-tramp-file-name filename nil (cond ... ... ... ...))) (progn (let* (... ... ...) (with-parsed-tramp-file-name filename nil ...))) (unwind-protect (progn (let* ... ...)) (set-match-data save-match-data-internal (quote evaporate))) (let ((save-match-data-internal ...)) (unwind-protect (progn ...) (set-match-data save-match-data-internal ...))) (save-match-data (let* (... ... ...) (with-parsed-tramp-file-name filename nil ...))) tramp-file-name-handler(file-name-completion /a:/ file-exists-p) read-file-name-internal(/usr/local/emacs22/share/emacs/22.0.91/lisp/net//a:/ /usr/local/emacs22/share/emacs/22.0.91/lisp/net/ nil) minibuffer-complete() call-interactively(minibuffer-complete) read-file-name(Find file: nil /usr/local/emacs22/share/emacs/22.0.91/lisp/net/ nil) find-file-read-args(Find file: nil) call-interactively(find-file) In GNU Emacs 22.0.91.34 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-12-19 on chrislap X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--prefix' '/usr/local/emacs22' '--with-xpm' '--with-jpeg' '--with-png' '--with-gif'' Important settings: value of $LC_ALL: en_GB.UTF-8 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: en_GB.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Improper switching to article buffer in Gnus
Chris Moore [EMAIL PROTECTED] writes: Michael Welsh Duggan [EMAIL PROTECTED] writes: * View the attachment inline using `2 K i'. The window containing the Article buffer is now selected, rather than the prior selected window (containing the Summary buffer). I don't see that. For me, the Summary window remains selected whether I click the link or type 2 K i. Could it be something in your .emacs file which is causing this? I should have check my `list-load-path-shadows' output. I forgot that on this installation I was using a different (more recent) version of gnus. I will take this up with the gnus people. Thanks. -- Michael Welsh Duggan ([EMAIL PROTECTED]) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
Juanma Barranquero [EMAIL PROTECTED] writes: BTW, as `magic-mode-alist' takes precedence over `auto-mode-alist', perhaps we should make some of the regexps in `image-type-header-regexp' somewhat less trigger-happy. I'm thinking mostly of the one for pbm, which matches any file that starts with P[1-6]. I propose the following patch (which also modifies the regexp for PNG to use the full PNG header, according to spec). Yes, it seems quite necessary to do this. -- 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: Directory name completion blocks when it shouldn't
Richard Stallman [EMAIL PROTECTED] writes: Is it feasible to fix read-file-name to obey the predicate in the completion case? It could be that the reason it doesn't do so was the difficulty of implementing that case efficiently. Since no one else seemed interested in this, I did it. I think you've introduced a new bug - lisp/net/ange-ftp.el.gz line 3980: (defun ange-ftp-file-name-completion (file dir) is being called like: (ange-ftp-file-name-completion /a:/ 'file-exists-p) and lisp/net/tramp.el.gz line 2859: (defun tramp-handle-file-name-completion (filename directory) is being called like: (tramp-handle-file-name-completion /a:/ 'file-exists-p) in both cases the functions expect 2 arguments, and they're being passed 3. I reported this earlier today: Message-Id: [EMAIL PROTECTED] To: emacs-pretest-bug@gnu.org Subject: TRAMP: error when completing filename without realising that this was related to the recent Directory name completion blocks when it shouldn't fix. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adieu *scratch*
Dan Jacobson [EMAIL PROTECTED] writes: Nope, it's time the *scratch* buffer should go for experienced user me. (kill-buffer *scratch*);in .emacs I don't see what you're doing with that. AFAIK, the *scratch* buffer never dies, never surrenders. If the default Lisp mode is not your cup of tea, you can change it, AYK :-) OK, that wasn't too hard. Anyway, there are plenty of variables regarding the *scratch* buffer but none to not create it in the first place. Wonder if it is at all possible to not have this buffer, AFAICS, plenty of code depends on it. The above humor is intended to keep me plopular. Sure you are ;-) -- /!\ My mail address has changed, please update your files accordingly. | Michaël `Micha' Cadilhac | (\(\ This is the cute bunny virus, | | Epita/LRDE Promo 2007 | (^.^) please copy this into your | | http://michael.cadilhac.name | ()) sig so it can spread. | `--JID: [EMAIL PROTECTED]' - --' pgpX8OjLTmD7C.pgp Description: PGP signature ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sound problem with SUSE x86_64
[EMAIL PROTECTED] skrev: The output of the pkg-config --cflags alsa is just a single space. That is not right, it should be -I/usr/include/alsa. Maybe I can do a configure.in test for this brokeness. Jan D. ___ 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
I think it's a bug: it looks like Emacs doesn't support the new format of Index menus introduced with the latest versions of Texinfo. Let me rephrase: Emacs doesn't _fully_ support the new format. Specifically, `m', `f', TAB, and RET work, but the link face, mouse highlight and related features don't. 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. (Look for the relevant line `(not (Info-index-node))' in `Info-fontify-node' and the user option `Info-fontify-maximum-menu-size'.) -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP password caching
Again, can we go back to using `ssh' rather than `scp', so that the default behavior is reliable? Maybe it's not perfect, but neither is `scp' and at least `ssh' is the safe choice. The recent problem is not because ssh or scp being the default, but because I've added ssh options which seem not to be common. I'm working on. You've added those options specifically to try and make `scp' less painful to use. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: TRAMP password caching
The check for the default method chooses scp only in case password.el is loaded or ssh-agent is running, otherwise it takes ssh. This should be robust. That sounds good, thank you. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Build problem with temacs
From: Eli Zaretskii [EMAIL PROTECTED] To: Lennart Borgman [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org; Francis Wright [EMAIL PROTECTED] Sent: Tuesday, December 19, 2006 4:18 AM Subject: Re: Build problem with temacs Date: Tue, 19 Dec 2006 00:55:50 +0100 From: Lennart Borgman [EMAIL PROTECTED] CC: Sven Axelsson [EMAIL PROTECTED], emacs-pretest-bug@gnu.org FYI cacls.exe comes with Windows. Thanks, but Francis needs first to tell me that he can use cacls to resolve the weird problem he had with executable permissions of temacs. Then I could add a call to cacls to the appropriate Makefile. Thanks for the suggestion. If I hit the problem again and am able to solve it by running cacls (or some similar command) then I'll let you know. ___ 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
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
Re: Shell completion on w32 uses / instead of \
Stefan Monnier wrote: My solution also includes adding to shell-mode two lines that makes shell-file-name and explicit-shell-file-name buffer local: (make-local-variable 'list-buffers-directory) (make-local-variable 'explicit-shell-file-name) (make-local-variable 'shell-file-name) I guess I lack the big-picture here: to me, the above three lines can never be the right fix for anything. At best, they may be acceptable workarounds in some special cases. `make-local-variable' to me only makes sense when followed pretty much immediately by `set' or `setq' on the same variable. I do not know about the first line, it was there before. However I know about the other two. The situation on w32 regarding shells is quite complicated, but I believe that part of what I have seen could apply to other platforms as well. Since there are many shells to use (at least on w32) and you in a case like completion wants to do it for the shell you are actually using in the interactive shell buffer (*Shell*) you need to know which shell is used in that particular buffer (or rather how completion should be done of course). A structured way to handle this is needed. How that structured way should look is a bit more complicated to tell. I preferred to make those variables local in just the interactive shell buffers. That would lead to a minimal disruption since their use there is very limited I believe. The bad thing about this is that this situation was not foreseen before. There is no notion about how to handle situations like this and the exact use of these variables. I suspect however that there are other similar cases where these variables should be buffer local so does it not seem like they simply should be made local with make-variable-buffer-local? There might be other situations when you need to know which shell is used. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
segmentation fault
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: Emacs crashes now and then at random without reason. The error code is: Segmentation fault - Error 11 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 /usr/share/emacs/22.0.50/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) of 2006-12-18 on ritzos.de X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure '--with-gtk' '--with-xft' '--x-includes=/usr/include/X11' '--x-libraries=/usr/lib/X11' '--prefix=/usr/' '--with-jpeg' '--with-tiff' '--with-xpm' '--with-png' '--with-gif'' 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: de_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Completion List Minor modes in effect: TeX-source-specials-mode: t display-time-mode: t desktop-save-mode: t tooltip-mode: t auto-compression-mode: t mouse-wheel-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: escape x C-g escape x e c b - d e tab a tab return f4 escape x r e o backspace p o tab r tab b u tab return Recent messages: The ECB is now activated. There are no NEWS to display. Desktop: 1 buffer restored. Loading semantic-el...done Quit Making completion list... Loading eieio-opt...done The ECB is now deactivated. Making completion list... Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
My solution also includes adding to shell-mode two lines that makes shell-file-name and explicit-shell-file-name buffer local: (make-local-variable 'list-buffers-directory) (make-local-variable 'explicit-shell-file-name) (make-local-variable 'shell-file-name) I guess I lack the big-picture here: to me, the above three lines can never be the right fix for anything. At best, they may be acceptable workarounds in some special cases. `make-local-variable' to me only makes sense when followed pretty much immediately by `set' or `setq' on the same variable. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: segmentation fault
* Harry Meyers (2006-12-19 11:39 +0100) said: Emacs crashes now and then at random without reason. The error code is: Segmentation fault - Error 11 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 /usr/share/emacs/22.0.50/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.20) Before the developers see your bug report, you might want to try version 22.0.92: ftp://alpha.gnu.org/gnu/emacs/pretest/emacs-22.0.92.tar.gz -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
How that structured way should look is a bit more complicated to tell. I preferred to make those variables local in just the interactive shell buffers. Where are the `setq's affected by the `make-local-variable' calls? Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
Stefan Monnier wrote: How that structured way should look is a bit more complicated to tell. I preferred to make those variables local in just the interactive shell buffers. Where are the `setq's affected by the `make-local-variable' calls? Anywhere. The point is that those variables may change during the time the interactive shell exists (or perhaps a non-interactive shell). In this case I noticed it because the file completion code needs to know the value of shell-file-name. If shell-file-name is set globally somewhere to something different from that in the shell buffer things may fail (as they did here). I hope I am clear enough. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't display Japanese text in menu bar
In [EMAIL PROTECTED] Katsumi Yamaoka wrote: (let ((japanese (decode-coding-string \e$B%F%9%H\e(B 'iso-2022-jp))) (easy-menu-define testing-menu global-map Testing. `(Testing [,japanese (lambda nil (interactive) (message ,japanese)) t])) (easy-menu-add testing-menu global-map)) In [EMAIL PROTECTED] Kenichi Handa wrote: I found a way to reproduce this problem. I have this X resource: *fontSet: -*-*-medium-r-normal--16-*-*-* (I had removed all the X resources for Emacs because I wanted to have a real vanilla Emacs, which can be launched by only the -q option. I will configure it in the ~/.emacs file even if I need to use customized ones. Although I have only two fontsets since I don't know how to do it, I don't feel inconvenience with them.) When I remove the resource and run Emacs, I see incorrect menu label, and (set-face-font 'menu (face-font 'menu)) surely make the label displayed correctly. Thank you for verifying it. And, starting emacs with: % emacs -xrm '*fontSet: -*-*-medium-r-normal--16-*-*-*' also displays the menu label correctly. Please try it by yourself. I confirmed it makes Emacs display Japanese menu. Anyway, I suspect that somehow the menu widget is not created with a correct fontset. Though, I have not yet investigated the problem deeper. I hope it is fixed in Emacs 22.2 or 23. ;-) Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: image.el doesn't associate image-mode with .JPG files
Richard Stallman wrote: The answer is no, and I've chosen a different solution. Please drop the subject. If a developers mailing list cannot be used for discussing development ideas, then I think I might as well unsubscribe. Discussing an idea in a useful way does not include continuing to pressure me after I've made a decision. I'm sorry if you felt pressured, but it seemed premature to dismiss my suggestion the first time you did so, as the only alternative proposal offered was an incomplete regexp that did not cover all jpeg files. Kim and others since refined it into a better solution, and I agree that solution is a better one for most image files. I still think there is a general underlying bug here though that is not specific to image files, but to transfer of files from sources that do not preserve case (ISO format CDs, DOS/Windows machines, SD Cards, floppy disks etc). But you seem to think it is more important not to use sh-mode for .LOGIN than it is to fix this bug, so I will leave it alone now. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Documentation error `tramp-default-method-alist'
Michael Welsh Duggan [EMAIL PROTECTED] writes: The documentation for `tramp-default-method-alist' is: *Default method to use for specific user/host pairs. This is an alist of items (HOST USER METHOD). The first matching item specifies the method to use for a file name which does not specify a method. HOST and USER are regular expressions or nil, which is interpreted as a regular expression which always matches. If no entry matches, the variable `tramp-default-method' takes effect. However, specifying nil for host or user causes an error. I've fixed that. Both and nil shall work now. Best regards, Michael. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Directory name completion blocks when it shouldn't
Chris Moore [EMAIL PROTECTED] writes: I think you've introduced a new bug - lisp/net/ange-ftp.el.gz line 3980: (defun ange-ftp-file-name-completion (file dir) is being called like: (ange-ftp-file-name-completion /a:/ 'file-exists-p) and lisp/net/tramp.el.gz line 2859: (defun tramp-handle-file-name-completion (filename directory) is being called like: (tramp-handle-file-name-completion /a:/ 'file-exists-p) in both cases the functions expect 2 arguments, and they're being passed 3. Shall be fixed now in both ange-ftp.el and tramp.el. Best regards, Michael. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
Date: Tue, 19 Dec 2006 09:16:42 +0100 From: Lennart Borgman [EMAIL PROTECTED] CC: emacs-pretest-bug@gnu.org X-Spam-Status: No, score=0.5 required=5.0 tests=FROM_ENDS_IN_NUMS autolearn=no version=3.0.4 Eli Zaretskii wrote: Date: Tue, 19 Dec 2006 01:23:18 +0100 From: Lennart Borgman [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org I believe the problem is in comint-dynamic-complete-as-filename. The let variable dirsuffix has a hardcoded /. Maybe a fix could look like this (dirsuffix (cond ((not comint-completion-addsuffix) ) ((not (consp comint-completion-addsuffix)) (if (w32-shell-dos-semantics) \\ /)) but I am not sure at all. Even if this is correct however I think that shell-file-name and explicit-shell-file-name must be made buffer local in the interactive shell buffers. (And did I not mention before that w32-shell-dos-semantics needs to test explicit-shell-file-name too?) I really don't think we should try to open this can of worms now. Let's wait until after the release. As I said this is clearly a bug. Could you please comment on my tentative solution? What do you think can go wrong? My solution also includes adding to shell-mode two lines that makes shell-file-name and explicit-shell-file-name buffer local: (make-local-variable 'list-buffers-directory) (make-local-variable 'explicit-shell-file-name) (make-local-variable 'shell-file-name) I believe steps similar to those are necessary to a solution. This must be done in one form or the other. It might not be sufficient and it might introduce other similar bugs, but that is in my opinion not enough to avoid them, not even now. I will add the above to my patched version, as usual. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Shell completion on w32 uses / instead of \
Date: Tue, 19 Dec 2006 09:16:42 +0100 From: Lennart Borgman [EMAIL PROTECTED] CC: emacs-pretest-bug@gnu.org I really don't think we should try to open this can of worms now. Let's wait until after the release. As I said this is clearly a bug. I heard what you said, and I obviously disagree that it's a clear bug. It is no more a bug than the fact that Emacs uses only forward slashes in file-name completion in the minibuffer, even on Windows. In other words, you are arguing for a new feature. While I'm not opposed to having such a feature, now is not the time to introduce new features. Could you please comment on my tentative solution? I believe I already have commented on it, see the citation from my original message above: I don't want us to mess with this so close to a release. What do you think can go wrong? Everything. As you yourself point out, the situation with w32 shells is complicated and fragile. What else should be said to convince you that now is not the time to mess with it? I will add the above to my patched version, as usual. Sigh... That's how the XEmacs fork started, you know... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't display Japanese text in menu bar
In article [EMAIL PROTECTED], Katsumi Yamaoka [EMAIL PROTECTED] writes:
Anyway, I suspect that somehow the menu widget is not
created with a correct fontset. Though, I have not yet
investigated the problem deeper.
I found what is wrong. In x_load_resources (xrdb.c),
default values of several X resources are set, but fontSet
is not set. But, in x_update_menu_appearance (xfaces.c)
which is called when you set `menu' face, the fontSet
resource is set. That's why executing
(set-face-font 'menu (face-font 'menu))
makes the menu label display correctly.
I hope it is fixed in Emacs 22.2 or 23. ;-)
I've just installed the attached patch for 23
(emacs-unicode-2 branch). Could you please confirm that the
change surely fixes the problem in your environment too?
By the way, I think the relevant code should be improved to
reflect a font specified for menu bar in a created fontset,
but, for the moment, I don't have a time to work on it,
sorry.
---
Kenichi Handa
[EMAIL PROTECTED]
2006-12-20 Kenichi Handa [EMAIL PROTECTED]
* xrdb.c (x_load_resources): Setup the default fontSet X reource.
Index: xrdb.c
===
RCS file: /cvsroot/emacs/emacs/src/xrdb.c,v
retrieving revision 1.48.8.8
retrieving revision 1.48.8.9
diff -u -r1.48.8.8 -r1.48.8.9
--- xrdb.c 17 Apr 2006 08:40:56 - 1.48.8.8
+++ xrdb.c 20 Dec 2006 07:07:13 - 1.48.8.9
@@ -610,6 +610,29 @@
#endif /* not USE_MOTIF */
+#ifdef HAVE_X_I18N
+ {
+#ifdef USE_MOTIF
+Bool motif = True;
+#else /* not USE_MOTIF */
+Bool motif = False;
+#endif /* not USE_MOTIF */
+/* Setup the default fontSet resource. */
+extern char *xic_create_fontsetname P_ ((char *base_fontname, Bool motif));
+char *fontsetname = xic_create_fontsetname (helv, motif);
+int len = strlen (fontsetname);
+char *buf = line;
+
+/* fontsetname may be very long. */
+if (len + 16 256)
+ buf = alloca (len + 16);
+sprintf (buf, Emacs*fontSet: %s, fontsetname);
+XrmPutLineResource (rdb, buf);
+if (fontsetname != helv)
+ xfree (fontsetname);
+ }
+#endif /* HAVE_X_I18N */
+
user_database = get_user_db (display);
/* Figure out what the customization string is, so we can use it
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
