Re: [bug] Gnus weird behavior
In [EMAIL PROTECTED] Reiner Steib [EMAIL PROTECTED] wrote: 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? Done. Though it might be better to provide a new tool-bar-map for gnus-article-mode, such a change should be first introduced to the development branch of Gnus, I think. Regards, -- Daiki Ueno ___ 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
Eli Zaretskii wrote: 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? It is actually from a directory list where emacs.exe is shown: 2006-12-10 16:14 6 588 879 emacs.exe ___ 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
Lennart Borgman (gmail) wrote: In *Shell* using cmdproxy.exe on w32 a character shows up as \377: 2006-12-10 16:14 6\377588\377879 emacs.exe It is actually from a directory list where emacs.exe is shown: 2006-12-10 16:14 6 588 879 emacs.exe It seems you have set your thousands separator to be a non-breaking space, and cmd.exe is using cp850 or cp437 for its output, while Emacs is expecting windows-1252 or iso8859-1. ___ 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
Jason Rumney wrote: Lennart Borgman (gmail) wrote: In *Shell* using cmdproxy.exe on w32 a character shows up as \377: 2006-12-10 16:14 6\377588\377879 emacs.exe It is actually from a directory list where emacs.exe is shown: 2006-12-10 16:14 6 588 879 emacs.exe It seems you have set your thousands separator to be a non-breaking space, and cmd.exe is using cp850 or cp437 for its output, while Emacs is expecting windows-1252 or iso8859-1. I am not sure, but the non-breaking space is then probably coming from Control Panel - Regional and Language Options - Regional Options (tab) - Standard and Formats - Number (on Windows XP). I can think of nothing else I have changed in this area. Then this is the normal condition for many pc:s in Sweden. Where do I found the codepage used by cmd.exe? What should Emacs do in this situation? ___ 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
In article [EMAIL PROTECTED], Lennart Borgman (gmail) [EMAIL PROTECTED] writes: It seems you have set your thousands separator to be a non-breaking space, and cmd.exe is using cp850 or cp437 for its output, while Emacs is expecting windows-1252 or iso8859-1. I am not sure, but the non-breaking space is then probably coming from Control Panel - Regional and Language Options - Regional Options (tab) - Standard and Formats - Number (on Windows XP). I can think of nothing else I have changed in this area. Then this is the normal condition for many pc:s in Sweden. Where do I found the codepage used by cmd.exe? What should Emacs do in this situation? It seems that default-process-coding-system is not setup properly on Windows. When I run Emacs on my Windows, default-buffer-file-coding-system is set correctly to: japanese-shift-jis-dos but default-process-coding-system is: (undecided-dos . undecided-unix) On the other hand, when I run Emacs on GNU-Linux with ja_JP.EUC-JP locale, default-process-coding-system is: (japanese-iso-8bit . japanese-iso-8bit) Is this because of DOS/Windows specific code in mule-cmds.el? --- Kenichi Handa [EMAIL PROTECTED] ___ 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
Juanma Barranquero [EMAIL PROTECTED] writes: 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: Sure, but if we had just added Stefan patch now, the rest of the patches would not have been needed before the release. That said, I agree that _some_ of the changes are good. - The possibility of adding matcher functions to `magic-mode-alist'. That's good IMO. Yes. - 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'. Correct, but we have not had reports of bad effects of the simpler regexp. - 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. Yes, that is the part of this approach which I think is going in a very bad direction ... trying to fix things in the wrong way. 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). I agree! - Modifying `image-type-header-regexps' to support NOT-ALWAYS. Not good IMO because it adds interface complexity just to fix one case. Precisely. This is the part which should be reverted. 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). Ok. So we could detect _just_ JPEG via magic-mode-alist, supposing that format is sufficiently different from anything else. 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. Agree ... for a _very limited set_ of image types, which cannot always be detected by their file suffixes... -- 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: python-mode.el doesn't associate python-mode with .PY files
On 12/28/06, Kim F. Storm [EMAIL PROTECTED] wrote: Sure, but if we had just added Stefan patch now, the rest of the patches would not have been needed before the release. Yes, of course. (BTW, I'm not particularly interested in this stuff, or in getting it in, just trying to be helpful.) Correct, but we have not had reports of bad effects of the simpler regexp. Right. Ok. So we could detect _just_ JPEG via magic-mode-alist, supposing that format is sufficiently different from anything else. Well, I don't really know whether it is common to find other image files with no descriptive file extension. Agree ... for a _very limited set_ of image types, which cannot always be detected by their file suffixes... I don't necessarily disagree... but I'm not sure either than doing such a specific fix is better than going the generic route (which is dead easy, as shown in the patch I just sent). I'm ready to be convinced otherwise, though. /L/e/k/t/u ___ 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/28/06, Kim F. Storm [EMAIL PROTECTED] wrote: Sure, but if we had just added Stefan patch now, the rest of the patches would not have been needed before the release. BTW, wasn't the approach in Stefan's patch more-or-less vetoed by Richard (even if most of us find this fix good and non-intrusive)? Or am I mixing things? /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
We never made any decision on this issue. Most of the answers pointed to that GetUserDefaultUILanguage is the correct function to use. Or am I just misinterpreting to confirm what I said at the beginning ;-) ___ 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
Kenichi Handa wrote: It seems that default-process-coding-system is not setup properly on Windows. When I run Emacs on my Windows, default-buffer-file-coding-system is set correctly to: japanese-shift-jis-dos but default-process-coding-system is: (undecided-dos . undecided-unix) On the other hand, when I run Emacs on GNU-Linux with ja_JP.EUC-JP locale, default-process-coding-system is: (japanese-iso-8bit . japanese-iso-8bit) Is this because of DOS/Windows specific code in mule-cmds.el? I do not know, but this is the value that is set by set-default-process-coding-system in w32-fns.el. This is run in before-init-hook. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Doc string for define-key does not cover menus
The description of DEF in the docstring for define-key does not cover the form it can have in menus. ___ 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
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.) That could be a good feature to add. I hesitate to add it now, though. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
C-RET is shown as just RET by substitute-command-keys
I just noticed that \\[COMMAND] just shows RET for something that was bound like (define-key map [(control ?\r)] 'nxhtml-complete-and-insert) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
diff rude
What a terrible thing Diff mode. In dired one hits = and we are in a diff mode, OK. Then there if one hits RET one sees Hunk already applied and what do you know, files have already been written to the disk without asking me are you sure or anything. This is the first time emacs has ever written something to other than a backup file with out first asking me. now I have to go in to figure out what happened and clean up the mess. yeah sure power tools for power users but i am just hereby letting you know my experience. you can set this and that and it won't happen next time well, the pro user should have to set them to enable, not the innocent user to disable. Emacs version of sep 23 2006, can't upgrade until go to town. I see I have too in .emacs: (setq diff-default-read-only t);broken? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ffap //
ffap/tramp: put the cursor upon a URL, then type C-x C-f. Now in the minibuffer add a //tmp at the end of the URL. The URL changes color, and it appears we are going to go to our local disk's /tmp, but instead we still get part of the URL passed thru as where to go. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
22.0.92 - make: Fatal error: Command failed for target `install-arch-dep'
I'm running out of time to look at this and I'm going to be offline for
several days so I'm going to report and go.
Config basics:
* Solaris 9 (9/05 if anyone cares) with /usr/sfw and /opt/sfw
* Sun Studio 10
* SunSolve patches through 2006-12-19 for OS and compiler
NB: all configure/build/commands are Sun-supplied versions, not GNU
versions (unless the Sun-supplied version is a GNU program)
* source directory == /tmp/E/src
* build directory == /tmp/E/s9
* install directory == /tmp/E/install
Config command:
---
#!/bin/sh
CPPFLAGS=-I/usr/sfw/include -I/opt/sfw/include
LDFLAGS=-L/usr/sfw/lib -L/opt/sfw/lib -R/usr/sfw/lib -R/opt/sfw/lib
export CPPFLAGS LDFLAGS
../src/configure --prefix=/tmp/E/install \
--with-xpm \
--with-jpeg \
--with-tiff \
--with-gif \
--with-png
---
Build command:
---
#!/bin/sh
CPPFLAGS=-I/usr/sfw/include -I/opt/sfw/include
LDFLAGS=-L/usr/sfw/lib -L/opt/sfw/lib -R/usr/sfw/lib -R/opt/sfw/lib
export CPPFLAGS LDFLAGS
make
---
Summary:
* configure runs without incident - my libungif is too old to use.
* build runs with no errors and only expected warnings (the same
warnings I've been seeing since the emacs v19 days)
* $(BUILD)/src/emacs runs fine both with and without -nw
* install dies with a fatal error
---
if [ `(cd /tmp/E/install/libexec/emacs/22.0.92/sparc-sun-solaris2.9
/bin/pwd)` \
!= `(cd /tmp/E/src/lib-src /bin/pwd)` ]; then \
for file in /tmp/E/src/lib-src/rcs2log vcdiff; do \
/tmp/E/src/install-sh -c /tmp/E/src/lib-src/$file
/tmp/E/install/libexec/emacs/22.0.92/sparc-sun-solaris2.9/$file; \
done ; \
fi
install: /tmp/E/src/lib-src//tmp/E/src/lib-src/rcs2log does not exist
*** Error code 1
make: Fatal error: Command failed for target
`/tmp/E/install/libexec/emacs/22.0.92/sparc-sun-solaris2.9'
Current working directory /tmp/E/s9/lib-src
*** Error code 1
make: Fatal error: Command failed for target `install-arch-dep'
---
The name of rcs2log in that for loop is a bit wonky. The above
snippet from the install log results from the following section
of lib-src/Makefile:
---
if [ `(cd $(DESTDIR)${archlibdir} /bin/pwd)` \
!= `(cd ${srcdir} /bin/pwd)` ]; then \
for file in ${SCRIPTS}; do \
$(INSTALL_SCRIPT) ${srcdir}/$$file $(DESTDIR)${archlibdir}/$$file;
\
done ; \
---
so the problem seems to lie in a strange value of ${SCRIPTS} but
I don't see from where the value observed arises. I plan to retry
this test install on another host but cannot do so for a few days
so I'm notifying y'all of the possible problem and promising to
report back with more details when time permits.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
lisp/progmodes/gdb-ui.el
GNU Emacs 22.0.92.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-12-28 on quant8 the latest lisp/progmodes/gdb-ui.el leads to the following error: Debugger entered--Lisp error: (error Unexpected `starting' annotation) signal(error (Unexpected `starting' annotation)) error(Unexpected `starting' annotation) gdb-starting() gud-gdba-marker-filter(\npost-prompt\n\nstarting\n) apply(gud-gdba-marker-filter \npost-prompt\n\nstarting\n) gud-marker-filter(\npost-prompt\n\nstarting\n) gud-filter(#process gud \npost-prompt\n\nstarting\n) as soon as start the program with run and I am stopped at a breakpoint, and I type n: instead of the program doing next, I see the list of breakpoints (as if by info break) and the above error. -- Sam Steingold (http://www.podval.org/~sds) on Fedora Core release 5 (Bordeaux) http://truepeace.org http://openvotingconsortium.org http://palestinefacts.org http://honestreporting.com http://camera.org http://mideasttruth.com Lisp is not dead, it just smells funny. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Hexl Problem on Mac OS when building a stand-alone package
Emacs Version: GNU Emacs 22.0.92.1 (i386-apple-darwin8.8.1, Carbon Version 1.6.0) of 2006-12-21 on black.local Emacs is looking for hexl utility in the Contents/MacOs/bin folder but it is installed in the Contents/Resources/.../libexec. This happens with hexlify-buffer and hexl-find-file. -David ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Scroll bar position bug?
Hi all, I am not quite sure if this is a bug. I have this setting: ,[ ~/.Xresources ] | Emacs.verticalScrollBars: right ` The scroll bar appears on the /RIGHT/ correctly. But after executing `M-x scroll-bar-mode' twice, the scroll bar is on the /LEFT/. Tested on: GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.6.4) of 2006-12-24 on soup -- 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: save-some-buffers ought to be in the menus
Kevin Rodgers wrote: Dan Jacobson wrote: save-some-buffers ought to be in the menus, under File. Advanced users, such as myself, use it all the time. I seldom use use it, so I guess I am not an advanced user. But I do know how to add it to the File menu: (define-key-after menu-bar-file-menu [save-some-buffers] '(menu-item Save Some Buffers... save-some-buffers :enable (and (menu-bar-menu-frame-live-and-visible-p) (menu-bar-non-minibuffer-window-p)) :help Save some modified file-visiting buffers) 'write-file) I admit, I copy-and-pasted the :enable form from the Save As... entry, and I don't know why the menu-bar-non-minibuffer-window-p predicate is necessary. Maybe be this would be better: :enable (and (menu-bar-menu-frame-live-and-visible-p) (catch 'some-buffer (mapc (lambda (buffer) (with-current-buffer buffer (when (and buffer-file-name (buffer-modified-p)) (throw 'some-buffer buffer (buffer-list)) nil)) -- Kevin Rodgers Denver, Colorado, USA ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Hexl Problem on Mac OS when building a stand-alone package
David Caldwell wrote: Emacs Version: GNU Emacs 22.0.92.1 (i386-apple-darwin8.8.1, Carbon Version 1.6.0) of 2006-12-21 on black.local Emacs is looking for hexl utility in the Contents/MacOs/bin folder but it is installed in the Contents/Resources/.../libexec. This happens with hexlify-buffer and hexl-find-file. Really? hexlify-buffer and dehexlify-buffer look for hexl-program in exec-directory, which on my iMac (running the same OS and Emacs pretest version as yours) is /usr/local/libexec/emacs/22.0.92/i386-apple-darwin8.8.1/ -- Kevin Rodgers Denver, Colorado, USA ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: lisp/progmodes/gdb-ui.el
GNU Emacs 22.0.92.3 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-12-28 on quant8 the latest lisp/progmodes/gdb-ui.el leads to the following error: Debugger entered--Lisp error: (error Unexpected `starting' annotation) signal(error (Unexpected `starting' annotation)) error(Unexpected `starting' annotation) gdb-starting() gud-gdba-marker-filter(\npost-prompt\n\nstarting\n) apply(gud-gdba-marker-filter \npost-prompt\n\nstarting\n) gud-marker-filter(\npost-prompt\n\nstarting\n) gud-filter(#process gud \npost-prompt\n\nstarting\n) as soon as start the program with run and I am stopped at a breakpoint, and I type n: instead of the program doing next, I see the list of breakpoints (as if by info break) and the above error. It works for me so I can't infer much from this report. Can you say which version of gdb-ui.el this is and whether it worked with an earlier one? Also, I think there must be something particular about your program. Can you work out what it is? Note that gdb-ui.el lists known bugs. One says: 3) M-x gdb doesn't work with run command in .gdbinit, use M-x gdba instead. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
