Could you skip the splash screen when emacs is started with a file name on the command 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: Is it by design that the user gets the splash-screen when emacs is started with FILE as an argument? People have come to me and asked my emacs takes so long to load... It is of course a matter of preferences, but I think it might be worth discussing (again?) if the splash-screen should be inhibited in situations similar to this: C:\download\emacs-cvs\070308\bin\emacs.exe -q ..\..\emacs\etc\SERVICE (I have '(inhibit-splash-screen t) in my .emacs' custom-set-variables since years, but beginners are supposed to have an empty .emacs) 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 c:/download/emacs-cvs/070308/etc/DEBUG for instructions. In GNU Emacs 22.0.95.1 (i386-mingw-nt5.0.2195) of 2007-03-08 on E001560B82878 X server distributor `Microsoft Corp.', version 5.0.2195 configured using `configure --with-gcc (3.4)' 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: SVE locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Text 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 M-x r e p o r t tab return Recent messages: (C:\download\emacs-cvs\070308\bin\emacs.exe -q ..\..\emacs\etc\SERVICE) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. Loading vc-cvs...done For information about the GNU Project and its goals, type C-h C-p. Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done call-interactively: Text is read-only ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Please consider using highlightening in occur-mode-display-occurrence
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: When using occur, I just found out that there was a command occur-mode-display-occurrence (C-o) that let me stay in the *occur*-buffer. Nice! Wouldn't it be a good idea to highlight the occurrence, at least temporarily, instead of just putting the not-so-easily-seen point on it? Whatever you choose, thanks for occur. It makes the parsing of logs so much easier. /Mats 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 c:/download/emacs-cvs/070308/etc/DEBUG for instructions. In GNU Emacs 22.0.95.1 (i386-mingw-nt5.0.2195) of 2007-03-08 on E001560B82878 X server distributor `Microsoft Corp.', version 5.0.2195 configured using `configure --with-gcc (3.4)' 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: SVE locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Occur 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: C-x C-f t e s t . t x t return a s d f return q w e r q return z x c v return a s d f return M-x o c c u r return a s return C-x o down C-e left left left down up help-echo C-c C-g C-o C-n C-o C-p C-o C-n C-p C-n C-o M-x r e p o r SPC SPC SPC return Recent messages: (C:\download\emacs-cvs\070308\bin\emacs.exe -q) Loading encoded-kb...done For information about the GNU Project and its goals, type C-h C-p. [2 times] (New file) Searched 1 buffer; 2 matches for `as' 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: Mode-line face bug
Chong Yidong [EMAIL PROTECTED] writes: Richard Stallman [EMAIL PROTECTED] writes: Here is an idea. When a face attribute is set by customization, set a flag to record that fact. That flag will cause the X resource to be ignored for that attribute. Do you agree that is feasible? Can you implement it? Like I mentioned, customized faces have a `theme-face' property, which can be used for this. I've checked in a fix along similar lines. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
Richard Stallman [EMAIL PROTECTED] writes: I don't see why the insertion of the initial scratch message should be conditional on which buffer happens to be current at that point in the start-up sequence. It makes sense to me. If your init file sets up other buffers, Emacs should let you see them, right? Actually this is not what this is about. There seems to be a confusion with the splash screen. The point here is that the *scratch* buffer is empty. (Where it is in the buffer list does not matter.) You could argue that there is no point in a *scratch* buffer, if desktop reverted a session. But in that case it shouldn't exist at all. Even if you discount my wacky attachment for the scratch message, it *is* a little bit puzzling why the *scratch* buffer is empty in that case and because the reason is not evident (to me it still isn't) it *does* seem a little bit as if Emacs were in an inconsistent state after restoring the desktop. Oliver -- Oliver Scholz 21 Ventôse an 215 de la Révolution Ostendstr. 61 Liberté, Egalité, Fraternité! 60314 Frankfurt a. M. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
On 2007-03-11, Chong Yidong said: Chong Yidong [EMAIL PROTECTED] writes: Richard Stallman [EMAIL PROTECTED] writes: Here is an idea. When a face attribute is set by customization, set a flag to record that fact. That flag will cause the X resource to be ignored for that attribute. Do you agree that is feasible? Can you implement it? Like I mentioned, customized faces have a `theme-face' property, which can be used for this. I've checked in a fix along similar lines. I confirm it is indeed fixed. BTW, does that mean this change is redundant? 2007-02-06 Chong Yidong [EMAIL PROTECTED] * faces.el (face-set-after-frame-default): Compile attributes to be set by frame parameters before merging in X resources. Regards, -- 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
Unsafe variable in a saved *compilation* buffer
Hello! When I try to open a previously saved *compilation* buffer, GNU Emacs complains about an unsafe variable, default-directory. Is this needed? The local variables list in Kompilation-doc 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/ In GNU Emacs 22.0.93.1 (powerpc-apple-darwin8.8.0, X toolkit, Xaw3d scroll bars) of 2007-02-23 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 Mit Jazz statt Bomben gegen die Taliban! ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Leo [EMAIL PROTECTED] writes: BTW, does that mean this change is redundant? 2007-02-06 Chong Yidong [EMAIL PROTECTED] * faces.el (face-set-after-frame-default): Compile attributes to be set by frame parameters before merging in X resources. I don't think so. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Richard Stallman [EMAIL PROTECTED] writes: The behavior where X resources override Custom (and all other Elisp face settings) seems to have been around since forever --- it can be seen in Emacs 21 ... So we obviously don't need to anything about it before the release. Bugs that bother users are important regardless of how long they have existed. With that logic, we'll never have a release. I didn't say the bug is not important -- I just claim it is far more important to make a release! -- 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: double-clicking on closing paren - wrong region marked
I can't think of any case where I'd expect Emacs to think I did a drag when I didn't physically move the mouse, really. 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? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Here is an idea. When a face attribute is set by customization, set a flag to record that fact. That flag will cause the X resource to be ignored for that attribute. Do you agree that is feasible? Can you implement it? Like I mentioned, customized faces have a `theme-face' property, which can be used for this. Thanks for fixing it. ___ 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
Indeed. That it doesn't interrupt isearch is not a surprise: isearch is implemented quite differently. emacsclient interrupts recursive edits and minibuffers, When you say interrupts, what precisely does that mean? Does that mean it does its job while you're in the minibuffer? Or does it exit the minibuffer? It is a bad thing for it to forcibly exit the minibuffer. but isearch uses neither (it basically temporarily switches major-mode instead). 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. Use of Emacsclient should not interfere with an isearch! ___ 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
When I try to open a previously saved *compilation* buffer, GNU Emacs complains about an unsafe variable, default-directory. Is this needed? The local variables list in Kompilation-doc 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/ Yes, indeed, this is very annoying. There are many other local variables (including numbers!) for which Emacs asks this question. Look, for example, at this section: ## Local_Variables: ## perl-indent-level: 2 ## perl-continued-statement-offset: 2 ## perl-continued-brace-offset: 0 ## perl-brace-offset: 0 ## perl-brace-imaginary-offset: 0 ## perl-label-offset: -2 ## cperl-indent-level: 2 ## cperl-brace-offset: 0 ## cperl-continued-brace-offset: 0 ## cperl-label-offset: -2 ## cperl-extra-newline-before-brace: t ## cperl-merge-trailing-else: nil ## cperl-continued-statement-offset: 2 It seems all these variables are safe, isn't? Perhaps Emacs shouldn't be released without marking all safe variables in packages distributed with Emacs. -- 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: Unsafe variable in a saved *compilation* buffer
On Sun, 11 Mar 2007 17:35:48 +0100 Peter Dyballa wrote: Hello! When I try to open a previously saved *compilation* buffer, GNU Emacs complains about an unsafe variable, default-directory. Is this needed? The local variables list in Kompilation-doc 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/ Just curious, could one exploit this + tramp to find out if someone has opened a file with Emacs? David ___ 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/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...) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Please consider using highlightening in occur-mode-display-occurrence
Wouldn't it be a good idea to highlight the occurrence, at least temporarily, instead of just putting the not-so-easily-seen point on it? Have you tried hl-line-mode in occur buffers? 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
* default-directory : ~/Quellen/X11R7.1/ 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. 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
I can't think of any case where I'd expect Emacs to think I did a drag when I didn't physically move the mouse, really. 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. 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
Stefan Monnier [EMAIL PROTECTED] writes: I can't think of any case where I'd expect Emacs to think I did a drag when I didn't physically move the mouse, really. 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. But a click is a down-mouse event followed by an up-mouse event. Since down-mouse is bound to a function which does track-mouse it is not entirely obvious what a click means or how to implement it. -- 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: double-clicking on closing paren - wrong region marked
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. For a click you have to find a POS-OR-AREA: This is the buffer position of the character clicked on in the text area ... Which buffer position would you choose for POS-OR-AREA? The one before the scroll or the one after? By definition it must be a drag: A drag event happens every time the user presses a mouse button and then moves the mouse to a different character position before releasing the button. Where moves does not necessarily refer to moving the mouse on the pad or the mouse pointer on the screen. ___ 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/11/07, Juanma Barranquero [EMAIL PROTECTED] wrote: The patch below seems to work This is a slightly better variant of the previous patch. Comments? Juanma Index: lisp/server.el === RCS file: /cvsroot/emacs/emacs/lisp/server.el,v retrieving revision 1.126 diff -u -2 -r1.126 server.el --- lisp/server.el 27 Jan 2007 19:03:43 - 1.126 +++ lisp/server.el 11 Mar 2007 23:28:07 - @@ -415,4 +415,14 @@ (lambda () (server-process-filter proc (top-level)) + (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))) ;; If the input is multiple lines, ;; process each line individually. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: byte-compile compile log shows wrong line number
I fixed the bug with slightly different code. Thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Actually this is not what this is about. There seems to be a confusion with the splash screen. The point here is that the *scratch* buffer is empty. (Where it is in the buffer list does not matter.) You could argue that there is no point in a *scratch* buffer, if desktop reverted a session. But in that case it shouldn't exist at all. I stand corrected. I agree that there is no reason not to put the usual scratch buffer message into the scratch buffer. So I guess this change should be made. Glenn, would you please install your startup.el patch? ___ 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
default-directory is safe, right? So let's mark it as safe. Does anyone object? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Richard Stallman wrote: I agree that there is no reason not to put the usual scratch buffer message into the scratch buffer. So I guess this change should be made. Glenn, would you please install your startup.el patch? done ___ 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
Just curious, could one exploit this + tramp to find out if someone has opened a file with Emacs? Maybe one can, but I don't think we want to consider all file name variables to be unsafe. ___ 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. ___ 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 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? 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)? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Please consider using highlightening in occur-mode-display-occurrence
Stefan Monnier asked me if I had used hl-line-mode in the occur buffers. I think Juri got what I meant: I think the corresponding location in the source buffer is not marked enough. A behaviour like grep where there location is temporarily highlighted is nice. (But there you end up in the source buffer, and I would like to be able to stay in the *occur* or the *grep* buffer.) /Mats On 3/11/07, Juri Linkov [EMAIL PROTECTED] wrote: When using occur, I just found out that there was a command occur-mode-display-occurrence (C-o) that let me stay in the *occur*-buffer. Nice! Wouldn't it be a good idea to highlight the occurrence, at least temporarily, instead of just putting the not-so-easily-seen point on it? Obviously, occur should be extended with more features already available in grep buffers. And one of them is using the next-error face to highlight matches in the source buffer. Sadly, now is the wrong time to add these features. (I also have tons of other improvements patiently waiting for the feature unfreeze.) -- 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
