Re: Unsafe variable in a saved *compilation* buffer
> Maybe the proposition by to only add the > default-directory file-local variable when the file is saved to > a different directory would make it possible to reconcile our > conflicting needs. > Yes, it would. I find the idea that saving modifies the buffer somewhat > disturbing, but time-stamp and VC can do that, so it is not outrageous. > Would you like to implement that? I'm kinda swamped right now, so if anybody else wants to beat me to it, feel free. 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
> No, the problem is not special to me or my usage. Wha makes you so sure? Saving a compilation buffer outside the directory where compilation was done is a simple use of a well-known feature, not an obscure combination. I can't be the only one who does it. ___ 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.e. by setting default-directory in the file-local variables you make the relative file names fail when I access the saved compilation buffer under a different name (e.g. via Tramp, NFS, sshfs, ...). I see your point about that. Maybe the proposition by to only add the default-directory file-local variable when the file is saved to a different directory would make it possible to reconcile our conflicting needs. Yes, it would. I find the idea that saving modifies the buffer somewhat disturbing, but time-stamp and VC can do that, so it is not outrageous. Would you like to implement that? ___ 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 tend to agree, but I think the most consistent rule is: if point has > changed, it's a drag. It clearly wasn't a good rule in the OP's situation. That problem was due to a bug that made Emacs scroll when it should not have scrolled. When the scrolling is correct, and expected, it's a different situation. ___ 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: scrolling up via mouse drag doesn't work
> On Wed, 14 Mar 2007 09:59:09 +, David Reitter <[EMAIL PROTECTED]> > said: > In a buffer with more than one page of text, move point to the end. > Turn off tool-bar-mode if it isn't turned off. Display only one > window in the frame. > Then click and drag the mouse over the upper boundary of the window > (and frame). This should cause Emacs to scroll the buffer, analogous > to what it does when clicking and dragging over the bottom of the > window. > However, it doesn't scroll. > When a tool-bar is displayed, scrolling works as intended. Thanks for the report. Could you try the patch below? YAMAMOTO Mitsuharu [EMAIL PROTECTED] *** src/macterm.c.~1.210.~ Sat Mar 10 15:26:33 2007 --- src/macterm.c Wed Mar 14 19:55:12 2007 *** note_mouse_movement (frame, pos) *** 4501,4507 rif->define_frame_cursor (frame, frame->output_data.mac->nontext_cursor); } - return 1; } /* Has the mouse moved off the glyph it was on at the last sighting? */ if (frame != last_mouse_glyph_frame --- 4501,4506 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
scrolling up via mouse drag doesn't work
In a buffer with more than one page of text, move point to the end. Turn off tool-bar-mode if it isn't turned off. Display only one window in the frame. Then click and drag the mouse over the upper boundary of the window (and frame). This should cause Emacs to scroll the buffer, analogous to what it does when clicking and dragging over the bottom of the window. However, it doesn't scroll. When a tool-bar is displayed, scrolling works as intended. I have produced this bug with a new build (CVS from last night, Carbon) as well. In GNU Emacs 22.0.93.1 (powerpc-apple-darwin7.9.0, Carbon Version 1.6.0) of 2007-02-14 on rodrigues.inf.ed.ac.uk X server distributor `Apple Computers', version 10.4.9 configured using `configure '--without-x' '--prefix=/usr/local'' 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: nil locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Lisp Interaction 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 transient-mark-mode: identity Recent input: M-v C-y C-y C-y C-y C-y Recent messages: (/Applications/Emacs.app/Contents/MacOS/Emacs) For information about the GNU Project and its goals, type C-h C-p. [2 times] Loading encoded-kb...done call-interactively: Beginning of buffer Mark set [5 times] Loading emacsbug... Loading regexp-opt...done Loading emacsbug...done -- http://aquamacs.org -- Aquamacs: Emacs on Mac OS X http://aquamacs.org/donate -- Could we help you? Return the favor and support the Aquamacs Project! ___ 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
