beginning-of-defun
Problems with (beginning-of-defun): Cursor at roof-sign (when t (defun foo () (interactive) (message %s baz))) ^ M-x beginning-of-defun == (when t ^ (defun foo () (interactive) (message %s baz))) Wrong, as at the start of the enclosing form. Set `defun-prompt-regexp' via customize at [ \t]* (when t (defun foo () (interactive) (message %s baz))) ^ M-x beginning-of-defun == (when t (defun foo () (interactive) (message %s baz))) ^ Also wrong: cursor at the beginning of line now. The reason seems the conception of the variable `defun-prompt-regexp' which solely takes spaces before the defuns beginning in consideration. It could be avoided, if this var would take instead of `a regexp to ignore before a defun' a regexp `describing the beginning of a defun' Then we could specify [ \t]*(defun for example in Emacs Lisp mode and it would not fail if we are inside a defun or just after it already. __ Andreas Roehler ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Font-locking and single quotes in shell script mode
This change: 2005-11-27 Stefan Monnier [EMAIL PROTECTED] * progmodes/sh-script.el (sh-font-lock-syntactic-keywords): \ doesn't escape single quotes. causes a bug in sh-mode when the file contains something like the following: | $ cat foo.sh | #!/bin/sh | echo Don\'t do that | echo Let's do that instead | $ The single quote on the second line messes up fontification of the rest of the file up to the next single quote. Reverting sh-script.el to revision 1.172 makes this test case work again. Thanks, -- Romain Francoise [EMAIL PROTECTED] | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Font-locking and single quotes in shell script mode
* progmodes/sh-script.el (sh-font-lock-syntactic-keywords): \ doesn't escape single quotes. causes a bug in sh-mode when the file contains something like the following: | $ cat foo.sh | #!/bin/sh | echo Don\'t do that | echo Let's do that instead | $ The single quote on the second line messes up fontification of the rest of the file up to the next single quote. Reverting sh-script.el to revision 1.172 makes this test case work again. Yes: one setting is right for some cases and the other is right for the other cases. I made the change because it seemed to be more often correct that way. But that depends on your usage pattern. Feel free to fix it for good, but it's difficult. And if you're up for such a challenge, then maybe you're up for the next one as well: echo $(echo '') -- Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
compile.el change
After this change: 2006-07-07 Stefan Monnier [EMAIL PROTECTED] * progmodes/compile.el (compilation-error-regexp-alist-alist) gnu: Use shy regexp. Fix incorrect backref to potentially unmatched group. the compilation start/end lines are recognized as compilation errors. | Compilation started at Sat Jul 8 15:14:23 | Compilation finished at Sat Jul 8 15:14:23 Reverting to compile.el revision 1.398 fixes the problem. -- Romain Francoise [EMAIL PROTECTED] | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Font-locking and single quotes in shell script mode
Stefan Monnier [EMAIL PROTECTED] writes: Yes: one setting is right for some cases and the other is right for the other cases. I made the change because it seemed to be more often correct that way. But that depends on your usage pattern. Okay, thanks. -- Romain Francoise [EMAIL PROTECTED] | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: beginning-of-defun
Andreas Roehler [EMAIL PROTECTED] writes: Wrong, as at the start of the enclosing form. well, defun here actually means top-level form; the command works w/ all kinds of sexps, whether or not they are actually `defun's. the way to make the behavior arbitrarily more precise is to customize `beginning-of-defun-function'. for example, see `python-beginning-of-defun' in progmodes/python.el. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: timer error
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: At Nick Robert's request, here is the lisp backtrace on the error I reported a couple of days ago. This happens to me at various random moments in recent CVS emacsen. In this instance I had only recently started up emacs... Gil Debugger entered--Lisp error: (range-error floor 174058816388191.03) floor(174058816388191.03) timer-relative-time((17583 46528 355684) 0.5 0) timer-inc-time([t 17583 46528 355684 0.5 blink-cursor-timer-function nil nil] 0.5 0) timer-event-handler([t 17583 46528 355684 0.5 blink-cursor-timer-function nil nil]) If emacs crashed, and you have the emacs process in the gdb debugger, please include the output from the following gdb commands: `bt full' and `xbacktrace'. If you would like to further debug the crash, please read the file /Applications/Emacs.app/Contents/Resources/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (i386-apple-darwin8.7.1) of 2006-06-28 on phi-qp617070u2s.princeton.edu X server distributor `Apple Computers', version 10.4.7 configured using `configure '--without-x' '--prefix=/usr/local'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: nil locale-coding-system: iso-8859-1 default-enable-multibyte-characters: t Major mode: Debugger Minor modes in effect: encoded-kbd-mode: t recentf-mode: t display-time-mode: t tooltip-mode: t mouse-wheel-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t line-number-mode: t Recent input: t i o n s SPC backspace return f C-v C-v C-v C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n help-echo wheel-up double-wheel-up down-mouse-1 mouse-1 C-x b d i SPC return C-n C-n C-n C-n C-n C-e return return * SPC S a t u r d a y , SPC J u l y SPC 8 , SPC 2 0 0 6 return return * * SPC S u z a n n e SPC a n d SPC P a u l return C-o S u help-echo menu-bar help-menu report-emacs -bug Recent messages: Cleaning up the recentf list...done (0 removed) For information about the GNU Project and its goals, type C-h C-p. Loading encoded-kb...done Debug on Error enabled Making completion list... Loading help-mode...done Loading dired...done Loading debug...done Entering debugger... Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: timer error
I am suddenly getting the following error regularly, using several recent CVS versions. timer-relative-time: Arithmetic range error: floor, 173915144354731.1 I suggest you try running under GDB all the time, with a breakpoint at the line in floor which signals this error, so you can find out more about what causes it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc string for define-minor-mode: deactivate, not disactivate
From: Drew Adams [EMAIL PROTECTED] Date: Fri, 7 Jul 2006 09:52:30 -0700 Subject line says it all - the word is deactivate, not disactivate. And it's better to say activated or deactivated than (de)activated. Better yet is to say turned on or off. Right on both accounts. In addition, the doc string used passive tense. I fixed all of these. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Rectangles are not explained or cross-referenced in Elisp manual
The Elisp manual says nothing about rectangles. It mentions them in passing in a few places, with no explanation. Those places should at least contain a cross-reference to the Rectangles node of the Emacs manual. Also, there are two places where the text says a 'frame' is a rectangle. This promotes confusion. It would be better to say a 'frame' is a rectangular area of your screen or, better, a 'frame' is a window-manager window. The latter is by far the most helpful description. In GNU Emacs 22.0.50.1 (i386-mingw-nt5.1.2600) of 2006-03-20 on W2ONE X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4) --cflags -Id:/g/include' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[Fwd: Re: beginning-of-defun]
---BeginMessage--- Thien-Thi Nguyen schrieb: Andreas Roehler [EMAIL PROTECTED] writes: Wrong, as at the start of the enclosing form. well, defun here actually means top-level form; the command works w/ all kinds of sexps, whether or not they are actually `defun's. `defun' is a special form with a special meaning in emacs-lisp , | 12.4 Defining Functions | === | | We usually give a name to a function when it is first created. This is | called defining a function, and it is done with the `defun' special | form. | | -- Spezielle Form: defun name argument-list body-forms | `defun' is the usual way to define new Lisp functions. ` Think it's disturbing to introduce a different meaning employing the same name. This pertains to the Emacs Manual were is said , | 31.2.2 Moving by Defuns | --- | | These commands move point or set up the region based on top-level major | definitions, also called defuns. ` A `top-level-form' might be a defun, but is a far more general terminus with his value at his own AFAIU. Certainly a function `beginning-of-top-level-form' is useful. However, it should be callable separate from `beginning-of-defun' and vice versa. the way to make the behavior arbitrarily more precise is to customize `beginning-of-defun-function'. for example, see `python-beginning-of-defun' in progmodes/python.el. `beginning-of-defun' should work right out of the box at least in Emacs Lisp. That's easily to be done - if the need is recognised so far. __ Andreas Roehler ---End Message--- ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Fwd: Re: beginning-of-defun]
Andreas Roehler [EMAIL PROTECTED] writes: `defun' is a special form with a special meaning in emacs-lisp yes, but defun is also in common parlance a top-level form. these two meanings are congruent but not identical. you have to sort of alternatively squint and relax your ears to hear the similarity... Think it's disturbing to introduce a different meaning employing the same name. you get used to being disturbed w/ a little practice. Certainly a function `beginning-of-top-level-form' is useful. However, it should be callable separate from `beginning-of-defun' and vice versa. here is a (self-testable in the right context ;-) toy: (global-set-key \C-\M-a (defun beginning-of-defun-just-defun-really-i-mean-it! () (interactive) (let ((beginning-of-defun-function (lambda () (search-backward (defun (point-min) t (beginning-of-defun `beginning-of-defun' should work right out of the box at least in Emacs Lisp. That's easily to be done - if the need is recognised so far. it works for my understanding of defun. more importantly, my understanding of defun is shared by many people, most of whom are probably uninclined to add something like the above function to emacs. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bootstrapping fails
CVS Emacs, fresh update. make maintainer-clean; CC=gcc ./configure; nice make bootstrap; sudo make install;; Compiling /var/local/cc/news/emacs/lisp/emacs-lisp/byte-opt.el Wrote /var/local/cc/news/emacs/lisp/emacs-lisp/byte-opt.elc Compiling /var/local/cc/news/emacs/lisp/emacs-lisp/bytecomp.el bytecomp.el:4204:1:Error: Wrong type argument: integerp, nil make[2]: *** [compile] Fehler 1 make[2]: Leaving directory `/var/local/cc/news/emacs/lisp' make[1]: *** [bootstrap-build] Fehler 2 make[1]: Leaving directory `/var/local/cc/news/emacs' make: *** [bootstrap] Fehler 2 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: timer error
When I execute (timer-relative-time '(17583 46528 355684) 0.5 0) I do not get this error. I don't see how that function could construct the value 174058816388191.03. I suggest that you define a function just like timer-relative-time, but with a different name, then call it explicitly and step thru it with edebug. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: timer error
Debugger entered--Lisp error: (range-error floor 174058816388191.03) floor(174058816388191.03) timer-relative-time((17583 46528 355684) 0.5 0) timer-inc-time([t 17583 46528 355684 0.5 blink-cursor-timer-function nil nil] 0.5 0) timer-event-handler([t 17583 46528 355684 0.5 blink-cursor-timer-function nil nil]) If I evaluate (timer-relative-time '(17583 46528 355684) 0.5 0) on GNU/Linux I get (17583 46528 855684). timer-relative-time calls floor twice. The arguments should be 0.5 and 50.0. You could instrument timer-relative-time with Edebug and step through it to see where it fails. However I suspect there is an underlying problem with floor which is a primitive and will need to be debugged with GDB. In GNU Emacs 22.0.50.1 (i386-apple-darwin8.7.1) ^^ This may be the source of the discrepancy. -- 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: read-face-name doc string incorrect
Nick Roberts [EMAIL PROTECTED] writes: Since the files in admin/ are only marginally useful for the average contributor, and the _are_ described in admin/README (modulo a few missing items), I still don't see a need to also describe them in CONTRIBUTE. If thats the case, FOR-RELEASE should be moved up a directory. As a late addition, it's not described in README I have updated admin/README. I didn't add it to CONTRIBUTE though. -- 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: compile.el change
After this change: 2006-07-07 Stefan Monnier [EMAIL PROTECTED] * progmodes/compile.el (compilation-error-regexp-alist-alist) gnu: Use shy regexp. Fix incorrect backref to potentially unmatched group. the compilation start/end lines are recognized as compilation errors. | Compilation started at Sat Jul 8 15:14:23 | Compilation finished at Sat Jul 8 15:14:23 I'm not sure what to do about it: these may indeed be error messages relating to line 14 of files Compilation started at Sat Jul 8 15 and Compilation finished at Sat Jul 8 15. Or is there something in those lines that tells us that they can't be error messages? Of course one way to deal with it is to do what we did for grep.el (where a similar problem showed up) and match those lines explicitly (and mark them as something else). Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
