Re: [Fwd: Re: beginning-of-defun]
Richard Stallman schrieb: Thanks for starting to explore this issue. Because it only finds `defun' calls, it fails to find other constructs that define functions or macros. Also, it would get rather confused when dealing with top-level forms that don't define functions at all: it just skips them. Correct my answer in this point. Here a hopefully better one: What was sent indeed was a `beginning-of-defun' in his true understanding (as I conceive that) - nothing more. After that we could have a function dealing with a group of function-forms in Emacs Lisp while extending the reg-rexp appropriate, i.e. a `beginning-of-function'. __ Andreas Roehler ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: file-attributes returns wrong info on Windows
It would be interesting if someone could repeat my experiment by calling file-attributes on the same file from both emacs 21 and 22, and reporting if both versions return identical time values. With GNU Emacs 21.2.1 (i386-msvc-windows98.3000) of 2002-03-19 on buffy: (nil 1 123 123 (17594 46816) (17575 36352) (17582 8600) 10733569 -rwxrwxrwx nil 0 (6175 . 4865)) With GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2006-07-07 on MACHNO X server distributor `Microsoft Corp.', version 4.90.3000 configured using `configure --with-gcc (3.4)' (nil 1 123 123 (17594 46815) (17575 36351) (17582 8600) 10733569 -rwxrwxrwx nil 0 (6175 . 4865)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: file-attributes returns wrong info on Windows
With GNU Emacs 21.2.1 (i386-msvc-windows98.3000) of 2002-03-19 on buffy: (nil 1 123 123 (17594 46816) (17575 36352) (17582 8600) 10733569 -rwxrwxrwx nil 0 (6175 . 4865)) With GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2006-07-07 on MACHNO X server distributor `Microsoft Corp.', version 4.90.3000 configured using `configure --with-gcc (3.4)' (nil 1 123 123 (17594 46815) (17575 36351) (17582 8600) 10733569 -rwxrwxrwx nil 0 (6175 . 4865)) It's a mystery to me, as the relevant lines for reading file modification/creation/access times in our stat() implementation in w32.c have not changed since 1993. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: file-attributes returns wrong info on Windows
Jason Rumney wrote: With GNU Emacs 21.2.1 (i386-msvc-windows98.3000) of 2002-03-19 on buffy: (nil 1 123 123 (17594 46816) (17575 36352) (17582 8600) 10733569 -rwxrwxrwx nil 0 (6175 . 4865)) With GNU Emacs 22.0.50.1 (i386-mingw-windows98.3000) of 2006-07-07 on MACHNO X server distributor `Microsoft Corp.', version 4.90.3000 configured using `configure --with-gcc (3.4)' (nil 1 123 123 (17594 46815) (17575 36351) (17582 8600) 10733569 -rwxrwxrwx nil 0 (6175 . 4865)) It's a mystery to me, as the relevant lines for reading file modification/creation/access times in our stat() implementation in w32.c have not changed since 1993. Does not that include calls to convert_time? At the end of convert_time there is a line return (time_t) (ret * 1e-7); Could something has changed in the arithmetics on w32? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: file-attributes returns wrong info on Windows
Lennart Borgman wrote: Does not that include calls to convert_time? At the end of convert_time there is a line return (time_t) (ret * 1e-7); Could something has changed in the arithmetics on w32? Are you suggesting that something in the source code for Emacs is affecting how the compiler treats floating point multiplication? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: file-attributes returns wrong info on Windows
Jason Rumney wrote: Lennart Borgman wrote: Does not that include calls to convert_time? At the end of convert_time there is a line return (time_t) (ret * 1e-7); Could something has changed in the arithmetics on w32? Are you suggesting that something in the source code for Emacs is affecting how the compiler treats floating point multiplication? I do not know enough to suggest something like that. It looked to me as there could be rounding errors, but I might be totally misunderstanding this. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Compile-goto-error can signal wrong-type-argument
Hi Stefan, thanks for the response. I had to apply the patch by hand, since I've been away and the patch was against an older revision that the one I now have post-update. I have only used this feature with popup windows, and the patch doesn't make any difference to me with those. I'm using the MOTIF toolkit. I am still able to click on the OK button even when in a directory that does not contain the file. Looking into it, maybe it is because x-file-dialog does not support PREDICATE? Or am I misreading code? Simon. -Original Message- From: Stefan Monnier [mailto:[EMAIL PROTECTED] Sent: 11 July 2006 15:21 To: Marshall, Simon Cc: 'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)' Subject: Re: Compile-goto-error can signal wrong-type-argument Marshall, == Marshall, Simon [EMAIL PROTECTED] writes: This is a buggette in CVS head as of 2006-06-19. src/emacs -Q Start a compilation which is going to raise some errors. Then mouse-1 on an error to get the popup window Find this error in (default ...) for you to navigate to the file. (The error message doesn't contain enough info for Emacs to be able to work it out itself.) So far, so good. In the popup, navigate to the wrong directory and click on OK without going through the process of finding the file entry and selecting it first. (You can't - you're in the wrong directory!) Does the patch below give a cleaner behavior (it should prevent you from selecting a directory in which the file doesn't exist). ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Compile-goto-error can signal wrong-type-argument
Hi Stefan, thanks for the response. I had to apply the patch by hand, since I've been away and the patch was against an older revision that the one I now have post-update. I have only used this feature with popup windows, and the patch doesn't make any difference to me with those. I'm using the MOTIF toolkit. I am still able to click on the OK button even when in a directory that does not contain the file. Looking into it, maybe it is because x-file-dialog does not support PREDICATE? Or am I misreading code? OK, thanks for testing. Yes, I forgot about those pesky dialog boxes ;-) I'll install a real patch ASAP. Stefan ___ 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]
Because it only finds `defun' calls, it fails to find other constructs that define functions or macros. This would be the task of `beginning-of-form' - a more abstract utility. A command that only finds calls to `defun' is not very useful. Indeed. Will proceed here. Will it be possible to write a reg-exp which matches a functions definition reliable? Not entirely reliable, I am afraid. You need to use syntax-ppss starting from a known top-level expression to find out whether a given position is inside a string. IMO different meanings of `defun' in Emacs are the reason of a major difficulty for beginners (at least for non-programmers). Have you had experience with a lot of beginners that got confused about this? I am not yet convinced that we should change it. Our use of the term defun for editing commands has 30 years of history behind it, and I have not yet seen evidence that it is a problem. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: file-attributes returns wrong info on Windows
From: Chris Britton [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 00:47:24 -0500 Cc: emacs-pretest-bug@gnu.org How do you know which one of these is wrong? What does DIR say about that file's times? ls (both cygwin and mingw) and Windows XP properties dialog report that the last modification time on the example file is March 28, 2006 2:25:39 AM. This is in the U.S. Central timezone which is March 28, 2006 7:25:39 AM UTC, or 1143530739 Unix time. Please invoke ls -l --full-time, and tell what it tells. You can see the other two times with full fractional digits if you use the --time=WHAT option. (I'm curious whether the fractions of the second cause one of the two Emacs versions to round the time stamp, whereas the other chops.) I get the same result whether I build under MinGW or Cygwin. ??? Do you really mean Cygwin? That one uses an entirely different implementation of the file I/O functions (such as `stat') invoked by file-attributes. I'm always suspicious of my cygwin build because I have to use mingw-make instead of cygwin's make and the mixing of the two may not be giving me what I expect. The flavor of Make has nothing to do with the flavor of the resulting binary. What matters is the compiler and the libraries used to compile and link the binary. In any case, if you used nt/configure.bat to configure and nt/makefile to build, then both your builds are MinGW builds. It would be interesting if someone could repeat my experiment by calling file-attributes on the same file from both emacs 21 and 22, and reporting if both versions return identical time values. Such a comparison is meaningless, AFAIK: CVS clients don't in general preserve the time stamps; what you get is the time when the file was updated from CVS in that particular sandbox . So different people will see different, albeit close, times. For example, on my system, I have 2 copies of that file in 2 different directories, for which ls -l --full-time reports this: -rw-rw-rw- 1 Zaretzky 0 5171 2006-03-28 12:22:14.38700 +0200 d:/gnu/emacs/README -rw-rw-rw- 1 Zaretzky 0 5171 2006-04-12 16:15:51.0 +0300 d:/gnu/test/emacs/README On top of that, the time-zone calculations on Windows are not very reliable, depending on the port of `ls' that you have and how your Windows is set up wrt time zones. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: file-attributes returns wrong info on Windows
Date: Mon, 17 Jul 2006 10:56:38 +0100 From: Jason Rumney [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org, Chris Britton [EMAIL PROTECTED] It's a mystery to me, as the relevant lines for reading file modification/creation/access times in our stat() implementation in w32.c have not changed since 1993. Indeed. Perhaps someone could step with a debugger into both versions and see what is different. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: file-attributes returns wrong info on Windows
Date: Mon, 17 Jul 2006 12:29:57 +0200 From: Lennart Borgman [EMAIL PROTECTED] Cc: Chris Britton [EMAIL PROTECTED], emacs-pretest-bug@gnu.org Does not that include calls to convert_time? Emacs 21.3 also called convert_time. At the end of convert_time there is a line return (time_t) (ret * 1e-7); Emacs 21.3 has the same line. Could something has changed in the arithmetics on w32? Only if the two versions were compiled by different versions of the C compiler, and even then it's extremely unlikely. ___ 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]
From: Andreas Roehler [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 08:06:26 +0200 Correct my answer in this point. Here a hopefully better one: What was sent indeed was a `beginning-of-defun' in his true understanding (as I conceive that) - nothing more. After that we could have a function dealing with a group of function-forms in Emacs Lisp while extending the reg-rexp appropriate, i.e. a `beginning-of-function'. in vietnamese, there is one word for both blue and green, and one needs to specialize w/ other words when talking about the color of the sea or the color of the tree leaves. changing the discourse requires introducing specific terms, convincing people that their usage of the old terms is out of date, and providing a way for people to slowly change their speech. here it is a similar situation: other people's concept of the term defun is much larger than your concept of true defun. you have introduced specific terms and have made arguments that may or may not convince people (that is up to people to decide for themselves), but you have not yet provided a way for people to slowly change their usage. to get people to change you have to throw your idea ahead, and walk WITH them towards it, even if that is more work. in the context of these emacs lisp functions, this means that your proposal is unevaluatable (or at best, only partially evaluatable, with inconclusive results) until all the After that... stuff (i.e., code) is included. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Re: ACL / Listener - Hang (Carbon port)
Thank you all for your help. I've just downloaded Aquamacs latest version with SLIME, and my problem has been solved. Best regards Maria On 27/06/06, YAMAMOTO Mitsuharu [EMAIL PROTECTED] wrote: On Sun, 25 Jun 2006 17:46:39 +0100, David Reitter [EMAIL PROTECTED] said: Emacs hangs (no C-g possible) when create new listener from the Allegro Common Lisp package is selected - I can't verify / investigate further as I don't have Allegro Common Lisp. The package seems non-standard, but I don't see how an elisp package can legally bring Emacs to a halt (with C-g not working). It's not difficult to do so. ;; Can't quit with C-g. Send SIGFPE instead. (let ((inhibit-quit t)) (while t)) And the info entry for with-local-quit says there are several places where inhibit-quit is bound to t. This macro is mainly useful in functions that can be called from timers, process filters, process sentinels, `pre-command-hook', `post-command-hook', and other places where `inhibit-quit' is normally bound to `t'. I'm not sure this is the cause of the unresponsiveness, though. The version he is using is a patched GNU Emacs CVS derviate (CVS as of 2006-04-10), Carbon port, running on an Intel Mac with OS X. I don't believe any of the extensions to GNU Emacs present in his build can account for the hang this user is seeing. The next thing to do for debugging would be identifying situations/platforms where the problem occurs. * Identifying situations: - Try sending SIGFPE. Hopefully we get Lisp-level backtrace. - Try debugging with GDB using hints in etc/DEBUG. * Identifying platforms: - Try X11 version. - Try Carbon version without any modifications. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
tumme does not show image buffer [was: tumme image size]
Mathias Dahl [EMAIL PROTECTED] writes: Dieter Wilhelm [EMAIL PROTECTED] writes: This is just a minor flaw, tumme doesn't fit an image into the *tumme-display-image* buffer when changing the size of the *tumme* Anyway, try this out: (defun tumme-display-thumbnail-original-image (optional arg) Display current thumbnail's original image in display buffer. ... Does this change work for you? Yes, thank you very much for your attention, but this time I stumbled over something more annoying (with the latest CVS source): emacs -D -Q --fullscreen M-x tumme dir and tumme doesn't show the *tumme* buffer only a dired buffer inhabits the screen! Maybe I didn't realise it before because most of the time my frames are split and then the *tumme* buffer gets visible. I think this is a bug because the tumme documentation string says Make a preview buffer for all images in dir and display it and what tumme does is displaying a dired buffer and not the image buffer. -- Best wishes Dieter Wilhelm Darmstadt, Germany ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad syntax highlighting in shell-script mode
I saved the following into a file called script.sh and then visited the file. The echo a backquote comment was coloured as if it was a string, as was the rest of the file after the comment: #!/bin/sh echo \` # echo a backquote echo hello echo hello echo hello echo hello I changed the file, removing the last 2 double quotes, and re-visited the file. The comment was then coloured correctly, as was the rest of the file: #!/bin/sh echo \` # echo a backquote echo hello echo hello echo hello echo hello It seems that the presence of double quotes in the file after the \` breaks highlighting. No, it's the backslash before the ` which confused Emacs. I've installed the patch below which I believe fixes it. But this code that tries to handle backquotes and $(..) inside strings is not very reliable. Other than the problem mentioned in the patch, there's also the fact that echo $(echo ) there)) doesn't recognize that the `there' is still within the $(...). It's a difficult problem. Stefan Index: lisp/progmodes/sh-script.el === RCS file: /sources/emacs/emacs/lisp/progmodes/sh-script.el,v retrieving revision 1.181 diff -u -r1.181 sh-script.el --- lisp/progmodes/sh-script.el 3 Jun 2006 08:37:49 - 1.181 +++ lisp/progmodes/sh-script.el 17 Jul 2006 21:06:14 - @@ -982,7 +982,10 @@ (defun sh-quoted-subshell (limit) Search for a subshell embedded in a string. Find all the unescaped \ characters within said subshell, remembering that subshells can nest. - (if (re-search-forward \\\(?:.\\|\n\\)*?\\(\\$(\\|`\\) limit t) + ;; FIXME: This can (and often does) match multiple lines, yet it makes no + ;; effort to handle multiline cases correctly, so it ends up being + ;; rather flakey. + (if (re-search-forward \\\(?:\\(?:.\\|\n\\)*?[^\\]\\(\\)*\\)?\\(\\$(\\|`\\) limit t) ;; bingo we have a $( or a ` inside a (let ((char (char-after (point))) (continue t) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Fn-. does not produce , on German keyboard
Hello! The Fn key is also used to switch part of the keyboard into a numerical keypad mode. The keys `m,.-´ then become `0,,+´, but Carbon Emacs 23.0.0 produces `0,.+´. Carbon Emacs 22.0.50 behaves correctly. In GNU Emacs 23.0.0.1 (powerpc-apple-darwin8.6.0) of 2006-05-03 on localhost X server distributor `Apple Computers', version 10.4.7 configured using `configure '--without-x' '--without-toolkit-scroll- bars' '--prefix=/usr/local' 'CPPFLAGS=-I/sw/lib/pango-ft219/include - I/sw/include/pango-1.0 -I/sw/lib/freetype219/include -I/sw/include' 'LDFLAGS=-dead_strip -L/usr/local/lib -L/sw/lib/ncurses -L/sw/lib/ freetype219/lib -L/sw/lib/pango-ft219/lib -L/sw/lib'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: de_DE.UTF-8 value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: de_DE.UTF-8 locale-coding-system: utf-8-unix default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: encoded-kbd-mode: t shell-dirtrack-mode: t display-time-mode: t show-paren-mode: t desktop-save-mode: t tooltip-mode: t auto-compression-mode: t tool-bar-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 global-auto-composition-mode: t auto-composition-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t -- Greetings Pete Real Time, adj.: Here and now, as opposed to fake time, which only occurs there and then. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: bad syntax highlighting in shell-script mode
On Mon, 2006-07-17 at 17:12 -0400, Stefan Monnier wrote: It seems that the presence of double quotes in the file after the \` breaks highlighting. No, it's the backslash before the ` which confused Emacs. Right, but my point is that it's a combination of the two which causes the problem. If there's no double quote on any following line then the script is highlighted correctly. Since $(...$(...)...) can be nested, does it mean that there's no way of highlighting it correctly using regular expressions? Chris. ___ 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]
What was sent indeed was a `beginning-of-defun' in his true understanding (as I conceive that) - nothing more. In Emacs we have used the term defun to mean top level expression for 30 years. There is no reason to change that. So the question I am considering what kind of behavior a user editing Emacs Lisp code might find more useful than the current C-M-a behavior. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Fn-. does not produce , on German keyboard
On Tue, 18 Jul 2006 00:57:41 +0200, Peter Dyballa [EMAIL PROTECTED] said: The Fn key is also used to switch part of the keyboard into a numerical keypad mode. The keys `m,.-´ then become `0,,+´, but Carbon Emacs 23.0.0 produces `0,.+´. Carbon Emacs 22.0.50 behaves correctly. They both insert `,' on my side. But I noticed that there is another problem: keypad keys does not generate kp-* events. I've just installed a fix to the trunk so that Fn-. or the keypad key next to `0' generates kp-decimal with US keyboards, and kp-separator with German or French keyboards. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
C-M-a
Emacs -q Whereas C-M-e works fine and sends info via C-h k, C-M-a seems dead, just sends nothing, no reaction at all, no keyboard event, even not with C-h k followed by C-M-a. Have to cancel such a request and then get the explanation to C-g... BTW this is an old problem, I'm used to employ C-super-a to call `beginning-of-defun'. Not reported that because I did something with `beginning-of-defun' and thougt it my own result. Seems not so. The surprise is, that all other key and combinations work fine. In GNU Emacs 22.0.50.2 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of 2006-06-18 on kiste X server distributor `The X.Org Foundation', version 11.0.60802000 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_DE.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t tool-bar-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: C-h k C-g C-x 1 C-h k C-M-e M-x r e p o r t - e m a c s - b u g return Recent messages: Loading /usr/local/share/emacs/22.0.50/leim/leim-list.el (source)...done (emacs -Q --debug-init) For information about the GNU Project and its goals, type C-h C-p. Loading help-mode...done Loading help-fns...done Type C-x 1 to remove help window. [2 times] Loading emacsbug... Source file `/usr/local/share/emacs/22.0.50/lisp/mail/sendmail.el' newer than byte-compiled file Loading regexp-opt...done Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
