Re: rx doc string
Richard Stallman <[EMAIL PROTECTED]> wrote > The documentation for `rx' currently claims `word-start' matches the end > of a word. > > Have you verified it does not? > (I don't use rx myself.) Yes. It evaluates to "\\<", which matches only the beginning of a word. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
rx doc string
Hello, The documentation for `rx' currently claims `word-start' matches the end of a word. Also, it neglects to mention `symbol-start' and `symbol-end'. regards, Nikolaj Schumacher diff -du /Users/nik/svn/carbon-emacs/emacs/lisp/emacs-lisp/rx.el /tmp/buffer-content-6339OMN --- lisp/emacs-lisp/rx.el 2007-05-27 21:59:08.0 +0200 +++ lisp/emacs-lisp/rx.el 2007-05-27 21:59:26.0 +0200 @@ -725,8 +725,7 @@ matches the empty string, but only at point. `word-start', `bow' - matches the empty string, but only at the beginning or end of a - word. + matches the empty string, but only at the beginning of a word. `word-end', `eow' matches the empty string, but only at the end of a word. @@ -740,6 +739,12 @@ matches the empty string, but not at the beginning or end of a word. +`symbol-start' + matches the empty string, but only at the beginning of a symbol. + +`symbol-end' + matches the empty string, but only at the end of a symbol. + `digit', `numeric', `num' matches 0 through 9. Diff finished. Sun May 27 21:59:26 2007 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
canonically-space-region and fill-delete-newlines leave bounds
Hello,
`canonically-space-region' doesn't stop at the end of the region.
That's because it limits its searches at `end', while the actual region
keeps getting smaller.
For example:
a b
c d
Mark the first line, call `canonically-space-region' and observe that
the spaces in the second line disappear as well.
`fill-delete-newlines' has the same problem because it calls
`canonically-space-region' and because it uses the `to' variable
afterwards.
A proposed patch is attached.
regards,
Nikolaj Schumacher
diff -du /Users/nik/.emacs.d/backup/\!Applications\!Emacs.app\!Contents\!Resources\!share\!emacs\!22.1.50\!lisp\!textmodes\!fill.el.\~1\~ /Applications/Emacs.app/Contents/Resources/share/emacs/22.1.50/lisp/textmodes/fill.el
--- lisp/textmodes/fill.el 2007-04-27 15:28:14.0 +0200
+++ lisp/textmodes/fill.el 2007-05-24 14:28:23.0 +0200
@@ -159,7 +159,8 @@
and `sentence-end-without-period').
Remove indentation from each line."
(interactive "*r")
- (let ((end-spc-re (concat "\\(" (sentence-end) "\\) *\\| +")))
+ (let ((end-spc-re (concat "\\(" (sentence-end) "\\) *\\| +"))
+ delete-begin delete-end)
(save-excursion
(goto-char beg)
;; Nuke tabs; they get screwed up in a fill.
@@ -169,35 +170,41 @@
(subst-char-in-region beg end ?\t ?\s)
(while (and (< (point) end)
(re-search-forward end-spc-re end t))
- (delete-region
- (cond
- ;; `sentence-end' matched and did not match all spaces.
- ;; I.e. it only matched the number of spaces it needs: drop the rest.
- ((and (match-end 1) (> (match-end 0) (match-end 1))) (match-end 1))
- ;; `sentence-end' matched but with nothing left. Either that means
- ;; nothing should be removed, or it means it's the "old-style"
- ;; sentence-end which matches all it can. Keep only 2 spaces.
- ;; We probably don't even need to check `sentence-end-double-space'.
- ((match-end 1)
- (min (match-end 0)
- (+ (if sentence-end-double-space 2 1)
- (save-excursion (goto-char (match-end 0))
- (skip-chars-backward " ")
- (point)
- (t ;; It's not an end of sentence.
- (+ (match-beginning 0)
- ;; Determine number of spaces to leave:
- (save-excursion
- (skip-chars-backward " ]})\"'")
- (cond ((and sentence-end-double-space
- (or (memq (preceding-char) '(?. ?? ?!))
-(and sentence-end-without-period
- (= (char-syntax (preceding-char)) ?w 2)
- ((and colon-double-space
- (= (preceding-char) ?:)) 2)
- ((char-equal (preceding-char) ?\n) 0)
- (t 1))
- (match-end 0))
+ (setq delete-begin
+ (cond
+ ;; `sentence-end' matched and did not match all spaces. I.e. it
+ ;; only matched the number of spaces it needs: drop the rest.
+ ((and (match-end 1) (> (match-end 0) (match-end 1)))
+ (match-end 1))
+ ;; `sentence-end' matched but with nothing left. Either that
+ ;; means nothing should be removed, or it means it's the
+ ;; "old-style" sentence-end which matches all it can. Keep only
+ ;; 2 spaces. We probably don't even need to check
+ ;; `sentence-end-double-space'.
+ ((match-end 1)
+ (min (match-end 0)
+ (+ (if sentence-end-double-space 2 1)
+ (save-excursion (goto-char (match-end 0))
+ (skip-chars-backward " ")
+ (point)
+ (t ;; It's not an end of sentence.
+ (+ (match-beginning 0)
+ ;; Determine number of spaces to leave:
+ (save-excursion
+ (skip-chars-backward " ]})\"'")
+ (cond ((and sentence-end-double-space
+ (or (memq (preceding-char) '(?. ?? ?!))
+ (and sentence-end-without-period
+ (= (char-syntax (preceding-char)) ?w 2)
+ ((and colon-double-space
+ (= (preceding-char) ?:)) 2)
+ ((char-equal (preceding-char) ?\n) 0)
+ (t 1))
+ delete-end (match-end 0))
+ (delete-region delete-begin delete-end)
+ ;; Move end position to accommodate for deleted text.
+ (setq end (- end (- delete-end delete-begin)))
+
(defun fill-common-string-prefix (s1 s2)
"Return the longest common prefix of strings S1 and S2, or nil if none."
@@ -482,10 +489,12 @@
(subst-char-in-region from to ?\n ?\s)
(if (and nosqueeze (not (eq justify 'full)))
nil
-(canonically-space-region (or squeeze-after (point)) to)
-;; Remove trailing whitespace.
+;; Remove trailing whitespace, so canonically-space-region doesn't leave
+;; them at the end. Do this first, since `to' will be invalid after.
;; Maybe canonically-space-region should do that.
-(goto-char to) (delete-char (- (skip-chars-bac
compilation-finish-functions might be called with wrong buffer
Hello, compilation-handle-exit does this: (with-no-warnings (if compilation-finish-function (funcall compilation-finish-function (current-buffer) msg))) (run-hook-with-args 'compilation-finish-functions (current-buffer) msg))) However, `compilation-finish-function' might change the current buffer. In fact, JDEE does this. And while I think it probably shouldn't, that's not stated anywhere. regards, Nikolaj Schumacher diff -du /Users/nik/.emacs.d/backup/\!Applications\!Emacs.app\!Contents\!Resources\!share\!emacs\!22.1.50\!lisp\!progmodes\!compile.el.\~3\~ /Applications/Emacs.app/Contents/Resources/share/emacs/22.1.50/lisp/progmodes/compile.el --- lisp/progmodes/compile.el 2007-05-16 17:43:57.0 +0200 +++ lisp/progmodes/compile.el 2007-05-21 00:04:44.0 +0200 @@ -1426,7 +1426,8 @@ process-status exit-status msg) (cons msg exit-status))) (omax (point-max)) - (opoint (point))) + (opoint (point)) + (cur-buffer (current-buffer))) ;; Record where we put the message, so we can ignore it later on. (goto-char omax) (insert ?\n mode-name " " (car status)) @@ -1447,8 +1448,8 @@ (goto-char opoint)) (with-no-warnings (if compilation-finish-function - (funcall compilation-finish-function (current-buffer) msg))) -(run-hook-with-args 'compilation-finish-functions (current-buffer) msg))) + (funcall compilation-finish-function cur-buffer msg))) +(run-hook-with-args 'compilation-finish-functions cur-buffer msg))) ;; Called when compilation process changes state. (defun compilation-sentinel (proc msg) Diff finished. Mon May 21 00:04:48 2007 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
recentf-auto-cleanup hangs for sudo-type tramp files
Hello, if a file has been visited with tramp and sudo (e.g. "/sudo:[EMAIL PROTECTED]:/etc/crontab"), and is automatically added to recentf-list, then `recentf-auto-cleanup' hangs. Apparently `file-readable-p' (which is in `recentf-keep' by default) is the reason. regards, Nikolaj Schumacher In GNU Emacs 22.1.50.1 (i386-apple-darwin8.9.1, Carbon Version 1.6.0) of 2007-05-18 on wednesday Windowing system distributor `Apple Inc.', version 10.4.9 configured using `configure '--prefix=/Applications/Emacs.app/Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/Applications/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI -O2'' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
compilation-finish-functions broken
Hello, compilation-handle-exit fails with: error in process sentinel: Wrong type argument: symbolp, (my-compilation-finish-function) I think (run-hook-with-args compilation-finish-functions (current-buffer) msg))) should be (run-hook-with-args 'compilation-finish-functions (current-buffer) msg))) regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-mode fails in non-existing directory
martin rudalics <[EMAIL PROTECTED]> writes: > In fact I told Richard about that but forgot to check his patches. > Please try the attached one. It works, thank you. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-mode fails in non-existing directory
Richard Stallman <[EMAIL PROTECTED]> writes: > I remember fixing such a bug. What version are you using? > Or when did you get the sources from CVS. I'm using the very latest CVS sources. There seems to be such a fix in `ispell-call-process', but not in `ispell-start-process'. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: flyspell-mode fails in non-existing directory
martin rudalics <[EMAIL PROTECTED]> writes: after finding a new file in a not yet created directory, flyspell- mode fails with: True, but when "finding" that file Emacs should have told you Use M-x make-directory RET RET to create the directory and its parents which you apparently ignored ;-) and when trying to save the buffer Emacs would tell you basic-save-buffer-2: ...: no such directory I already knew that the directory didn't exist and how to create it. But why should I have to save the file to run flyspell, when I can even use it on buffers with no files associated? Also, I call flyspell-mode in a major-mode hook (or is there anything wrong with that?), so the error occurs before I even could save it. ispell seems to work around this for synchronous processes, but apparently not for `start-process'. I presume both ispell and flyspell use asynchronous processes on your system. Moreover the same error should be issued for synchronous ones. In fact, both `start-process' and `call-process' have identic code here: True, those two have identical code. Yet `ispell-call-process' is a wrapper used by ispell to "defend against bad `default-directory'". There is no such wrapper for in `ispell-start-process'. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
flyspell-mode fails in non-existing directory
Hello,
after finding a new file in a not yet created directory, flyspell-mode
fails with:
(file-error "Setting current directory" "no such file or directory"
"/Users/nik/Desktop/foo/")
start-process("ispell" nil "aspell" "-a" "-m" "-d" "en"
"--encoding=utf-8")
apply(start-process "ispell" nil "aspell" "-a" "-m"
("-d" "en" "--encoding=utf-8"))
ispell-start-process()
ispell-init-process()
ispell-buffer-local-words()
ispell-accept-buffer-local-defs()
flyspell-accept-buffer-local-defs(force)
flyspell-mode-on()
flyspell-mode(toggle)
ispell seems to work around this for synchronous processes, but apparently not
for `start-process'.
regards,
Nikolaj Schumacher
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: eval-last-sexp narrows buffer on error
martin rudalics <[EMAIL PROTECTED]> writes: >> I've tried. From what I can tell `specpdl' isn't being wound back >> afterwards, so `save_restriction_restore' is never called. >> >> In fact, this apparently is the case after any error (unless caught by >> `condition-case'), so `specpdl' grows bigger and bigger. Is that >> supposed to happen?? >> >> The functions called by `error' are >> * signal >> ** find_handler_clause >> *** call_debuger > > I'm too silly. Try to run with `debug-on-error' and > `eval-expression-debug-on-error' both nil. Okay, the problem doesn't occur then. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: eval-last-sexp narrows buffer on error
martin rudalics <[EMAIL PROTECTED]> writes: > It's a problem with `save-restriction'. Take: > > (with-current-buffer (get-buffer-create "*foo*") > (delete-region (point-min) (point-max)) > (insert "foo\nbar\nfoo\n") > (save-restriction > (narrow-to-region (line-beginning-position -1) (line-end-position -1)) > (error ""))) > > It will leave the buffer narrowed although the doc-string of > `save-restriction' says: > > AFAICT Emacs 20 DTRT here, Emacs 21 and 22 don't. Could you try to > debug it? I've tried. From what I can tell `specpdl' isn't being wound back afterwards, so `save_restriction_restore' is never called. In fact, this apparently is the case after any error (unless caught by `condition-case'), so `specpdl' grows bigger and bigger. Is that supposed to happen?? The functions called by `error' are * signal ** find_handler_clause *** call_debuger debug ***** recursive-edit ** command_loop *** internal_catch command_loop_2 from which it never returns. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
eval-last-sexp narrows buffer on error
Hello, Calling `eval-last-sexp' on: "\u" correctly causes the error "Non-hex digit used for Unicode escape", but unexpectedly leaves the buffer narrowed to point-min and point. regards, Nikolaj Schumacher In GNU Emacs 22.0.98.1 (i386-apple-darwin8.9.1, Carbon Version 1.6.0) of 2007-04-26 on wednesday Windowing system distributor `Apple Inc.', version 10.4.9 configured using `configure '--prefix=/Applications/Emacs.app/Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/Applications/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: de_DE.UTF-8 value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: up-list gives error inside strings
Richard Stallman <[EMAIL PROTECTED]> writes: > Calling `up-list' inside a string gives this error: > up-list: Scan error: "Unbalanced parentheses", 14, 19 > > These commands do not know that they are starting from inside a string. > > It may now be possible to make them understand that, using > syntax-ppss. If someone wants to start implementing this, please go > ahead; it could be installed in a later release. Thank you for pointing that out. Using this, it was very easy to get the function I wanted. (defun up-list-forward (arg) "Move forward out of one level of parentheses. With arg, do this that many times. A negative argument means move backward but still to a less deep spot." (interactive "p") (let ((pos (point))) (if (< arg 0) ;; backward (while (and pos (/= arg 0)) (setq pos (cadr (syntax-ppss pos))) (incf arg)) ;; forward (while (and pos (/= arg 0)) (when (setq pos (cadr (syntax-ppss pos))) (setq pos (scan-sexps pos 1)) ; move to end of sexp (decf arg (if pos (goto-char pos) (error "Reached top level" ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: up-list gives error inside strings
Stefan Monnier <[EMAIL PROTECTED]> writes: >> I can't tell if the failure to move out of the parentheses is by design, >> but the error message is misleading. > > One of the design constraints we've imposed on ourselves is that operations > like up-list and friends should ideally work "locally" without having to > parse the buffer from the very beginning > > Now you're going to say "but it's highlighted as a string, so Emacs knows > it's a string". Well, yes, kind of. But now users have found advantages to > the misfeature, and font-lock highlighting is not guaranteed to be > available and even less guaranteed to be correct, and > > So let's call it a known misfeature. It should be improved in the future. Well, I didn't even expect it to be fixable, as I suspected that it was a design limitation. However I'd like this to be documented in either the doc string or the error message. That would make it a _known_ misfeature, in my opinion. :) regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
up-list gives error inside strings
Hello, Calling `up-list' inside a string gives this error: up-list: Scan error: "Unbalanced parentheses", 14, 19 This is obviously not the case in this example: (setq foo "bar") ^ point I can't tell if the failure to move out of the parentheses is by design, but the error message is misleading. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: C- doesn't respect current keyboard layout, OS X Carbon
Hello, I've accumulated a bit of experience with these Unicode layouts since I use one myself. I've had the exact same problems with earlier versions of Emacs, however I've found that recent versions work correctly out of the box. I could not reproduce your problem, either, using a your layout on a (physically) German keyboard and OS 10.4.9. > In the input menu, the only other available keyboard is a British (UK) > layout. No other account has the German keyboard available. > - The key with the label z, which sends y to every app on the system, > sends C-z to this emacs build when pressed at the same time as the > control key Usually it would fall back to the available non-Unicode keyboards, i.e. UK in this case. Can you verify that only the UK layout was checked in International (other than you layout of course). Would you try my keylayout to see what happens? You can get it on https://bugs.eclipse.org/bugs/show_bug.cgi?id=153432 regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: keymap changes in run-with-timer
Stefan Monnier writes: > > It would probably be good to delay it, but this is not very high priority. > I've added it to the TODO list. Thank you. Lennart Borgman writes: > If you think it is possible to do it now it would be good. I need this for > mumamo too. (Mumamo is here: http://www.emacswiki.org/cgi-bin/wiki/MuMaMo) > > I have a workaround there for this. I call top-level after such > changes (in this case after changing major mode in a timer). Thank you for pointing that out; it works well. It is unfortunate that it prints out "Back to top level" every time. My workaround so far has been to merge the keymap into the current map using define-key, one entry at a time. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
keymap changes in run-with-timer
Hello, selecting a keymap (e.g. when changing minor-mode, creating 'keymap overlays, setting overriding-local-map, use-local-map) in a run-with-timer or run-with-idle-timer event doesn't take immediate effect. Consider the following example: (run-with-timer 3 nil '(lambda () (let ((map (make-sparse-keymap))) (define-key map "x" "y") (use-local-map map)) (message "timer fired"))) After the message "timer fired", pressing the "x" key still inserts an "x". Only beginning with the second time it will insert a "y". Changing the /content/ of a keymap like this: (run-with-timer 3 nil '(lambda () (define-key (current-local-map) "x" "y") (message "timer fired"))) works immediately, though. regards, Nikolaj Schumacher In GNU Emacs 22.0.97.2 (i386-apple-darwin8.9.1, Carbon Version 1.6.0) of 2007-04-05 on wednesday Windowing system distributor `Apple Inc.', version 10.4.9 configured using `configure '--prefix=/Applications/Emacs.app/Contents/Resources' '--with-carbon' '--without-x' '--libexecdir=/Applications/Emacs.app/Contents/MacOS/libexec' 'CFLAGS=-arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -DUSE_ATSUI'' ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: edebug-pop-to-buffer fails for dedicated windows
martin rudalics <[EMAIL PROTECTED]> writes: >> edebug-pop-to-buffer changes the buffer in the "next window". >> However this results in an error, if that window is dedicated. > > Please try the attached patch. It fixes the problem for me. Thank you. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
edebug-pop-to-buffer fails for dedicated windows
Hello, edebug-pop-to-buffer changes the buffer in the "next window". However this results in an error, if that window is dedicated. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: move-to-column inconsistent with invisible text
martin rudalics <[EMAIL PROTECTED]> writes: > Could you please try the attached patch. Yes, it apparently fixes the problem. Thank you. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
move-to-column inconsistent with invisible text
Hello, when I create an overlay to hide text, move-to-column works differently depending on the point's position in the current line. If the point is before the hidden characters, it will move the point to the N'th visible column (i.e. the one given by column-number-mode), but when the point is behind the hidden characters, it will move the point to (point-at-bol) + N. Consider the following example: (progn (insert "1234567890") (let ((overlay (make-overlay (+ (point-at-bol) 2) (+ (point-at-bol) 4 (overlay-put overlay 'invisible t) (let ((point-a (save-excursion (beginning-of-line) (move-to-column 6) (point))) (point-b (save-excursion (end-of-line) (move-to-column 6) (point (delete-overlay overlay) (message "%d %d" point-a point-b point-a and point-b should be equal, but they are not. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Bug in documentation for buffer-display-table
Hello, the documentation for `buffer-display-table' contains: > For example, (aset buffer-display-table ?X ?Y) will cause Emacs to display > a capital Y instead of each X character. However this is not true, as it needs to be something like: (aset buffer-display-table ?X (vector ?Y)) regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: x-show-tip color choices
Nick Roberts <[EMAIL PROTECTED]> writes: > Why do you call x-show-tip? Ok, actually I don't. A package I tried to use does, I just couldn't read the tooltips. > I think x-show-tip is just meant as an internal function for > tooltip-show. > Unless you have a real purpose for using x-show-tip directly, I don't > think this is worth changing. Fair enough, but in that case I'd suggest pointing that out in x-show-tip's documentation. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
x-show-tip color choices
Hello, I'm not quite sure if this qualifies as a bug, however I find it irritating: I have this in my .emacs: (add-to-list 'default-frame-alist '(background-color . "black")) (add-to-list 'default-frame-alist '(foreground-color . "wheat")) So when I call (x-show-tip "hello") I get a tooltip with wheat-colored text and a yellow background. I don't think it should override only one of the background and foreground colors; either both or none. regards, Nikolaj Schumacher ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
byte-compile compile log shows wrong line number
Hello, *Compile-Log* shows a wrong line number for the error in certain cases. To reproduce, create a file "foo.el" with the content: foo (byte-compile-file "foo.el") will result in foo.el:1:2:Warning: reference to free variable `foo' which is correct. Now change the file content to: foo (byte-compile-file "foo.el") will result in foo.el:0:1:Warning: reference to free variable `foo' which is not. A patch is attached. regards Nikolaj Schumacher --- lisp/emacs-lisp/bytecomp.el 2007-03-11 15:29:29.0 +0100 +++ lisp/emacs-lisp/bytecomp.el 2007-03-11 15:29:40.0 +0100 @@ -967,21 +967,24 @@ (format "%s:" (file-relative-name byte-compile-current-file dir))) ((bufferp byte-compile-current-file) (format "Buffer %s:" (buffer-name byte-compile-current-file))) (t ""))) (pos (if (and byte-compile-current-file (integerp byte-compile-read-position)) (with-current-buffer byte-compile-current-buffer - (format "%d:%d:" (count-lines (point-min) - byte-compile-last-position) - (save-excursion - (goto-char byte-compile-last-position) - (1+ (current-column) + (save-excursion + (format "%d:%d:" + (progn +(goto-char byte-compile-last-position) +(1+ (count-lines (point-min) (point-at-bol + (progn +(goto-char byte-compile-last-position) +(1+ (current-column)) "")) (form (if (eq byte-compile-current-form :end) "end of data" (or byte-compile-current-form "toplevel form" (when (or (and byte-compile-current-file (not (equal byte-compile-current-file byte-compile-last-logged-file))) (and byte-compile-current-form (not (eq byte-compile-current-form ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
ediff spaces and multifile patches
Hello,
I've noticed two problems with ediff.
* It has a problem with spaces in file names
Ediff mistakes the space for the file name/date separator. I've changed
it to look for a tab instead, which worked in my case. But I don't know
if the tab is guaranteed by the diff format and hence whether this is safe
to do.
Incidentally, diff-font-lock-keywords exhibits the same problem
* Applying a patch with relative file names to a directory using
ediff-patch-file will look for the relative file names in the directory of
the patch instead of the to-be-patched directory. That means, unless
those are equal, ediff will unnecessarily prompt for the path of every
file.
Small patches are attached for both.
Regards,
Nikolaj Schumacher
diff -rdU8 lisp_orig/diff-mode.el lisp/diff-mode.el
--- lisp/diff-mode.el 2007-02-25 18:16:25.0 +0100
+++ lisp/diff-mode.el 2007-02-25 17:59:32.0 +0100
@@ -333,17 +333,17 @@
`(("^\\(@@ -[0-9,]+ \\+[0-9,]+ @@\\)\\(.*\\)$" ;unified
(1 diff-hunk-header-face) (2 diff-function-face))
("^\\(\\*\\{15\\}\\)\\(.*\\)$";context
(1 diff-hunk-header-face) (2 diff-function-face))
("^\\*\\*\\* .+ \\*\\*\\*\\*". diff-hunk-header-face) ;context
("^--- .+ $" . diff-hunk-header-face) ;context
("^[0-9,]+[acd][0-9,]+$" . diff-hunk-header-face) ;normal
("^---$" . diff-hunk-header-face) ;normal
-("^\\(---\\|\\+\\+\\+\\|\\*\\*\\*\\) \\(\\S-+\\)\\(.*[^*-]\\)?\n"
+("^\\(---\\|\\+\\+\\+\\|\\*\\*\\*\\) \\([^\t]+\\)\\(.*[^*-]\\)?\n"
(0 diff-header-face) (2 diff-file-header-face prepend))
("^\\([-<]\\)\\(.*\n\\)"
(1 diff-indicator-removed-face) (2 diff-removed-face))
("^\\([+>]\\)\\(.*\n\\)"
(1 diff-indicator-added-face) (2 diff-added-face))
("^\\(!\\)\\(.*\n\\)"
(1 diff-indicator-changed-face) (2 diff-changed-face))
("^Index: \\(.+\\).*\n"
diff -rdU8 lisp_orig/ediff-ptch.el lisp/ediff-ptch.el
--- lisp/ediff-ptch.el 2007-02-25 18:16:25.0 +0100
+++ lisp/ediff-ptch.el 2007-02-25 18:11:11.0 +0100
@@ -311,22 +311,23 @@
(file-exists-p base-dir1))
(message "(file-exists-p base-dir2) %s"
(file-exists-p base-dir2))
;; If both base-dir1 and base-dir2 are relative and exist,
;; assume that
;; these dirs lead to the actual files starting at the present
;; directory. So, we don't strip these relative dirs from the
;; file names. This is a heuristic intended to improve guessing
- (unless (or (file-name-absolute-p base-dir1)
- (file-name-absolute-p base-dir2)
- (not (file-exists-p base-dir1))
- (not (file-exists-p base-dir2)))
+(let ((default-directory (file-name-directory filename)))
+ (unless (or (file-name-absolute-p base-dir1)
+ (file-name-absolute-p base-dir2)
+ (not (file-exists-p base-dir1))
+ (not (file-exists-p base-dir2)))
(setq base-dir1 ""
- base-dir2 ""))
+ base-dir2 "")))
(or (string= (car proposed-file-names) "/dev/null")
(setcar proposed-file-names
(ediff-file-name-sans-prefix
(car proposed-file-names) base-dir1)))
(or (string=
(cdr proposed-file-names) "/dev/null")
(setcdr proposed-file-names
(ediff-file-name-sans-prefix
--- ediff-ptch.el 2007-02-25 18:10:42.0 +0100
+++ ediff-ptch.el 2007-02-25 18:11:11.0 +0100
@@ -311,22 +311,23 @@
(file-exists-p base-dir1))
(message "(file-exists-p base-dir2) %s"
(file-exists-p base-dir2))
;; If both base-dir1 and base-dir2 are relative and exist,
;; assume that
;; these dirs lead to the actual files starting at the present
;; directory. So, we don't strip these relative dirs from the
;; file names. This is a heuristic intended to improve guessing
- (unless (or (file-name-absolute-p base-dir1)
- (file-name-absolute-p base-dir2)
- (not (file-exists-p base-dir1))
- (not (file-exists-p base-dir2)))
+(let ((default-directory (file-name-directory filename)))
+ (unless (or (file-name-absolute-p base-dir1)
+ (file-name-absolute-p base-dir2)
+ (not (file-exists-p base-dir1))
+ (not (file-exists-p base-dir2)))
(setq base-dir1 ""
- base-dir2 ""))
+ base-dir2 "")))
(or (string= (car proposed-file-names) "/dev/null")
(setcar proposed-file-names
(ediff-file-name-sans-prefix
(car
