Re: display-buffer-reuse-frames makes View-quit abnormal
Please CC this and all related postings to emacs-pretest-bug. > I am not clear about the all the innards of the process of view quit, but > what about: > just let > >>`help-mode' after (C-h f ...) has done > > >> (setq view-exit-action (lambda (buffer) >>(or (window-minibuffer-p (selected-window)) >> (one-window-p t) >> (delete-window `view-exit-action' should care about BUFFER and not about any windows. > but let > `quit-window' > invoked by `view-mode-exit' go without > > >>(switch-to-buffer (other-buffer, `quit-window' is called by functions that have no relation to help, help-mode, or view-mode. It might be called interactively by you. Hence, we can't change that without giving it either an additonal, optional argument or breaking other code. > and let > view-mode-exit' go without > > >> (if (window-live-p old-window) ; still existing window >> (select-window old-window)). The same goes here: `view-mode-exit' is used by other functions as well. Usually, selecting old-window won't harm. That's the window where you called C-h f from. > Following this line, the effective (delete-window) will be done in the help > window, with the original buffer in the other window, and then all is > restored. Your approach would work for help-mode (it should even work if we _did_ switch buffers in `quit-window' - the window gets deleted anyway). It might break other modes though that don't set `view-exit-action' and still expect old-window to get reselected. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: two View-mode "quit" bugs
> I've found what I believe to be two bugs in View-quit. > I have two frames visible. In one frame I type: C-h m C-x o C-x 1. > This makes the only window in this frame show the *Help* buffer. > Now I type "q", and the frame iconifies. After C-h m `view-return-to-alist' will contain references for the *Help* window W1 and the original window W2 as (W1 W2 . t) which essentially means if W1 still exists try to delete it when you're done. C-x 1 makes `one-window-p' non-nil for W1 and `view-mode-exit' will subsequently fail to delete W1 due to ((not (one-window-p t)) (delete-window)) In the sequel it sticks to the rule ;; If a frame is removed by iconifying it, then the window is not ;; really lost. and iconifies the frame. Note that `view-exit-action' fails to do anything here since `one-window-p' is non-nil. > I find this quite surprising. I would much prefer View-quit to simply > act like bury-buffer. I certainly never want it to iconify the frame. If you had set `view-remove-frame-by-deleting' to a non-nil value, `view-mode-exit' would have deleted the frame. Burying the buffer might be a good idea but Emacs would then have to display another buffer in W1. Maybe the one from W2. However, information about that buffer was never recorded and W2 is dead. Also, if you had displayed another buffer in W2 in the meantime you'd still get the buffer displayed in W2 when you invoked C-h m. > Now, I deiconify this frame. Then I switch to the other frame, and in > that frame type C-x b *Help* RET C-x 1. This makes the only window in > the other frame display the *Help* buffer. > > Now I type "q". Nothing changes. Again I expected the help buffer to > be buried. C-x b *Help* does _not_ change the exit information established above, namely (W1 W2 . t). `view-mode-exit' notes that W1 is _not_ the window displaying *Help* in the second conjunct of (if (and (window-live-p (setq window (car (car alist (eq buffer (window-buffer window))) and refrains from doing anything. `view-exit-action' won't do anything since `one-window-p' is non-nil. As a rule, you can expect "q" DTRT iff you created the help window with a help command. Doing the right thing here seems difficult. We'd have to add a function to `window-configuration-change-hook' and, for every buffer, update any information for all windows on `view-return-to-alist'. Comments welcome. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display-buffer-reuse-frames makes View-quit abnormal
> After `(setq display-buffer-reuse-frames t)', `C-h f'(or `C-h v' and the > alike) to view help, `C-x o' to jump to the help window, `q' to quit view > mode, then I find `View-quit' does not restore window and buffer to > previous > state as usual, instead Emacs pops one of other buffers. Thank you for reporting this. The behavior you experience is due to the following changes: 2000-08-08 Gerd Moellmann <[EMAIL PROTECTED]> * help.el (print-help-return-message): When display-buffer-reuse-frames is set, let the help window been quit, instead of deleting it, which might delete a reused frame. and 2006-04-18 Richard Stallman <[EMAIL PROTECTED]> * help-mode.el (help-mode): Set view-exit-action to delete window. and 2006-05-01 Richard Stallman <[EMAIL PROTECTED]> * help-mode.el (help-mode): view-exit-action calls delete-window only when it is safe and possible. Now with `display-buffer-reuse-frames' non-nil `print-help-return-message' (called by C-h f ...) adds (W1 W2 . 'quit-window) to `view-return-to-alist'. With `display-buffer-reuse-frames' nil it would add (W1 W2 . t) instead, where in both cases W1 is the help window, W2 the original window, and t means delete W1 when done, 'quit-window call that function. When you type "q" in window W1 the (contrived code of) `quit-window' invoked by `view-mode-exit' will do (switch-to-buffer (other-buffer switching in W1 to some buffer not shown in W2. On the other hand invoking `help-mode' after (C-h f ...) has done (setq view-exit-action (lambda (buffer) (or (window-minibuffer-p (selected-window)) (one-window-p t) (delete-window locally in *Help*. After invoking `quit-window' as described above `view-mode-exit' does (if (window-live-p old-window) ; still existing window (select-window old-window)) where old-window is W2. Since W2 is still live it gets selected. Finally, `view-mode-exit' calls `view-exit-action' with BUFFER the still existing *Help* buffer and W2 selected. `view-exit-action' does not pay attention to BUFFER and deletes the selected window W2. You are left with W1 showing a completely unrelated buffer. Reverting the changes above would give the correct behavior in _this_ case. Keeping Gerd's change means that you would have to live with a frame with W2 showing the original buffer and W1 the one selected by `quit-window'. Richard's change could then be modified by doing (setq view-exit-action (lambda (buffer) (or (window-minibuffer-p (selected-window)) (one-window-p t) (not (eq (window-buffer) buffer)) (delete-window though I think that `view-exit-action' should _not_ fiddle with windows. Comments welcome. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: `C-h f' and `C-h v' don't split window anymore?
`C-h f' and `C-h v' used to split window and give help information in another window, why this behavior changed? Now it doesn't split window anymore and gives help information in a window occupy the whole frame. Should have been fixed now. Please try again and tell me whether it works as expected. Thanks, martin. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: README.unicode in GNU Emacs 23
Fontset: -*-*-*-*-*-*-*-*-*-*-*-*-fontset-default Fontset: -*-*-medium-r-normal--10-*-*-*-*-*-fontset-hiraginokaku Fontset: -*-*-medium-r-normal--12-*-*-*-*-*-fontset-hiraginokaku Fontset: -*-*-medium-r-normal--14-*-*-*-*-*-fontset-hiraginokaku Fontset: -*-*-medium-r-normal--16-*-*-*-*-*-fontset-hiraginokaku And loading this file creates in *Messages* the warning: Ignoring unknown mode `*-mode' So it seems to be more of a bug with local-variables ... ... funny bug. In general there seems nothing peculiar about fontset specification we could use to inhibit `set-auto-mode-1' finding a mode (the special case is trivial to fix). We could drop a note somewhere to say that such specifications should not occur in the first two lines of a file. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-unicode-2: ido doesn't work
with (ido-mode t), emacs complains while C-x C-f: ad-cache-id-verification-code: Symbol's value as variable is void: ad-special-forms Since ido-mode doesn't use advice this has, a priori, nothing to do with ido (try with Emacs -Q). I suspect you load something in your .emacs which advices `find-file'. Please try to find what, see why it interacts badly with `find-file' and ido, and tell us about your findings. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
>mode: font-lock
>font-lock-defaults: (("^\\S-.*:$"))
I must say that I don't know why this has changed.
Does the patch below fix your problem?
>>
>>>No, nothing changed. If I use font-lock-keywords I get the message:
>>> "Toggling font-lock-mode off; better pass an explicit argument."
>>
>>That looks correct: since font-lock is now enabled by default your "mode:
>>font-lock" might very well end up turning the mode OFF, and this is what the
>>message tells you.
>
>
> Nonetheless, the behaviour does not change. Either with your patch:
> - (font-lock-eval-keywords keywords))
> + (font-lock-eval-keywords (or keywords font-lock-keywords)))
>
> or without, the behaviour is the same. Specifically:
>
> - if I remove the "mode: font-lock" line from the local variables, no
> fontification is done
> - else, if "mode: font-lock" is there:
> + if I use font-lock-keywords I get the above message
> + if I use font-lock-defaults I get fontification and no messages
Why didn't you try the very first solution I proposed? You have to
activate font-lock-mode _after_ setting the defaults, like this
# Local Variables:
# font-lock-defaults: (("^\\s-*:0" "##+"))
# mode: font-lock
# End:
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: shell-script mode vs. quoted apostrophe
> +("\\(\\)'" (1 (sh-font-lock-backslash-quote)))
Then we might do
> +("\\(\\)" (1 (sh-font-lock-backslash)))
as well.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> (set (make-local-variable 'font-lock-keywords) > ! (font-lock-eval-keywords (or keywords font-lock-keywords))) Wouldn't this mean that old keywords survive a major-mode change? What about the companions in `font-lock-defaults'? In general I think all those should survive iff they have been hacked before. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: shell-script mode vs. quoted apostrophe
> shell-script mode thinks everything after the quoted apostrophe is
> quoted at least judging from the color.
>
> GNU Emacs 22.0.95.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
2007-03-03 on pacem, modified by Debian
>
> #!/bin/sh -ex
> test $# -eq 3 ||{ echo $0: couldn\'t look it up in $f 1>&2; exit 55;}
> exec pppd user $1 $extra_opts connect \
> "chat -v -f /etc/chatscripts/generic -T $2"
Most shell scripts require that within single quotes _all_ characters
get quoted, including the backslash. Emacs resolves this by removing
the escape property for a backslash whenever it appears before a single
quote due to the following (inherently wrong) specification within
`sh-font-lock-syntactic-keywords':
;; In a '...' the backslash is not escaping.
("\\(\\)'" 1 ,sh-st-punc)
This strips the escape property from _any_ backslash preceding a single
quote (since it does not render backslashes non-escaping when they are
followed by any other character within single quotes the specification
is obviously wrong, without visible consequences, though). In your case
things go wrong outside a single quote environment: The backslash in
couldn\'t gets punctuation syntax, doesn't escape the subsequent quote,
which consequently starts quoting everything after it ...
I'm afraid that solving this is non-trivial. It could be done by
calling the parser in font-lock's syntactic keyword pass but this would
render font-lock unbearably slow. It should be done in the parser but
I'm not sure whether shell scripts warrant such a modification.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: recentf-auto-cleanup hangs for sudo-type tramp files
> if a file has been visited with tramp and sudo > (e.g. "/sudo:[EMAIL PROTECTED]:/etc/crontab"), and is automatically added to > recentf-list, then `recentf-auto-cleanup' hangs. > > Apparently `file-readable-p' (which is in `recentf-keep' by default) is the > reason. Looks like a bug within find_file_name_handler. Could you try to debug `file-readable-p' to tell us precisely where it hangs? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> I had this in my local variables section:
>
> mode: font-lock
> font-lock-keywords: ("^\\S-.*:$")
>
> which worked in Emacs 21, but does not work any more in Emacs 22.
It's a regression though personally I'd avoid placing font-lock
directives in the local variables section and would never permit Emacs
hacking them. It would not be overly difficult to put something like a
locally-hacked property on `font-lock-keywords' and have font-lock obey
that rather than evaluating `font-lock-defaults' but I'm afraid we've
missed this opportunity.
> I solved the problem by writing instead:
>
> mode: font-lock
> font-lock-defaults: (("^\\S-.*:$"))
>
> I don't know whether this should be mentioned in the NEWS.
It should be mentioned. Maybe Stefan can enumerate the directives that
can't be set any more.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
I think it's cleaner to put the condition-case outside. Does this work for you? Good. Eventually, someone could try to avoid theses scans when it's easy to determine that they fail. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> I couldn't reproduce it on Mac OS X. It only shows an error like > > forward-list: Scan error: "Containing expression ends prematurely" OK. To prevent this I'd apply something like the attached patch (low priority). We also might consider not running point-entered/-left hooks when running a point-entered/-left hook (as with before-/after-change-functions). *** sgml-mode.elMon May 14 23:19:20 2007 --- sgml-mode.elMon May 28 11:51:12 2007 *** *** 894,911 (defun sgml-point-entered (x y) ;; Show preceding or following hidden tag, depending of cursor direction. ! (let ((inhibit-point-motion-hooks t)) ! (save-excursion ! (message "Invisible tag: %s" ! ;; Strip properties, otherwise, the text is invisible. ! (buffer-substring-no-properties ! (point) ! (if (or (and (> x y) !(not (eq (following-char) ?<))) ! (and (< x y) !(eq (preceding-char) ?>))) ! (backward-list) ! (forward-list))) (defun sgml-validate (command) --- 894,917 (defun sgml-point-entered (x y) ;; Show preceding or following hidden tag, depending of cursor direction. ! (let* ((inhibit-point-motion-hooks t) !(tag-string ! (save-excursion ! ;; Strip properties, otherwise, the text is invisible. ! (buffer-substring-no-properties !(point) !(if (or (and (> x y) ! (not (eq (following-char) ?<))) !(and (< x y) ! (eq (preceding-char) ?>))) !(condition-case nil !(backward-list) ! (error (point))) ! (condition-case nil ! (forward-list) !(error (point ! (unless (string-equal tag-string "") ! (message "Invisible tag: %s" tag-string (defun sgml-validate (command) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
I could reproduce this, but shouldn't the above `let' be `let*'? My bad, let*'s ignore this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
>> Reports from Windows users still wanted. > > > Works here, thanks. Sorry, no. With a newline after the and moving down and back that line I get sgml-point-entered: Lisp nesting exceeds `max-lisp-eval-depth' If I define `sgml-point-entered' as (defun sgml-point-entered (x y) ;; Show preceding or following hidden tag, depending of cursor direction. (let ((inhibit-point-motion-hooks t) (tag-string (save-excursion ;; Strip properties, otherwise, the text is invisible. (buffer-substring-no-properties (point) (if (or (and (> x y) (not (eq (following-char) ?<))) (and (< x y) (eq (preceding-char) ?>))) (condition-case nil (backward-list) (error (point))) (condition-case nil (forward-list) (error (point (unless (string-equal tag-string "") (message "Invisible tag: %s" tag-string it stalls as before with 100% CPU consumption. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
Reports from Windows users still wanted. Works here, thanks. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> This patch does not work for me. Because it didn't apply? > I think we should go with the approach suggested by YAMAMOTO > Mitsuharu, which does work. It may not be the most general > approach---as you pointed out, exotic user-set mode lines might cause > failures---but such situations are sufficiently rare that I think it > is good enough for 22.1. Agreed. Let's see whether it fixes Tak Ota's table cell menu problem too. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> BTW, as far as I can tell, this is a satisfactory permanent solution, > not just a temporary hack; so we might as well check it into the trunk > too. However, we may want to overhaul the way column-number-works, > after the release, to avoid problems of this sort. Suppose someone wants to put the length of the current line into the mode-line (or the name of the current function into the frame-title). Running point-entered/-left hooks has to be avoided for all sorts of code that simply wants to "analyze" buffer text. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> This patch works on Mac OS X for the original problem (without my > previous patch). Adding specbind and unbind_to around the > `current_column' in redisplay_internal also works. I'm still uncertain whether this would catch all occurrences. The most simple patch I can come up with is specbinding it within `display_mode_line' since that's causing the present problems. Please test it (no other patches needed). If there are more occurrences left I'll have move it to `display_mode_element'. *** xdisp.c Thu May 3 08:00:52 2007 --- xdisp.c Sun May 27 17:21:18 2007 *** *** 16664,16669 --- 16664,16667 struct it it; struct face *face; int count = SPECPDL_INDEX (); + specbind (Qinhibit_point_motion_hooks, Qt); init_iterator (&it, w, -1, -1, NULL, face_id); /* Don't extend on a previously drawn mode-line. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
>>>SET_PT_BOTH (opoint, opoint_byte); > > >>still spoils everything on Windows. Commenting out that line works, >>though. > > > Hmm, I couldn't test on Windows, and my previous patch worked on Mac > OS X (both X11 and Carbon) and Solaris for the original problem. Hence the original problem is present on these platforms? Anyway, I'll have to wait what Windows XP people say about this. >>I continue to have no idea how current_column gets called with >>Qinhibit_point_motion_hooks not bound to Qt here ... > > > Maybe you can find such traces by setting a breakpoint to > current_column with the condition `Vinhibit_point_motion_hooks == > Qnil'. I found the following cases: > > pos_visible_p -> display_mode_line > echo_area_display -> redisplay_mode_lines -> display_mode_lines -> display_mode_line Thanks, I'm aware of these. I don't understand why pos_visible_p should be called by redisplay. For the second one I earlier tried to specbind Qinhibit_point_motion_hooks around it - to no avail. I have to retry. In any case this would just solve the current_column problem. There are, however, no restrictions as to what the modeline is allowed to display. Hence, this problem may raise it's ugly head whenever modeline calculations set point. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> Unless someone who is familiar with this matter gives a better one, > I'd propose the following minimal and conservative change to avoid > regression at this stage. It's too minimal. The following > SET_PT_BOTH (opoint, opoint_byte); still spoils everything on Windows. Commenting out that line works, though. I continue to have no idea how current_column gets called with Qinhibit_point_motion_hooks not bound to Qt here ... Anyway, could people on Windows affected by this please try whether it works with Yamamoto's change or the attached one? *** indent.cMon Apr 9 09:24:48 2007 --- indent.cSun May 27 11:02:30 2007 *** *** 522,528 scan_newline (PT, PT_BYTE, BEGV, BEGV_BYTE, -1, 1); current_column_bol_cache = PT; scan = PT, scan_byte = PT_BYTE; ! SET_PT_BOTH (opoint, opoint_byte); next_boundary = scan; if (tab_width <= 0 || tab_width > 1000) tab_width = 8; --- 522,533 scan_newline (PT, PT_BYTE, BEGV, BEGV_BYTE, -1, 1); current_column_bol_cache = PT; scan = PT, scan_byte = PT_BYTE; ! /* Restore point to the original value. */ ! TEMP_SET_PT_BOTH (opoint, opoint_byte); ! /* The following commented out to avoid that SET_PT_BOTH runs point-entered ! hooks when displaying the mode-line. If this forms a regression, restore ! it and find out why these hooks are run during redisplay at all. */ ! /*** SET_PT_BOTH (opoint, opoint_byte); ***/ next_boundary = scan; if (tab_width <= 0 || tab_width > 1000) tab_width = 8; ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
>>With `debug-on-error' t you do get an error from `forward-list'? > > > Yes, but I don't see the "not accepting any operations" or "continuous > redisplay" behaviors. Maybe that part of the bug is specific to > Windows. I think there are three bugs: (1) The list scanning bug in `sgml-point-entered'. It shouldn't be a problem to fix that, maybe it's even a non-issue once (2) gets done. (2) A bug in redisplay. Somewhere Qinhibit_point_motion_hooks doesn't get bound to Qt but so far I was not able to find out where. There's evidence that the bug shows up when `column-number-mode' is enabled, `current-column' is called and triggers sgml's point-entered hook. Maybe it's got something to do with sgml's invisibility properties. Kim would find this in five minutes, but where are thou ... (3) A bug that may render Emacs disfunctional on Windows and is related to menus. I suspect this is a consequence of (2) which causes Emacs to consume ~100% CPU and maybe interacts badly with something w32 specific like menu_free_timer (a very wild guess, I know). I conjecture that (2) and (3) are also responsible for the behavior reported by Tak Ota for his table cell menu entry. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
>>In GNU Emacs 22.0.990 on Windows, the following operation causes >>contiguous redisplay of the menu and beeps. And Emacs doesn't >>accept any operations for a while. >> >> emacs -q >> M-x html-mode ;; in the scratch buffer >> M-x column-number-mode >> >> C-u 8 C-b ;; move back the cursor on `>' of "" >> C-c C-i ;; runs the command sgml-tags-invisible > > > I can't reproduce this on GNU Emacs 22.0.990.2 (i686-pc-linux-gnu). With `debug-on-error' t you do get an error from `forward-list'? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> > In GNU Emacs 22.0.990 on Windows, the following operation causes > > contiguous redisplay of the menu and beeps. And Emacs doesn't > > accept any operations for a while. > > > > emacs -q > > M-x html-mode ;; in the scratch buffer > > M-x column-number-mode > > > > C-u 8 C-b ;; move back the cursor on `>' of "" > > C-c C-i ;; runs the command sgml-tags-invisible > > In fact these are two problems: To solve the first one could specbind > Vinhibit_point_motion_hooks to Qt before calculating the column number. > The second is that sgml-mode shouldn't scan list forwards before a ">". Could someone test whether this happens on non-Windows OSs too? AFAICT the bug is (1) caused by repeatedly running a point-entered hook (but I can't detect whether it is run by something in redisplay) and (2) hence could be related to the table cell menu bug reported earlier by Tak Ota. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Contiguous redisplay of the menu and beeps
> In GNU Emacs 22.0.990 on Windows, the following operation causes > contiguous redisplay of the menu and beeps. And Emacs doesn't > accept any operations for a while. > > emacs -q > M-x html-mode ;; in the scratch buffer > M-x column-number-mode > > C-u 8 C-b ;; move back the cursor on `>' of "" > C-c C-i ;; runs the command sgml-tags-invisible In fact these are two problems: To solve the first one could specbind Vinhibit_point_motion_hooks to Qt before calculating the column number. The second is that sgml-mode shouldn't scan list forwards before a ">". ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo gone in dired buffers
This is a change with respect to Emacs 21, and I don't think anyone feels that it is necessary in practice, while some are against it. I think it should be reverted. I think it is just plain wrong to undo a revert. We could introduce an option `revert-discard-undo'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: "Local variables list is not properly terminated"
> ;; Declaring and initializing local variables: > -- Declaring and initializing local variables: These lines are problematic. You should remove the colons, at least, otherwise Emacs will consider them as start of the local variables section and search for its end. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-mode fails in non-existing directory
Please install your patch. Installed in the trunk. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ffap-list-directory prompt too like real dired
ffap-list-directory is nice but it misleadingly gives the same prompt as dired, "Dired file or URL:" You mean "the same prompt as dired-at-point". I can offer the attached patch. Could you try it? *** ffap.el Sun Apr 8 09:27:20 2007 --- ffap.el Tue May 15 08:27:20 2007 *** *** 1793,1799 ;; Extra complication for the temporary highlighting. (unwind-protect (ffap-read-file-or-url !(if ffap-url-regexp "Dired file or URL: " "Dired file: ") (prog1 (setq guess (or guess (let ((guess (ffap-guesser))) --- 1793,1803 ;; Extra complication for the temporary highlighting. (unwind-protect (ffap-read-file-or-url !(cond ! ((eq ffap-directory-finder 'list-directory) !"List directory (brief): ") ! (ffap-url-regexp "Dired file or URL: ") ! (t "Dired file: ")) (prog1 (setq guess (or guess (let ((guess (ffap-guesser))) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-mode fails in non-existing directory
> Also, I call flyspell-mode in a major-mode hook (or is there anything > wrong with that?), so the error occurs before I even could save it. I understand. >>> ispell seems to work around this for synchronous processes, but >>> apparently not for `start-process'. >>> >> >> I presume both ispell and flyspell use asynchronous processes on your >> system. Moreover the same error should be issued for synchronous ones. >> In fact, both `start-process' and `call-process' have identic code here: >> > > True, those two have identical code. Yet `ispell-call-process' is a > wrapper used by ispell to "defend against bad `default-directory'". > There is no such wrapper for in `ispell-start-process'. In fact I told Richard about that but forgot to check his patches. Please try the attached one. *** ispell.el Fri Mar 23 08:46:26 2007 --- ispell.el Mon May 14 14:15:00 2007 *** *** 2483,2489 (defun ispell-start-process () "Start the ispell process, with support for no asynchronous processes. Keeps argument list for future ispell invocations for no async support." ! (let (args) ;; Local dictionary becomes the global dictionary in use. (setq ispell-current-dictionary (or ispell-local-dictionary ispell-dictionary)) --- 2483,2493 (defun ispell-start-process () "Start the ispell process, with support for no asynchronous processes. Keeps argument list for future ispell invocations for no async support." ! (let ((default-directory default-directory) ! args) ! (unless (and (file-directory-p default-directory) !(file-readable-p default-directory)) ! (setq default-directory (expand-file-name "~/"))) ;; Local dictionary becomes the global dictionary in use. (setq ispell-current-dictionary (or ispell-local-dictionary ispell-dictionary)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-mode fails in non-existing directory
> after finding a new file in a not yet created directory, flyspell-mode
> fails with:
>
> (file-error "Setting current directory" "no such file or directory"
> "/Users/nik/Desktop/foo/")
True, but when "finding" that file Emacs should have told you
Use M-x make-directory RET RET to create the directory and its parents
which you apparently ignored ;-) and when trying to save the buffer Emacs
would tell you
basic-save-buffer-2: ...: no such directory
> ispell seems to work around this for synchronous processes, but apparently not
> for `start-process'.
I presume both ispell and flyspell use asynchronous processes on your
system. Moreover the same error should be issued for synchronous ones.
In fact, both `start-process' and `call-process' have identic code here:
current_dir
= expand_and_dir_to_file (Funhandled_file_name_directory (current_dir),
Qnil);
if (NILP (Ffile_accessible_directory_p (current_dir)))
report_file_error ("Setting current directory",
Fcons (current_buffer->directory, Qnil));
What would you want Emacs to do instead?
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: eval-last-sexp narrows buffer on error
> I've tried. From what I can tell `specpdl' isn't being wound back > afterwards, so `save_restriction_restore' is never called. > > In fact, this apparently is the case after any error (unless caught by > `condition-case'), so `specpdl' grows bigger and bigger. Is that > supposed to happen?? > > The functions called by `error' are > * signal > ** find_handler_clause > *** call_debuger I'm too silly. Try to run with `debug-on-error' and `eval-expression-debug-on-error' both nil. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: eval-last-sexp narrows buffer on error
> Calling `eval-last-sexp' on: > "\u" > correctly causes the error "Non-hex digit used for Unicode escape", but > unexpectedly leaves the buffer narrowed to point-min and point. It's a problem with `save-restriction'. Take: (with-current-buffer (get-buffer-create "*foo*") (delete-region (point-min) (point-max)) (insert "foo\nbar\nfoo\n") (save-restriction (narrow-to-region (line-beginning-position -1) (line-end-position -1)) (error ""))) It will leave the buffer narrowed although the doc-string of `save-restriction' says: The old restrictions settings are restored even in case of abnormal exit (throw or error). AFAICT Emacs 20 DTRT here, Emacs 21 and 22 don't. Could you try to debug it? You can side-step the problem with something like (with-current-buffer (get-buffer-create "*foo*") (delete-region (point-min) (point-max)) (insert "foo\nbar\nfoo\n") (condition-case err (save-restriction (narrow-to-region (line-beginning-position -1) (line-end-position -1)) (error "")) (error err (widen) (error (error-message-string err) which does the wrong thing when the buffer was already narrowed before executing the `save-restriction' form. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: up-list gives error inside strings
> Using this, it was very easy to get the function I wanted. Calling `syntax-ppss' repeatedly can become costly for deeply nested positions. I'd propose something like the below: (defun up-list-forward (arg) "Move forward out of one level of parentheses. With arg, do this that many times. A negative argument means move backward but still to a less deep spot." (interactive "p") (or arg (setq arg 1)) (unless (zerop arg) (let* ((pos (point)) (abs (abs arg)) (ppss (syntax-ppss pos)) (depth (nth 0 ppss)) (ninth (nth 9 (syntax-ppss pos (if (< depth abs) (error "Reached top level") (goto-char (nth (- depth abs) ninth)) (unless (< arg 0) (condition-case nil (forward-sexp) (scan-error ;; Improve as soon as `scan-error' gets documented somewhere. (goto-char pos) (error "No enclosing list" ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
>>What happens if you set (customize) `whitespace-check-indent-whitespace' >>_before_ you toggle `whitespace-global-mode'? > > > No difference; sequences of 8 spaces in indentation are still highlighted. I don't understand. If my .emacs is (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(whitespace-check-indent-whitespace nil)) and I launch Emacs without arguments, activate `whitespace-global-mode', and open some file, sequences of eight spaces at bol do not get highlighted. Maybe someone else can check this. > * whitespace-check-indent-whitespace--when non-nil--doesn't play >nicely with indent-tabs-mode; this has been the case for as long as >I know. If my .emacs is (custom-set-variables ;; custom-set-variables was added by Custom. ;; If you edit it by hand, you could mess it up, so be careful. ;; Your init file should contain only one such instance. ;; If there is more than one, they won't work right. '(indent-tabs-mode nil)) and I launch Emacs without arguments, activate `whitespace-global-mode', and open some file, sequences of eight spaces at bol do not get highlighted. Again I ask others to check this. > * Setting whitespace-check-indent-whitespace to nil simply doesn't >work. That is, it doesn't turn off checking (and correcting) >indentation whitespace. This is (relatively) new. I changed `whitespace-indent-regexp' in November 2006 from (concat "^\\(\t*\\)" "") to "^\t*\\(\\)+" so maybe that's a reason. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: pending-undo-list is not buffer local
> > I think for the reason above that it should be buffer local and I also > > think that it should be permanent buffer local then. > > I think this wouldn't make much sense since `buffer-undo-list' isn't > permanently buffer-local either. > > It is, practically speaking. It is buffer-local, and changing major > modes does not clear it out. Like `buffer-file-name'. Would it make sense to introduce a variable, say `buffer-file-name-extension', assign its initial value from `buffer-file-name', make it a permanent buffer-local, and hope that the value of the new variable always correctly reflects the extension of `buffer-file-name' without any additional provisions? Various parts of Emacs manipulate `buffer-undo-list' in various ways. `revert-buffer' may reset it. Some applications temporarily bind it to t to avoid, for example, recording text property changes. Finally undo recording may be switched off. Should `pending-undo-list' be affected by all these and how? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: redisplay
> In my Emacs (GNU Emacs 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version > 2.10.6) of 2007-04-20 on escher) I see two behaviors: > > 1. Evalling the above sexp in *scratch* with C-j or in any buffer with > M-: results in what the OP reported: "produces a blank frame while the > popup dialog is active, i.e., (redisplay t) fails to wait for > redisplay to finish." > > 2. Evalling the sexp with C-x C-e in any buffer results in what RMS > reported. On my Emacs - 22.0.97.1 (i386-mingw-windows98.3000) - I only see the second behavior. GTK+ related? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
> If I start with -Q and then set whitespace-global-mode to non-nil and > set both whitespace-check-leading-whitespace and > whitespace-check-indent-whitespace to nil, leading sequences of 8 spaces > still get highlighted. What happens if you set (customize) `whitespace-check-indent-whitespace' _before_ you toggle `whitespace-global-mode'? > I see. But I think this has gotten sidetracked from the real bug that > was introduced here. Indeed, the fact that > whitespace-check-indent-whitespace has never done what I want is exactly > the reason I have it set to nil (along with > whitespace-check-leading-whitespace; I'm not clear on how these two > differ). `whitespace-check-leading-whitespace' only serves for removing leading empty lines from the buffer, hence it doesn't enter here. > So the bug that has been introduced recently is whatever causes > whitesapce checking to flag indentation whitespace even though > whitespace-check-indent-whitespace is nil. I'm not sure what you mean here. Above you said that it "has never done what you want" here you talk about a recently introduced bug. Please tell me whether and when this worked correctly. I could try to track the changes that occurred since then. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: pending-undo-list is not buffer local
> If those calls are done in different buffers it looks like trouble to > me. Should not pending-undo-list be buffer local? Not by default. If you want to write a function which say, tries to undo changes simultaneously in two or more buffers in some lock-step fashion, you can always make it local yourself (and probably `undo-in-region' as well). > I think for the reason above that it should be buffer local and I also > think that it should be permanent buffer local then. I think this wouldn't make much sense since `buffer-undo-list' isn't permanently buffer-local either. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting certain .c file adds to kill ring
Please install your patch. Done. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting certain .c file adds to kill ring
>>Here are other incorrect uses of kill-* functions in lisp/progmodes: >> >>cc-cmds.el:859: (kill-region (progn (forward-line 0) (point)) >>perl-mode.el:653: (kill-region (point) eol)) >> >>And there's a bunch of suspicious kill-line/kill-word/kill-region in >>mantemp.el and vhdl-mode.el. > > > In lisp/ > > array.el:688: (kill-line 1)) > array.el:708: (kill-line 1) > strokes.el:1361: (kill-region (1+ (point)) (point-max > tumme.el:918: (kill-line 1) > vc.el:2279: (or (eobp) (kill-line)) FWIW there are more in rnews.el, tramp.el, bib-mode.el, calc-... The two uses in ido.el don't appear very clean either. We should fix them up after the release (maybe using something like a generalized `woman-delete-line' for the `kill-line' case to be on the safe side). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting certain .c file adds to kill ring
cc-mode doesn't like `line-beginning-position' and `line-end-position'. [subr.el] ;; These are the XEmacs names: (defalias 'point-at-eol 'line-end-position) (defalias 'point-at-bol 'line-beginning-position) I think it's for Emacs < 20 compatibility. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: visiting certain .c file adds to kill ring
> With my recent cvs build or the debian snapshot, and starting from > "emacs -Q", visiting the file foo.c below with > >C-x C-f foo.c > > leaves the first line in the kill ring, > >C-y >=> inserts "/* hello */ > > where I hoped it would leave the kill ring alone. (In particular it's > not good to have the kill changed when you're doing a cut and paste >>from another file into that one.) > > I suspect c-remove-any-local-eval-or-mode-variables in cc-mode.el > shouldn't be using kill-line, but cc-mode is hellishly complicated ... Would the attached patch do the right thing for you? cc-mode doesn't like `line-beginning-position' and `line-end-position'. *** progmodes/cc-mode.elMon Apr 2 07:45:14 2007 --- progmodes/cc-mode.elSat Apr 21 12:03:10 2007 *** *** 820,826 "$") nil t) (beginning-of-line) ! (kill-line 1))) ;; Delete the first line, if we've got one, in case it contains a mode spec. (unless (and lv-point --- 820,826 "$") nil t) (beginning-of-line) ! (delete-region (point) (progn (end-of-line) (point) ;; Delete the first line, if we've got one, in case it contains a mode spec. (unless (and lv-point *** *** 828,835 (forward-line 0) (bobp))) (goto-char (point-min)) ! (unless (eobp) ! (kill-line 1) (defun c-postprocess-file-styles () "Function that post processes relevant file local variables in CC Mode. --- 828,834 (forward-line 0) (bobp))) (goto-char (point-min)) ! (delete-region (point) (progn (end-of-line) (point)) (defun c-postprocess-file-styles () "Function that post processes relevant file local variables in CC Mode. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
Sorry for not answering earlier but I just retrieved your response from
gmx's spam folder.
> So, what is now the recommended way to set file-specific font-lock
> keywords using file-local variables? If this has changed, it should be
> specified in the NEWS. I can write an entry once I understand the
> answer to my questions above.
You could add to your .emacs something like
(setq safe-local-eval-forms '((my-very-private-foobar))) ; customizable!
(defun my-very-private-foobar ()
(setq font-lock-defaults '(("^\\s-*:0" "##+")))
(font-lock-mode 1))
and in the local variables section use
# Local Variables:
# eval: (my-very-private-foobar)
# End:
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cannot activate font-lock-mode
> # Local Variables:
> # mode: indented-text
> # fill-column: 95
> # mode: font-lock
> # font-lock-keywords : ("^\\s-*:0" "##+")
> # End:
>
> Now, when desktop.el loads it, it asks if I want to apply the
> font-lock-keywords customisation, because it is risky (is it?).
The question is asked by `hack-local-variables-confirm'.
> I
> answer y, but I get the message:
> Toggling font-lock-mode off; better pass an explicit argument.
This is done in `hack-one-local-variable' where
(funcall mode)
simply executes `font-lock-mode' which toggles font-lock mode off since
it does not get an argument.
> and font lock is apparently inactive, as I see no colours. If I toggle
> it, it says
> Font-Lock mode disabled
> I then again do M-x font-lock-mode RET, and it says
> Font-Lock mode enabled
> but I still see no colours.
Look at the value of `font-lock-keywords' in this buffer - it's probably
(t nil). You should modify this either by setting `font-lock-defaults'
or via `font-lock-add-keywords' or `font-lock-remove-keywords'.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: corrected report for Emacs crash on WIN32 with slime
If slime is up and running and M-x slime is called again you are asked if
you
want to start an addtional inferior lisp. If this question is answered with
n
Emacs will crash. The action that triggers the crash is (kill-buffer "
*cl-connection*")
Can you reproduce the bug with the attached (100% unreliable) patch?
*** buffer.h.~1.109.~ Tue Jan 23 06:41:24 2007
--- buffer.hFri Apr 13 10:00:56 2007
***
*** 518,523
--- 518,519
/* Set nonzero whenever the narrowing is changed in this buffer. */
int clip_changed;
+ /* Set nonzero when kill_buffer is in progress for this buffer. */
+ int kill_buffer_in_progress;
+
/* If the long line scan cache is enabled (i.e. the buffer-local
variable cache-long-line-scans is non-nil), newline_cache
points to the newline cache, and width_run_cache points to the
*** buffer.c.~1.525.~ Mon Apr 2 07:45:22 2007
--- buffer.cFri Apr 13 10:20:08 2007
***
*** 693,698
--- 693,699
b->last_window_start = 1;
/* It is more conservative to start out "changed" than "unchanged". */
b->clip_changed = 0;
+ b->kill_buffer_in_progress = 0;
b->prevent_redisplay_optimizations_p = 1;
b->backed_up = Qnil;
b->auto_save_modified = 0;
***
*** 1361,1369
b = XBUFFER (buf);
! /* Avoid trouble for buffer already dead. */
! if (NILP (b->name))
return Qnil;
/* Query if the buffer is still modified. */
if (INTERACTIVE && !NILP (b->filename)
--- 1362,1371
b = XBUFFER (buf);
! /* Avoid trouble for buffer already dead or about being killed. */
! if ((NILP (b->name)) || (b->kill_buffer_in_progress))
return Qnil;
+ b->kill_buffer_in_progress = 1;
/* Query if the buffer is still modified. */
if (INTERACTIVE && !NILP (b->filename)
***
*** 1374,1380
b->name, make_number (0)));
UNGCPRO;
if (NILP (tem))
! return Qnil;
}
/* Run hooks with the buffer to be killed the current buffer. */
--- 1376,1385
b->name, make_number (0)));
UNGCPRO;
if (NILP (tem))
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
}
/* Run hooks with the buffer to be killed the current buffer. */
***
*** 1390,1396
arglist[0] = Qkill_buffer_query_functions;
tem = Frun_hook_with_args_until_failure (1, arglist);
if (NILP (tem))
! return unbind_to (count, Qnil);
/* Then run the hooks. */
Frun_hooks (1, &Qkill_buffer_hook);
--- 1395,1404
arglist[0] = Qkill_buffer_query_functions;
tem = Frun_hook_with_args_until_failure (1, arglist);
if (NILP (tem))
! {
! b->kill_buffer_in_progress = 0;
! return unbind_to (count, Qnil);
! }
/* Then run the hooks. */
Frun_hooks (1, &Qkill_buffer_hook);
***
*** 1403,1412
/* Don't kill the minibuffer now current. */
if (EQ (buf, XWINDOW (minibuf_window)->buffer))
! return Qnil;
if (NILP (b->name))
! return Qnil;
/* When we kill a base buffer, kill all its indirect buffers.
We do it at this stage so nothing terrible happens if they
--- 1411,1426
/* Don't kill the minibuffer now current. */
if (EQ (buf, XWINDOW (minibuf_window)->buffer))
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
if (NILP (b->name))
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
/* When we kill a base buffer, kill all its indirect buffers.
We do it at this stage so nothing terrible happens if they
***
*** 1438,1444
tem = Fother_buffer (buf, Qnil, Qnil);
Fset_buffer (tem);
if (b == current_buffer)
! return Qnil;
}
/* Notice if the buffer to kill is the sole visible buffer
--- 1452,1461
tem = Fother_buffer (buf, Qnil, Qnil);
Fset_buffer (tem);
if (b == current_buffer)
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
}
/* Notice if the buffer to kill is the sole visible buffer
***
*** 1448,1454
{
tem = Fother_buffer (buf, Qnil, Qnil);
if (EQ (buf, tem))
! return Qnil;
}
/* Now there is no question: we can kill the buffer. */
--- 1465,1474
{
tem = Fother_buffer (buf, Qnil, Qnil);
if (EQ (buf, tem))
! {
! b->kill_buffer_in_progress = 0;
! return Qnil;
! }
}
/* Now there is no question: we can kill the buffer. */
***
*** 1520,1525
--- 1540,1546
reset_buffer_local_variables (b, 1);
b->name = Qnil;
+ b->kill_buffer_in_progress = 0;
BLOCK_INPUT;
if (! b->base_buffer)
___
emacs-pretest-bug maili
Re: edebug-pop-to-buffer fails for dedicated windows
> edebug-pop-to-buffer changes the buffer in the "next window". > However this results in an error, if that window is dedicated. Please try the attached patch. *** edebug.el.~3.96.~ Mon Apr 2 07:45:10 2007 --- edebug.el Thu Apr 12 09:06:24 2007 *** *** 364,389 (defun edebug-pop-to-buffer (buffer &optional window) ;; Like pop-to-buffer, but select window where BUFFER was last shown. ! ;; Select WINDOW if it provided and it still exists. Otherwise, ;; if buffer is currently shown in several windows, choose one. ;; Otherwise, find a new window, possibly splitting one. ! (setq window (if (and (windowp window) (edebug-window-live-p window) ! (eq (window-buffer window) buffer)) ! window !(if (eq (window-buffer (selected-window)) buffer) !(selected-window) ! (edebug-get-buffer-window buffer ! (if window ! (select-window window) ! (if (one-window-p) ! (split-window)) ! ;; (message "next window: %s" (next-window)) (sit-for 1) ! (if (eq (get-buffer-window edebug-trace-buffer) (next-window)) ! ;; Don't select trace window ! nil ! (select-window (next-window ! (set-window-buffer (selected-window) buffer) ! (set-window-hscroll (selected-window) 0);; should this be?? ;; Selecting the window does not set the buffer until command loop. ;;(set-buffer buffer) ) --- 364,394 (defun edebug-pop-to-buffer (buffer &optional window) ;; Like pop-to-buffer, but select window where BUFFER was last shown. ! ;; Select WINDOW if it is provided and still exists. Otherwise, ;; if buffer is currently shown in several windows, choose one. ;; Otherwise, find a new window, possibly splitting one. ! (setq window ! (cond !((and (windowp window) (edebug-window-live-p window) ! (eq (window-buffer window) buffer)) ! window) !((eq (window-buffer (selected-window)) buffer) ! (selected-window)) !((edebug-get-buffer-window buffer)) !((one-window-p 'nomini) ! (split-window)) !((let ((trace-window (get-buffer-window edebug-trace-buffer))) ! (catch 'found ! (dolist (elt (window-list nil 'nomini)) ! (unless (or (eq elt (selected-window)) (eq elt trace-window) ! (window-dedicated-p elt)) ! (throw 'found elt)) !;; All windows are dedicated or show `edebug-trace-buffer', split !;; selected one. !(t (split-window ! (select-window window) ! (set-window-buffer window buffer) ! (set-window-hscroll window 0);; should this be?? ;; Selecting the window does not set the buffer until command loop. ;;(set-buffer buffer) ) ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: miss spell in `accept-process-output' doc string
Now that I think about it, I realize that many Emacs users have not studied the advanced mathematics where they would encounter the term "iff". So I think it is better to avoid that term. (I was the one who introduced it into Emacs doc strings.) I have added this to TODO for fixing post-22 release. ** Avoid using "iff" in doc strings. Even advanced mathematical textbooks usually explain this in an initial section. Maybe we could add a definition in the manuals. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: delete-trailing-whitespace misbehaves in scheme-mode
In a buffer with scheme-mode active, delete-trailing-whitespace treats a traling vertical bar character (|) as trailing whitespace (that is, the character is deleted when invoking delete-trailing-whitespace, either interactively or as a write hook). Other modes (elisp, lisp, c, fundamental) seem to behave correctly. What does `describe-char' say about the character? ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
> I set it in custom-set-variables; another likely scenario, I would think. whitespace.el has this form (defcustom whitespace-check-indent-whitespace indent-tabs-mode which, as Miles explained, gets evaluated when whitespace is loaded with the value `indent-tabs-mode' has at that time. Apparently you set `indent-tabs-mode' to a different value afterwards. Hence, the values of `indent-tabs-mode' and `whitespace-check-indent-whitespace' eventually conflict in one of your buffers. I just wanted to know your particular usage pattern in order to propose a solution. > With regard to your request, I'm unfamiliar with -Q and so far I haven't > found documentation for it. So, more explicit instructions about what > you'd like me to try would be appreciated. -Q is an initial option. From the Emacs manual: `-Q' `--quick' Start emacs with minimum customizations. This is like using `-q' and `--no-site-file', but also disables the startup screen. >>IMHO there's no reasonable way to reconcile a user's settings of >>`indent-tabs-mode' with those of `whitespace-check-indent-whitespace'. I >>think `whitespace-indent-cleanup' should be executed iff >>`indent-tabs-mode' is non-nil in the current buffer. But I'm afraid >>that anything we change here will break existing customizations. > > > Why isn't it reasonable for whitespace-indent-cleanup to change tabs in > indentation to spaces when indent-tabs-mode is nil? It is reasonable. Unfortunately, the decisions of `whitespace-indent-cleanup' are based on the actual value of `whitespace-check-indent-whitespace' and not on that of `indent-tabs-mode'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infloop in skeleton-insert
I also find this confusing: (eq 1 1) t (eq 1.0 1.0) nil At present, each integer value has a unique Lisp object in Emacs Lisp. Therefore, `eq' is equivalent to `=' where integers are concerned. It is sometimes convenient to use `eq' for comparing an unknown value with an integer, because `eq' does not report an error if the unknown value is not a number--it accepts arguments of any type. By contrast, `=' signals an error if the arguments are not numbers or markers. However, it is a good idea to use `=' if you can, even for comparing integers, just in case we change the representation of integers in a future Emacs version. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: miss spell in `accept-process-output' doc string
Current CVS head. The last line of `accept-process-output' doc string says: Return non-nil iff we received any output before the timeout expired. There is a miss spell. "iff" stands for "if and only if" but maybe "Return non-nil if and only if we received output before the timeout expired." would be more comprehensible. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
>>(defcustom whitespace-check-indent-whitespace indent-tabs-mode >> "Flag to check indentation whitespace. This is the global for the system. > > > That fails to do the right thing if the user changes indent-tabs-mode > mode after whitespace.el is loaded -- which is certainly not unlikely, > especially given that indent-tabs-mode is automatically buffer local, > and traditionally set on a per-buffer basis! I have to admit that I wanted the original poster to describe exactly this sequence of events. > In general, using another variable as the initial value in a > defvar/defcustom is almost never the right thing for exactly this > reason. In particular if the variable comes from another group. > The right thing to do with whitespace.el is probably support a special `auto' > value for such settings. For instance, in `whitespace-cleanup-internal', > instead of just checking the value of `whitespace-check-buffer-indent' (the > "local" version of `whitespace-check-indent-whitespace'), it could do > something like: > >(if (eq whitespace-check-buffer-indent 'auto) >indent-tabs-mode > whitespace-check-buffer-indent) IMHO there's no reasonable way to reconcile a user's settings of `indent-tabs-mode' with those of `whitespace-check-indent-whitespace'. I think `whitespace-indent-cleanup' should be executed iff `indent-tabs-mode' is non-nil in the current buffer. But I'm afraid that anything we change here will break existing customizations. > [Incidentally, whitespace.el seems absurdly overspeced in many ways -- > is it really necessary to have separate names for the global and local > versions of every config variable, and a toggle function for just about > every whitespace option?!?] After the release we should probably distill a simple and robust implementation. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [unicode-2] whitespace-auto-cleanup always replaces leading spaces with tabs
> I'm using the emacs-unicode-2 branch. After a recent update of my > working copy, whitespace-auto-cleanup replaces sequences of 8 spaces in > leading whitespace with tabs. It does this even though indent-tabs-mode, > whitespace-check-leading-whitespace, and > whitespace-check-indent-whitespace are all nil. > > I am of the mind that having indent-tabs-mode set to nil should be > sufficient to disable this behavior. This should be handled by (defcustom whitespace-check-indent-whitespace indent-tabs-mode "Flag to check indentation whitespace. This is the global for the system. It can be overriden by setting a buffer local variable `whitespace-check-buffer-indent'." :type 'boolean :group 'whitespace) Apparently it doesn't work for you. Could you please give a more detailed report using emacs -Q? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: move-to-column inconsistent with invisible text
Consider the following example:
(progn
(insert "1234567890")
(let ((overlay (make-overlay (+ (point-at-bol) 2) (+ (point-at-bol) 4
(overlay-put overlay 'invisible t)
(let ((point-a (save-excursion (beginning-of-line)
(move-to-column 6)
(point)))
(point-b (save-excursion (end-of-line)
(move-to-column 6)
(point
(delete-overlay overlay)
(message "%d %d" point-a point-b
point-a and point-b should be equal, but they are not.
Could you please try the attached patch.
*** indent.c.~1.191.~ Mon Apr 2 07:45:22 2007
--- indent.cThu Apr 5 11:28:08 2007
***
*** 951,957
pos = PT;
pos_byte = PT_BYTE;
end = ZV;
- next_boundary = pos;
/* If we're starting past the desired column,
back up to beginning of line and scan from there. */
--- 951,956
***
*** 963,968
--- 962,969
col = 0;
}
+ next_boundary = pos;
+
while (pos < end)
{
while (pos == next_boundary)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C-a acts different in 22.0.90 then past versions
emacs-22.0.90 -Q c-xc-f /etc/termcap c-xc-q To make it writable c-kc-kc-y kill the first line and put it back. It will not do it without this line kill c-s thedo this until you leave the first screen displayed. This will recenter the buffer on the "the" found. Then c-s for one more "the" below but on the same display screen. For the GNU/Linux on the redhat 4.0 release it was about 16 additional c-s commands to get it. I think near the bottom will work also. c-athis will recent the screen on the line where the "the" was at. I can repeat this. AFAICT it's due to a change between June 12th, 2006 and July 2nd, 2006. ___ 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: 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: abbrev can't be required
package abbrev can't be required. abbrev is preloaded. Why do you see a need to require it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error when using partial-completion-mode
"PC-do-complete-and-exit: Wrong type argument: char-or-string-p, t" Thanks for reporting. Should have been fixed in the meantime. Please try again. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: syntax-table for info
>>Interesting. It might be a bit harder in this case though, because you can >>have an apostrophe at the end of a word, e.g, "two mens' sons", meaning the >>sons of two men. So you would also have to check for an apostrophe at the >>start of the word. > > > .. or a back-quote, as in `kill-word' -- but what about `can't' ?. Still possible - you usually don't have a word with two apostrophes in it, hence the leading backquote (which could be also an apostrophe) and the trailing apostrophe are dropped. You can do that with `mens'' too. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo-information kept for *occur*
> This is not correct, because it seems to leave buffer-undo-list > permanently set to t. That prevents undoing of changes made by hand > by the user. > Locally binding `buffer-undo-list' around the `erase-buffer' in `occur-1' is trivial. But `occur-mode' has this (add-hook 'change-major-mode-hook 'font-lock-defontify nil t) which means I would have to bind `buffer-undo-list' whenever I change the major-mode for this buffer. Locally bind `buffer-undo-list' around `kill-all-local-variables' in `occur-mode'? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo-information kept for *occur*
The attached patch uses brute force. *** replace.el Fri Feb 23 07:56:32 2007 --- replace.el Mon Feb 26 11:40:36 2007 *** *** 739,744 --- 739,745 (use-local-map occur-mode-map) (setq major-mode 'occur-mode) (setq mode-name "Occur") + (setq buffer-undo-list t) ; Don't record undo information. (set (make-local-variable 'revert-buffer-function) 'occur-revert-function) (make-local-variable 'occur-revert-arguments) (add-hook 'change-major-mode-hook 'font-lock-defontify nil t) *** *** 1086,1093 title-face prefix-face match-face keep-props) (with-current-buffer out-buf (let ((globalcount 0) - ;; Don't generate undo entries for creation of the initial contents. - (buffer-undo-list t) (coding nil)) ;; Map over all the buffers (dolist (buf buffers) --- 1087,1092 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo-information kept for *occur*
> Emacs turns off undo data generation while computing the *occur* buffer: > > (defun occur-engine (regexp buffers out-buf nlines case-fold-search >title-face prefix-face match-face keep-props) > (with-current-buffer out-buf >(let ((globalcount 0) > ;; Don't generate undo entries for creation of the initial contents. > (buffer-undo-list t) > (coding nil)) > ... > > So why does it build up a lot of undo records? I think most of them come from `erase-buffer' in `occur-1' (`occur-mode' sets `buffer-undo-list' to nil). `font-lock-defontify' should add some too. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
> How do you continue to interact with the menu after toggling the menu item? I lied: The toggle is specified in a function `speck-menu-tail' as ... "---" ["Query-replace" 'query :style toggle :selected speck-replace-query :help "Replace this and query for further occurrences."] "---" ... called in the following loop which I don't leave as long as I'm toggling ... (while (eq replace 'query) (setq speck-replace-query (not speck-replace-query)) (setq replace (popup-menu (append (list word) ... (speck-menu-tail ...)) posn))) where "(list word)" is the menu title. Hence, I obviously replace one menu with another and do pretty much the same as Lennart. Anyway, I can confirm that your patch fixes it. Thanks a lot (I didn't delve into this earlier because I considered my behavior w98 specific). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
> Do you mean that the second menu is created before returning from the > first w32_menu_show. It does not look so to me, but I might be > misreading the code. Is not "selection" that is returned from the first > w32_menu_show what is used to decide to do? > > Will not the that return value be used to decide what to do (in this > case popup a second menu)? In popup-menu the return value is used to > find cmd to execute. So when that is done the first popup menu should be > gone, or? I have the same problem with a popup-menu and a toggle-styled entry. Whenever I toggle the entry and line- or mouse-move to the menu title, the latter changes to something like "t", a dot, or an unprintable character. When I toggle the entry again the original title is restored, and changes again when I move there again ... Hence, this problem is inherent to the menu code, or, you don't need two menus like Lennart to make the problem show up. My two observations: (1) The affected element is _always_ the title of the menu (remaining entries are never affected). (2) The original, correct title is kept somewhere since otherwise it couldn't be re-created when I toggle back. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: No refresh of buffer before popup-menu
> Because your model of what happens is incorrect. The menu is > processed in its entirety by the Windows menu-handling API, and Emacs > never sees anything until the menu is popped down. In Lennart's example there are _two_ menus. The one popped by `temp-test1' and the other popped by `temp-test2'. In between he does (insert ";; SOME STRING 2\n") which should get displayed before popping up the second menu. Lennart's problem is that `sit-for' doesn't redisplay because `input-pending-p' returns non-nil. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info indices are slow to display
> Info indices take too long to display. I wonder if that's why they didn't used > to be fontified. Ever since `Info-fontify-maximum-menu-size' was bumped to 100 `Info-fontify-node' takes ages to execute. I've customized that to 10 (the previous value). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ispell otherchars
> I think the following patch should be applied to ispell.el (but I don't > use "polish"). > > What bug is this trying to fix? In English you use the regexp "[']" to match any "'" embedded in a word like "don't". In Polish "." would match _any_ character embedded in a word. Simply noticed by analogy. Since I don't know Polish I can't tell whether that's a bug. Also note that this is Ispell related. Aspell rolls its own special characters. Hence it might be difficult to find someone to test this case. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ispell otherchars
I think the following patch should be applied to ispell.el (but I don't
use "polish"). The regexp in "francais7" is not wrong but misleading.
*** ispell.el.~1.203.~ Mon Nov 6 10:23:02 2006
--- ispell.el Fri Jan 12 11:47:16 2007
***
*** 574,580
"[A-Za-z^\\]" "[^A-Za-z^\\]"
"[-'`\"]" t ("-C" "-d" "esperanto") "~tex" iso-8859-3)
("francais7"
! "[A-Za-z]" "[^A-Za-z]" "[`'^---]" t nil nil iso-8859-1)
("francais" ; Francais.aff
"[A-Za-z\300\302\306\307\310\311\312\313\316\317\324\331\333\334\340\342\347\350\351\352\353\356\357\364\371\373\374]"
"[^A-Za-z\300\302\306\307\310\311\312\313\316\317\324\331\333\334\340\342\347\350\351\352\353\356\357\364\371\373\374]"
--- 574,580
"[A-Za-z^\\]" "[^A-Za-z^\\]"
"[-'`\"]" t ("-C" "-d" "esperanto") "~tex" iso-8859-3)
("francais7"
! "[A-Za-z]" "[^A-Za-z]" "[`'^-]" t nil nil iso-8859-1)
("francais" ; Francais.aff
"[A-Za-z\300\302\306\307\310\311\312\313\316\317\324\331\333\334\340\342\347\350\351\352\353\356\357\364\371\373\374]"
"[^A-Za-z\300\302\306\307\310\311\312\313\316\317\324\331\333\334\340\342\347\350\351\352\353\356\357\364\371\373\374]"
***
*** 623,629
("polish"; Polish mode
"[A-Za-z\241\243\246\254\257\261\263\266\274\277\306\312\321\323\346\352\361\363]"
"[^A-Za-z\241\243\246\254\257\261\263\266\274\277\306\312\321\323\346\352\361\363]"
! "." nil nil nil iso-8859-2)
("portugues" ; Portuguese mode
"[a-zA-Z\301\302\311\323\340\341\342\351\352\355\363\343\372]"
"[^a-zA-Z\301\302\311\323\340\341\342\351\352\355\363\343\372]"
--- 623,629
("polish"; Polish mode
"[A-Za-z\241\243\246\254\257\261\263\266\274\277\306\312\321\323\346\352\361\363]"
"[^A-Za-z\241\243\246\254\257\261\263\266\274\277\306\312\321\323\346\352\361\363]"
! "[.]" nil nil nil iso-8859-2)
("portugues" ; Portuguese mode
"[a-zA-Z\301\302\311\323\340\341\342\351\352\355\363\343\372]"
"[^a-zA-Z\301\302\311\323\340\341\342\351\352\355\363\343\372]"
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [BUG] describe-variable
> In Emacs 22 evaluate: > > (setq myvar '((0) (1) (2) (3) (4) (5) (6) (7) (8) (9))) > > (make-local-variable 'myvar) > > (setq myvar 1) > > then do C-h v myvar . > > Help buffer output: [...] > > Note the local value of 1 is not shown. Would the below break anything else? *** help-fns.el.~1.94.~ Sun Dec 24 22:38:56 2006 --- help-fns.el Fri Jan 12 08:46:02 2007 *** *** 553,559 ;; of a symbol. (set-syntax-table emacs-lisp-mode-syntax-table) (goto-char val-start-pos) ! (delete-region (point) (progn (end-of-line) (point))) (save-excursion (insert "\n\nValue:") (set (make-local-variable 'help-button-cache) --- 553,559 ;; of a symbol. (set-syntax-table emacs-lisp-mode-syntax-table) (goto-char val-start-pos) ! (when (looking-at "value is") (replace-match "")) (save-excursion (insert "\n\nValue:") (set (make-local-variable 'help-button-cache) *** *** 563,569 'action help-button-cache 'follow-link t 'help-echo "mouse-2, RET: show value") ! (insert ".\n\n"))) ;; Mention if it's an alias (let* ((alias (condition-case nil --- 563,569 'action help-button-cache 'follow-link t 'help-echo "mouse-2, RET: show value") ! (insert ".\n"))) ;; Mention if it's an alias (let* ((alias (condition-case nil ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Word boundaries in wdired mode
> This does indeed fix it. I suggest it be installed even if it's > somewhat suboptimal. I still have to learn how to install patches. Anyway, if people think that this patch is sufficient, the doc strings and manual entries for `downcase-word', `upcase-word', `capitalize-word' should explain that similar to `kill-word' they operate on the entire region from `point' to the end (or beginning) of the next (or previous) word and not on individual words alone. These commands will fail when there's a non-word, read-only character in that region. BTW the `backward-word' doc-string should be corrected as well: "Move backward until encountering the beginning of a word." is incorrect with a negative argument (unfortunately). I think that `downcase-word' and friends should downcase word characters and not touch anything else. Implementing that efficiently would require a C level function (similar to scan_words) that skips any non-word characters after or before `point'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Word boundaries in wdired mode
> There's something screwy about word boundries in wdired mode. Say I > have the following files in a directory: > > FOO.EXT > BAR.EXT > BAZ.EXT > > If I try to downcase them by placing point on F and hitting "M-l" a > number of times, then I end up with this: > > foo.ext > BAR.ext > BAZ.ext > > The first two M-l work as expected, but the next two skips over BAR and > BAZ respectively. The patch below should work around this but the bug is inherently with `operate_on_word': When you have a buffer line like FOO.TXT with point-at-bol and the space before FOO is read-only, `downcase-word' will fail to downcase FOO even if it's not read-only. In principle, `operate_on_word' should skip any non-word syntax first before attempting to downcase the following word. Unfortunately, Emacs misses a cheap `forward-nonword' primitive, (skip-syntax-forward "^w") is a poor substitute. *** wdired.el.~1.22.~ Sat Dec 9 22:30:12 2006 --- wdired.el Fri Jan 5 18:22:44 2007 *** *** 576,583 (funcall command 1) (setq arg (1- arg))) (error ! (if (not (forward-word 1)) ! (setq arg 0))) (defun wdired-downcase-word (arg) "WDired version of `downcase-word'. --- 576,584 (funcall command 1) (setq arg (1- arg))) (error ! (if (forward-word) !(skip-syntax-forward "^w") ! (setq arg 0))) (defun wdired-downcase-word (arg) "WDired version of `downcase-word'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-buffer runs forever
> flyspell-buffer runs much longer than flyspell-region, except for > regions 1,$ (line 1 to EOF) and 2,$ whereupon I also have to kill it > with ^G. Region 3,$ is OK. > > $ wget http://jidanni.org/abj/articles/20061230.html > $ LC_ALL=C LANG=C emacs -Q 20061230.html > flyspell-buffer > > emacs-snapshot version of way back in 20060923, sorry. Remarkable, indeed - Aspell, I presume. Please do (setq ispell-local-dictionary "english") before invoking `flyspell-buffer' and tell me whether it's any faster. Next please try to verify with Emacs -Q and _Ispell_ that it doesn't run forever. If both of the above apply, please send a report to the maintainers of Aspell. BTW, didn't you want to complain there about getting those dumbo choices ... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Value menu value should be listed on a separate line
>>You would have to specify what a "simple" tag is in the first place. > > > I would? My bug report was clear enough, I think, for someone who really > wants to understand. Sorry. I apologize again for answering to your report. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
> So? Bug reports about customization don't concern such users, so ignore them > in the present context. If you don't care about customization either, then > perhaps someone else should respond to this bug report. I do care about > customization, and that's why I reported the bug. Sorry. I herewith apologize for answering to your bug report. Please disregard my comments on this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
>> > - They are apparently not autoloaded, so `C-h v' doesn't recognize them >> > until customize has been loaded. >> >>How can `C-h v' help you to find something you're not aware of? > > > That's not the point. The point is that these should be well documented, and > autoloaded so you can get to the documentation. Many Emacs users don't care about customization. I would appreciate a lot if you tried to improve its documentation. > However, C-h v can easily help you find something you are not aware of, by > showing you what's available with completion. I do it every day. C-h v with completion is hardly an option for beginners and hardly useful when there are many completions. >> > - None are mentioned in the Emacs manual (or the Elisp manual, for that >> > matter), so a user is unlikely to know about them. >> >>They are customizable, so users should be able to find them. > > > Why would they look for them if they are not aware of them, to use your > logic? They would browse customization groups, try options, and use them. >> > - Why would the default value of any of these be nil (off)? If >> > the nil order >> > is (apparently) random, how does that benefit anyone as the >> > default value? >> >>The "nil" order is the one chosen by the designer of the option. > > > Emacs maintainers are now responsible. I don't know what the designer's > rationale was, and I don't see a good rationale. I was asking if there is > one. The designers of an option are the persons who invented the option, assigned a name to it, and wrote the customization definition. Their rationale should be to write options such that an option `bar' depending on an option `foo' appears in the customization buffer after `foo' unless the user deliberately changed that order. >> > I don't understand why we would even have such options - who >> > would ever want a random order? >> >>Why do you think it's random? > > > I said "apparently". I have no idea what determines the order. It is not an > obvious, understandable, or obviously useful order. I don't care if it's > actually random. I asked if there was a good reason for it, and you > essentially told me to go ask the designer. Indeed. You should tell the designers of the options for a specific group whenever you think they wrote them in an inappropriate way. >> > A better idea, if really we want to allow users flexibility in >> > the order, is >> > to use a sort function as the customizable value, and have >> > `string-lessp' be >> > the default value. If you want to allow unsorted (random), >> > then use this: >> > >> > (defcustom custom-sort-alphabetically 'string-lessp >> > "Sort function for Customize buffers. >> > Do not sort if the value is nil. >> > :type '(choice (const :tag "None" nil) function)) >> > >> > I personally don't see why anyone would want an order other >> > than alphabetic, >> > but at least that would be a reasonable way to give people a >> > choice. The >> > current approach does not seem useful. >> >>It would give people the inverse choice, not fundamentally different >>though. > > > Fundamentally different: they could supply any sort function. Now they have > a choice between string-lessp and nil, that's all. People already have the choice between using the order proposed by the designer and alphabetic order. My remark applied to you proposal to invert the default value. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Value menu value should be listed on a separate line
>>Usually with ":entry-format" and ":format". > > > No special formatting should be necessary, just to be able to use a simple > tag. I don't believe that was why :*format were introduced. You would have to specify what a "simple" tag is in the first place. Formatting tags is for handling non-standard cases like, for example, options whose values may be variable-length strings. Such options are not necessarily preceded by a [Value Menu]. >> > Writers of defcustom's shouldn't need to concern themselves >> > with the layout >> > of the Customize buffer, anyway. They should be able to define >> > a :tag string >> > without the preoccupation of its starting position and the number of >> > characters already taken up by the option name and the button widths. >> >>I'm convinced that writers of defcustoms should care about the layout. > > > OK, you're convinced. I said that they should not *need* to concern > themselves with the layout of stuff, beyond their own creations. This is a > flaw in the basic layout, which should not be shoved off onto the definers > of individual values, to work around. It should be trivial to fix, no less - > why not fix the general case, instead of making writers of each value work > around it over and over? Your general case is based on the presence of the term [Value Menu]. Often that term is followed by a fixed-length string or an integer as in the following excerpt from the comment group: ... comment-empty-lines: Hide Value Value Menu Never State: STANDARD. If nil, `comment-region' does not comment out empty lines. More comment-fill-column: Hide Value Value Menu nil State: STANDARD. Column to use for `comment-indent'. If nil, use `fill-column' instead. comment-padding: Hide Value Value Menu Integer: 1 State: SAVED and set. Padding string that `comment-region' puts between comment chars and text. More comment-style: Hide Value Value Menu plain ... Moving the text after [Value Menu] to a new line would render this customization buffer completely unreadable. Hence, I'm against a trivial fix. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Value menu value should be listed on a separate line
>> > When a value menu is present, the current value should be on a >> > separate line from the Value Menu button. Currently, the current value >> > is listed next to the Value Menu button, which makes the Customize >> > buffer far too wide. >> >>The author of an option is responsible for its appearance. > > > Uh, how is the author supposed to start a value that has a tag on a separate > line? Usually with ":entry-format" and ":format". > Writers of defcustom's shouldn't need to concern themselves with the layout > of the Customize buffer, anyway. They should be able to define a :tag string > without the preoccupation of its starting position and the number of > characters already taken up by the option name and the button widths. I'm convinced that writers of defcustoms should care about the layout. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
> Thx - I wasn't aware of those. > > However: > > - They are apparently not autoloaded, so `C-h v' doesn't recognize them > until customize has been loaded. How can `C-h v' help you to find something you're not aware of? > - None are mentioned in the Emacs manual (or the Elisp manual, for that > matter), so a user is unlikely to know about them. They are customizable, so users should be able to find them. > - What is the difference between them, besides the fact that they are in > different subgroups of the Customize group? They have identical doc > strings - how is a user to understand their difference? What is the scope of > the sorting (where are the members sorted)? Why are there 3 separate options > for this, if they all do the same thing (same doc string)? This should be improved. > - Why would the default value of any of these be nil (off)? If the nil order > is (apparently) random, how does that benefit anyone as the default value? The "nil" order is the one chosen by the designer of the option. > I don't understand why we would even have such options - who would ever want > a random order? Why do you think it's random? > A better idea, if really we want to allow users flexibility in the order, is > to use a sort function as the customizable value, and have `string-lessp' be > the default value. If you want to allow unsorted (random), then use this: > > (defcustom custom-sort-alphabetically 'string-lessp > "Sort function for Customize buffers. > Do not sort if the value is nil. > :type '(choice (const :tag "None" nil) function)) > > I personally don't see why anyone would want an order other than alphabetic, > but at least that would be a reasonable way to give people a choice. The > current approach does not seem useful. It would give people the inverse choice, not fundamentally different though. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Value menu value should be listed on a separate line
> When a value menu is present, the current value should be on a > separate line from the Value Menu button. Currently, the current value > is listed next to the Value Menu button, which makes the Customize > buffer far too wide. The author of an option is responsible for its appearance. > Tags for menu items are generally less than 81 > characters wide. Putting the value (tag) on a separate line would mean > that the entire buffer would generally be no more than 80 chars > wide. Currently, a buffer with a 70-char value has a width of about > 134. This should be decided for each option individually. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: customize options and faces are not in alphabetical order
> emacs -Q > M-x customize > > The options and faces should be in alphabetical order. The actual > order seems random. Should be possible: (defcustom custom-browse-sort-alphabetically nil "If non-nil, sort members of each customization group alphabetically." :type 'boolean :group 'custom-browse) (defcustom custom-buffer-sort-alphabetically nil "If non-nil, sort members of each customization group alphabetically." :type 'boolean :group 'custom-buffer) (defcustom custom-menu-sort-alphabetically nil "If non-nil, sort members of each customization group alphabetically." :type 'boolean :group 'custom-menu) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
>>BTW, in Elisp an open bracket in column zero of a string should not
>>confuse Emacs. Yet you highlight it with `font-lock-warning-face'.
>
>
> Indeed, it *shouldn't*, but it does confuse Emacs, which is why it's
> highlighted ;-(. We should fix it so it doesn't confuse Emacs any more (and
> doesn't get highlighted either).
Due to the fact that "\\s(" is hardwired in `font-lock-compile-keywords'
and can't be set individually by a major mode. A minor issue showing
that it's not entirely trivial to give a simple recipe fitting all major
modes.
What I meant is "stay away from putting an open paren in column zero
unless it starts a defun" in any programming mode where "open paren" is
what the syntax table says it is. It's one constraint for the user,
easy to explain, understand, and implement, difficult to defend, tho.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
> I disagree in general. What I agree to is that programmers should avoid > putting things that look like defuns inside comments and strings. Commented-out code may look like a defun. > I.e. in Lisp, an open-paren-in-col0 is indeed a bad idea. In C it's not > a problem (maybe an open-brace-in-col0 is a problem there, but not an open > paren). The Emacs manual states In modes where `open-paren-in-column-0-is-defun-start' is `t', *don't put an opening delimiter at the left margin unless it is a defun start*. and you say `open-paren-in-column-0-is-defun-start' is obsolete ;-) BTW, in Elisp an open bracket in column zero of a string should not confuse Emacs. Yet you highlight it with `font-lock-warning-face'. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc strings of variable-at-point and find-variable
> These doc strings don't describe the position of the variable well: > The variable-at-point doc string mentions nothing about using a > variable near point - it says only "around point", which suggests that > only a variable at point is used. The find-variable doc string > mentions using a variable near point, but this suggests that the > nearest variable will be used, which is not always the case. > > The actual variable used seems to be the one before or at point, even > if there is a closer one after point. I didn't check all cases, but > perhaps it would be more correct to say at or before point for both > doc strings. Perhaps something also needs to be said about the > possible distance before point. The "at-point" fuzziness is hard to explain. It's simple when `point' is immediately before, after, or within the print name of a variable. Otherwise, "at-point" refers to the last sexp in the buffer preceding `point'. Finding that may depend on whether `point' is in a string or comment, the (buffer-local?) values of `parse-sexp-ignore-comments', `parse-sexp-lookup-properties', `syntax-table' text properties, ... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Replacement of spaces in wdired
> One problem I found is that it allows me to edit the last space in the > " -> " string that indicates a symbolic link. > > If I have a symbolic link "a -> b" in the directory I'm editing, I can > delete the 2nd space, leaving "a ->b", and when I hit C-c C-c, I end > up with "a -> /dev/null". > > Doing a query replace of " " with "." when there are symlinks present > also replaces the " " which follows each "->". > > Martin, I suggest you install your patch, since it is an improvement. Chong could you please try to install it. Below is a hopefully adequate ChangeLog: * wdired.el (wdired-change-to-wdired-mode, wdired-finish-edit) (wdired-search-and-rename): Simplify code. (wdired-preprocess-files, wdired-preprocess-perms): Make read-only property of preceding character rear-nonsticky to avoid that it can be modified. Put old-name and old-link properties on character preceding name and replace put-text-property by add-text-properties. (wdired-get-filename, wdired-get-previous-link): Get old-name and old-link properties from character preceding name and simplify code. (wdired-preprocess-perms, wdired-set-bit, wdired-toggle-bit) (wdired-perms-to-number): Make local-map property rear-nonsticky to avoid that text following permissions may be modified. Use add-text-properties instead of put-text-property when changing a permission bit. (wdired-change-to-dired-mode): Remove stickiness properties. > Then can you fix this other problem? I couldn't reliably test that. On Windows the " -> " show up and can be manipulated iff you install an external package like w32-symlinks.el. For reasons I never bothered to investigate that package occasionally screws up my Emacs, hence I refrained from using it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
> Evening, Martin! Evening, Alan! >>1. You don't widen the buffer before calling `syntax-ppss'. > > > You mean I don't have to, and would get the same result without > widening? I need to widen anyway, in case point is inside a > comment/string and (point-min) is after the c/s's start. No, I mean you have to widen _before_ calling `syntax-ppss'. > > >>2. A construct built along > > >>(foo >>) (bar) > > >>with point at "bar" might derail font-lock (remember, >>`c-beginning-of-defun-1' calls `beginning-of-defun', not >>`beginning-of-defun-raw'). > > > I think it's best to keep the discussion of beginning-of-defun and the CC > Mode stuff separate. Once b-o-d works right, the question is then how CC > Mode should use it. You discuss this below. In my example `beginning-of-defun' would move to the beginning of the line and thus not to the outermost level. >>4. You could avoid the tedious `up-list' steps by using a variant of the >>tentative fix I attached. > > > (nth 9 ppss) is "Internal data for continuing the parsing". If we're > going to be using that thing's car as "the least nested paren", why > don't we give up the pretence of an "internal" variable and document it > properly? I know it's used in some other places too, but it seems to > be being economical with our integrity to use it ourselves whilst > telling everybody else "it's internal stuff". Or has this been > discussed already? I don't know. But it is used in `syntax-ppss' and since you already call that we probably shouldn't care. Just add the same comment as `syntax-ppss' does and let things evolve. > Your patch is more compact than mine was, and makes scrolling in xdisp.c > acceptably (to me) fast. In fact, that 6 seconds has been reduced to > about half a second. So it gets my vote. (I've got a 1.2 GHz Athlon > machine, by the way.) You win, mine is a 1 GHz Athlon. > Just a small point, though: your patch doesn't > handle the silly case (beginning-of-defun 0). I think this should mean > "point doesn't move". That's what I meant by "tentative" ;-) you'll find more of that. > Is it the `up-list' calls which slow my version down so much? Depends on your mileage, parsing backward is not entirely trivial, you always have to check for stray comments. >>5. Consider making `open-paren-in-column-0-is-defun-start' a real user >>option in C mode. Let, for example, users decide whether they want to >>respect GNU coding standards [ ]. > > > I think I might agree with this, now. Or is your version of > beginning-of-defun-raw fast enough so that this doesn't really matter? I don't think so. > I think there are lots of programmers who hang braces which open defuns. > I think Java hackers do it a lot. But we need to implement this in a > way which doesn't repeat the unholy hassle we had with > `require-final-newline'. > > I don't think there should be a variable `c-open-paren-start" - the > name's long enough already. ;-) Maybe CC Mode should make > o-p-i-c-o-i-d-s local in each of its buffers. In any case, it should be the user's responsibility - and I'm a user here myself ... ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
> 6. In any case, the new behavior should be documented since it applies
> whenever `open-paren-in-column-0-is-defun-start' is set to nil.
>
> Where are documentation changes are needed for this?
In the Elisp description of `beginning-of-defun' I presume. I'd explain
the following issues:
1. `beginning-of-defun' moves to the beginning of the line where it
expects the beginning of a defun. That position is not necessarily part
of that defun and maybe not even at the "outermost" level as I explained
in the example of point 2 of my previous mail. This was a non-issue
when searching for an open paren in column zero (think of a couple of
parenthesized expressions on the same line).
2. That a user's idea of "defun" for her programming language does not
necessarily coincide with that of `beginning-of-defun'.
foo (...)
...
{
...
}
will now get you two defuns instead of one. This should be explained
for C mode at least.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
> Here's a tentative fix for the bug, not that well tested, but tested a
> little bit:
>
> 2006-12-04 Alan Mackenzie <[EMAIL PROTECTED]>
>
> * emacs-lisp/lisp.el (beginning-of-defun-raw): In the seeking a
> non-nested open-paren case, check there are enough lists to move
> over. Return the correct value.
Thanks for taking care of this. Please note:
1. You don't widen the buffer before calling `syntax-ppss'.
2. A construct built along
(foo
) (bar)
with point at "bar" might derail font-lock (remember,
`c-beginning-of-defun-1' calls `beginning-of-defun', not
`beginning-of-defun-raw').
3. All this is still awfully slow and expensive: Open a larger buffer
like xdisp.c, jump to its end, hit M-v a couple of times, and look at
CPU consumption.
4. You could avoid the tedious `up-list' steps by using a variant of the
tentative fix I attached.
5. Consider making `open-paren-in-column-0-is-defun-start' a real user
option in C mode. Let, for example, users decide whether they want to
respect GNU coding standards as mentioned in
http://lists.gnu.org/archive/html/bug-gnu-emacs/2006-11/msg00037.html
This should also permit binding C-M-a / C-M-e to `c-beginning-of-defun'
/ `c-end-of-defun' when `open-paren-in-column-0-is-defun-start' is nil.
6. In any case, the new behavior should be documented since it applies
whenever `open-paren-in-column-0-is-defun-start' is set to nil.
*** lisp.el Thu Nov 9 07:55:26 2006
--- lisp.el Wed Dec 6 08:53:18 2006
***
*** 229,271
"^\\s(")
nil 'move arg)
(progn (goto-char (1- (match-end 0 t))
-
(t
! ;; Column 0 has no significance - so scan forward from BOB to see how
! ;; nested point is, then carry on from there.
! (let* ((floor (point-min))
! (ceiling (point-max))
! (pps-state (let (syntax-begin-function
! font-lock-beginning-of-syntax-function)
! (syntax-ppss)))
! (nesting-depth (nth 0 pps-state)))
(save-restriction
(widen)
! ;; Get outside of any string or comment.
! (if (nth 8 pps-state)
! (goto-char (nth 8 pps-state)))
!
! (cond
!((> arg 0)
! (when (> nesting-depth 0)
! (up-list (- nesting-depth))
! (setq arg (1- arg)))
! ;; We're now outside of any defun.
! (backward-list arg)
! (if (< (point) floor) (goto-char floor)))
!
!((< arg 0)
! (cond
! ((> nesting-depth 0)
! (up-list nesting-depth)
! (setq arg (1+ arg)))
! ((not (looking-at "\\s("))
! ;; We're between defuns, and not at the start of one.
! (setq arg (1+ arg
! (forward-list (- arg))
! (down-list)
! (backward-char)
! (if (> (point) ceiling) (goto-char ceiling)
(defvar end-of-defun-function nil
"If non-nil, function for function `end-of-defun' to call.
--- 229,263
"^\\s(")
nil 'move arg)
(progn (goto-char (1- (match-end 0 t))
(t
! (let ((floor (point-min))
! (ceiling (point-max)))
(save-restriction
(widen)
! (let* ((ppss (let (syntax-begin-function
! font-lock-beginning-of-syntax-function)
! (syntax-ppss)))
! (pos (or (let ((pos (car (nth 9 ppss
! (when pos ; Within defun.
! (when (> arg 0) (setq arg (1- arg)))
! pos))
! (nth 8 ppss); Within string or comment.
! (point ; Must be at outermost level.
! (goto-char pos)
! (condition-case nil
! (progn
! (forward-list (- arg))
! (cond
!((< pos floor)
! (goto-char floor)
! nil)
!((> pos ceiling)
! (goto-char ceiling)
! nil)
!(t)))
! (error
!(goto-char (if (< arg 0) ceiling floor))
!nil
(defvar end-of-defun-function nil
"If non-nil, function for function `end-of-defun' to call.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
> I see this too a lot, even in plain C files. A backtrace when this > happen looks like this: > > Debugger entered--Lisp error: (scan-error "Containing expression ends > prematurely" 107612 107612) > scan-lists(107699 -1 0) > forward-list(-1) > backward-list(1) > beginning-of-defun-raw(nil) > beginning-of-defun() > c-get-fallback-start-pos(108117) > c-parse-state() > c-electric-semi&comma(nil) > call-interactively(c-electric-semi&comma) > call-last-kbd-macro(nil kmacro-loop-setup-function) > kmacro-call-macro(nil nil) > kmacro-end-and-call-macro(nil) > call-interactively(kmacro-end-and-call-macro) > > Usually moving the cursor up a few lines, hitting tab to indent that > line, and then move back to the offending line cures it. It's a consequence of the recent change to `beginning-of-defun-raw'. Compare the threads "font-locking and open parens in column 0" and "emacs hangs in jit-lock". ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Replacement of spaces in wdired
> The patch at
> http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg01071.html no
> longer applies cleanly to the wdired.el in CVS, even after correcting
> the wrapping of long lines and ignoring white space. The patch is
> also really quite large.
It is large because it also tries to handle permission bits correctly.
Attached find a revised patch of this which should apply against the
August version of wdired.el. It also removes keymap text properties -
the current version still wants to remove local-map properties instead.
Please test my changes since I probably missed something during merging.
*** wdired.el Tue Aug 15 11:00:52 2006
--- wdired.el Sun Dec 3 19:38:16 2006
***
*** 283,292
(when (and filename
(not (member (file-name-nondirectory filename) '("." ".."
(dired-move-to-filename)
! (put-text-property (- (point) 2) (1- (point)) 'old-name filename)
! (put-text-property b-protection (1- (point)) 'read-only t)
! (setq b-protection (dired-move-to-end-of-filename t)))
! (put-text-property (point) (1+ (point)) 'end-name t)
(forward-line))
(put-text-property b-protection (point-max) 'read-only t
--- 283,295
(when (and filename
(not (member (file-name-nondirectory filename) '("." ".."
(dired-move-to-filename)
! ;; The rear-nonsticky property below shall ensure that text preceding
! ;; the filename can't be modified.
! (add-text-properties
! (1- (point)) (point) `(old-name ,filename rear-nonsticky
(read-only)))
! (put-text-property b-protection (point) 'read-only t)
! (setq b-protection (dired-move-to-end-of-filename t))
! (put-text-property (point) (1+ (point)) 'end-name t))
(forward-line))
(put-text-property b-protection (point-max) 'read-only t
***
*** 312,331
non-nil means don't include directory. Optional arg OLD with value
non-nil means return old filename."
;; FIXME: Use dired-get-filename's new properties.
! (let* ((end (line-end-position))
! (beg (next-single-property-change
!(line-beginning-position) 'old-name nil end)))
! (unless (eq beg end)
! (let ((file
! (if old
! (get-text-property beg 'old-name)
!(wdired-normalize-filename
! (buffer-substring-no-properties
! (+ 2 beg) (next-single-property-change (1+ beg)
'end-name))
! (if (or no-dir old)
! file
! (and file (> (length file) 0)
!(concat (dired-current-directory) file)))
(defun wdired-change-to-dired-mode ()
--- 315,335
non-nil means don't include directory. Optional arg OLD with value
non-nil means return old filename."
;; FIXME: Use dired-get-filename's new properties.
! (let (beg end file)
! (save-excursion
! (setq end (line-end-position))
! (beginning-of-line)
! (setq beg (next-single-property-change (point) 'old-name nil end))
! (unless (eq beg end)
! (if old
! (setq file (get-text-property beg 'old-name))
! (setq end (next-single-property-change (1+ beg) 'end-name))
! (setq file (buffer-substring-no-properties (1+ beg) end)))
! (and file (setq file (wdired-normalize-filename file
! (if (or no-dir old)
! file
! (and file (> (length file) 0)
! (concat (dired-current-directory) file))
(defun wdired-change-to-dired-mode ()
***
*** 333,341
(or (eq major-mode 'wdired-mode)
(error "Not a Wdired buffer"))
(let ((inhibit-read-only t))
! (remove-text-properties (point-min) (point-max)
! '(read-only nil local-map nil)))
! (put-text-property 1 2 'front-sticky nil)
(use-local-map dired-mode-map)
(force-mode-line-update)
(setq buffer-read-only t)
--- 337,345
(or (eq major-mode 'wdired-mode)
(error "Not a Wdired buffer"))
(let ((inhibit-read-only t))
! (remove-text-properties
! (point-min) (point-max)
! '(front-sticky nil rear-nonsticky nil read-only nil keymap nil)))
(use-local-map dired-mode-map)
(force-mode-line-update)
(setq buffer-read-only t)
***
*** 368,413
(errors 0)
file-ori file-new tmp-value)
(save-excursion
! (if (and wdired-allow-to-redirect-links
! (fboundp 'make-symbolic-link))
! (progn
! (setq tmp-value (wdired-do-symlink-changes))
! (setq errors (cdr tmp-value))
! (setq changes (car tmp-value
! (if (and wdired-allow-to-change-permissions
! (boundp 'wdired-col-perm)) ; could have been changed
! (progn
! (setq tmp-value (wdired-do-perm-changes))
! (setq errors (+ errors (cdr tmp-value)))
!
Re: Replacement of spaces in wdired
> In wdired I can replace the space before the filenames during > query-replace with a character. It doesn't seem to cause anything, > it just doesn't look good. > > I think it's a bug: > "The only editable texts in a WDired buffer are filenames, > symbolic link targets, and filenames permission." Please try to retrieve the patch from http://lists.gnu.org/archive/html/emacs-devel/2006-02/msg01071.html Unfortunately, the author of wdired.el was not really interested. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-auto-correct-word: always third choice luckier
> These days flyspell-auto-correct-word seems to always take three > invocations to correct a word. First always giving two dumbo choices > similar to this sequence: > 0. accross > 1. ac cross > 2. ac-cross > 3. across The choices are provided by ispell / aspell, flyspell can't do much about that. BTW, aspell (0.50.3) gets me "across" first. Did you set or customize `flyspell-sort-corrections'? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bootstrapping CVS emacs fails
Should be fixed now. Thanks for correcting my mistake. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fwd: Serious performace problems on Windows XP with new(!) GNU Emacs v22 (both patched and unpatched EmacsW32 were tried)
I've just noticed that you added (overlay-recenter (point-max)) to `remove-overlays'. That might cause a slowdown if you remove overlays near bob and there are many overlays between the ones you remove and eob. Please consider replacing this by (overlay-recenter end) after the value of `end' has been set up correctly. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fwd: Serious performace problems on Windows XP with new(!) GNU Emacs v22 (both patched and unpatched EmacsW32 were tried)
So, if I understand you correctly, the change to make is to replace (remove-overlays nil nil 'face 'whitespace-highlight) (overlay-recenter (point-max)) with (overlay-recenter (point-max)) (remove-overlays nil nil 'face 'whitespace-highlight) Is that right? Right. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fwd: Serious performace problems on Windows XP with new(!) GNU Emacs v22 (both patched and unpatched EmacsW32 were tried)
> If you've found a slowness in remove-overlays, could you aim to make > that function faster, rather than making its caller faster by not using > remove-overlays? Using `remove-overlays' to delete all overlays with a given property is overkill. The tests (if (< (overlay-start o) beg) (if (> (overlay-end o) end) ... (if (> (overlay-end o) end) are needed iff you want to split or move overlays. Admittedly, my change doesn't gain too much, hence there's no need to implement it. On the other hand, doing "(overlay-recenter (point-max))" before deleting the overlays seems crucial. Apparently, `overlays-in' always returns a list of overlays in reverse order of their buffer positions. With the overlay center at bob, unchain_overlay always searches till the end of overlays_after, hence overhead is inherently quadratic with respect to the number of overlays in the buffer. With the overlay center at eob unchain_overlay always stops at the first element of overlays_before. Thus, an improvement of `remove-overlays' would start it with "(overlay-recenter end)" (possibly directed by an optional fifth argument). Maybe what's really needed is a C function, say "delete_overlays_in", that deletes all overlays with a given property in a given region. The overhead would be always linear with respect to the number of overlays in the buffer. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Build error around new function `Fmenu_or_popup_active_p'
> The defun part is in condition HAVE_MENU but registration part in
> syms_of_xmenu() is out of HAVE_MENU condition.
> It cause compilation error on non-X-Window environment.
Thank you very much for spotting this. To my dismay this bug also
permeates the corresponding sections in macmenu.c and w32menu.c.
My problem is that `menu-or-popup-active-p' should return nil even in
the case where you build without menus. Hence I propose the attached
patch. Please try whether it works on your system.
Thanks again
martin rudalics.
*** macmenu.c Mon Nov 6 10:23:06 2006
--- macmenu.c Mon Nov 6 15:18:42 2006
***
*** 1052,1068
UNBLOCK_INPUT;
}
- /* The following is used by delayed window autoselection. */
-
- DEFUN ("menu-or-popup-active-p", Fmenu_or_popup_active_p,
Smenu_or_popup_active_p, 0, 0, 0,
-doc: /* Return t if a menu or popup dialog is active. */)
- ()
- {
- /* Always return Qnil since menu selection functions do not return
- until a selection has been made or cancelled. */
- return Qnil;
- }
-
/* Find the menu selection and store it in the keyboard buffer.
F is the frame the menu is on.
MENU_BAR_ITEMS_USED is the length of VECTOR.
--- 1052,1057
***
*** 2653,2658
--- 2642,2658
}
#endif /* HAVE_MENUS */
+
+ /* The following is used by delayed window autoselection. */
+
+ DEFUN ("menu-or-popup-active-p", Fmenu_or_popup_active_p,
Smenu_or_popup_active_p, 0, 0, 0,
+doc: /* Return t if a menu or popup dialog is active. */)
+ ()
+ {
+ /* Always return Qnil since menu selection functions do not return
+ until a selection has been made or cancelled. */
+ return Qnil;
+ }
void
syms_of_macmenu ()
*** w32menu.c Mon Nov 6 10:23:06 2006
--- w32menu.c Mon Nov 6 15:23:12 2006
***
*** 990,1006
complete_deferred_msg (FRAME_W32_WINDOW (f), WM_INITMENU, 0);
}
- /* The following is used by delayed window autoselection. */
-
- DEFUN ("menu-or-popup-active-p", Fmenu_or_popup_active_p,
Smenu_or_popup_active_p, 0, 0, 0,
-doc: /* Return t if a menu or popup dialog is active on selected
frame. */)
- ()
- {
- FRAME_PTR f;
- f = SELECTED_FRAME ();
- return (f->output_data.w32->menubar_active > 0) ? Qt : Qnil;
- }
-
/* This callback is called from the menu bar pulldown menu
when the user makes a selection.
Figure out what the user chose
--- 990,995
***
*** 2536,2541
--- 2525,2545
#endif /* HAVE_MENUS */
+ /* The following is used by delayed window autoselection. */
+
+ DEFUN ("menu-or-popup-active-p", Fmenu_or_popup_active_p,
Smenu_or_popup_active_p, 0, 0, 0,
+doc: /* Return t if a menu or popup dialog is active on selected
frame. */)
+ ()
+ {
+ #ifdef HAVE_MENUS
+ FRAME_PTR f;
+ f = SELECTED_FRAME ();
+ return (f->output_data.w32->menubar_active > 0) ? Qt : Qnil;
+ #else
+ return Qnil;
+ #endif /* HAVE_MENUS */
+ }
+
void syms_of_w32menu ()
{
globals_of_w32menu ();
*** xmenu.c Mon Nov 6 10:23:06 2006
--- xmenu.c Mon Nov 6 15:17:38 2006
***
*** 1414,1420
gtk_menu_shell_select_item (GTK_MENU_SHELL (menubar),
GTK_WIDGET (children->data));
!
popup_activated_flag = 1;
g_list_free (children);
}
--- 1414,1420
gtk_menu_shell_select_item (GTK_MENU_SHELL (menubar),
GTK_WIDGET (children->data));
!
popup_activated_flag = 1;
g_list_free (children);
}
***
*** 1496,1510
return popup_activated_flag;
}
- /* The following is used by delayed window autoselection. */
-
- DEFUN ("menu-or-popup-active-p", Fmenu_or_popup_active_p,
Smenu_or_popup_active_p, 0, 0, 0,
-doc: /* Return t if a menu or popup dialog is active. */)
- ()
- {
- return (popup_activated ()) ? Qt : Qnil;
- }
-
/* This callback is invoked when the user selects a menubar cascade
pushbutton, but before the pulldown menu is posted. */
--- 1496,1501
***
*** 3770,3775
--- 3761,3780
#endif /* not USE_X_TOOLKIT */
#endif /* HAVE_MENUS */
+
+
+ /* The following is used by delayed window autoselection. */
+
+ DEFUN ("menu-or-popup-active-p", Fmenu_or_popup_active_p,
Smenu_or_popup_active_p, 0, 0, 0,
+doc: /* Return t if a menu or popup dialog is active. */)
+ ()
+ {
+ #ifdef HAVE_MENUS
+ return (popup_activated ()) ? Qt : Qnil;
+ #else
+ return Qnil;
+ #endif /* HAVE_MENUS */
+ }
void
syms_of_xmenu ()
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fwd: Serious performace problems on Windows XP with new(!) GNU Emacs v22 (both patched and unpatched EmacsW32 were tried)
> Thanks for your prompt answer! > Yes, with this last fix finally whitespace-buffer seems to be quite > fast each time. Thanks for you cooperation. Please keep an eye on this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
