Re: Initial scratch message missing with desktop-save-mode on
Or perhaps no change is needed. If you resume a saved session, you have presumably seen the scratch screen in the previous session. So maybe it is right that it goes straight back to the status that was saved, without showing the scratch screen again. I'd agree with that. I think `desktop' aims to do a suspend/resume, so there's no need to show the splash screen again. 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
The problem can be fixed at 2 places: 1 - at step 4, there shouldn't be any scrolling. 2 - at step 5, since the mouse hasn't moved, and since the time between the down-mouse-1 and the (up) mouse-1 is short, this shouldn't be considered as a drag. I think #4 should be fixed. I am not sure #5 is a bug. It is true that the mouse has not moved physically, but in some virtual sense it has moved due to the scrolling. In this case, the scrolling was a bug. But suppose there had been scrolling for a valid reason. Wouldn't it be correct to treat the click as a drag in that case? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: abbrev can't be required
I fixed this. 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
Another possibility is to stop the window manager from automatically setting a face resource for the mode-line. There would then be no problem with the convention that X resources override Elisp, since X resources would be set by the user. That is an interesting way of looking at it. I have asked the GNOME developers to turn off the setting for mode-line, for other reasons. However, the theme manager also makes settings for other faces, such as scroll-bar, so the problem would still exist. It could be that the theme-based settings for other faces won't bother many users, so few will try to override them by customization. If so, the remaining problem would not bother people very much. It would still be a problem, but less urgent. However, that's academic, because even if the GNOME developers listen to us, it will take a long time for corrected versions of GNOME to replace the current ones. So we need a fix for this now, even if we won't need it badly 3 years from now. 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? ___ 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 think #4 should be fixed. I am not sure #5 is a bug. It is true that the mouse has not moved physically, but in some virtual sense it has moved due to the scrolling. In this case, the scrolling was a bug. But suppose there had been scrolling for a valid reason. Wouldn't it be correct to treat the click as a drag in that case? 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. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
doc string of indent-to should mention the return value
`indent-to' returns the column. I've seen code that depends upon this feature. The doc string doesn't mention the return value, but the Elisp manual does. In GNU Emacs 22.0.93.1 (i386-mingw-nt5.1.2600) of 2007-01-25 on LENNART-69DE564 X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Ic:/g/include' ___ 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: 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. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Strange emacsclient behaviour during use of isearch
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: First I start my newly compiled emacs from CVS head (but I think this has been present at least for a while: C:\download\emacs-cvs\070310\etc..\bin\runemacs.exe -q Then I run server-start and after that I use isearch in the scratch buffer. Now I try to use emacsclient to open something else, but since isearch is running the new buffer does not appear on top. C:\download\emacs-cvs\070310\etc..\bin\emacsclient.exe --no-wait WHY-FREE That it does not hide the isearched buffer _might_ be ok, but how about not putting it furthest away, that is if I go looking for it by killing buffers I have to kill them all before I find the buffer? Now that I know about it, I can easily find it by just using C-x b file-name, but most people new to this will probably wonder Oops, why did that not work?. emacsclient seems to interrupt find-file, swith-to-buffer and areas marked to be copied, so I think it is somewhat inconsistent not to quit isearch and put the new buffer on top. This is just a detail. I am very happy that emacsclient has been implemented for MS Windows. Except for this it works like a charm. Thank you very much. O.T: Microsoft Corp. hasn't really built an X server, do they? It looks a bit odd a few lines down in this message. /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/070310/etc/DEBUG for instructions. In GNU Emacs 22.0.95.1 (i386-mingw-nt5.0.2195) of 2007-03-10 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: Fundamental 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: M-x s e r v e r SPC s t a r t return M- C-s ; ; return C-x k return C-x k return M-x r e p o r t SPC b tab backspace tab return Recent messages: 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: Strange emacsclient behaviour during use of isearch
Now I try to use emacsclient to open something else, but since isearch is running the new buffer does not appear on top. Hmm... indeed, I can reproduce it. Not sure why, yet. emacsclient seems to interrupt find-file, swith-to-buffer and areas marked to be copied, so I think it is somewhat inconsistent not to quit isearch and put the new buffer on top. Indeed. That it doesn't interrupt isearch is not a surprise: isearch is implemented quite differently. emacsclient interrupts recursive edits and minibuffers, 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. O.T: Microsoft Corp. hasn't really built an X server, have they? It looks a bit odd a few lines down in this message. Good point. I'll change the text to Windowing system distributor. 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 wrote: Now I try to use emacsclient to open something else, but since isearch is running the new buffer does not appear on top. Hmm... indeed, I can reproduce it. Not sure why, yet. emacsclient seems to interrupt find-file, swith-to-buffer and areas marked to be copied, so I think it is somewhat inconsistent not to quit isearch and put the new buffer on top. Indeed. That it doesn't interrupt isearch is not a surprise: isearch is implemented quite differently. emacsclient interrupts recursive edits and minibuffers, 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. Can it perhaps be done with a timer + (top-level)? ___ 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, Stefan Monnier [EMAIL PROTECTED] wrote: 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. 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 03:12:26 - @@ -405,4 +405,10 @@ (setq string (concat prev string)) (process-put proc :previous-string nil))) + (mapc #'(lambda (buffer) + (when (local-variable-p 'isearch-mode buffer) + (with-current-buffer buffer + (isearch-done) + (message nil + (buffer-list)) (when ( (recursion-depth) 0) ;; We're inside a minibuffer already, so if the emacs-client is trying ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
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. ___ 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
But since we are trying to make a release happen, reverting a change (for some minor bug) which turns out to cause more problems than it fixes seems acceptable to me. Once in a while, this is the right thing to do. But people seem to be too quick to propose it, as if it were the first solution they think of. It should never be treated as the first solution. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
However, I don't if this is because Emacs implements the scrollbar differently, or because Metacity handles it differently. It appears to be a GNOME theme manager that sets up these X resources. ___ 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
That sounds like a larger change. Is your change a reversion of that whole previous change, or just an adjustment of it? The change was a large one. This was tiny, IMO incidental part of it. I suggest you avoid using the word revert for anything other than reverting a change, because it is misunderstanding-prone. ___ 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
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? I think this is not a bug; let's drop it and move on. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Strange behaviour of drag-n-drop and find-file at the same time
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: Hi, I think this has been around for a very long time, but this seems like a good time to report it. If you start with C-x C-f, but then instead drag-n-drop a file to emacs instead of specifying it and pressing RET you end up with the file shown in the window you dragged it to. So long all seems ok. The annoying thing is that find-file is still there in the mini-buffer, and if you C-x o yourself to the mini-buffer and use C-g to quit find-file, emacs will no longer show the dragged-n-dropped buffer, but instead whatever it was showing before. switch-to-buffer easily takes you to the disappeared buffer, but most people probably thinks this is strange. Thank you for your work. /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: Emacs-Lisp Minor modes in effect: encoded-kbd-mode: t tooltip-mode: t tool-bar-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: C-x C-f drag-n-drop C-x o C-g C-x b return M-x r e p o r t tab 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] Loading url-util...done Loading vc-cvs...done Quit 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
