Re: CVS directories after make install
Date: Thu, 8 Mar 2007 22:55:31 +0100 From: Matzi Kratzi [EMAIL PROTECTED] After the installation has finished, I have a working emacs, but I also have a few not wanted catalogues and files in C:\download\emacs-cvs\070308\: .\data .\etc\.arch-inventory .\etc\.cvsignore .\etc\CVS .\info\.arch-inventory .\info\.cvsignore .\info\CVS .\leim\ja-dic\CVS .\leim\jquail\CVS and so on. The source control files are everywhere. Are they supposed to be around after installation? No, I don't think so. Thanks for reporting this, I will see if it can be fixed easily enough to install before the release of Emacs 22.1; if not, it will be fixed after the release. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ELP bug with CL's labels
Does that code work correctly when you do NOT debug it with edebug? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: unread
(list (input-pending-p) (setq unread-post-input-method-events '(?x)) (input-pending-p) (setq unread-input-method-events '(?y)) (input-pending-p) (discard-input) (input-pending-p)) ; (nil (120) t (121) t nil t)xy I am not really sure, but since this isn't changed and isn't a bug, let's leave it alone. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Richard Stallman [EMAIL PROTECTED] writes: , | Emacs.mode-line.attributeBackground:#fbf8f1 | Emacs.mode-line.attributeForeground:#101010 ` but I don't have such settings in my ~/.Xresources. The window manager makes those, but you've identified an Emacs bug. The bug is that, for frames other than the first, the X resources override your customization: Can someone please fix that, then ack? The behavior where X resources override Custom (and all other Elisp face settings) seems to have been around since forever --- it can be seen in Emacs 21 --- and there is no easy clean way to fix it. One possibility is for the relevant code in faces.el to look for a 'theme-face, and not apply X resources if so. This is a kludge since the faces code should ideally be independent of custom, but maybe it will suffice for now. Another possibility is to stop the window manager from automatically setting a face resource for the mode-line. There would then be no problem with the convention that X resources override Elisp, since X resources would be set by the user. I don't know how to do this, though. In the first place, why does the window manager automagically set the mode-line face resource? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: ELP bug with CL's labels
Richard Stallman [EMAIL PROTECTED] writes: Does that code work correctly when you do NOT debug it with edebug? Yes, it does. (Otherwise I'd have mentioned it.) I suppose it is nevertheless a bug and not just a missing feature, because: if edebug encounters a macro about which it has no information, it normally just jumps over the entire macro body while silently macroexpanding it. For instance: (defmacro my-do-vector (var vect rest body) (let ((i (make-symbol i)) (len (make-symbol len)) (v (make-symbol v))) `(let* ((,i 0) (,v ,vect) (,len (length ,vect))) (while ( ,i ,len) (setq ,var (aref ,v ,i) ,i (1+ ,i)) ,@body (defun my-test () (my-do-vector e [alpha beta gamma] (print e))) No error here, when edebugging `my-test'. Though, edebug does not step through the loop in the `my-do-vector' expression, either. IIRC, it is possible to advise `edebug' about what to do with such macros. I suppose, the described bug with `labels' happens, because edebug actually tries to DTRT, but fails. I have not checked yet, whether this bug might be more general; for instance, it could be a bug in said advice mechanism. Oliver -- Oliver Scholz 19 Ventôse an 215 de la Révolution Ostendstr. 61 Liberté, Egalité, Fraternité! 60314 Frankfurt a. M. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Error when using partial-completion-mode
emacs -q --no-site-file M-: ;; (eval-expression) (partial-completion-mode t) RET M-x emacs-version ;; or a lot of other interactive commands = error: PC-do-complete-and-exit: Wrong type argument: char-or-string-p, t Debugger entered--Lisp error: (wrong-type-argument char-or-string-p t) apply(debug error (wrong-type-argument char-or-string-p t)) edebug(error (wrong-type-argument char-or-string-p t)) signal(wrong-type-argument (char-or-string-p t)) edebug-signal(wrong-type-argument (char-or-string-p t)) PC-do-completion(exit) (edebug-after (edebug-before 10) 11 (PC-do-completion 'exit)) (let ((flag ...)) (edebug-after (edebug-before 12) 28 (and ... ...))) (edebug-after (edebug-before 9) 29 (let (...) (edebug-after ... 28 ...))) (if (edebug-after (edebug-before 1) 6 (= ... ...)) (edebug-after (edebug-before 7) 8 (exit-minibuffer)) (edebug-after (edebug-before 9) 29 (let ... ...))) (edebug-after (edebug-before 0) 30 (if (edebug-after ... 6 ...) (edebug-after ... 8 ...) (edebug-after ... 29 ...))) (lambda nil (edebug-after (edebug-before 0) 30 (if ... ... ...)))() edebug-enter(PC-do-complete-and-exit nil (lambda nil (edebug-after (edebug-before 0) 30 (if ... ... ... edebug-enter(PC-do-complete-and-exit nil (lambda nil (edebug-after (edebug-before 0) 30 (if ... ... ... PC-do-complete-and-exit() PC-complete-and-exit() call-interactively(PC-complete-and-exit) execute-extended-command(nil) call-interactively(execute-extended-command) In GNU Emacs 22.0.95.1 (i386-msvc-nt5.1.2600) of 2007-03-09 on CLEOPATRA X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-msvc (13.10)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: ELI Minor modes in effect: regexp-lock-mode: t erc-track-mode: t minibuffer-electric-default-mode: t which-function-mode: t auto-image-file-mode: t pc-selection-mode: t dynamic-completion-mode: t recentf-mode: t shell-dirtrack-mode: t show-paren-mode: t encoded-kbd-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: SPC SPC SPC SPC SPC SPC SPC SPC SPC up S-down S-down S-down S-down S-down S-down S-down S-down S-down S-down S-down S-down S-down C-insert C-S-end C-insert C-M-up C-M-up C-g home C-M-up C-M-up q backspace return C-M-x q M-x r e p o r t - e m tab return end C-g C-M-up down down M-right M-right M-right left left C-s C-w C-w C-w C-s C-s home M-down M-down M-down M-down M-down C-M-up backspace n i l end C-x C-e M-s M-x up up up up up up up up up M-backspace M-backspace M-backspace r e p o r tab return Recent messages: PC-do-complete-and-exit Back to top level. let: Wrong type argument: char-or-string-p, t Quit Mark saved where search started Toggling partial-completion-mode off; better pass an explicit argument. nil Saving file d:/user/cco/_emacs... Wrote d:/user/cco/_emacs Loading emacsbug...done -- SurgiTAIX AG Aachen Pauwelsstraße 19 D-52074 Aachen Mail: [EMAIL PROTECTED] I-Net: www.surgitaix.de Tel: +49 241 9632146 Fax: +49 241 9632145 Vorstand: Dr. Frank Portheine Vorsitzender Aufsichtsrat Prof. Dr. Hans-Walter Staudte Amtsgericht Aachen HRB 8474 UStIdNr. DE 215423410 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
abbrev can't be required
package abbrev can't be required. In GNU Emacs 22.0.95.1 (i386-msvc-nt5.1.2600) of 2007-03-09 on CLEOPATRA X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-msvc (13.10)' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: ELI Minor modes in effect: regexp-lock-mode: t erc-track-mode: t minibuffer-electric-default-mode: t which-function-mode: t auto-image-file-mode: t pc-selection-mode: t recentf-mode: t shell-dirtrack-mode: t show-paren-mode: t encoded-kbd-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: next prior M-delete home M-up M-up M-up down down right M-S-right S-delete l o a d - l i b r a r y M-s down M-left M-left M-S-right S-delete r e q u i r e right delete ' end left backspace M-s home up C-M-x down C-M-x down C-x C-f up up M-backspace M-backspace return down next up up up up up up up up up up up up up up up up up up up up up up up up return C-end C-home M-delete M-delete M-x r e p o r t - e m tab return Recent messages: Wrote d:/user/cco/_emacs Mark set Saving file d:/user/cco/_emacs... Wrote d:/user/cco/_emacs Loading abbrev... ad-handle-definition: `write-abbrev-file' got redefined Loading abbrev...done t dabbrev Mark set -- SurgiTAIX AG Aachen Pauwelsstraße 19 D-52074 Aachen Mail: [EMAIL PROTECTED] I-Net: www.surgitaix.de Tel: +49 241 9632146 Fax: +49 241 9632145 Vorstand: Dr. Frank Portheine Vorsitzender Aufsichtsrat Prof. Dr. Hans-Walter Staudte Amtsgericht Aachen HRB 8474 UStIdNr. DE 215423410 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
partial-completion-mode error reported some hours ago not reproducible on GNU/Linux
Hi, i compiled a new emacs from CVS on GNU/Linux, slightly newer than the one compiled some hours ago on the Windows XP machine. With this emacs i can not reproduce the bug (tested with emacs -q --no-site-file). In GNU Emacs 22.0.95.1 (i686-pc-linux-gnu) of 2007-03-09 on brabbelbox X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure 'CC=gcc'' Important settings: value of $LC_ALL: [EMAIL PROTECTED] value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: [EMAIL PROTECTED] locale-coding-system: iso-8859-15 default-enable-multibyte-characters: t Major mode: Ibuffer by recency Minor modes in effect: shell-dirtrack-mode: t partial-completion-mode: t recentf-mode: t minibuffer-electric-default-mode: t auto-image-file-mode: t erc-track-mode: t global-cwarn-mode: t delete-selection-mode: t pc-selection-mode: t icomplete-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Second part: partial-completion-mode error reported some hours ago not reproducible on GNU/Linux
Sorry, send too fast my last mail. Two considerations on the bug absence: - maybe it is fixed in the meantime - or it only occurs on windows xp compiled with vc 7.1 In GNU Emacs 22.0.95.1 (i686-pc-linux-gnu) of 2007-03-09 on brabbelbox X server distributor `The X.Org Foundation', version 11.0.70101000 configured using `configure 'CC=gcc'' Important settings: value of $LC_ALL: [EMAIL PROTECTED] value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: [EMAIL PROTECTED] locale-coding-system: iso-8859-15 default-enable-multibyte-characters: t Major mode: Group Minor modes in effect: shell-dirtrack-mode: t partial-completion-mode: t recentf-mode: t minibuffer-electric-default-mode: t auto-image-file-mode: t gnus-topic-mode: t gnus-undo-mode: t erc-track-mode: t global-cwarn-mode: t delete-selection-mode: t pc-selection-mode: t show-paren-mode: t icomplete-mode: t mouse-wheel-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Error when using partial-completion-mode
PC-do-complete-and-exit: Wrong type argument: char-or-string-p, t Thanks for reporting. Should have been fixed in the meantime. Please try again. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: abbrev can't be required
package abbrev can't be required. abbrev is preloaded. Why do you see a need to require it? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
2001-11-03 Richard M. Stallman [EMAIL PROTECTED] (command-line-1): Reorganize display of startup screen, to simplify the logic. Use a temp buffer for it. That sounds like a larger change. Is your change a reversion of that whole previous change, or just an adjustment of it? It looks to me that you simply decided not to insert the initial scratch message if another buffer had been selected during startup. More precisely, if the init file leaves a different buffer selected. That sounds right; shouldn't it be so? Perhaps the right change is in desktop, to make it not select any of the buffers it makes. Or perhaps no change is needed. If you resume a saved session, you have presumably seen the scratch screen in the previous session. So maybe it is right that it goes straight back to the status that was saved, without showing the scratch screen again. (If I hadn't written the last sentence you quote above, would we be having this discussion?). We would be having a discussion with a different starting point but about the same questions. Previous history would still come into it. In general, people seem to be too quick to propose reverting a previous change as a solution to a new problem. It is not unusual that the change to fix one problem causes another. Reverting the change would bring back the former problem. Once in a while, this is the right thing to do, but usually it is not. Usually the right thing to do is to look for a change that fixes the new problem without bringing back the old one. When we know what the problem was that motivated the previous fix, we can specifically think about not bringing it back. Otherwise, we have to try to figure out what it was (perhaps guessing), or else just be cautious, looking for a way to change the code to fix the new problem without altering most of the effect of the previous fix. It is also important to be clear about whether you are proposing to revert a previous fix. The words you wrote are It reverts the behaviour to what it was before rev 1.270 I took that to mean that you were reverting the patch, but now I can see it could be interpreted differently, as just reverting a certain aspect of the behavior. Which meaning did you have in mind? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Chong Yidong [EMAIL PROTECTED] writes: Can someone please fix that, then ack? The behavior where X resources override Custom (and all other Elisp face settings) seems to have been around since forever --- it can be seen in Emacs 21 ... So we obviously don't need to anything about it before the release. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
Richard Stallman [EMAIL PROTECTED] writes: In general, people seem to be too quick to propose reverting a previous change as a solution to a new problem. It is not unusual that the change to fix one problem causes another. Reverting the change would bring back the former problem. Once in a while, this is the right thing to do, but usually it is not. Usually the right thing to do is to look for a change that fixes the new problem without bringing back the old one. In general, I agree. But since we are trying to make a release happen, reverting a change (for some minor bug) which turns out to cause more problems than it fixes seems acceptable to me. Also, IMO for 22.1, we should only fix bugs which are regressions since 21.4. Any bug which was also present in 21.4 should wait for 22.2 or 23.1 -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
Can someone please fix that, then ack? The behavior where X resources override Custom (and all other Elisp face settings) seems to have been around since forever --- it can be seen in Emacs 21 ... So we obviously don't need to anything about it before the release. Actually it seems to be present for the mode-line and toolbar, but not the scrollbar. That is, if I start emacs -Q, customize the background of the faces of all three (to white, say), then do `C-x 5 2', the new frame displays the mode-line and toolbar with the previos face, but the scrollbar retains its white background. However, I don't if this is because Emacs implements the scrollbar differently, or because Metacity handles it differently. -- Nick http://www.inet.net.nz/~nickrob ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
On 3/10/07, Kim F. Storm [EMAIL PROTECTED] wrote: Also, IMO for 22.1, we should only fix bugs which are regressions since 21.4. Any bug which was also present in 21.4 should wait for 22.2 or 23.1 I'd like to think you're talking about trivial bugs or bugs that cannot lead to data loss. A bug that crashes Emacs, or corrupts a buffer contents, or silently fails to write changes to disk, or some such, should be fixed right now even if it's been with us forever. (Not that I know of any such bug, of course.) Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
[EMAIL PROTECTED] (Kim F. Storm) writes: [...] Also, IMO for 22.1, we should only fix bugs which are regressions since 21.4. Any bug which was also present in 21.4 should wait for 22.2 or 23.1 FYI, both this bug and the other one I reported about edebug and `labels' were already present in 21.4. I just checked. Oliver -- Oliver Scholz 20 Ventôse an 215 de la Révolution Ostendstr. 61 Liberté, Egalité, Fraternité! 60314 Frankfurt a. M. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: double-clicking on closing paren - wrong region marked
Stefan Monnier [EMAIL PROTECTED] writes: 4 - somehow this highlighting causes scrolling. 5 - the subsequent (up) mouse-1 is then treated as a drag because the start and end point in the buffer are different. .. The problem can be fixed at 2 places: 1 - at step 4, there shouldn't be any scrolling. I have installed a change to fix this. 2 - at step 5, since the mouse hasn't moved, and since the time between the down-mouse-1 and the (up) mouse-1 is short, this shouldn't be considered as a drag. I don't think we need to do anything about this now. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
Juanma Barranquero [EMAIL PROTECTED] writes: On 3/10/07, Kim F. Storm [EMAIL PROTECTED] wrote: Also, IMO for 22.1, we should only fix bugs which are regressions since 21.4. Any bug which was also present in 21.4 should wait for 22.2 or 23.1 I'd like to think you're talking about trivial bugs or bugs that cannot lead to data loss. A bug that crashes Emacs, or corrupts a buffer contents, or silently fails to write changes to disk, or some such, should be fixed right now even if it's been with us forever. (Not that I know of any such bug, of course.) There were many bugs in 21.4 which can crash or lose data which are already fixed in 22.1 -- so even if we know that 22.1 can still crash or lose data in some obscure way should - IMHO - not delay the release any further. Of course, if someone can find a fix for the problem before the release, that's good. -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Initial scratch message missing with desktop-save-mode on
Richard Stallman wrote: That sounds like a larger change. Is your change a reversion of that whole previous change, or just an adjustment of it? The change was a large one. This was tiny, IMO incidental part of it. It looks to me that you simply decided not to insert the initial scratch message if another buffer had been selected during startup. More precisely, if the init file leaves a different buffer selected. That sounds right; shouldn't it be so? I don't see why the insertion of the initial scratch message should be conditional on which buffer happens to be current at that point in the start-up sequence. There exists a mechanism to disable the message if so desired. Perhaps the right change is in desktop, to make it not select any of the buffers it makes. No, I think it's right that desktop restore the order of the buffer list at the time you save, which is what it seems to do now. The splash screen is still displayed, BTW, but when you click through it you get your last buffer back. I took that to mean that you were reverting the patch, but now I can see it could be interpreted differently, as just reverting a certain aspect of the behavior. Which meaning did you have in mind? I meant, revert this particular tiny aspect of behaviour, not revert the whole change. I intended revert to be a comforting word, in the sense of, it used to work like this, so it can't be too crazy... :) I'm happy if we drop this till after 22. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mode-line face bug
On 2007-03-09, Nick Roberts said: Can someone please fix that, then ack? The behavior where X resources override Custom (and all other Elisp face settings) seems to have been around since forever --- it can be seen in Emacs 21 ... So we obviously don't need to anything about it before the release. Actually it seems to be present for the mode-line and toolbar, but not the scrollbar. That is, if I start emacs -Q, customize the background of the faces of all three (to white, say), then do `C-x 5 2', the new frame displays the mode-line and toolbar with the previos face, but the scrollbar retains its white background. However, I don't if this is because Emacs implements the scrollbar differently, or because Metacity handles it differently. The scroll bar had a similar bug but it is fixed in http://news.gmane.org/group/gmane.emacs.devel/thread=65822/force_load=t/focus=65839. I am wondering if a similar patch can be created for mode-line and toolbar. Regards, -- Leo sdl.web AT gmail.com (GPG Key: 9283AA3F) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
