Re: emacs-22.0.95 successful installs
Richard Stallman schrieb: Do you want this kind of testing status sent to emacs-pretest-bug? You may as well report successes only to me. Don't you risk to receive a lot of redundant reports that way, as other users can't see if their system is mentioned already? Beside: As far as it concerns me, I like to read about successful installations in this list, for what reason whatever. __ Andreas Roehler ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: double-clicking on closing paren - wrong region marked
On 12 Mar 2007, at 04:24, Richard Stallman wrote: What do you think it should do in such a case, where scrolling happens validly and correctly (and you expected it) while mouse-1 is held down? If mouse did not move? A click. That surprises me. Does anyone else agree? Does anyone disagree? I think it would be a drag, for example in cases where the mouse wheel is used to scroll while mouse-1 is held down, or in when the mouse is moved to a window boundary and back, causing scrolling. I cannot think of a case where scrolling would be legitimate and expected when there is just a short click with no movement or other events in between mouse-1-down and mouse-1-up. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
Juanma Barranquero [EMAIL PROTECTED] writes: On 3/11/07, Richard Stallman [EMAIL PROTECTED] wrote: Use of Emacsclient should not interfere with an isearch! Why not? Emacsclient usually interrupts what Emacs is doing (try doing sleep 5; emacsclient myfile.txt from a shell while you work on Emacs). Certainly, emacsclient terminating the isearch is the behavior I would expect (and so does the user who reported the bug...) I agree. Whether or not isearch is terminated or suspended possibly should be made dependent on the setting of enable-recursive-minibuffers: this is the setting that indicates whether the user can be considered comfortable with suspended minibuffer usage. It definitely is a mistake for Emacs to do nothing visibly: emacsclient is not something called asynchronously, but as a direct result of a user action and/or requiring user attention. -- David Kastrup ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Windows are changing their size
Hello! I had some text buffer that filled one third of the frame and a *grep* buffer that filled two thirds of the frame. When I typed C-x C- b (list-buffers) from the *grep* buffer, the text buffer was exchnaged by the *Buffer List* that now swalled half of the frame while containing only six buffers, which is one third of this window's size. When type C-x C-b from the (small) text buffer the large *grep* buffer is exchanged, but its size does not change. A similiar bug I reported last year when I described that the *Calendar* buffer creates a window that is half the frame's size and three or four times too big. Or when I type 'C-h k C-x C-b' from the large *grep* buffer: small window is increased in size, large window does not change. Similiarly ``o´´ behaves in *Buffer List*: if the other window is less then half the frame it gets expanded, if it's more than half the frame, its size does not change. Is this disturbing behaviour really wanted and a progress? GNU Emacs was launched with -Q! In GNU Emacs 22.0.95.1 (powerpc-apple-darwin8.8.0, X toolkit, Xaw3d scroll bars) of 2007-03-09 on Latsche.local X server distributor `The XFree86 Project, Inc', version 11.0.4040 configured using `configure '--without-sound' '--without-pop' '-- with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '-- enable-locallisppath=/Library/Application Support/Emacs/calendar22:/ Library/Application Support/Emacs' 'CPPFLAGS=-no-cpp-precomp -I/usr/ include/openssl -I/sw/include/pango-1.0 -I/sw/lib/freetype219/include -I/sw/lib/freetype219/include/freetype2 -I/sw/lib/fontconfig2/include -I/sw/include/libpng12 -I/usr/local/include -I/sw/include' 'CXXFLAGS=- no-cpp-precomp -I/usr/include/openssl -I/sw/include/pango-1.0 -I/sw/ lib/freetype219/include -I/sw/lib/freetype219/include/freetype2 -I/sw/ lib/fontconfig2/include -I/sw/include/libpng12 -I/usr/local/include - I/sw/include' 'LDFLAGS=-L/sw/lib/freetype219/lib -L/sw/lib/ fontconfig2/lib -L/sw/lib/ncurses -L/usr/local/lib -L/sw/lib' 'CFLAGS=-pipe -fPIC -mcpu=7450 -mtune=7450 -fast -mpim-altivec -ftree- vectorize -foptimize-register-move -freorder-blocks -freorder-blocks- and-partition -fthread-jumps -fpeephole -fno-crossjumping'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: de_DE.UTF-8 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: Grep Minor modes in effect: show-paren-mode: t display-time-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 transient-mark-mode: t -- Mit friedvollen Grüßen Pete Let's face it; we don't want a free market economy either. James Farley, president, Coca-Cola Export Corp., 1959 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
GNU Emacs 22.0.95 complains about local variable default-directory : ~/Quellen/X11R7.1/
Hello! When trying to open the saved contents of a *compile* buffer, GNU Emacs does some lengthy fontifying and then starts to complain: The local variables list in Kompilation-xserver,komplett,no-debug contains values that may not be safe (*). Do you want to apply it? You can type y -- to apply the local variables list. n -- to ignore the local variables list. ! -- to apply the local variables list, and permanently mark these values (*) as safe (in the future, they will be set automatically.) * default-directory : ~/Quellen/X11R7.1/ If it's really needed to suspect a relative path from my home directory in a patriotic act as dangerous, then I'd prefer to save some time not having to wait until the file's contents has been fontified! In GNU Emacs 22.0.95.1 (powerpc-apple-darwin8.8.0, X toolkit, Xaw3d scroll bars) of 2007-03-09 on Latsche.local X server distributor `The XFree86 Project, Inc', version 11.0.4040 configured using `configure '--without-sound' '--without-pop' '-- with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '-- enable-locallisppath=/Library/Application Support/Emacs/calendar22:/ Library/Application Support/Emacs' 'CPPFLAGS=-no-cpp-precomp -I/usr/ include/openssl -I/sw/include/pango-1.0 -I/sw/lib/freetype219/include -I/sw/lib/freetype219/include/freetype2 -I/sw/lib/fontconfig2/include -I/sw/include/libpng12 -I/usr/local/include -I/sw/include' 'CXXFLAGS=- no-cpp-precomp -I/usr/include/openssl -I/sw/include/pango-1.0 -I/sw/ lib/freetype219/include -I/sw/lib/freetype219/include/freetype2 -I/sw/ lib/fontconfig2/include -I/sw/include/libpng12 -I/usr/local/include - I/sw/include' 'LDFLAGS=-L/sw/lib/freetype219/lib -L/sw/lib/ fontconfig2/lib -L/sw/lib/ncurses -L/usr/local/lib -L/sw/lib' 'CFLAGS=-pipe -fPIC -mcpu=7450 -mtune=7450 -fast -mpim-altivec -ftree- vectorize -foptimize-register-move -freorder-blocks -freorder-blocks- and-partition -fthread-jumps -fpeephole -fno-crossjumping'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: de_DE.UTF-8 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: Fundamental Minor modes in effect: TeX-PDF-mode: t shell-dirtrack-mode: t show-paren-mode: t display-time-mode: t desktop-save-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t -- Mit friedvollen Grüßen Pete The future will be much better tomorrow. -- George W. Bush ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs doesn't interpret down-mouse events on `before' and `after' strings
[EMAIL PROTECTED] (Johan Bockgård) writes: What happened to the down-mouse event? It got lost :-) I've installed a fix. -- 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: Strange emacsclient behaviour during use of isearch
+ (condition-case nil + ;; If we're running isearch, we must abort it to allow Emacs to + ;; display the buffer and switch to it. + (mapc #'(lambda (buffer) + (with-current-buffer buffer + (when (bound-and-true-p isearch-mode) + (isearch-cancel + (buffer-list)) +;; Signaled by isearch-cancel +(quit (message nil))) I still would like to know *why* the emacsclient buffer is not even displayed. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Unsafe variable in a saved *compilation* buffer
I'm not sure what's the reason to put such a file-local variable. More to the point, I'm not sure it's a good idea in the first place. The reason M-x compile generates this local variable is to make sure the error messages are interpreted with respect to the proper directory. We want this variable to be put into effect if the text is saved and visited again. Presumably if it's saved, it'll be saved in that same directory, so it'll work just as well without the default-directory file-local variable. OTOH, if the whole directory tree is moved/renamed (or accessed under a different name, such as via Tramp, or sshfs, or ...), without the default-directory file-local variable, things will still work just as well, whereas with the default-directory file-local variable, the error messages will be interpreted with respect to the improper directory. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: double-clicking on closing paren - wrong region marked
If mouse did not move? A click. That surprises me. Does anyone else agree? Does anyone disagree? I think it would be a drag, for example in cases where the mouse wheel is used to scroll while mouse-1 is held down, Good point: if there's some other mouse action in the mean time, it shouldn't be considered as a click. or in when the mouse is moved to a window boundary and back, causing scrolling. I said mouse did not move, not mouse is at the same place at beginning and end. I cannot think of a case where scrolling would be legitimate and expected when there is just a short click with no movement or other events in between mouse-1-down and mouse-1-up. I can: current-buffer is just constantly scrolling (it's watching an active log file, or it's a game, or a shell buffer with a process gone wild, ...). Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: double-clicking on closing paren - wrong region marked
What about the case where the user moves the mouse around substantially but brings it back to the same place (although it's over a different character, so he can't tell it's the same)? This used to result in a click in Emacs-21, and I've changed it to a drag in Emacs-22. Stefan PS: this needs to be qualified, because the decision is taken twice: once in the C code to decide whether the up even is a drag-mouse-1 or just mouse-1, and once in elisp in mouse-drag-region. My change was only to the C code, because the elisp code already considered such situations as drags, but the discrepency between the two resulted in odd behaviors. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Unsafe variable in a saved *compilation* buffer
Stefan Monnier [EMAIL PROTECTED] writes: Presumably if it's saved, it'll be saved in that same directory, so it'll work just as well without the default-directory file-local variable. So maybe we should only store the default-directory if it differs from the target directory of the file ... -- 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
22.0.95 on OpenBSD.
Here is what I found with just ./configure --without-x on a handful of OpenBSD ports running OpenBSD 4.1 (-current). First I needed to add a few m/s combos into the configure script. I think this is the complete list - alpha*-*-openbsd*)machine=alpha ;; arm*-*openbsd*) machine=arm ;; hppa-*-openbsd*) machine=hp9000s300 ;; i386-*-openbsd*) machine=intel386 ;; m68k-*-openbsd*) machine=hp9000s300 ;; m88k-*-openbsd*) machine=aviion ;; mips64-*-openbsd*)machine=mips64 ;; powerpc-*-openbsd*) machine=macppc ;; sh-*-openbsd*)machine=sh3el ;; sparc*-*-openbsd*)machine=sparc ;; vax-*-openbsd*) machine=vax ;; x86_64-*-openbsd*)machine=amdx86-64 ;; Results - * i386: Success. * amd64: Success. * alpha: Failure. * powerpc: Failure. * vax: Failure. More details below. alpha failure - cd lib-src; make all CC='gcc' CFLAGS='-g -O2' CPPFLAGS='-I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib -fno-common' LDFLAGS='-Wl,-znocombreloc' MAKE='make' cd src; make all CC='gcc' CFLAGS='-g -O2' CPPFLAGS='-I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib -fno-common' LDFLAGS='-Wl,-znocombreloc' MAKE='make' gcc -c -I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib -fno-common -Demacs -DHAVE_CONFIG_H -I. -I/home/deanna/emacs-22.0.95/src -fno-common -I/usr/X11R6/include -I/usr/pkg/include -I/usr/local/include -L/usr/pkg/lib -L/usr/local/lib -g -O2 unexelf.c unexelf.c:542:1: warning: ELFSIZE redefined In file included from unexelf.c:528: /usr/include/sys/exec_elf.h:533:1: warning: this is the location of the previous definition unexelf.c: In function `unexec': unexelf.c:1086: error: syntax error before symhdr unexelf.c:1088: error: `symhdr' undeclared (first use in this function) unexelf.c:1088: error: (Each undeclared identifier is reported only once unexelf.c:1088: error: for each function it appears in.) *** Error code 1 Stop in /home/deanna/emacs-22.0.95/src. *** Error code 1 Stop in /home/deanna/emacs-22.0.95 (line 305 of Makefile). * powerpc (aka macppc): failure - echo dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.oterminfo.o lastfile.o gmalloc.o ralloc.o vm-limit.o buildobj.lst gcc `echo | sed -e 's/-R/-Wl,-rpath,/'` -Z -Wl,-znocombreloc -o temacs pre-crt0.o /usr/lib/crt0.o /usr/lib/crtbegin.o dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.o emacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o editfns.o callint.o eval.o floatfns.o fns.o print.o lread.o abbrev.o syntax.o unexelf.o bytecode.o process.o callproc.o region-cache.o sound.o atimer.o doprnt.o strftime.o intervals.o textprop.o composite.o md5.oterminfo.o lastfile.o gmalloc.o ralloc.o vm-limit.o -lossaudio -lncurses -lm -lgcc -lc -lgcc /usr/lib/crtend.o /usr/lib/crt0.o(.text+0x0): In function `_start': : multiple definition of `__start' /usr/lib/crt0.o(.text+0x0): first defined here /usr/lib/crt0.o(.sdata+0x0): multiple definition of `__progname' /usr/lib/crt0.o(.sdata+0x0): first defined here /usr/lib/crt0.o(.text+0x0): In function `_start': : multiple definition of `_start' /usr/lib/crt0.o(.text+0x0): first defined here /usr/lib/crtbegin.o(.init+0x0): In function `__init': : multiple definition of `__init' /usr/lib/crtbegin.o(.init+0x0): first defined here /usr/lib/crtbegin.o(.fini+0x0): In function `__fini': : multiple definition of `__fini' /usr/lib/crtbegin.o(.fini+0x0): first defined here *** Error code 1 Stop in /home/deanna/emacs-22.0.95/src (line 105 of Makefile). *** Error code 1 Stop in /home/deanna/emacs-22.0.95 (line 305 of Makefile). * vax: failure - echo dispnew.o frame.o scroll.o xdisp.o xmenu.o window.o charset.o coding.o category.o ccl.o cm.o term.o xfaces.oemacs.o keyboard.o macros.o keymap.o sysdep.o buffer.o filelock.o insdel.o marker.o minibuf.o fileio.o dired.o filemode.o cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o alloc.o data.o doc.o
Re: Strange emacsclient behaviour during use of isearch
On 3/12/07, Stefan Monnier [EMAIL PROTECTED] wrote: Yes, we can add some ad-hoc isearch hack in server.el for it. It's kind of ugly, tho. No doubt. Having server.el forcefully exit from recursive edits and abort isearches is inellegant. The alternative is for someone who knows isearch, recursive edits and event handling in deep to investigate the issue and propose a better fix :) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Unsafe variable in a saved *compilation* buffer
Am 12.03.2007 um 16:49 schrieb Kim F. Storm: Stefan Monnier [EMAIL PROTECTED] writes: Presumably if it's saved, it'll be saved in that same directory, so it'll work just as well without the default-directory file-local variable. So maybe we should only store the default-directory if it differs from the target directory of the file ... Particularly these compilations I saved and re-visited during the last days where saved outside the default-directory to avoid any complaints from cvs, svn, git, or such. Is the meaning of default- directory that to allow easy re-compilation? Can this really work, i.e. can GNU Emacs find how compilation then started? Or would it simply try a make? Re-compilation works in the live buffer, but then I use repeat-complex-command or M-x compile RET and step backward in history, so a complicated compile command can be retrieved, changed if necessary, and started again. *I* would not mind if default-directory is removed ... -- Greetings Pete There is no worse tyranny than to force a man to pay for what he does not want merely because you think it would be good for him. -- Robert Heinlein ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
Richard Stallman [EMAIL PROTECTED] writes: Use of Emacsclient should not interfere with an isearch! I don't see why this should be true in general. Consider the case where you are *not* using emacsclient: while in the middle of an isearch, do C-x C-f: that breaks out of isearch and displays the new file. Since opening a new file from inside Emacs interferes with an isearch, it is no surprise that doing it through emacsclient also does the same. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
I don't think we will be able to find a patch that can break out of isearch for Emacs-22 (it's probably going to be too big a change). But the fact that not only it doesn't break out of isearch, but additionally the buffer isn't displayed at all looks more serious. The patch below seems to work, but you know server.el better than I do, so perhaps you can see some downside to it. *Sigh* Yes, we can add some ad-hoc isearch hack in server.el for it. It's kind of ugly, tho. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
define-globalized-minor-mode is not fontified as a keyword
... but define-global-minor-mode is in emacs-lisp-mode. In GNU Emacs 22.0.95.1 (i386-mingw-nt5.1.2600) of 2007-03-08 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
Yes, we can add some ad-hoc isearch hack in server.el for it. It's kind of ugly, tho. No doubt. Having server.el forcefully exit from recursive edits and abort isearches is inellegant. I don't think the behavior is inelegant (it's not great, but there's not much we can do without major changes to Emacs). So I think the forceful exit from recursive minibuffers is OK (it's generic), whereas the isearch part is a complete hack. The alternative is for someone who knows isearch, recursive edits and event handling in deep to investigate the issue and propose a better fix :) The better fix is easy: implement concurrency in Emacs (at least the cooperating form of it). Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
Stefan Monnier [EMAIL PROTECTED] writes: Yes, we can add some ad-hoc isearch hack in server.el for it. It's kind of ugly, tho. No doubt. Having server.el forcefully exit from recursive edits and abort isearches is inellegant. I don't think the behavior is inelegant (it's not great, but there's not much we can do without major changes to Emacs). So I think the forceful exit from recursive minibuffers is OK (it's generic), whereas the isearch part is a complete hack. In the absence of The better fix is easy: implement concurrency in Emacs (at least the cooperating form of it). ..., why don't we live with this hack for the time being? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
x-show-tip color choices
Hello, I'm not quite sure if this qualifies as a bug, however I find it irritating: I have this in my .emacs: (add-to-list 'default-frame-alist '(background-color . black)) (add-to-list 'default-frame-alist '(foreground-color . wheat)) So when I call (x-show-tip hello) I get a tooltip with wheat-colored text and a yellow background. I don't think it should override only one of the background and foreground colors; either both or none. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: x-show-tip color choices
I'm not quite sure if this qualifies as a bug, however I find it irritating: I have this in my .emacs: (add-to-list 'default-frame-alist '(background-color . black)) (add-to-list 'default-frame-alist '(foreground-color . wheat)) So when I call (x-show-tip hello) Why do you call x-show-tip? I get a tooltip with wheat-colored text and a yellow background. I think x-show-tip is just meant as an internal function for tooltip-show. Why not use that, or even tooltip-mode and the help-echo text proerty, instead? I don't think it should override only one of the background and foreground colors; either both or none. It probably overrides the background so that it doesn't appear as part of the parent frame (unless that happens to be lightyellow) when debugging tooltip functionality. Unless you have a real purpose for using x-show-tip directly, I don't think this is worth changing. -- 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
Re: x-show-tip color choices
Nick Roberts [EMAIL PROTECTED] writes: Why do you call x-show-tip? Ok, actually I don't. A package I tried to use does, I just couldn't read the tooltips. I think x-show-tip is just meant as an internal function for tooltip-show. Unless you have a real purpose for using x-show-tip directly, I don't think this is worth changing. Fair enough, but in that case I'd suggest pointing that out in x-show-tip's documentation. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
On 3/12/07, Stefan Monnier [EMAIL PROTECTED] wrote: So I think the forceful exit from recursive minibuffers is OK (it's generic) Elegant would be for packages and modes to have a way to tell server.el what to do. Forced exit is never going to be elegant IMO. YMMV. whereas the isearch part is a complete hack. From a cursory read of isearch.el, isearch itself is a hack (though very useful). The better fix is easy: implement concurrency in Emacs (at least the cooperating form of it). Yeah, well. The thing is, what do we do now wrt the isearch problem? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
Yeah, well. The thing is, what do we do now wrt the isearch problem? I can't answer that before I've figured out what is the reason that the buffer is not displayed. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-22.0.95 successful installs
Don't you risk to receive a lot of redundant reports that way, as other users can't see if their system is mentioned already? We don't expect pretesters to read this list. Beside: As far as it concerns me, I like to read about successful installations in this list, for what reason whatever. I was only trying to save other people email. If people on this list would generally prefer to see success reports too, then let's do it that way. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Unsafe variable in a saved *compilation* buffer
Presumably if it's saved, it'll be saved in that same directory, so it'll work just as well without the default-directory file-local variable. The user could save it anywhere. He might not want to save it in the directory with the source files. ISTR that I added this because I ran into problems without it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: double-clicking on closing paren - wrong region marked
I cannot think of a case where scrolling would be legitimate and expected when there is just a short click with no movement or other events in between mouse-1-down and mouse-1-up. I can: current-buffer is just constantly scrolling (it's watching an active log file, or it's a game, or a shell buffer with a process gone wild, ...). If you hold down the mouse on a buffer that is scrolling continually, you will see it scroll and you will see a region start to highlight. Wouldn't operating on that region be the right thing? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Strange emacsclient behaviour during use of isearch
I don't see why this should be true in general. Consider the case where you are *not* using emacsclient: while in the middle of an isearch, do C-x C-f: that breaks out of isearch and displays the new file. I don't think that an action from outside Emacs is comparable to one done by typing Emacs commands. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: define-globalized-minor-mode is not fontified as a keyword
Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.95 on OpenBSD.
Richard Stallman writes:
First I needed to add a few m/s combos into the configure
script. I think this is the complete list -
alpha*-*-openbsd*)machine=alpha ;;
arm*-*openbsd*) machine=arm ;;
hppa-*-openbsd*) machine=hp9000s300 ;;
i386-*-openbsd*) machine=intel386 ;;
m68k-*-openbsd*) machine=hp9000s300 ;;
m88k-*-openbsd*) machine=aviion ;;
mips64-*-openbsd*)machine=mips64 ;;
...
I do not understand what those words mean. When you say the
complete list, what is that a list of?
This is a list of currently supported hardware platforms.
Are you suggesting that configure.in needs a change?
If so, could you say explicitly what the change is?
I think this should do it.
--- configure.in.orig Sun Mar 11 23:24:34 2007
+++ configure.inSun Mar 11 23:49:57 2007
@@ -279,13 +279,17 @@ dnl see the `changequote' comment above.
opsys=openbsd
case ${canonical} in
alpha*-*-openbsd*) machine=alpha ;;
- i386-*-openbsd*) machine=intel386 ;;
- x86_64-*-openbsd*)machine=amdx86-64 ;;
- m68k-*-openbsd*) machine=hp9000s300 ;;
- mipsel-*-openbsd*) machine=pmax ;;
- ns32k-*-openbsd*)machine=ns32000 ;;
- sparc-*-openbsd*)machine=sparc ;;
- vax-*-openbsd*) machine=vax ;;
+ arm-*-openbsd*) machine=arm ;;
+ hppa-*-openbsd*) machine=hp9000s300 ;;
+ i386-*-openbsd*) machine=intel386 ;;
+ m68k-*-openbsd*) machine=hp9000s300 ;;
+ m88k-*-openbsd*) machine=aviion ;;
+ mips64-*-openbsd*) machine=mips64 ;;
+ powerpc-*-openbsd*) machine=macppc ;;
+ sh-*-openbsd*) machine=sh3el ;;
+ sparc*-*-openbsd*) machine=sparc ;;
+ vax-*-openbsd*) machine=vax ;;
+ x86_64-*-openbsd*) machine=amdx86-64 ;;
esac
;;
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
C indentation (problem)
Hi emacs-pretest-bug,
In the emacs pretest I have indentation problems running php-mode.
The indentation breaks if I put in a php opening tag, otherwise it works
fine. I have tracked the source of the problem to the new c-mode
which php-mode inherits.
I am not sure if it's a bug or the ancient php-mode just needs to
accommodate for the new emacs.
This is the indentation in c-mode (it is the same in php-mode):
? php
void foo() {
bar();
}
?
the closing bracket aligns with the text in the php tag.
If this is not a bug, I would appreciate any information of how to
tweak c-mode settings to eliminate this closing indentation.
Sincerely
Thomas
In GNU Emacs 22.0.95.6 (i686-pc-linux-gnu, GTK+ Version 2.8.20)
of 2007-03-12 on toshiba
Windowing system distributor `The X.Org Foundation', version 11.0.70101000
configured using `configure '--with-gtk' '--without-toolkit-scroll-bars''
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: en_DK.UTF-8
locale-coding-system: utf-8
default-enable-multibyte-characters: t
Major mode: C/l
Minor modes in effect:
show-paren-mode: t
iswitchb-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
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
abbrev-mode: t
Recent input:
backspace d SPC f o o ( ) SPC { return } right
up left up left left left down up SPC
SPC SPC down tab down tab up C-e return
tab b a t r backspace backspace r ( ) ; up
tab down tab down tab down C-x C-s up
up up up C-a C-SPC C-SPC down down down
down down down down M-w M-x e m a tab - backspace
r backspace p tab backspace b tab C-g help-echo
help-echo help-echo help-echo help-echo help-echo
help-echo 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:
Loading paren...done
Loading advice...done
end
For information about the GNU Project and its goals, type C-h C-p.
(New file) [2 times]
Wrote /home/thomasc/test.c
Mark set
Mark activated
Quit [2 times]
Loading emacsbug...done
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
