Re: Strange emacsclient behaviour during use of isearch
On 3/21/07, Richard Stallman <[EMAIL PROTECTED]> wrote: So I think the minibuffer always has to be aborted. (I said this a few days ago.) I read that, but I wasn't sure about the isearch. So please go ahead and make the proposed change. Done. 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
On 3/21/07, Stefan Monnier <[EMAIL PROTECTED]> wrote: I wish we could do it more prettily than with the code you showed, but I think we'll have to live with it for now. Agreed. 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
I looked at the code and concluded that there is no way to distinguish the case of a minibuffer on another terminal from the case of a minibuffer on the same terminal. So I think the minibuffer always has to be aborted. (I said this a few days ago.) We may as well treat isearch like the minibuffer. So please go ahead and make the proposed change. ___ 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
> We've done another pretest and this issue is still undecided. > After researching the problem, Stefan said: >> [...] if I remove the `isearch-mode' check, the buffer is indeed displayed. >> The problem is that since it doesn't exit isearch, you end up isearching in >> the new buffer. > which seems like an argument for aborting the isearch (or an argument for > rethinking isearch, but I don't think we want to do that right now). > One way or the other, we should reach a decision and fix the bug. Yes, I think aborting the isearch is the best choice. I wish we could do it more prettily than with the code you showed, but I think we'll have to live with it for now. 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
We've done another pretest and this issue is still undecided. After researching the problem, Stefan said: [...] if I remove the `isearch-mode' check, the buffer is indeed displayed. The problem is that since it doesn't exit isearch, you end up isearching in the new buffer. which seems like an argument for aborting the isearch (or an argument for rethinking isearch, but I don't think we want to do that right now). One way or the other, we should reach a decision and fix the bug. 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
Richard Stallman <[EMAIL PROTECTED]> writes: > So can we install the patch to server.el to terminate > isearch-mode and get on with the release. PLEASE!!! > > Your shouting does not convince me. But it should not keep you from considering the arguments Kim and others (who actually use emacsserver) brought forth. -- David Kastrup ___ 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
So can we install the patch to server.el to terminate isearch-mode and get on with the release. PLEASE!!! Your shouting does not convince me. ___ 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
> Why not do this as with `isearch-allow-scroll' t? I don't know > server.el, maybe something flashy like ... Yuck. > (cond > ((minibufferp)) > ((buffer-local-value 'isearch-mode (current-buffer)) > (let ((isearch-point (point)) > (new-window (split-window))) > ;; ... do the server-switch-buffer stuff in the new window and > ;; return to the old ... > (isearch-adjust-after-window-configuration-change isearch-point) > (t ... This does not obey server-window. Adjusting it to obey server-window will make the code even more twisted. 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
Why not do this as with `isearch-allow-scroll' t? I don't know server.el, maybe something flashy like ... (cond ((minibufferp)) ((buffer-local-value 'isearch-mode (current-buffer)) (let ((isearch-point (point)) (new-window (split-window))) ;; ... do the server-switch-buffer stuff in the new window and ;; return to the old ... (isearch-adjust-after-window-configuration-change isearch-point) (t ... (defun isearch-adjust-after-window-configuration-change (isearch-point) (let ((ab-bel (isearch-string-out-of-window isearch-point))) (if ab-bel (isearch-back-into-window (eq ab-bel 'above) isearch-point) (goto-char isearch-point))) (isearch-update)) ... and when the window is too small print a message. ___ 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: > and if I remove the `isearch-mode' check, the buffer is indeed displayed. > The problem is that since it doesn't exit isearch, you end up isearching in > the new buffer. I bet someone will argue that this is the right thing to do when emacsclient is used :-) Maybe that's why normal buffer switching terminates isearch :-) Not terminating isearch-mode means fixing yet unknown problems in isearch -- for no good reason, since everybody (minus one) here agrees that terminating isearch-mode is TRT. So can we install the patch to server.el to terminate isearch-mode and get on with the release. PLEASE!!! -- 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. Duh, it was right there staring in my face in server-process-filter: (unless (or isearch-mode (minibufferp)) (server-switch-buffer (nth 1 client)) (run-hooks 'server-switch-hook) (unless nowait (message "%s" (substitute-command-keys "When done with a buffer, type \\[server-edit]") and if I remove the `isearch-mode' check, the buffer is indeed displayed. The problem is that since it doesn't exit isearch, you end up isearching in the new buffer. Stefan PS: Interestingly, since the `isearch-mode' variable is buffer local, I can circumvent the check: emacsclient --eval '(pop-to-buffer "someotherbuffer")' emacsclient this will show the buffer (and will move the isearch session to this buffer), despite the isearch-mode check. ___ 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/14/07, Richard Stallman <[EMAIL PROTECTED]> wrote: Those facts do not present an argument for that conclusion. Well, my "conclusion" is that most people expects emacsclient to interrupt, and the fact is that everyone who has expressed an opinion in this thread seems (if I'm reading correctly) to support that idea. You excepted, of course. 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
Also: the change to abort recursive edits is in CVS since 2006-11-27, so there's been four pretests in between, and not a single complain about emacsclient interrupting. On the contrary, this thread shows that some people *expects* it doing so. Those facts do not present an argument for that conclusion. ___ 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
David Kastrup wrote: [EMAIL PROTECTED] (Kim F. Storm) writes: "Juanma Barranquero" <[EMAIL PROTECTED]> writes: On 3/13/07, Richard Stallman <[EMAIL PROTECTED]> wrote: I don't think that an action from outside Emacs is comparable to one done by typing Emacs commands. It could be argued (and I would) that typing "emacsclient myfile" or clicking in a file associated to emacsclient is comparable to typing Emacs commands. The immediate response I expect from both of them is getting the Emacs frame on top (server-raise-frame defaults to t for a good reason) and ready to accept my input. I agree. Emacsclient don't just open files -- the user has to request that somehow. Also, most commands in Emacs will interrupt isearch. So I see NO reason for Emacsclient not to interrupt isearch. Let's make that change, and get on with the release! Seconded. I find myself unable to comprehend Richard's rationale for a different behavior here. I agree too. The file is open through Emacsclient is still opened by a user decision and action. ___ 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
[EMAIL PROTECTED] (Kim F. Storm) writes: > "Juanma Barranquero" <[EMAIL PROTECTED]> writes: > >> On 3/13/07, Richard Stallman <[EMAIL PROTECTED]> wrote: >> >>> I don't think that an action from outside Emacs is comparable to one >>> done by typing Emacs commands. >> >> It could be argued (and I would) that typing "emacsclient myfile" or >> clicking in a file associated to emacsclient is comparable to typing >> Emacs commands. The immediate response I expect from both of them is >> getting the Emacs frame on top (server-raise-frame defaults to t for a >> good reason) and ready to accept my input. > > I agree. > > Emacsclient don't just open files -- the user has to request that somehow. > > Also, most commands in Emacs will interrupt isearch. > > So I see NO reason for Emacsclient not to interrupt isearch. > > Let's make that change, and get on with the release! Seconded. I find myself unable to comprehend Richard's rationale for a different behavior here. -- David Kastrup ___ 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/13/07, Richard Stallman <[EMAIL PROTECTED]> wrote: > >> I don't think that an action from outside Emacs is comparable to one >> done by typing Emacs commands. > > It could be argued (and I would) that typing "emacsclient myfile" or > clicking in a file associated to emacsclient is comparable to typing > Emacs commands. The immediate response I expect from both of them is > getting the Emacs frame on top (server-raise-frame defaults to t for a > good reason) and ready to accept my input. I agree. Emacsclient don't just open files -- the user has to request that somehow. Also, most commands in Emacs will interrupt isearch. So I see NO reason for Emacsclient not to interrupt isearch. Let's make that change, and get on with the 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: Strange emacsclient behaviour during use of isearch
On 3/13/07, Richard Stallman <[EMAIL PROTECTED]> wrote: I don't think that an action from outside Emacs is comparable to one done by typing Emacs commands. Also: the change to abort recursive edits is in CVS since 2006-11-27, so there's been four pretests in between, and not a single complain about emacsclient interrupting. On the contrary, this thread shows that some people *expects* it doing so. 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
On 3/13/07, Richard Stallman <[EMAIL PROTECTED]> wrote: I don't think that an action from outside Emacs is comparable to one done by typing Emacs commands. It could be argued (and I would) that typing "emacsclient myfile" or clicking in a file associated to emacsclient is comparable to typing Emacs commands. The immediate response I expect from both of them is getting the Emacs frame on top (server-raise-frame defaults to t for a good reason) and ready to accept my input. 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
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: 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: 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
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
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
>> 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
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
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: 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: 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
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: 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: 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: 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: 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
> 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
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 , 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 M-< C-s ; ; C-x k C-x k M-x r e p o r t SPC b 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
