Re: Coding system conversion error
I agree that signaling an error is better than xassert. But, it seems that a function in selection-converter-alist can return a multibyte string as long as we have a fixed rule about how to handle it. And converting to a unibyte string by string-make-unibyte seems to be a good rule. String-make-unibyte might not do the right thing. It's just a guess when we don't have any alternative. In this case we have an alternative which is to signal an error. After all, this did catch an error in the handling of encode-coding-string with compound-text, so I think it's better to signal the error than to silently try to correct it. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: re-builder visibility
+ (defun regexp-builder () + Alias for `re-builder': Construct a regexp interactively. + (interactive) + (re-builder)) Why not just (defalias 'regexp-builder 're-builder) -- Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-quick-startup unbound on the initialization of blink-cursor-mode
The initial value of blink-cursor-mode is set using the value of emacs-quick-startup when noninteractive is nil. :init-value (not (or noninteractive emacs-quick-startup (eq system-type 'ms-dos) (not (memq window-system '(x w32) Does the patch below help? Stefan --- frame.el26 fév 2005 00:23:59 -0500 1.218 +++ frame.el03 mar 2005 08:10:45 -0500 @@ -1270,7 +1270,7 @@ displays through a window system, because then Emacs does its own cursor display. On a text-only terminal, this is not implemented. :init-value (not (or noninteractive - emacs-quick-startup + (if (boundp 'emacs-quick-startup) emacs-quick-startup) (eq system-type 'ms-dos) (not (memq window-system '(x w32) :group 'cursor ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Setting face-font in Carbon Emacs 21.3.50.1
Trying to get it to use Lucida Grande, I put (set-face-font 'default -apple-lucida grande-medium-r-normal--12-140-75-75-m-120-mac-roman) You usually shouldn't use `set-face-font'; instead set the various other face attributes. Does that mean we should mark set-face-font as obsolete? Also, looking at the code of set-face-font, it doesn't do aything else than call (set-face-attribute face frame :font font), so I doubt it will give much better results. Also the docstring of set-face-font says that a nil `frame' argument makes it apply to all frames, which I'd understand as including future frames as well. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Setting face-font in Carbon Emacs 21.3.50.1
Also, looking at the code of set-face-font, it doesn't do aything else than call (set-face-attribute face frame :font font), so I doubt it will give much better results. Well what I mean to say was you shouldn't call set-frame-attribute :font either. :-) It's often convenient to set :font for the default font since the font name often comes from outside Emacs (the user knows he likes font -blabla-foo-120-10-*-* on his screen because he used it for other applications or he chose it in a font selector). I don't think we should discourage people from doing it especially in this particular circumstance, and I think it's important for Emacs to support it well (e.g. make sure that if you set the default font to -blabla-foo-120-10-*-*, Emacs indeed will use -blabla-foo-120-10-*-* and not some other. Given how Emacs decomposes this into its own info to later reconstruct it, it's not obvious at all that it works correctly, and there's been problems with it in the past). Also the docstring of set-face-font says that a nil `frame' argument makes it apply to all frames, which I'd understand as including future frames as well. The code does future frames for t, current frames for nil, and future + current frames for `0'. The docstring of set-face-attribute says FRAME nil means change attributes on all frames. FRAME t means change the default for new frames (this is done automatically each time an attribute is changed on all frames). so nil should also change future frames. And if not, it should be changed because I really can't think of a situation where it makes sense to change the attribute on all current frames and not on the future ones (and if that's really what you want, than a (dolist (frame (frame-list)) ...) will do what you want in a much clearer way). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: diary-redraw-calendar clobbers point in diary-file buffer.
Thanks - I put the save-excursion in redraw-calendar itself. For some reason I though with-current-buffer would preserve point. with-current-buffer doesn't preserve point. But note that (save-excursion (set-buffer foo) ...) doesn't quite preserve point either: it preserves point in the current buffer but not in foo. So if preserving point is important, maybe (with-current-buffer foo (save-excursion ...)) may make sense (although it appears redundant). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: character syntax fixes needed
The guillemets , , and should all be punctuation. The single
ones currently have word syntax, and the double ones are treated as
parens in latin-{1,5,9}.el.
As I don't use those characters, I don't know what is
correct. But, it seems that they are used as a pair; isn't
it convenient if we give them paren syntax?
The problem is that they may be paired differently. In German texts
they may be used as quotation marks like this and in French texts
like that.
Maybe a workaround is to give them generic string fence syntax (aka |)?
Stefan
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: character syntax fixes needed
Maybe a workaround is to give them generic string fence syntax (aka |)? [That hasn't got to me.] It seems to be a good idea. Are there any objection? That isn't correct. There is a comment somewhere in the doc or code about quotation marks intentionally _not_ having string syntax in text modes or globally. Anyhow, guillemets are not always used balanced; Hart's Rules discusses that, for instance. Why do people think the guillemets are special cases which shouldn't be treated like other quotes, or how Unicode says? I've never seen guillemets used alone. They always come in pairs in my experience, so it'd be convenient to be able to use M-C-f and M-C-b to jump over them. Just like the quote, actually. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: poor additions in quail/latin-ltx
However, as far as I remember, it needn't be confined to GTK. I think the Lucid and Motif menus should be able to display utf-8 in a utf-8 locale, at least with recent enough XFree86/X.org for Lucid. I don't recall the details, though, and I think the Lucid menu code needs fixing in some way. It should at least try not to display junk, as it currently does if you use text that isn't encodable in the locale. What I currently see in my Lucid menu is a question mark. Is that what you mean by junk? Or maybe it depends on your locale and other Mule settings. In any case, it would be great to get utf-8 support in the Lucid menu, even if it's only when you're running under a utf-8 locale. By the way, the AUCTeX menu has the same problem as mine with text mode menus -- you don't get type-able keys for most of the items, and they're obviously useful to have in the absence of a mouse. I think TMM should avoid non-ASCII characters for that, e.g. not do this: Possible completions are: 0== (plus-minus sign)== (minus-or-plus sign) 1== (multiplication sign)2== (division sign) == (minus sign) == (asterisk operator) == (star operator) == (white circle) == (bullet) 3== (middle dot) == (intersection)== (union) == (multiset union) == (square cap) == (square cup) == (logical or) == (logical and) == (set minus) == (wreath product) How 'bout the patch below to maths-menu.el (which also fixes your code so you get paren-matching when inserting a paren-like char). Stefan diff -u -b /u/monnier/src/elisp/misc/maths-menu.el.orig /u/monnier/src/elisp/misc/maths-menu.el --- /u/monnier/src/elisp/misc/maths-menu.el.orig2005-03-10 17:10:24.279261870 -0500 +++ /u/monnier/src/elisp/misc/maths-menu.el 2005-03-10 17:09:05.582045901 -0500 @@ -51,15 +51,19 @@ (define-key-after map (vector (intern name)) (cons name pane-map)) (dolist (elt pane) (define-key-after pane-map - (vector (intern (string (car elt ; convenient unique symbol - (cons (format %c (%s) (car elt) (cadr elt)) + (vector (intern (cadr elt))) ; convenient unique symbol + (list 'menu-item + (cadr elt) ;; Using a string here doesn't work. You get a ;; `Wrong type argument: commandp,' error. ;; That looks like a bug, since ;; (commandp a) = t `(lambda () +,(format Insert the character `%c'. (car elt)) (interactive) -(insert ,(car elt +(let ((last-command-char ,(car elt))) + (call-interactively 'self-insert-command))) + :keys (string (car elt))) map)) (defvar maths-menu-menu ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: character syntax fixes needed
Maybe a workaround is to give them generic string fence syntax (aka |)? It seems to be a good idea. Are there any objection? That isn't correct. There is a comment somewhere in the doc or code about quotation marks intentionally _not_ having string syntax in text modes or globally. Which comment in which code? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: animate incredibly slow compared to 21.3
To make reliable judgement about the display state, line-move must call sit-for which does redisplay. That is a really bad problem. IMO, it is not too bad -- line-move is primarily (solely?) for interactive use, so redisplay will happen after the command anyway. Agreed. We need to redesign this. In the past, functions such as compute-motion did the job. But they have not yet been upgraded to handle computations involving variabled width fonts, images, etc. To make scrolling (even of images or lines of widely different height) reliable, compute-motion would need to pay attention to every display element and parameter, including things like frame-local face properties. So either it re-implements the redisplay or it reuses the redisplay. I.e. the current code of line-move reuses the result of redisplay, which seems to be the best solution. That has been in etc/TODO for many years, but nobody has done it. We need this! IMO, compute-motion is too cumbersome to use. Agreed (see comments in windmove.el, one of the two packages that use this function; the other being avoid.el, and also the window-buffer-height function in window.el). For both avoid.el and windmove.el, compute-motion is used to get the X/Y coordinate of point. I.e. posn-at-point would be a better choice now. As for window-buffer-height, the patch below simplifies it by using count-screen-lines (which uses vertical-motion) rather than compute-motion. I.e. compute-motion could be made obsolete, in my opinion. OTOH vertical-motion seems to be used more frequently and its behavior is similar to compute-motion (it can be used for a buffer that's not currently displayed), so maybe there is indeed a need to compute hypothetical display behavior (i.e. display behavior of something that is not displayed). Provide a function update-display-state which does _everything_ in redisplay, except doing Xflush (or similar for other platforms). Then the user display is not updated visually with a possible premature result. But maybe it's important to be able to compute the matrix without *ever* displaying it. E.g. in fit-window-to-buffer, count-screen-lines is used to decide how to resize the window. In the case where the matrix will be displayed sooner or later, I don't think it makes much sense to delay the Xflush. What's the benefit? Stefan --- orig/lisp/window.el +++ mod/lisp/window.el @@ -521,20 +521,12 @@ (defun window-buffer-height (window) Return the height (in screen lines) of the buffer that WINDOW is displaying. - (save-excursion -(set-buffer (window-buffer window)) -(goto-char (point-min)) -(let ((ignore-final-newline - ;; If buffer ends with a newline, ignore it when counting height - ;; unless point is after it. - (and (not (eobp)) (eq ?\n (char-after (1- (point-max))) - (+ 1 (nth 2 (compute-motion (point-min) - '(0 . 0) - (- (point-max) (if ignore-final-newline 1 0)) - (cons 0 1) - nil - nil - window)) + (with-current-buffer (window-buffer window) +(count-screen-lines (point-min) (point-max) + ;; If buffer ends with a newline, ignore it when + ;; counting height unless point is after it. + (or (eobp) (not (eq ?\n (char-before (point-max) + window))) (defun count-screen-lines (optional beg end count-final-newline window) Return the number of screen lines in the region. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: animate incredibly slow compared to 21.3
But maybe it's important to be able to compute the matrix without *ever* displaying it. E.g. in fit-window-to-buffer, count-screen-lines is used to decide how to resize the window. In the case where the matrix will be displayed sooner or later, I don't think it makes much sense to delay the Xflush. What's the benefit? I was thinking about the situation where the sit-for in line-move results in a situation where we would adjust the vscroll, and thus update the display once more. I haven't noticed this myself, but I could envision that may cause flickering. I see. If delaying the Xflush prevents flickering, it might be a good cheap way to solve this problem. But I suspect that delaying the Xflush will only reduce the flickering (the Xserver will still process two screen updates in quick succession, or does it try to drop operations that are overridden by subsequent operations already in the queue?). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display property strangeness
(eq (substring fred 0 1) (substring fred 1 2)) nil `substring' creates/allocates a string, so (eq (substring ...) ...) will *always* return nil. `eq' is pointer equality, whereas `equal' is structural equality. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: poor additions in quail/latin-ltx
What I currently see in my Lucid menu is a question mark. Is that what you mean by junk? No, I meant basically random characters. Question marks would be better. Maybe something has changed; I can't check at present. I can't remember how it is (or was) and what cleanup was rejected, but I think the encoding of text sent to the menus was wrong, at least. Oh, now I see: my local hacked Emacs got question marks, but that was a side-effect of a local change (I redefine make_string_unibyte to do (encode-coding-string str locale-coding-system)), Or maybe it depends on your locale and other Mule settings. In any case, it would be great to get utf-8 support in the Lucid menu, even if it's only when you're running under a utf-8 locale. If it worked, it would depend on the locale, the fonts used, and how coding conversion was done. I wrote something about it on TODO. See the patch I sent on this list yesterday. How 'bout the patch below to maths-menu.el (which also fixes your code so you get paren-matching when inserting a paren-like char). I think it would be best to fix tmm to DTRT and fix the menu code so that you can bind a string as a command like you'd expect. (The idea was to make this effectively, or actually, an input method.) The error message you get binding a string is clearly wrong, at least. Hmmm you seem to be talking about why the code used a lambda rather than a string. This seems unrelated to tmm. It should be fixed indeed, but I have no time to look into it. The problem with tmm is that it uses the menu entry's first char as the key to hit to select the entry. But this doesn't work well in case where you don't know how to input this char. We could restrict tmm to only use ASCII chars for those things, but it might be inconvenient in some cases. But the change I posted (which basically moves the unicode char to the end of the entry's text) works as well and I think putting the char in the short cut key section makes a lot of sense regardless of the problem w.r.t tmm. Anyway it's moot if rms won't accept multilingual menus. I don't know what you're referring to. I can't remember Richard rejecting the idea of multilingual menus. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: character syntax fixes needed
That isn't correct. There is a comment somewhere in the doc or code about quotation marks intentionally _not_ having string syntax in text modes or globally. Which comment in which code? I don't know, or I'd have referenced it. I guess rms can comment on the intent. I guess this answer more or less implies that the answer to which code is Emacs doc or code, right? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: display property strangeness
As someone who doesn't have a background in Lisp, I would expect executing
the same statement three times to give the same result as executing three
identical statements. Perhaps its a bit like quantum mechanics, in that,
once you've passed the stage of disbelief, you can no longer see what the
problem is.
`eq' is equivalent to C's `==' and `equal' is equivalent (for strings) to
`strcmp'. So try:
#include stdio.h
main ()
{
int test = a == a;
printf (A is equal to A? %d\n, test);
}
-- Stefan
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tabbar-mode breaks debugging with match data
!;; Return `mode-name' if not blank, `major-mode' otherwise. !(if (and (stringp mode-name) ! ;; Take care of preserving the match-data because this ! ;; function is called when updating the header line. ! (save-match-data ! (string-match [^ ] mode-name))) Any reason why you don't use simpler a test like (zerop (length mode-name)) or (equal mode-name ), or even just check for mode-name being non-nil? Are there cases where mode-names are made of nothing but spaces? Is the empty string ever used for the mode-name? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: pcvs and smerge-ediff autoload.
With emacs -Q, smerge-ediff is fully documented, and can be invoked interactively. After loading pcvs, it is undocumented, and cannot be invoked interactively. This is a minor irritation, since smerge-mode now has to be loaded by hand before interactive use of smerge-ediff. Duh! Thank you. The patch below I just installed should fix this problem, Stefan --- pcvs.el 21 fév 2005 13:35:02 -0500 1.75 +++ pcvs.el 14 mar 2005 14:18:38 -0500 @@ -1704,8 +1704,6 @@ (message Retrieving revision %s... Done rev) (current-buffer)) -(eval-and-compile (autoload 'smerge-ediff smerge-mode)) - ;; FIXME: The user should be able to specify ancestor/head/backup and we should ;; provide sensible defaults when merge info is unavailable (rather than rely ;; on smerge-ediff). Also provide sane defaults for need-merge files. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Latin-1 chars not recognized for default french flyspell dict
On the machines here, the default ispell dictionary is French. This confuses flyspell as the example below shows: % emacs -q ~/tmp/foo.txt M-x flyspell-mode RET chocolat chocolate problème the first word is accepted as correct while the second is highlighted as a typo (this is just to show that it's indeed using the French dictionary), but the third also gets highlighted, tho in a messed up way: only the probl part gets highlighted, because flyspell obviously didn't consider the accented char as being part of the word. BTW, I see that the problem is linked to the fact that the entry in ispell-dictionary-alist-1 corresponding to the default dictionary (nil) assumes the default is English. I'm currently using the patch below to good effect (on both a machine where the default is French and on another machine where the default is English). Stefan --- orig/lisp/textmodes/ispell.el +++ mod/lisp/textmodes/ispell.el @@ -509,7 +509,7 @@ (setq ispell-dictionary-alist-1 '((nil; default (English.aff) -[A-Za-z] [^A-Za-z] ['] nil (-B) nil iso-8859-1) +\\w \\W ['] nil (-B) nil iso-8859-1) (american ; Yankee English [A-Za-z] [^A-Za-z] ['] nil (-B) nil iso-8859-1) (brasileiro ; Brazilian mode ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: stty isn't a terminal
When I'm executing a shell-command-on-region I receive beside the result also that notice: stty: stdin isn't a terminal What does that mean? Google should be able to answer that one. It's a problem in your shell's config file (like .cshrc) where you use `stty' without first checking whether the shell is actually running on a terminal. It's probably in the comp.unix.shell FAQ and has nothing specifically to do with Emacs. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Somehow disp-table.el gets loaded on Mac OS X
Could you try with completely vanilla Emacsen (i.e. no extra package from /Library/Application Support/Emacs, no .emacs, ...). The most likely problem is that some code somewhere calls standard-display-european. Renaming /Library/Application Support/Emacs I have in GNU Emacs 22.0.50's *Messages*: Warning: Lisp directory `/Library/Application Support/Emacs/auctex/images' does not exist. Warning: Lisp directory `/Library/Application Support/Emacs/auctex' does not exist. Warning: Lisp directory `/Library/Application Support/Emacs/reftex' does not exist. Warning: Lisp directory `/Library/Application Support/Emacs' does not exist. That's not *vanilla*! Please recompile without *any* local changes (no site-load, nothing). -- because of loading disp-table! Do you have any particular reason to doubt me ? Yes. Both Emacsen are configured and compiled by me, having received the same site-init.el file, starting to load the same .emacs file and then loading the same extra packages from /Library/Application Support/Emacs. Remember: disp-table.el is loaded *before* .emacs is even touched! I told you several times already that it's only a symptom and not the cause. Yes, I do believe that, Then please note that the word because in English expresses a causal relation. E.g when you say because of loading disp-table, you actually imply that the *cause* of the problem is the at of loading disp-table. but I too believe that the cause is in Emacs 22.0.50's code. If I didn't believe the same thing, I wouldn't be trying to help you debug this. I do not want disp-table so me, *I*, do *not* switch it on. There is no such thing as switching disp-table ON. Disp-table.el is just a set of functions, loaded on demand; nothing more. Please stop obsessing over it so we can try to get to the actual source of your problem. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem with string to fontset conversion
I don't have .Xresources -- but as I said in my previous mail, the message did change to Warning: Cannot convert string -*-helvetica-medium-r-*--*-120-*-*-*-*,* to type FontSet but the menu bar font is still wrong... Unless/until someone can help me fix this, could someone just take out my patch? In view of the above, I don't think it's ready for 22. Done. Duh! I asked 'cause I thought I'd be away from my machine for a while, but it turned out that's not the case, so I could have done it myself. Thanks for beating me to it, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 2 character comment starter bug
(modify-syntax-entry ?\= _ b12 st) ; comment start == Yes, it seems the problem is that your 2-char comment sequence is made of symbol-chars, so there are cases where the code does things like oh, here's a symbol, let's skip it without checking whether some of the chars that compose the symbol happen to also be a comment-marker. Does your = char really need to have symbol syntax (i.e. _) or could it have punctuation syntax instead (i.e. .) ? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Dave Love] python.el: block is ended prematurely
python.el ends the current block if a line starts with return. However, it doesn't checkt whether this is followed with _. So, if I write return_count = 4 python.el closes the current block wrongly. I've installed Dave's suggestion in Emacs-CVS. Can you confirm that it fixes your bug? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: icomplete-mode deactivates region
This problem currently prevents AUCTeX users from marking LaTeX environments as long as icomplete-mode is active. It only prevents them if they use M-x ..., not if they use a key-binding to mark the environment, right? Yes. Does the patch below help? Yes, it does. Thanks very much for looking into this. Thanks, I've installed it, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Suggestion for python.el and emacs.py
In the shell, the text wraps around to the next line, which is acceptable. This is not the case for Emacs windows split vertically with C-x 3 or ECB. Try (setq truncate-partial-width-windows nil) On my system, the emacs.py rlcompleter interface works correctly and outputs a string, but python.el does not successfully read this string and reports Can't find completion for os. Can you try to debug this? Try the following: - C-h f python-symbol-completions RET - middle-click on python.el to jump to the definition of the function - C-u C-M-x so as to redefine the function with edebug-instrumentation - now go to the python-mode buffer and redo the os.[TAB] - you should now hopefully be in edebug-mode in python.el where you can advance step by step with SPC or n (it's not the same steps). See the elisp manual for more info about edebug. Another thing you can do is to change: (condition-case () (car (read-from-string (python-send-receive (format emacs.complete(%S) symbol (error nil into (condition-case err (car (read-from-string (python-send-receive (format emacs.complete(%S) symbol (error (message Error in completion: %S err) nil so you'll get more information about the error you get (the error is most likely in read-from-string. E.g. a missing close-paren, ...) Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Symbol's value as variable when byte-compiling an eval-when-compile
(defvar nero-link-regexp \\[\\([0-9]+\\)\\] (defvar nero-font-lock-keywords (eval-when-compile (list `(,nero-link-regexp . font-lock-keyword-face))) When byte-compiling, nero-link-regexp will be compiled (i.e. some code will be output for it) but not evaluated (the variable is not defined). Then when the byte-compiler gets to nero-font-lock-keywords, eval-when-compile tells it to evaluate (list `(,nero-link-regexp . font-lock-keyword-face)) where nero-link-regexp will signal an error. a. Why the package author wasn't seeing the original file byte-compile error with a recent CVS snapshot on MacOS, yet I was on gnu/linux? He was most likely byte-compiling in an Emacs where nero.el was already loaded, so nero-link-regexp was already defined (tho maybe to a different value, so he may have generated a wrong .elc file that hard-coded the old value). BTW, tell him that mixing list backquote like he did is ugly, he'd better use: (defvar nero-font-lock-keywords `((,nero-link-regexp . font-lock-keyword-face)) Font lock for `nero-mode'. Currently, only numbered links are fontified.) Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: undo mechanism
I think that running ogg123 on a .ogg file in the shell will do it. I think running wget asynchronously to download a big file will do it. If you are handling 3+M files, the warning is to be expected. Actually, I don't see any reason why Emacs should complain about it. Most likely what should happen is that undo that's accumulated from process's output should be chunked automatically. E.g. we could add an undo-boundary after running a process filter, or from an idle-timer. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: OS X python.el completion issue
Curiouser and curiouser. I put a message in python-preoutput-filter that echoes its parameter as you suggest. Looking at the contents of my messages buffer after attempting the completion for os., the Can't find completion message from the python completion routine happens after precisely 1024 characters are read. Furthermore it looks like the data coming from the process is interrupted every 1024 characters. Oh, I think I know what's happening. Can you try the patch below? I haven't been able to really test it because in my case the input string is always just one complete line, so the looping and the python-preoutput-leftover aren't used. Stefan --- orig/lisp/progmodes/python.el +++ mod/lisp/progmodes/python.el @@ -1098,28 +1098,46 @@ (defvar python-preoutput-continuation nil If non-nil, funcall this when `python-preoutput-filter' sees `_emacs_ok'.) +(defvar python-preoutput-leftover nil) + ;; Using this stops us getting lines in the buffer like ;; ... ... ;; Also look for (and delete) an `_emacs_ok' string and call ;; `python-preoutput-continuation' if we get it. (defun python-preoutput-filter (s) `comint-preoutput-filter-functions' function: ignore prompts not at bol. - (cond ((and (string-match (rx (and string-start (repeat 3 (any .)) - string-end)) - s) - (/= (let ((inhibit-field-text-motion t)) - (line-beginning-position)) - (point))) -) - ((string= s _emacs_ok\n) -(when python-preoutput-continuation - (funcall python-preoutput-continuation) - (setq python-preoutput-continuation nil)) -) - ((string-match _emacs_out \\(.*\\)\n s) -(setq python-preoutput-result (match-string 1 s)) -) - (t s))) + (when python-preoutput-leftover +(setq s (concat python-preoutput-leftover s)) +(setq python-preoutput-leftover nil)) + (let ((res )) +(while ( (length s) 0) + (cond ((and (string-match (rx (and string-start (repeat 3 (any .)) + string-end)) + s) + (/= (let ((inhibit-field-text-motion t)) + (line-beginning-position)) + (point))) +(setq s nil)) + ((string-match \\`_emacs_ok\n s) +(setq s (substring s (match-end 0))) +(when python-preoutput-continuation + (funcall python-preoutput-continuation) + (setq python-preoutput-continuation nil))) + ((string-match \\`_emacs_out \\(.*\\)\n? s) +(setq python-preoutput-result + (concat python-preoutput-result (match-string 1 s))) +(setq s (substring s (match-end 0))) +(if (/= (match-end 1) (match-end 0)) +(set (make-local-variable 'python-preoutput-leftover) + _emacs_out ))) + ((or (eq t (compare-strings s nil nil _emacs_ok\n nil (length s))) +(eq t (compare-strings s nil nil _emacs_out nil (length s +(set (make-local-variable 'python-preoutput-leftover) s) +(setq s nil)) + ((string-match \\`.*\n? s) +(setq res (concat res (match-string 0 s))) +(setq s (substring s (match-end 0)) +res)) ;;;###autoload (defun run-python (optional cmd noshow) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: icomplete-mode deactivates region
You can always fix these problems locally by setting or binding deactivate-mark in the particular place. WOuld you please fix it that way? Because I just compiled a fresh CVS checkout of Emacs and still see the problem and haven't found a check-in by Stefan related to the problem, I am a bit unsure whom you are referring to. Should it be fixed in Emacs or AUCTeX? I think we're talking about a fix in Emacs. The question is where. I think the fix should be in the command to exit the minibuffer. That is a localized change rather than a broad-reaching change. I've installed a fix already (in Fexit_minibuffer). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Standard faces not working with font-lock-keywords
(setq font-lock-keywords '((foo . bold))) This shouldn't be a face symbol but an expression (whose value is typically a face symbol). I.e.: (setq font-lock-keywords '((foo (0 'bold -- Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Standard faces not working with font-lock-keywords
No, it's just an expression -- for the standard font-lock faces there are variable names that are _exactly_ the same as the face names, which evaluate to the corresponding face name. [I think this is silly and confusing, but font-lock is very old...] But as you know, this has proved useful for various users who wanted different font-lock-*-face in different modes: if the keywords were using quoted symbols, that would have required buffer-local faces (which we still don't have: any progress on this side?), whereas the use of the indirection through variables made it possible. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: OS X python.el completion issue
(defun python-preoutput-filter (s) `comint-preoutput-filter-functions' function: ignore prompts not at bol. (cond ((and (string-match (rx (and string-start (repeat 3 (any .)) I see you've reverted to the basic code and thus removed the while loop I had added. I guess it's OK so long as we know we'll only be waiting for one line of output at a time. Also the loop was already missing before anyway. I installed a slightly different patch (halfway between yours and mine). Can you try it? Your code special-cased the case when the emacs_out line is cut, but what is really happenning is that we may receive Python's output in chunks of arbitrary sizes: from one-byte at a time to several lines at a time (depending on many different factors), so the problem exists for all kinds of output. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Standard faces not working with font-lock-keywords
that would have required buffer-local faces (which we still don't have: any progress on this side?) They've worked great in my emacs for ages and ages; I use them daily... :-/ I know, but I still can't see any trace of it in the CVS :-( Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: A doc typo?
I recently suggested patches to report menu bindings using the real menu item texts rather than the internal names, like this: File=Print=Print With Faces But Richard didn't want that feature (why not?). I agree it would be an improvement. But IIRC you did it by modifying key-description, which also applies to things like C-h c where I think it's important to keep a representation that can be passed directly to `kbd'. So I'd recommend to add an arg to key-description and then only use it at those places where it makes sense (basically, for the keys returned by `where-is'). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: obscure new display features
I don't know about you, but when I do here emacs -Q or emacs -nw -Q in either case, standard-display-table is not nil, Why is that? It is nil for me. Probably the locale. I have LANG=fr_CH.ISO-8859-1. Admittedly, the fr_CH population is small, but the same is probably true for most other locales. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sensible menu bindings
With my patch, (key-description KEY t) will do just that. Making C-h c using that is trivial (I already did so). Great, then I strongly support it. C-h k File New File... reports: ,-- | File=New File... runs the command find-file |which is an interactive compiled Lisp function in `files'. | It is also bound to open, C-x C-f. | | Menu binding: menu-bar file new-file I wouldn't bother with this part of the change, just keep: | menu-bar file new-file runs the command find-file |which is an interactive compiled Lisp function in `files'. | It is also bound to open, C-x C-f. Since after all the user has just selected the entry in the menu, so she knows damn well what many entry it was. | find-file File=New File..., C-x C-f, open | Command: Edit file FILENAME. | find-file-at-pointM-x ... RET | Command: Find FILENAME, guessing a default from text around point. | find-file-existingFile=Open File... | Command: Edit the existing file FILENAME. | ... OTOH, this is much more readable than the current form. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mouse-autoselect-window and menu bar
It doesn't bother me this much :-), I've been using mouse-autoselect-window for a quite a while now and 2 days ago was the first time, that I noticed this behavior. But then again I'm hardly using the menu bar (and I've never used the tool bar). That's the problem: with the select on no-move or select after delay, you'll be making the common case (i.e. move the mouse pointer to select another window) less reliable. Your experience sows that this common is *a lot more* common than the problem you report. And the problem you report can already be circumvented by moving your mouse around the upper window. I think the current tradeoff looks pretty good, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell.el: down-mouse-2 leads to unwanted text insertion
Hm, it now was surprisingly hard for me to reproduce it. Surprising because when I wrote the bug report I was annoyed by it happening so often. It seems to happen only when there is an active selection, e.g. a part of the buffer marked by dragging with mouse-1. (I normally have transient-mark-mode enabled; maybe this is related.) Then when I press down-mouse-2, nothing happens and the menu pops up only when the mouse button is released. After selecting the Save word menu item, the menu is closed and the text from the marked region is inserted. Oh, I can reproduce it: The problem seems to be in the mouse-drag-region code. You have to do: - press mouse-1 somewhwere - drag to select a region - release mouse-1 - move mouse to the word with bad spelling - press mouse-2 !! the menu does not appear yet !! - release mouse-2 !! the menu now appears !! - select something in the menu (or nothing) - when you finally exit the menu with a mouse click, the menu is popped down (on the release event) and then the mouse-yank-at-click command is called Yes, I think I see the problem. It's in the dreadful mouse-show-mark function: it does (while (progn (setq event (read-event)) ... (and (memq 'down (event-modifiers event)) (not (key-binding key)) (not (mouse-undouble-last-event events)) (not (member key mouse-region-delete-keys) I'm not sure what this loop is intended to do or what the purpose of this mouse-show-mark function is (e.g. why it's not implemented using a one-time pre-command-hook), but the above code awry here because key-binding does not pay attention to keymaps on overlays under the mouse. So basically the loop sees the down-mouse-2, decides not to exit yet because it can't find a binding for it, then it sees the mouse-2 event which is bound, so it pushes both events back on the unread-command-events, at which point the down-mouse-2 is processed and pops up the menu and when the menu is popped the remaining mouse-2 event causes the yank. My take on it: kill mouse-show-mark. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem with string to fontset conversion
(gdb) r -q -xrm 'Emacs*fontSet: -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*' Starting program: /home/kfs/fsf/latest/src/emacs -q -xrm 'Emacs*fontSet: -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*' Warning: Missing charsets in String to FontSet conversion Warning: Cannot convert string -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,* to type FontSet That is truly odd. How come the XIM code doesn't trigger this same problem? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Default :group in lisp/emacs-lisp/easy-mmode.el.
The use of custom-current-group seems like a bad practice to me. [...] The reason for that is that most of the time the default group chosen by define-minor-mode is a bogus group without one of the major groups as its ancestors. The whole point of the use of custom-current-group is to try and default to the group that was defined in the current file. Such a group is unlikely to be bogus. I still think it's a much better default and it shouldn't be removed. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Default :group in lisp/emacs-lisp/easy-mmode.el.
But, I guess that at the present state it will be difficult to do that and get rid of `custom-current-group', because many things already rely on `custom-current-group'. What we definitely could and, I believe should, do is discourage people from relying on it, because it is quite simply not solid. Unless you're currently hacking on the code, custom-current-group is very much reliable. At least I don't know of any case where it fails. The worst problem is if someone does a few C-M-x of C-x C-e in a buffer and then is surprised that the variable doesn't appear in the right group. Big deal. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem with string to fontset conversion
BTW, I googled for Missing charsets in String to FontSet conversion. Similar problems have been reported for several other applications. The missing charset is just a warning. But the Cannot convert string ... to type FontSet is a hard failure. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Default :group in lisp/emacs-lisp/easy-mmode.el.
rms didn't like this new behavior so the second patch I posted (and did not install yet) merely changes the behavior of define-major-mode back to the situation before 2005-03-31. So implying that my (second) patch has big consequences is not really fair. I didn't realize you hadn't installed it. I think the current situation is best, it fixed the bug that the behavior was different when loading the .el file than when loading the .elc file. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Default :group in lisp/emacs-lisp/easy-mmode.el.
* diff-mode.el (diff-minor-mode): Specify :group. * font-core.el (font-lock-mode): Specify :group. * reveal.el (reveal-mode): Specify :group. * smerge-mode.el (smerge-mode): Specify :group. [...] Does it make sense to have a :group for buffer-local minor modes? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem with string to fontset conversion
(gdb) r -q -xrm Emacs*fontSet: -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*' Starting program: /home/kfs/fsf/latest/src/emacs -q -xrm Emacs*fontSet: -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,*' Warning: Missing charsets in String to FontSet conversion Warning: Cannot convert string -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,* to type FontSet That is truly odd. How come the XIM code doesn't trigger this same problem? I think the XIM code explicitly names the charset it wants. But our XIM code calls XCreateFontSet, just like Xt code. And browsing the Xt source, the Cannot convert string to FontSet message seems to be generated when XCreateFontSet returns NULL, so maybe we could track it down further by making an appropriate call to XFontSet and seeing what it returns. Presumably it will return NULL but with a non-zero list of missing charsets. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problem with string to fontset conversion
$ ./missfonts $ ./missfonts -*-helvetica-medium-r-*--*-120-*-*-*-*-*-*,* Missing 0: ISO8859-1 $ ./missfonts -*-helvetica-medium-r-*--*-120-*-*-*-*,* Missing 0: ISO8859-1 The xfs configuration doesn't list any ISO8859-1 fonts: Somewhere, specifying UTF-8 requires ISO8859-1 ? So it seems the utf-8 locale doesn't only use the iso8859-1 charset but specifies to fail if it's missing. That's OK. Now why does your libXt think you don't have any font that covers iso8859-1? Even if you don't have any iso8859-1 font, an iso10646-1 font should do the trick since it also covers iso8859-1. And your xlsfonts showed you have -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 So it looks like a local installation problem with missing the ISO8859-1 fonts. I don't understand this as I installed _everything_ from the redhat 9.0 disks IIRC, and not installing the -1 fonts in any case seems very odd. Can you check the xfs log (is there such a thing?), see if it complains about something? What does xterm -fn -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 do and/or say? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
The problem is triggered in vhdl-template-field, it seems that read-from-minibuffer switches to the point position of the wrong window. I don't know how to fix it, but I've traced it to the following problem: % emacs -Q [ type in some random text] C-x 2 [ move point elsewhere ] M-: (save-window-excursion (select-window (next-window))) RET after the M-: command, point in the second window is set back to the same position as it is in the first window. If we do M-: (save-window-excursion (let ((win (selected-window))) (select-window (next-window)) (select-window win))) RET instead, it works correctly. So it seems to be a problem in set-window-configuration, but the code there is sufficiently tricky that I can't find the problem off hand. And I won't have time to delve into it any time soon. Can someone else take a look at it? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: gnus-carpal-mode and mouse-autoselect-window
Functions that expect an argument to be a position (an integer), but accept a marker as a substitute, normally ignore the marker buffer. The meaning of this sentence isn't clear to me. If marker M points to position P in buffer A and you're in buffer B, (goto-char M) will go to position P in buffer B, ignoring the fact that M is a position in buffer A and that P may be outside of point-min...point-max in buffer B. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: BibTeX-mode: Key generation when latin-1 characters appear in author field
Now, press `C-c C-c' inside the entry -- Emacs suggests `blöd05:_test' as the key to use -- and hit RET: Emacs writes in the minibuffer `New inserted entry yields duplicate key'. Does the patch below fix the problem for you? Stefan --- bibtex.el 26 jan 2005 14:25:43 -0500 1.91 +++ bibtex.el 06 avr 2005 13:30:04 -0400 @@ -1,6 +1,6 @@ ;;; bibtex.el --- BibTeX mode for GNU Emacs -;; Copyright (C) 1992, 1994, 1995, 1996, 1997, 1998, 1999, 2003, 2004 +;; Copyright (C) 1992, 1994, 1995, 1996, 1997, 1998, 1999, 2003, 2004, 2005 ;; Free Software Foundation, Inc. ;; Author: Stefan Schoef [EMAIL PROTECTED] @@ -652,7 +652,7 @@ (defcustom bibtex-autokey-titleword-ignore '(A An On The Eine? Der Die Das -[^A-Z].* .*[^A-Z0-9].*) +[^[:upper:]].* .*[^[:upper:]0-9].*) Determines words from the title that are not to be used in the key. Each item of the list is a regexp. If a word of the title matches a regexp from that list, it is not included in the title part of the key. @@ -1063,10 +1063,10 @@ (defconst bibtex-entry-type (concat @ bibtex-field-name) Regexp matching the type part of a BibTeX entry.) -(defconst bibtex-reference-key [][a-zA-Z0-9.:;?!`'/[EMAIL PROTECTED]|()_^$-]+ +(defconst bibtex-reference-key [][[:alnum:].:;?!`'/[EMAIL PROTECTED]|()_^$-]+ Regexp matching the reference key part of a BibTeX entry.) -(defconst bibtex-field-const [][a-zA-Z0-9.:;?!`'/[EMAIL PROTECTED]|_^$-]+ +(defconst bibtex-field-const [][[:alnum:].:;?!`'/[EMAIL PROTECTED]|_^$-]+ Regexp matching a BibTeX field constant.) (defconst bibtex-entry-head @@ -2088,7 +2088,7 @@ (defun bibtex-autokey-demangle-name (fullname) Get the last part from a well-formed FULLNAME and perform abbreviations. (let* (case-fold-search - (name (cond ((string-match \\([A-Z][^, ]*\\)[^,]*, fullname) + (name (cond ((string-match \\([[:upper:]][^, ]*\\)[^,]*, fullname) ;; Name is of the form von Last, First or ;; von Last, Jr, First ;; -- Take the first capital part before the comma @@ -2097,7 +2097,7 @@ ;; Strange name: we have a comma, but nothing capital ;; So we accept even lowercase names (match-string 1 fullname)) - ((string-match \\(\\[a-z][^ ]* +\\)+\\([A-Z][^ ]*\\) + ((string-match \\(\\[[:lower:]][^ ]* +\\)+\\([[:upper:]][^ ]*\\) fullname) ;; name is of the form First von Last, von Last, ;; First von von Last, or d'Last @@ -2782,7 +2782,7 @@ (set (make-local-variable 'comment-start-skip) (concat (regexp-quote bibtex-comment-start) \\[ \t]*)) (set (make-local-variable 'comment-column) 0) - (set (make-local-variable 'defun-prompt-regexp) ^[ [EMAIL PROTECTED] \t]*) + (set (make-local-variable 'defun-prompt-regexp) ^[ [EMAIL PROTECTED]:alnum:]]+[ \t]*) (set (make-local-variable 'outline-regexp) [ \t]*@) (set (make-local-variable 'fill-paragraph-function) 'bibtex-fill-field) (set (make-local-variable 'fill-prefix) (make-string (+ bibtex-entry-offset ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs crashes with eval-region and marker
+int marker_pos = -1; This should be EMACS_INT, since Lisp_Object can be 64bit even if int is only 32bit (and it should be in the MARKERP branch of PRINTPREPARE rather than in PRINTDECLARE). Stefan PS: Yes, it's a very widespread problem, but if we ever want to be able to handle 2GB buffers, we should start thinking about it. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't isearch 'ö'
How do you input the ö? I just press the 'Ö' key on my keyboard! The problem is that the ö you type at the isearch prompt is a latin-1 ö whereas the one in the buffer is a latin-9 ö (Emacs's internal representation of characters has such duplicates). Try M-x unify-8859-on-decoding-mode RET (before you even open the file). It is already set: Hmm... please try the following: - open the latin-9 file - go to the ö file in it, hit C-u C-x =, and shows the result - then insert ö somewhere, place point back on this newly inserted char and do C-u C-x = again (and show us the result again). also try the following: C-u M-: (read-event) RET ö and show us the result. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I don't know how to fix it, but I've traced it to the following problem:
% emacs -Q
[ type in some random text]
C-x 2
[ move point elsewhere ]
M-: (save-window-excursion (select-window (next-window))) RET
after the M-: command, point in the second window is set back to the same
position as it is in the first window.
This is not a bug. It is actually documented:
DEFUN (current-window-configuration, Fcurrent_window_configuration,
Scurrent_window_configuration, 0, 1, 0,
doc: /* Return an object representing the current window
configuration of FRAME.
If FRAME is nil or omitted, use the selected frame.
This describes the number of windows, their sizes and current buffers,
and for each displayed buffer, where display starts, and the positions of
point and mark. An exception is made for point in the current buffer:
its value is -not- saved.
This feature is somewhat inconsistent, and one could argue for
changing it. Removing this exception would certainly make things
simpler. ISTR that I arrived at this exception in the late 80s
as I was trying to aim for consistent and predictable behavior.
I don't think the behavior in my above example is consistent
and predictable: it doesn't happen if the two windows displaying the buffer
are on different frames, it doesn't happen if current-buffer is displayed
in one or zero windows on the frame, ...
The patch below fixes the above buggy behavior.
I think it preserves the current behavior in all other cases.
Stefan
--- window.c02 mar 2005 22:20:12 -0500 1.496
+++ window.c11 avr 2005 00:50:28 -0400
@@ -5589,7 +5589,20 @@
else
{
if (XBUFFER (new_current_buffer) == current_buffer)
+ {
+ /* The code further down is careful to preserve point in current
+buffer (if current-buffer is equal to new_current_buffer), but
+that ends up moving the window's point if the selected-window
+before and after both display current-buffer but aren't the
+same window. So to work around this, in this specific case we
+restore the selected window first. */
+ if (XBUFFER (XWINDOW (data-current_window)-buffer)
+ == current_buffer
+ WINDOWP (selected_window)
+ XBUFFER (XWINDOW (selected_window)-buffer) == current_buffer)
+ Fselect_window (data-current_window, Qnil);
old_point = PT;
+ }
else
old_point = BUF_PT (XBUFFER (new_current_buffer));
}
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
the patch fixes the reduced error, but not the original problem.
Can you try the patch below instead?
It seems to fix it for me *and* it explains why font-lock-mode is
a necessary ingredient.
Stefan
--- window.c02 mar 2005 22:20:12 -0500 1.496
+++ window.c12 avr 2005 08:17:51 -0400
@@ -5589,6 +5591,17 @@
{
if (XBUFFER (new_current_buffer) == current_buffer)
old_point = PT;
+ else
+ /* BUF_PT (XBUFFER (new_current_buffer)) gives us the position of
+ point in new_current_buffer as of the last time this buffer was
+ used. This can be non-deterministic since it can be changed by
+ things like jit-lock by mere temporary selection of some random
+ window that happens to show this buffer.
+ So if possible we want this arbitrary choice of which point to
+ be the one from the to-be-selected-window so as to prevent this
+ window's cursor from being copied from another window. */
+ if (EQ (XWINDOW (data-current_window)-buffer, new_current_buffer))
+ old_point = XMARKER (XWINDOW (data-current_window)-pointm)-charpos;
else
old_point = BUF_PT (XBUFFER (new_current_buffer));
}
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: more key bindings for xterm
In what xterm did you test these? I remember vaguely that I tried in the past to add more bindings to xterm.el, but abandoned the idea after I discovered that different flavors of Unix had xterm's that used incompatible bindings. Luckily, tho the bindings are sometimes different, they rarely conflict. I'm not sure. I think, at the time, I did find conflicts. We can deal with them when we find them. As I said, those bindings are weak and overridden by anything, so they can't be much worse than no binding at all. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Re: Can't isearch 'ö'
Any objection/adjustment? In X11 in an ISO 8859-1 buffer it works to i-search (and find) for ä,ö,ü,Ñ,í ... but: in an ISO 8859-2 buffer it fails to find ° (degree). [... more cut ...] Sorry, you went too fast for me. Could you restate the problem with more details of what you did? To start with, please mention if you're using my patch and/or any other patch. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: more key bindings for xterm
Would it be acceptable to add something like: (substitute-key-definition [f29] [C-f5] function-key-map) to xterm.el? Would it work? I thought the translation from esc-sequence to f29 is already done by function-key-map (with elements added by reading the terminfo data) and you function-key-map is not iterated, so once we get f29 we don't look at function-key-map again. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Re: Can't isearch 'ö'
I think I got the reason for this behaviour: '(unify-8859-on-decoding-mode t nil (ucs-tables)) I'm not sure I completely understood your previous mails, so just to be sure, here is what I believe to be what you said: - emacs -q in a latin-1 locale has problems isearching for an é in a latin-9 buffer. - emacs -q plus M-x unify-8859-on-decoding-mode in a latin-1 locale also has trouble isearching for é in a latin-9 buffer. - my patch fixes the first but not the second problem. Right? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Re: =?ISO-8859-1?Q?Re:_Can't_isearch_'=F6'?=
With your patch to keyboard.c it does not work, i.e. i-search é does not find the character in my test file ISO 8859-15.txt, without the patch it works, i.e. i-search finds é. unify-8859-on-decoding-mode's value is t. Hmm, it works for me. Could you pretty please give an actual R.E.C.I.P.E to reproduce the problem? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't search
Check unify-8859-on-decoding-mode's value: C-h v unif TAB de TAB RET == nil Open the directory with test files: C-x d ~/ISO TAB RET Click with mouse-1 the ISO 8859-15 test file == opens writable in new buffer I-search that accented e: C-s ´e RET == success, é found! Close that buffer: C-x k Toggle unify-8859-on-decoding-mode's value: M-x unif TAB de TAB RET Check unify-8859-on-decoding-mode's value: C-h v unif TAB de TAB RET == t Click with mouse-1 the ISO 8859-15 test file == opens writable in new buffer I-search that accented e: C-s ´e == error message: Failing I-search: é This time I can reproduce the problem (and it can be reproduced without my patch by using a latin-1 input method to input the é instead of using an é key (or an XIM input method)). The problem comes from an unexpected call to ucs-set-table-for-input from get-buffer-create. I think the patch below that I just installed fixes it, Stefan Index: lisp/international/ucs-tables.el === RCS file: /cvsroot/emacs/emacs/lisp/international/ucs-tables.el,v retrieving revision 1.37 diff -u -r1.37 ucs-tables.el --- lisp/international/ucs-tables.el29 Mar 2004 12:05:16 - 1.37 +++ lisp/international/ucs-tables.el16 Apr 2005 21:00:28 - @@ -2496,8 +2496,10 @@ ;; normal-mode and minibuffer-setup-hook. (defun ucs-set-table-for-input (optional buffer) Set up an appropriate `translation-table-for-input' for BUFFER. -BUFFER defaults to the current buffer. +BUFFER defaults to the current buffer. +This function is automatically called directly at the end of `get-buffer-create'. (when (and unify-8859-on-encoding-mode + (not unify-8859-on-decoding-mode) (char-table-p translation-table-for-input)) (let ((cs (and buffer-file-coding-system (coding-system-base buffer-file-coding-system))) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't search
I think the patch below that I just installed fixes it, Are both of your patches needed, emacs/src/keyboard.c + emacs/lisp/international/ucs-tables.el? They're unrelated. They both fix different cases. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I think I agree now that the patch you installed is a bug fix and correct. Good, thanks. The problem that point moves after (save-window-excursion (select-window (next-window))) That's the problem I saw reported. No, the problem is not that point is moved, but that the window's cursor is moved. The two are clearly related, of course. I'm saying that changing it to (save-excursion (save-window-excursion (select-window (next-window ought to solve the problem too, and the approach is less risky. That's true. But what about: (save-window-excursion (forward-char 1) (select-window (next-window))) I'd expect this to move the window's cursor by one char. With the current behavior, the cursor is moved to the same spot as the one on the other window, which is not what we want, and wrapping it with save-excursion is not what we want either. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Can't isearch 'ö'
No, I can't. But shouldn't we avoid such an incompatible change at this stage? Can be. But since it's about a year now since we called a freeze and I see no sign of getting to the pretest stage, I figure I don't understand enough what feature freeze means: I just propose changes and I'll let someone else decide whether they should be installed. I think it's The Right Way to solve the problem, so that's what I use in my local code, but if someone wants to write a quicksafe fix instead and use that instead I see no problem with it. I'm still interested to know whether I'm right or not in thinking that my fix is The Right Way. Hypothetical examples aren't too interesting since we can also concoct such examples where the current translate in self-insert-command can be made to fail. I didn't know that self-insert-command also uses translation-table-for-input. I have thought that the variable is for an input method as in this docstring: Char table for translating self-inserting characters. This is applied to the result of input methods, not their input. See also `keyboard-translate-table'. Anyway, could you show me such an example? Let's see: (insert (with-current-buffer foo (buffer-substring (point) (progn (call-interactively 'self-insert-command) (point) Yes, it's silly, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: dired can't display UTF-8 characters in monthname
When I dired a directory with files from March I see something like this: -rw-r--r--1 pete pete2688 7 Mär 16:19 slh-inst.log Do you also get that with emacs -q --no-site-file? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: more key bindings for xterm
Would it be acceptable to add something like: (substitute-key-definition [f29] [C-f5] function-key-map) to xterm.el? Would it work? As I said in another message substitute-key-definition works, and the reason why it would be needed is what you just stated above. Duh, I didn't pay attention to the `substitute-key-definition' and simply assumed it was `define-key'. Sorry for my being so dense, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I'm saying that changing it to (save-excursion (save-window-excursion (select-window (next-window ought to solve the problem too, and the approach is less risky. That's true. But what about: (save-window-excursion (forward-char 1) (select-window (next-window))) I'd expect this to move the window's cursor by one char. No, that is not what it should do. (select-window (next-window)) positions point at the position for the other window, and that is the value that should remain in effect. So I think there is no bug here. I have a hard time believing you tyhink this behavior is desirable. So just to double check: you do realize I'm talking about the window's cursor. Not the buffer's point. Whether the buffer's point is changed or not doesn't bother me. Another way to look at the problem: A save-selected-window around a save-window-excursion is redundant because save-window-excursion saves/restores the selected window. I.e. (save-selected-window (save-window-excursion BODY)) == (save-window-excursion BODY) Yet the reverse is not true (with the current code): (save-window-excursion (save-selected-window BODY)) =/= (save-window-excursion BODY) I find this very unintuitive at least, and inconvenient in the above case. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Point of wrong window used in read-from-minibuffer?
I have a hard time believing you tyhink this behavior is desirable. So just to double check: you do realize I'm talking about the window's cursor. I am not sure if that statement is meaningful. Remember, the window's point value is never in use for the selected window. I know the two are intricately linked, of course. But then trying to come up with a sensible spec, I think it's best to start by separating those concerns. I'm *not* talking so much about operational details of the behavior as about the general user-level behavior. From the users's perspective point barely exists (most users only care about the windows's cursors), and users have no clue that the window's point value is never in use for the selected window. save-window-excursion is currently defined to preserve the buffer's point value even when it switches windows. This is indeed somewhat strange, since ordinarily switching windows swaps the buffer's point value into the old window and swaps the new window's point value into the buffer. Maybe it should be changed. But changing it is somewhat risky, too. As I said, I agree with the general idea that save-window-excursion shouldn't affect point, but I indeed think it's more important that it shouldn't cause any window's cursor to move. Copying the value of one window's point to another window's point is (to me) always a bug. So, yes, I really think it should be changed. I doubt it's risky, but there's no hurry, so we can keep it for post-22. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: pcl-cvs: merging in wrong revision file when conflicts: SOLVED
Contrary to what I wrote in my previous mail, the problem is not in the file-newer-than-file-p function but in the calls to it in pcvs-info.el, at function cvs-fileinfo-backup-file The concatenation of dir should only done on the single result at the end and not within the loop. Thanks for tracking it down. I installed your fix in the repository, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: cperl-mode Parsing Bug
cperl-mode 5.0-Emacs does not properly parse POD, regular expressions,
or q* operators. When I start emacs -Q and enable font-lock-mode and
load the following program under cperl-mode, the regular expression is
not properly parsed and highlighted (if I were to insert a ' into it,
it would think that the rest of the script was a string!). The POD is
not recognized as separate from the program, and the qq{} operator in
the last line is not marked as a string.
Thank you. I've installed the patch below which I believe should fix
your problem.
Index: lisp/progmodes/cperl-mode.el
===
RCS file: /cvsroot/emacs/emacs/lisp/progmodes/cperl-mode.el,v
retrieving revision 1.60
diff -u -r1.60 cperl-mode.el
--- lisp/progmodes/cperl-mode.el25 Mar 2005 10:06:23 - 1.60
+++ lisp/progmodes/cperl-mode.el27 Apr 2005 19:44:16 -
@@ -1514,7 +1514,7 @@
(make-local-variable 'font-lock-syntactic-keywords)
(setq font-lock-syntactic-keywords
(if cperl-syntaxify-by-font-lock
- '(t (cperl-fontify-syntaxically))
+ '((cperl-fontify-syntaxically))
'(t)
(make-local-variable 'cperl-old-style)
(if (boundp 'normal-auto-fill-function) ; 19.33 and later
___
Emacs-pretest-bug mailing list
Emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Focus problem with multiple frames popup help
in CVS Emacs but the default value for focus-follows-mouse appears to be wrong (t) on MS Windows systems. Indeed, it seems wrong. I don't believe there is an option that will cause focus to follow a mouse on MS Windows systems. Actually there is (thank god), using the PowerUI or whatever-name-that-was tool, but it's very rarely used anyway. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: xterm.el
On the slowest machine that I have access to, a 500MHz P3 the xterm.elc load time (as reported by elp) goes from 2.2 seconds to 0.3 seconds if all the substitute-key-definition calls are moved before (let ((map (make-sparse-keymap))) That's a good point: the keys we want to substitute are all in the original map, so we can do the substitute first, on the smaller map, and add our extra bindings afterwards. Stefan, do you have any idea what might be the problem here? I don't see any problem. substitute-key-definition takes time at least proportional to the total size of the keymap and it's made slower in the presence of keymap inheritance, so it's no wonder that the calls to substitute-key-definition should be faster when done on the smaller non-inheriting map. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: xterm.el
Nick == Nick Roberts [EMAIL PROTECTED] writes: xterm.el makes Emacs take about seven times as long to load for me (about 14 seconds on my 200MHz PC). I have tested this by setting term-file-prefix to nil as described in startup.el I think this is due to the recent changes in xterm.el e.g substitute-key-definition is invoked 48 times. We could speed this up significantly by doing a single traversal of the keymap, doing the 48 substitutions simultaneously. The patch below defines a new function substitute-key-definitions which xterm.el could use to good advantage. The interest of this new function is that it is a *simultaneous* substitution, so it can be used to swap FOO and BAR, whereas doing it with substitute-key-definition requires substituting TOTO for FOO, than FOO for BAR and then BAR for TOTO. Stefan --- orig/lisp/subr.el +++ mod/lisp/subr.el @@ -363,14 +363,10 @@ (defvar key-substitution-in-progress nil Used internally by substitute-key-definition.) -(defun substitute-key-definition (olddef newdef keymap optional oldmap prefix) - Replace OLDDEF with NEWDEF for any keys in KEYMAP now defined as OLDDEF. -In other words, OLDDEF is replaced with NEWDEF where ever it appears. -Alternatively, if optional fourth argument OLDMAP is specified, we redefine -in KEYMAP as NEWDEF those keys which are defined as OLDDEF in OLDMAP. - -For most uses, it is simpler and safer to use command remappping like this: - \(define-key KEYMAP [remap OLDDEF] NEWDEF) +(defun substitute-key-definitions (subst keymap optional oldmap prefix) + Applies the SUBST remapping to key bindings in KEYMAP. +SUBST will be a list of elements of the form (OLDDEF . NEWDEF). +See `substitue-key-definition'. ;; Don't document PREFIX in the doc string because we don't want to ;; advertise it. It's meant for recursive calls only. Here's its ;; meaning @@ -388,11 +384,28 @@ (map-keymap (lambda (char defn) (aset prefix1 (length prefix) char) - (substitute-key-definition-key defn olddef newdef prefix1 keymap)) + (substitute-key-definitions-key defn subst prefix1 keymap)) scan))) -(defun substitute-key-definition-key (defn olddef newdef prefix keymap) - (let (inner-def skipped menu-item) +(defun substitute-key-definition (olddef newdef keymap optional oldmap prefix) + Replace OLDDEF with NEWDEF for any keys in KEYMAP now defined as OLDDEF. +In other words, OLDDEF is replaced with NEWDEF where ever it appears. +Alternatively, if optional fourth argument OLDMAP is specified, we redefine +in KEYMAP as NEWDEF those keys which are defined as OLDDEF in OLDMAP. + +For most uses, it is simpler and safer to use command remappping like this: + \(define-key KEYMAP [remap OLDDEF] NEWDEF) + ;; Don't document PREFIX in the doc string because we don't want to + ;; advertise it. It's meant for recursive calls only. Here's its + ;; meaning + + ;; If optional argument PREFIX is specified, it should be a key + ;; prefix, a string. Redefined bindings will then be bound to the + ;; original key, with PREFIX added at the front. + (substitute-key-definitions (list (cons olddef newdef)) keymap oldmap prefix)) + +(defun substitute-key-definitions-key (defn subst prefix keymap) + (let (inner-def skipped menu-item mapping) ;; Find the actual command name within the binding. (if (eq (car-safe defn) 'menu-item) (setq menu-item defn defn (nth 2 defn)) @@ -402,17 +415,17 @@ ;; Skip past cached key-equivalence data for menu items. (if (consp (car-safe defn)) (setq defn (cdr defn -(if (or (eq defn olddef) +(if (or (setq mapping (assq defn subst)) ;; Compare with equal if definition is a key sequence. ;; That is useful for operating on function-key-map. (and (or (stringp defn) (vectorp defn)) -(equal defn olddef))) +(setq mapping (assoc defn subst (define-key keymap prefix (if menu-item (let ((copy (copy-sequence menu-item))) - (setcar (nthcdr 2 copy) newdef) + (setcar (nthcdr 2 copy) (cdr mapping)) copy) - (nconc (nreverse skipped) newdef))) + (nconc (nreverse skipped) (cdr mapping ;; Look past a symbol that names a keymap. (setq inner-def (and defn @@ -428,7 +441,7 @@ ;; Avoid recursively rescanning keymap being scanned. (not (memq inner-def key-substitution-in-progress))) ;; If this one isn't being scanned already, scan it now. - (substitute-key-definition olddef newdef keymap inner-def prefix) + (substitute-key-definitions subst keymap inner-def prefix) (defun define-key-after (keymap key definition optional after) Add binding in KEYMAP for KEY = DEFINITION, right after AFTER's binding. ___ Emacs-pretest-bug mailing list
Re: OSX: Interprogram cut/paste issues ///
Stuff like mouse-extend mainly. But I noticed that it's enough to just (require 'mouse-sel), but not activate the mode - so that's what I'm doing now. That's obviously a workaround, not a fix... If doing nothing more than (require 'mouse-sel) already modifies the behavior of Emacs, it's a bug which should be reported, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: *cvs-commit* gets used as PCVS buffer
If you do something like M-x cvs-examine RET /home/tmp/emacs RET go on one line, then use C-u C to get a Log edit buffer, then do a kill-buffer of the original *cvs* buffer, switch to some arbitrary buffer and do M-x cvs-examine RET /home/tmp/emacs RET again, then the *cvs-commit* buffer will get reused as the main PCVS buffer. Since this usage conflicts when you are doing another commit, PCVS can get rather confused. Hmm... I've had bug reports for this problem for a wile now, but haven't been able to reproduce it and/or track it down. Your recipe looks more promising than the ones I've seen until now, so hopefully I'll be able to finally put this to rest. Stay tuned, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: *cvs-commit* gets used as PCVS buffer
David == David Kastrup [EMAIL PROTECTED] writes: This bug report will be sent to the Free Software Foundation, not to your local site managers! Please write in English if possible, because the Emacs maintainers usually do not have translators to read other languages for them. Your bug report will be posted to the emacs-pretest-bug@gnu.org mailing list. Please describe exactly what actions triggered the bug and the precise symptoms of the bug: If you do something like M-x cvs-examine RET /home/tmp/emacs RET go on one line, then use C-u C to get a Log edit buffer, then do a kill-buffer of the original *cvs* buffer, switch to some arbitrary buffer and do M-x cvs-examine RET /home/tmp/emacs RET again, then the *cvs-commit* buffer will get reused as the main PCVS buffer. Since this usage conflicts when you are doing another commit, PCVS can get rather confused. Ahh... I think I finally got it. Does the patch below fix the problem? I believe it should. The only problem is that I can't figure out what this code was supposed to do, so it may break something. Stefan --- pcvs.el 02 mai 2005 11:41:42 -0400 1.80 +++ pcvs.el 04 mai 2005 13:44:29 -0400 @@ -1438,12 +1438,10 @@ ;; displayed in the wrong minibuffer). (cvs-mode!) (let ((buf (cvs-temp-buffer message 'normal 'nosetup)) - (lbd list-buffers-directory) (setupfun (or (nth 2 (cdr (assoc message cvs-buffer-name-alist))) 'log-edit))) (funcall setupfun 'cvs-do-commit setup 'cvs-commit-filelist buf) (set (make-local-variable 'cvs-minor-wrap-function) 'cvs-commit-minor-wrap) -(set (make-local-variable 'list-buffers-directory) lbd) (run-hooks 'cvs-mode-commit-hook))) (defun cvs-commit-minor-wrap (buf f) @@ -1494,14 +1492,12 @@ ;; displayed in the wrong minibuffer). (cvs-mode!) (let ((buf (cvs-temp-buffer message 'normal 'nosetup)) - (lbd list-buffers-directory) (setupfun (or (nth 2 (cdr (assoc message cvs-buffer-name-alist))) 'log-edit))) (funcall setupfun 'cvs-do-edit-log nil 'cvs-edit-log-filelist buf) (when text (erase-buffer) (insert text)) (set (make-local-variable 'cvs-edit-log-revision) rev) (set (make-local-variable 'cvs-minor-wrap-function) 'cvs-edit-log-minor-wrap) -(set (make-local-variable 'list-buffers-directory) lbd) ;; (run-hooks 'cvs-mode-commit-hook) )) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: switch-to-buffer in hack-local-variables and hack-one-local-variable
Both `hack-local-variables' and `hack-one-local-variable' may call `switch-to-buffer' when parsing local variables. As a consequence, a save-window-excursion: Cannot switch buffers in a dedicated window error is generated when calling `find-file-noselect' while the selected window is dedicated. Replacing `switch-to-buffer' with `pop-to-buffer' resolves the problem for me. Would the patch below suit you? Alternatively, the approach from `hack-local-variables-prop-line' might be used. That's pretty ugly. I'd rather use pop-to-buffer. Any objection against this patch? Stefan --- orig/lisp/files.el +++ mod/lisp/files.el @@ -2198,17 +2195,11 @@ (eq enable-local-variables t) (and enable-local-variables (save-window-excursion - (condition-case nil - (switch-to-buffer (current-buffer)) - (error - ;; If we fail to switch in the selected window, - ;; it is probably a minibuffer. - ;; So try another window. - (condition-case nil - (switch-to-buffer-other-window (current-buffer)) -(error - (switch-to-buffer-other-frame (current-buffer)) - (y-or-n-p (format Set local variables as specified in -*- line of %s? +(let ((pop-up-frames nil)) + ;; Refrain from popping up frames since it can't + ;; be undone by save-window-excursion. + (pop-to-buffer (current-buffer))) +(y-or-n-p (format Set local variables as specified in -*- line of %s? (file-name-nondirectory buffer-file-name))) (let ((enable-local-eval enable-local-eval)) (while result @@ -2242,7 +2233,10 @@ mode-only (and enable-local-variables (save-window-excursion - (switch-to-buffer (current-buffer)) + (let ((pop-up-frames nil)) +;; Refrain from popping up frames since it +;; can't be undone by save-window-excursion. +(pop-to-buffer (current-buffer))) (save-excursion (beginning-of-line) (set-window-start (selected-window) (point))) @@ -2475,7 +2469,10 @@ (or (eq enable-local-eval t) (and enable-local-eval (save-window-excursion -(switch-to-buffer (current-buffer)) + (let ((pop-up-frames nil)) + ;; Refrain from popping up frames since it + ;; can't be undone by save-window-excursion. + (pop-to-buffer (current-buffer))) (save-excursion (beginning-of-line) (set-window-start (selected-window) (point))) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu filter triggered too early
Hm, this might be a knock-out criterion for the usage of menu filters or hooks in order to ask the user for a master file of a multi-file LaTeX document. Indeed. Why do you want to do it from a menu-filter? It sounds like an odd idea to start with. OTOH, you say that the filter is run during easy-menu-define, which sounds very odd and would most likely be a bug. Are you sure that's what happens? No, OK. because I don't know how to debug the filter function. If it would produce a backtrace or debugging buffer upon putting (error) or (debug) into the filter function, I could see where it is called. Well, you may not be able to tell when it's done, but you can tell whether it's done at one specific place or not: add a `message' before easy-menu-define and another after and see whether your filter's message occurs between the two or not. In any case I guess it just takes place as part of the first redisplay after easy-menu-define. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu filter triggered too early
So we searched for a way to delay the question about the master file until this information is actually needed in the editing process. One of these events is when the user opens the menu for inserting a LaTeX environment or macro. I understand. I do think the current behavior of menu filters (and similarly for menu-bar-update-hook) is not great, but it takes work to fix it and it's pretty far down the priority list (and it has to be fixed for each and every toolkit, often in different ways for each toolkit, ...). Note, tho, that as a user I'd be at least perplexed if clicking on the menubar didn't open the menu immediately but instead proceeded to first give me a prompt asking me to enter the name of the master file. So even if we fix the menu filters, it doesn't seem like a good solution to your problem. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: syntax class for $ in sh-mode
Is there any reason that $ does not have a `.' (punctuation) syntax class in sh-mode? Just . would be wrong IMNSHO (because C-M-b wouldn't properly jump over $BLAH). I'd vote for . p or ' syntax. Not sure between the two. The current w is clearly wrong and should at least be changed to _. Note that such a change may require adjustments in font-lock-keywords and/or indentation code (then again, it may not). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: syntax class for $ in sh-mode
Is there any reason that $ does not have a `.' (punctuation) syntax class in sh-mode? Just . would be wrong IMNSHO (because C-M-b wouldn't properly jump over $BLAH). I'd vote for . p or ' syntax. Not sure between the two. A little bit of testing showed that none of the above required any changes to the indentation code or font-lock-keywords. So if somebody can pick one, I can check in the change... I don't think anybody really understands the difference between ' and . p enough to make a choice here. So just pick one, and add a comment explaining that the other would apparently work as well. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: loading and evaluating the buffer are not the same thing.
(eval-when-compile (require 'cl)) If I do load-library RET gud RET then gud is loaded and cl is not, as you would expect. Try M-x load-library RET gud.el RET and discover that your problem has nothing to do with eval vs load but with source vs byte-compiled code. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: make-mode hanging
Upon opening, some makefiles are causing Emacs to begin 100% CPU utilization for an unacceptably long time (minutes). My crystal ball tells me it's a regexp that exhibits bad backtracking behavior. The fact that it only occurs when font-lock is ON means it's a regexp in font-lock-keywords or font-lock-syntactic-keywords. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ding - too often (OS X and in general)
Quitting rings the bell because you do it with the bell character, C-g. Also, it works by causing something almost indistiguishable from an error. Of course we could distinguish them. I do think it's important to do something when execution is interrupted by C-g so the user can tell the difference between normal and abnormal termination. But I can see the point in making this feedback different than the one corresponding to an error. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: url-http does not propagate redirected URL as callback argument
+ (and url-callback-arguments + (cdr url-callback-arguments Since (cdr nil) = nil, you can simplify this to just (cdr url-callback-arguments). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: its possible to make emacs not respond with ido mode
- ido starts looking for the file everywhere according to some algorithm I dont know, something like locate. - This is annoying and time consuming, so i press c-g. However, ido doesnt stop looking, so I get annoyed and press c-g several times quickly. I recommend the use of while-no-input for such cases (I actually wrote the first version of it when working on icomplete.el). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when visiting source file
This is the output from gdb: as i586-suse-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) run Have you tried with -q --no-site-file? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mac-command-key-is-meta on non-mac systems
I'm now working on both a mac laptop and a gnu/linux desktop system, and I pull the emacs session from the desktop to my laptop for work. This means I run the linux variant on the Mac screen/keyboard. There is a small problem with running emacs on macintosh keyboards which is solvable via setting the mac-command-key-is-meta variable. But this variable is only defined on emacsen that where compiled on/for Macintosh! As this is a feature of the client and not the server, perhaps this could should be part of all emacs and not just the mac ones? Have tried to solve your problem with xmodmap? Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when visiting source file
The backtrace I get when I type bt is 84000+ lines. When? If Emacs seems to hang, it means it's stuck in an (almost-)inf-loop, and you can try stopping it a few times and compare the backtraces. The one you show was taken from within the GC, which always leads to such long lists of `mark_object', so better skip that backtrace and try another one. In any case the backtrace you show seems not to be from a regexp-match. You could try and check the value of Vinhibit_quit with (gdb) p Vinhibit_quit NNN (gdb) xtype should say it's a symbol (gdb) xsymbol could say nil or t Stefan PS: It's also useful sometimes to show the result of xbacktrace (see etc/DEBUG as well for more info about debugging in general). ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash when visiting source file
The attached file contains the top and bottom of a Lisp backtrace I got from C-g, after enabling enter debugger on quit. Indeed it looks like a loop/recursion bug in EDE. So can we conclude that emacs does not _crash_ ? And since C-g works as well, it's not frozen. I.e. it's not an Emacs bug. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Use no tabs in Info
The same argument could be made for *Help*, or Dired, or *Apropos*, or *Buffer List*, or Those buffers don't use TABs, but there is no restriction on their use or any explicit enforcement to not use TABs, AFAIK. AFAICT these are different situations: the TABs in info buffers don't come from Emacs but from actual info files (generated by makeinfo, or install-info, or by hand). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: after-change-functions called when menu action
The hooks in after-change-functions seem to be called even when I just open a menu from the menu bar with the mouse (before even selecting a menu item!). Clearly, no change has been made to the buffer in such a situation. I think that after-change-functions shouldn't be called. Testcase, please, Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [make-mode.el] Multi-line font locking not working correctly
I think the only feasible fix for this problem is to turn off the new feature of highlighting the value assigned to the make macro, and go back to highlighting only the macro name. Yes, please. It is sort of unfortunate, but I don't know how to fix it any better than this. I don't find it unfortunate at all. Font-lock should only highlight significant syntactic elements, not every single char in the buffer. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: after-change-functions called when menu action
(add-hook 'after-change-functions 'yell-at-me) Usually after-change-functions are only added buffer-locally, like this: (add-hook 'after-change-functions 'yell-at-me nil t) -- Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: debugger with pop-up-frames non-nil: keeps creating new frames
I get the same bugged behavior (in Emacs -q) when these are both `t': pop-up-frames display-buffer-reuse-frames In fact, it is in such a setup that I first discovered the bug. Could you post a detailed recipe, so I can try and reproduce the problem? A detailed recipe starts with emacs -q --no-site-file and lists every key typed along with the expected result. 1. runemacs.exe -q --no-site-file 2. M-x set-variable RET pop-up-frames RET t RET 3. M-x set-variable RET display-buffer-reuse-frames RET t RET 4. M-x debug-on-entry RET describe-variable RET 5. M-x describe-variable RET display-buffer-reuse-frames RET 6. (in debugger): d d d d... With each `d' in the debugger, a new frame is created. Oh, I didn't realize you were talking about a new problem not present in Emacs-21.4. I actually introduced this problem in the following change: revision 1.65 date: 2005/02/26 05:28:24; author: monnier; state: Exp; lines: +46 -47 (debug): Hide the buffer if it's not killed. Remove unused and inexistent var `inhibit-trace'. (debugger-mode): Use run-mode-hooks. (debugger-list-functions): Add buttons; setup xref stack. Can you try the fix below and confirm that it solves your problem? Stefan --- orig/lisp/emacs-lisp/debug.el +++ mod/lisp/emacs-lisp/debug.el @@ -213,12 +213,18 @@ ;; Still visible despite the save-window-excursion? Maybe it ;; it's in a pop-up frame. It would be annoying to delete and ;; recreate it every time the debugger stops, so instead we'll - ;; erase it and hide it but keep it alive. + ;; erase it (and maybe hide it) but keep it alive. (with-current-buffer debugger-buffer (erase-buffer) (fundamental-mode) (with-selected-window (get-buffer-window debugger-buffer 0) - (bury-buffer))) + (when (window-dedicated-p (selected-window)) +;; If the window is not dedicated, burying the buffer +;; will mean that the frame created for it is left +;; around showing smoe random buffer, and next time we +;; pop to the debugger buffer we'll create yet +;; another frame. +(bury-buffer (kill-buffer debugger-buffer)) (set-match-data debugger-outer-match-data))) ;; Put into effect the modified values of these variables ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: debugger with pop-up-frames non-nil: keeps creating new frames
If I do (setq special-display-regexps '([ ]?[*][^*]+[*])), then when I hit `d' in the debugger, the debugger frame iconifies. Doesn't it de-iconify right after (thus flashing)? That's very odd. No; it does not deiconify. Oh, I think I know what it is: that's because of Richard's new code which uses just `select-window' instead of `pop-to-buffer' and thus fails to de-iconify. If it did, I would consider that too to be a bug - why would one want the debugger frame to first be iconified and then be deiconified each time you issue a debugger command? Yes, it'd also be a bug. But it'd be fixed by the last patch I sent. I don't understand: - Why bury-buffer iconifies. Because of the case where you hit `q' or `c' or ... rather than `d'. I don't understand what you are saying here. I'm saying that in the case of `q' or `c', I don't want the keep displaying the frame, instead I want it iconified. It iconifies with every command, including `d'. But, aside from `d', why should it iconify with `q' or `c'? Because `q' and `c' both really leave the debugger so you don't want to keep an empty *Backtrace* buffer/window/frame staring at you. If you hit `q', perhaps iconifying is OK. However, I think quit-window or killing the buffer and deleting the window (and frame) would be better than iconifying the frame. Have you read the patches I sent and the corresponding code? It includes a comment explaining why. Even if iconifying were OK for `q', why do that when you hit `c'? You are still using the debugger window/buffer/frame, no? Sometimes, but usually no. Or at least I won't get back into the debugger immediately (contrary to `d'). Why would you want to bury or iconify the buffer with `c'? It should remain displayed, so you can use it. You can't really use it any more: at that point it's empty (until you re-enter the debugger). Actually the code is used when we leave the debugger. It's just that when you use `d' you only leave the debugger temporarily. I don't see why you (or the code) would consider `d' to leave the debugger, even temporarily. In what sense is the user leaving it? The debugger is entered by calling the function `debug' and is exited when the `debug' function returns. The code in question is executed at the end of `debug' just before exiting. I.e. technically, `d' causes Emacs to leave the debugger while setting up the evaluator to immediately re-enter the debugger. This is admittedly irrelevant to the user, so the last patch I sent you tries to hide it, but it is the reason why I consider `d' to leave the debugger. Even if one considers `d' to leave the debugger, that way of leaving it requires a completely different behavior from quitting it (`q)', IMO. Agreed, thus my patch. If you look at what happens in a single-frame case, the code deletes/creates a window at each step. I don't see why it should do that either. The why is not really relevant: it's what it does (by wrapping the body of `debug' within a save-window-excursion). You're still in the debugger; why delete and re-create the window? Does that perhaps represent some kind of optimization? It's invisible to the user in this case, so I don't mind, but I don't understand why it should be done. Yes, it's invisible as long as Emacs doesn't refresh the display between the time when you hit `d' and the next function call which causes Emacs to re-enter the debugger. Sadly, contrary to what happens for window where window creation/deletion is propagated to the display upon redisplay, frame creation/deletion is effected immediately so the iconify/deiconify causes flashing whereas the deletionre-creation of the window is usually not visible. I still don't see why any of the debugger commands should delete and recreate, or iconify and deiconify, or erase and redraw ... windows and frames. As long as you are in the debugger, it should remain displayed, IMO. When you quit, the debugger buffer and its window or frame (if one-window-p) should be deleted completely. There's no way to know, when you quit, that you're quitting for ever. In practice, when I hit `q' it's quite frequent that I'll be getting back to the debugger pretty soon. Deleting the buffer+window+frame means losing the sizeplacement information, which I find very annoying. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: scan-lists sees comment delimiter inside string
With parse-sexp-ignore-comments t and point in between ( in (setq foo (;)) forward-sexp gets me forward-sexp: Scan error: Unbalanced parentheses. Obviously, this is because scan-lists finds the semicolon and does not check whether it's inside a string. Could someone please add the necessary conjunct? It's not as trivial a change as it may seem since figuring out whether we're inside a string (or comment for that matter) or not often requires parsing the buffer from the beginning and this parsing can fail if the syntax table doesn't match 100% the language in use. I do think it'd be good to do it and I suggest we beginning by introducing new commands move-forward-sexp and move-backward-sexp (which are user-level sexp movement commands) which could try to DTRT like you suggest, while keeping the behavior of forward-sexp the way it is now. If such a thing is done maybe forward-sexp-function should be used in move-forward-sexp rather than in forward-sexp itself. But then transpose-sexps should also be changed to use move-forward-sexp since it should obey forward-sexp-function. Patches are welcome, but I really hope they won't be part of the next release, which is already about to enter its second year of so-called feature freeze. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: debugger with pop-up-frames non-nil: keeps creating new frames
I'm saying that in the case of `q' or `c', I don't want the keep displaying the frame, instead I want it iconified. In the case of `c', I definitely want to keep displaying the debugger. Why would you want it to disappear? Using `c' doesn't mean you're done with the debugger. I can always use `q' when I'm done with the debugger. `q' doesn't just leave the debugger, it also aborts the current execution, whereas `c' continues it (without necessarily setting things up to re-enter the debugger in the future). Because `q' and `c' both really leave the debugger so you don't want to keep an empty *Backtrace* buffer/window/frame staring at you. `c' does not leave the debugger at all. It simply completes evaluation of a sexp. That depends on the circumstance. See below. Again, quitting the debugger should delete the buffer, window and frame (if one-window-p) - iconifying serves no purpose. What is wrong with deleting the buffer/window/frame? What's unclear about losing the sizeposition info? And `d' and`c' should not be considered to leave the debugger at all - the debugger buffer/window/frame should continue to be displayed. With the current code, `d' indeed keeps the backtrace buffer displayed. I don't understand this. I use `d' and `c' all the time. I use `c' when I don't want to drill down into the eval of a sexp; I just want to see its result. But that still leaves me in the middle of a trace, and I continue with `d' or `c' to evaluate the next sexp (or I quit with `q', if I'm done). I think I'm beginning to understand a bit more what you're complaining about. IIUC you use debug-on-error extensively, whereas I use edebug for those situations. I mostly only use the `debug' debugger via debug-on-error, debug-on-signal, debug-on-quit, or an explicit call to (debug). Of course, if the sexp to be eval'd with `c' is the only one, then evaluation is finished, and you end up with an empty buffer. That is the only case when it would be OK to remove the buffer/window/frame after `c' is finished. Indeed, except it's not easy to distinguish the different cases. I'll send a patch later. so the last patch I sent you tries to hide it, but it is the reason why I consider `d' to leave the debugger. OK. Is that how it worked previously also? `d' caused function `debug' to return (exit) at each step? Yes, it's always worked this way. You're still in the debugger; why delete and re-create the window? Probably for simple implementation reasons. And maybe also so that the code itself is run in an environment unaffected by the debugger. I.e. without the extra window. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: makefile-mode font-lock bugs and annoyances
2. Highlighting of conditional constructs is broken: ifdef FOO blah else blah blah endif i) FOO does not get highlighted as a variable. Emacs-21.3 gets this right. ii) ifdef / else / endif do not get highlighted as keywords. Emacs-21.3 gets this right. This is correct, because ifdef et al. are not keywords for make! The old makefile-mode mixed up make, gmake and automake, not allowing you to see when you wrote stuff for the wrong make into a makefile. In Emacs' own makefiles for example ifdef must *not* get highlighted for this very reason. (Maybe it should even signal an error when you type it, so you really notice :-) The problem here is that for backwards compatibility gmake will read in a Makefile when there is no GNUmakefile. That made some people get sloppy and actually write gmake constructs into plain Makefiles. There is a keybinding C-c C-m C-g for quickly switching to makefile-gmake-mode in such a case. There you get what you are looking for. You mean the problem is that you make a decision (i.e. this is a non-GNU makefile) based on insufficient information. I.e. you make a poor decision. The nature of Emacs is that it always has to be overly permissive because it can rarely if ever know with enough certainty that something is really wrong. E.g. cc-mode will highlight an else even if it doesn't follow an if and it will properly indent a call to argc(1,2) even if `argc' is not a function. Most BSD-only makefiles are called Makefile; most GNU-only makefiles are called Makefile; ... you can't assume that if a file is called Makefile it will be plain-old make (what is that anyway, SUSv3? SUSv2? SysV?). So please revert the default make-mode to accept GNU-isms (as well as BSD-isms, ...). You can also additionally provide stricter derived modes if you want, but the default should stay on the safe side and trust the user that she knows what she's doing. Or you can provide sanity-check functions (rather than derived modes) which verify that the file doesn't use any GNU-isms, or BSD-isms. Then users can put those functions on their before-save-hook if they want to. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: makefile-mode font-lock bugs and annoyances
We're basically arguing over defaults, which seems to be generally fruitless. I just found the new ones so bad, I was motivated to say something. And for what it's worth, I'll reiterate that I agree with you. It's good to fix make-mode so it highlights more correctly (parses the various funny constructs more precisely), but it doesn't have to come at the cost of making the whole thing illegible because of an overload of clashing colors. I don't know about other people, but for myself I can instantaneously tell the difference between $@ and $TOTO without any additional highlighting and highlighting them differently doesn't help me read the rest of the code more quickly either. Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: adaptive-fill bug?
While I'm not sure of it since I don't use the adaptive-fill-mode normally, I found something like a bug. Try the following: (with-temp-buffer (insert-char ?- 70) (let ((fill-column 70) (adaptive-fill-mode t)) (fill-region (point-min) (point-max = fill-prefix too long for specified width Is it reasonable that the form causes an error? Similar errors have occurred when decoding the text/enriched MIME messages which contain long dash lines. The enriched-decode function which runs fill-region is performed then. Does the patch below fix your problem? Though we can solve it for that case by binding adaptive-fill-mode to nil, I'm hesitating to do so. I appreciate any comment. I agree. Binding adaptive-fill-mode to nil is nothing more than a workaround. Stefan --- fill.el 24 mai 2005 15:01:00 -0400 1.176 +++ fill.el 09 jun 2005 14:04:51 -0400 @@ -1,7 +1,7 @@ ;;; fill.el --- fill commands for Emacs-*- coding: iso-2022-7bit -*- -;; Copyright (C) 1985,86,92,94,95,96,97,1999,2001,02,03,2004 -;; Free Software Foundation, Inc. +;; Copyright (C) 1985, 1986, 1992, 1994, 1995, 1996, 1997, 1999, 2001, 2002, +;; 2003, 2004, 2005 Free Software Foundation, Inc. ;; Maintainer: FSF ;; Keywords: wp @@ -205,6 +205,22 @@ (unless (zerop cmp) (substring s1 0 cmp) +(defun fill-match-adaptive-prefix () + (let ((str (cond + ;; We don't need to consider `paragraph-start' here since it + ;; will be explicitly checked later on. Also setting + ;; first-line-prefix to nil prevents second-line-prefix from + ;; being used. + ;; ((looking-at paragraph-start) nil) + ((and adaptive-fill-regexp (looking-at adaptive-fill-regexp)) + (match-string-no-properties 0)) + (adaptive-fill-function + (funcall adaptive-fill-function) +(if (= (+ (current-left-margin) (length str)) (current-fill-column)) +;; Death to insanely long prefixes. +nil + str))) + (defun fill-context-prefix (from to optional first-line-regexp) Compute a fill prefix from the text between FROM and TO. This uses the variables `adaptive-fill-regexp' and `adaptive-fill-function' @@ -224,27 +240,13 @@ second-line-prefix start) (setq start (point)) - (setq first-line-prefix - ;; We don't need to consider `paragraph-start' here since it - ;; will be explicitly checked later on. - ;; Also setting first-line-prefix to nil prevents - ;; second-line-prefix from being used. - (cond ;; ((looking-at paragraph-start) nil) - ((and adaptive-fill-regexp (looking-at adaptive-fill-regexp)) - (match-string-no-properties 0)) - (adaptive-fill-function (funcall adaptive-fill-function + (setq first-line-prefix (fill-match-adaptive-prefix)) (forward-line 1) (if ( (point) to) (progn (move-to-left-margin) (setq start (point)) - (setq second-line-prefix - (cond ((looking-at paragraph-start) nil) ;Can it happen ? -stef - ((and adaptive-fill-regexp - (looking-at adaptive-fill-regexp)) - (buffer-substring-no-properties start (match-end 0))) - (adaptive-fill-function - (funcall adaptive-fill-function +(setq second-line-prefix (fill-match-adaptive-prefix)) ;; If we get a fill prefix from the second line, ;; make sure it or something compatible is on the first line too. (when second-line-prefix ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
