Re: Manual: indexes are missing links
From: Juri Linkov [EMAIL PROTECTED] Date: Sun, 07 Jan 2007 02:09:52 +0200 Simply turning this on has an undesirable consequence that node names are now hidden in the index node, but it is very useful to see them! You see them when the mouse pointer hovers above the link. No, thanks, it is very inconvenient to hover the mouse pointer on every index entry to see their corresponding node name. Why do you think it's more important to see the node names in the index than it is in any other menu? Menu item names in any other menu are often just a modified version of the node name, so it makes sense to hide node names as e.g. in: * Format: Outline Format. What the text of an outline looks like. * Motion: Outline Motion. Special commands for moving through outlines. * Visibility: Outline Visibility. Commands to control what is visible. * Views: Outline Views.Outlines and multiple views. Unlike this, index entry names contain no information about node names to which they belong, and it is helpful to see them, e.g.: * face-background: Attribute Functions. * face-bold-p: Attribute Functions. * face-differs-from-default-p: Face Functions. * face-documentation 1:Face Functions. * face-documentation:Accessing Documentation. It is especially important to see node names with the same index names like in the two last lines above. There is enough horizontal space in the index menus to leave node names displayed where they were displayed for many years so far without complaints from users. -- Juri Linkov http://www.jurta.org/emacs/ ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp slow for evaluated lisp expressions
Quoting Chris Moore [EMAIL PROTECTED]: Aaron S. Hawley [EMAIL PROTECTED] writes: Then, do the most basic of replacements that would never be done in practice, but shows how slow interactive regexp replacements can be: Or just replace it with \,\ for an even simpler test case. Damn right. Does this patch fix the bug? Yes, it does. I felt confident your patch would as soon as I looked at it. When reporting the bug I had narrowed the problem to that section of replace.el and to the `noedit' variable, but had no clue what the resolution of the bug was going to be take. Thanks for taking a look into this, Chris. /a --- old/replace.el 2007-01-07 01:40:26.0 +0100 +++ replace.el 2007-01-07 01:40:42.0 +0100 @@ -1518,8 +1518,7 @@ (set-match-data real-match-data) (setq next-replacement (funcall (car replacements) (cdr replacements) -replace-count) - noedit nil)) +replace-count))) (if (not query-flag) (let ((inhibit-read-only query-replace-skip-read-only)) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: say where attempt to write backup file was
Actually there are a few other things we could do: 1 - try to keep messages short (which was my original point and is always the best solution when it's available). 2 - use scrolling if the message is larger than the minibuffer (IIRC there was some package back in Emacs-20 days that did just that). This issue arose from my change to put the entire backup file name in a message. That message will be visible for most users, so I will keep the change. In my original complaint I said I do not want to oppose this change, so indeed, please keep this change. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
[:upper:] inconsistency
Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I would expect the regexp [[:upper:]] to behave the same as [A-Z] (in English text). However, by default [[:upper:]] matches all letters, whereas [A-Z] matches only upper case letters, as I expect. I have to set case-fold-search to nil to make [[:upper:]] match only upper case letters. This difference in behaviour seems inconsistent and wrong to me. I think a search using [[:upper:]] should ignore case-fold-search as [A-Z] does. The search command I was using for these tests was isearch-forward-regexp, but a quick check suggests that the problem applies also to search-forward-regexp. I started Emacs with the -Q flag. In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2007-01-07 on MONOLITH X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' 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: ENG locale-coding-system: cp1252 default-enable-multibyte-characters: t Major mode: Text Minor modes in effect: encoded-kbd-mode: t 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: help-echo help-echo help-echo help-echo drag-n-drop C-down-mouse-1 C-M-s C-g C-h v c a s e SPC SPC f tab return C-M-s [ A - Z ] C-g C-g C-M-s [ [ : u p p e r ; ] backspace backspace : ] ] return help-echo help-echo down-mouse-1 mouse-2 help-echo down-mouse-1 mouse-1 help-echo help-echo help-echo help-echo down-mouse-1 C-x b return C-home C-M-s up C-M-s [ [ : u p p e r : ] ] C-g C-M-s [ A - Z ] C-g C-x 1 help-echo help-echo help-echo help-echo help-echo help-echo help-echo help-echo menu-bar help-menu report-emacs-bug Recent messages: Creating customization items... Creating customization items ...done Resetting customization items...done Creating customization setup...done To install your edits, invoke [State] and choose the Set operation Mark set Quit [2 times] Loading emacsbug... 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
emacsclient - bogus error message on Windows XP
When emacsclient needs to start Emacs as an alternate editor it now outputs an error message that says there is, in fact, no error. It then starts Emacs correctly. If run again, while Emacs is still running, there is no problem. The error message is illustrated below. It is not a huge problem when using emacsclient, but with emacsclientw it appears as a popup dialogue box that must be acknowledged to continue. This did not happen with emacsclient 22.0.91 (with the patch to handle quoting of filenames in MS Windows). emacsclient -V emacsclient 22.0.92 emacsclient -a runemacs Tablet Buttons.txt emacsclient: connect: No error emacsclient -a runemacs Tablet Buttons.txt Waiting for Emacs... In GNU Emacs 22.0.92.1 (i386-mingw-nt5.1.2600) of 2007-01-07 on MONOLITH X server distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (3.4)' ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: emacsclient -a runemacs Tablet Buttons.txt emacsclient: connect: No error I don't see that. runemacs.exe is run normally. Are you using a CVS Emacs, or Lennart's prebuilt binary? (I ask because Lennart's contains quite a few changes in emacsclient.exe.) /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
Francis Wright wrote: When emacsclient needs to start Emacs as an alternate editor it now outputs an error message that says there is, in fact, no error. It then starts Emacs correctly. If run again, while Emacs is still running, there is no problem. The error message is illustrated below. It is not a huge problem when using emacsclient, but with emacsclientw it appears as a popup dialogue box that must be acknowledged to continue. This did not happen with emacsclient 22.0.91 (with the patch to handle quoting of filenames in MS Windows). emacsclient -V emacsclient 22.0.92 Have you downloaded from my site (EmacsW32)? Are you using the patched or the unpatched version? (I should add something to emacsclient -V telling whether is it patched or unpatched, but I have forgot that.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
Lennart Borgman (gmail) wrote: Francis Wright wrote: When emacsclient needs to start Emacs as an alternate editor it now outputs an error message that says there is, in fact, no error. It then starts Emacs correctly. If run again, while Emacs is still running, there is no problem. The error message is illustrated below. It is not a huge problem when using emacsclient, but with emacsclientw it appears as a popup dialogue box that must be acknowledged to continue. This did not happen with emacsclient 22.0.91 (with the patch to handle quoting of filenames in MS Windows). emacsclient -V emacsclient 22.0.92 Have you downloaded from my site (EmacsW32)? Are you using the patched or the unpatched version? (I should add something to emacsclient -V telling whether is it patched or unpatched, but I have forgot that.) Sorry, I had already done that some weeks ago. This should be the unpatched (if it is not too old). The patched version adds (patched) to the end of the -V output. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
replace.el documentation typo
--- old/replace.el 2007-01-07 19:23:43.0 +0100 +++ replace.el 2007-01-07 19:24:06.0 +0100 @@ -474,7 +474,7 @@ In interactive calls, the replacement text may contain `\\,' followed by a Lisp expression used as part of the replacement text. Inside of that expression, `\\' is a string denoting the -whole match, `\\N' a partial matches, `\\#' and `\\#N' the +whole match, `\\N' a partial match, `\\#' and `\\#N' the respective numeric values from `string-to-number', and `\\#' itself for `replace-count', the number of replacements occured so far. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: This did not happen with emacsclient 22.0.91 (with the patch to handle quoting of filenames in MS Windows). The only recent patch to emacsclient affecting the running of the alternate editor is the one you mention (quoting arguments with embedded spaces in Windows). The few patches after that are related to passing focus to Emacs after connecting with it, which never happens if the alternate editor is called. If you're using the stock Emacs from CVS, could you please try to determine exactly what change to emacsclient started the behavior you're seeing? /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
From: Juanma Barranquero [EMAIL PROTECTED] To: Francis Wright [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Sent: Sunday, January 07, 2007 5:54 PM Subject: Re: emacsclient - bogus error message on Windows XP On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: emacsclient -a runemacs Tablet Buttons.txt emacsclient: connect: No error I don't see that. runemacs.exe is run normally. Are you using a CVS Emacs, or Lennart's prebuilt binary? (I ask because Lennart's contains quite a few changes in emacsclient.exe.) I'm running the standard emacs 22.0.92.1 pretest release from alpha.gnu.org which I built myself today. That appears to be the latest pretest release, although it was dated about 20th December, as I recall. So maybe this problem is fixed in the latest version. I'll see if the CVS version works better. Thanks, Francis ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
Juanma Barranquero wrote: On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: emacsclient -a runemacs Tablet Buttons.txt emacsclient: connect: No error I don't see that. runemacs.exe is run normally. Are you using a CVS Emacs, or Lennart's prebuilt binary? (I ask because Lennart's contains quite a few changes in emacsclient.exe.) /L/e/k/t/u A bit of confusion here I believe. You can download both unpatched prebuilt binaries and patched binaries from my site. I think Juanma wanted to ask whether you used an unpatched or a patched version. As Juanma says there emacsclient that comes with the patched version has quite a few changes (to allow automatic startup of Emacs). Do you start emacs server in your .emacs? If you use the unpatched version you must to that in addition to the command you use above. (The command you use starts Emacs, but you have to start emacs server too.) With the patched version you can just do emacsclient Tablet Buttons.txt Then emacs + emacs server will start automatically. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: query-replace-regexp slow for evaluated lisp expressions
Aaron S. Hawley [EMAIL PROTECTED] writes: Quoting Chris Moore [EMAIL PROTECTED]: Or just replace it with \,\ for an even simpler test case. Damn right. Or: \, makes it one character shorter, and gives lie to replace-match-string-symbols's docstring. It turns out that doesn't need to be preceeded by a backslash in order to type it using Lisp syntax. Does this patch fix the bug? Yes, it does. I felt confident your patch would as soon as I looked at it. I'm not confident about it. It seems to be working well for me still, but there's quite a lot of functionality available at the query-replace prompt which I neither understand nor use. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: replace.el documentation typo
On 1/7/07, Chris Moore [EMAIL PROTECTED] wrote: -whole match, `\\N' a partial matches, `\\#' and `\\#N' the +whole match, `\\N' a partial match, `\\#' and `\\#N' the Committed, thanks. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: I think Juanma wanted to ask whether you used an unpatched or a patched version. Yes, sorry. (But as you said yourself, most people that downloads from your site gets the patched version, so I think the mistake is understandable :) /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: That appears to be the latest pretest release, although it was dated about 20th December, as I recall. So maybe this problem is fixed in the latest version. I'll see if the CVS version works better. Thanks. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
From: Juanma Barranquero [EMAIL PROTECTED] To: Francis Wright [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Sent: Sunday, January 07, 2007 6:37 PM Subject: Re: emacsclient - bogus error message on Windows XP On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: This did not happen with emacsclient 22.0.91 (with the patch to handle quoting of filenames in MS Windows). The only recent patch to emacsclient affecting the running of the alternate editor is the one you mention (quoting arguments with embedded spaces in Windows). The few patches after that are related to passing focus to Emacs after connecting with it, which never happens if the alternate editor is called. If you're using the stock Emacs from CVS, could you please try to determine exactly what change to emacsclient started the behavior you're seeing? Just for the record, the patch I was referring to was the one you sent me before Christmas in response to my previous emacsclient bug report. However, I have just tested my previous version of emacsclient again and it also gives the bogus error message. So this must be caused by something else that just happened to coincide with me installing emacs 22.0.92.1. Sorry about that! I'll have to investigate further. Francis ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacsclient - bogus error message on Windows XP
On 1/7/07, Francis Wright [EMAIL PROTECTED] wrote: Just for the record, the patch I was referring to was the one you sent me before Christmas in response to my previous emacsclient bug report. Aha. Sorry about that! I'll have to investigate further. OK, thanks for taking the time to determine what's wrong. /L/e/k/t/u ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [:upper:] inconsistency
I would expect the regexp [[:upper:]] to behave the same as [A-Z] (in English text). However, by default [[:upper:]] matches all letters, whereas [A-Z] matches only upper case letters, as I expect. Hmm... I can't see to get A-Z to only match upper-case letters ... Oh I see what you mean now. Does the patch below fix it for you? (I guess we could also allows the use of [:UPPER:] so you could workaround this problem ;-) Stefan --- orig/lisp/isearch.el +++ mod/lisp/isearch.el @@ -2297,7 +2297,15 @@ (setq found t)) (setq quote-flag nil))) (setq i (1+ i))) -(not found))) +(or (not found) +;; Even if there's no uppercase char, we want to detect the use of +;; [:upper:] char-class. +(and regexp-flag (string-match \\[:upper:] string) + (condition-case err + (progn (string-match (substring string 0 (match-string 0)) ) +nil) + (invalid-regexp +(equal Unmatched [ or [^ (cadr err ;; Portability functions to support various Emacs versions. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
emacs server fails to start with large uid on unix
I have a large unix uid: $ id uid=800154870(ruttbe) gid=705(www) it seems the emacs server of pretest 92 can't cope with this, possibly b/c of the limit on emacs lisp's integer size. perhaps calc should be used, as it can handle bignums? also `file-attributes' may have a problem with this large UID. see the backtrace upon M-x server-start after an emacs -q: Debugger entered--Lisp error: (range-error truncate 800154870.0) format(/tmp/emacs%d 800154870.0) byte-code(=8c1=8c2!=88=... [current-load-list make-variable-buffer-local server-existing-buffer server-name default-boundp set-default server server- socket-dir format /tmp/emacs%d user-uid] 5) execute-extended-command(nil) call-interactively(execute-extended-command) Thanks, --BR In GNU Emacs 22.0.92.2 (sparc-sun-solaris2.8, X toolkit) of 2007-01-03 on .com X server distributor `The Cygwin/X Project', version 11.0.60899901 configured using `configure '--prefix=/home/ruttbe/.upak- jade/installed/emacs22-pretest'' Important settings: value of $LC_ALL: C 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: nil default-enable-multibyte-characters: t Major mode: Debugger 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: M-x s e r v e tab s t tab return M-! i d return M-x r e p o r t - e m tab return Recent messages: For information about the GNU Project and its goals, type C-h C-p. Debug on Error enabled globally For information about the GNU Project and its goals, type C-h C-p. Loading server... Loading debug...done Entering debugger... uid=800154870(ruttbe) gid=705(www) Loading emacsbug... 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
Re: Manual: indexes are missing links
Menu item names in any other menu are often just a modified version of the node name, so it makes sense to hide node names as e.g. in: [...] Unlike this, index entry names contain no information about node names to which they belong, and it is helpful to see them, e.g.: Agreed, Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs server fails to start with large uid on unix
Does this fix it? *** server.el 27 Nov 2006 21:05:42 -0500 1.124 --- server.el 07 Jan 2007 23:00:49 -0500 *** *** 198,204 (defvar server-name server) (defvar server-socket-dir ! (format /tmp/emacs%d (user-uid))) (defun server-log (string optional client) If a *server* buffer exists, write STRING to it for logging purposes. --- 198,207 (defvar server-name server) (defvar server-socket-dir ! (let ((uid (user-uid))) ! (if (floatp uid) ! (format /tmp/emacs%1.0f uid) ! (format /tmp/emacs%d uid (defun server-log (string optional client) If a *server* buffer exists, write STRING to it for logging purposes. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Calc broken in Emacs unicode-2 branch
Can someone give me a hint what has screwed up calc? Another error: 1. Start calc with C-x * * 2. 'x RET 3. a i x RET ,[ error ] | Preparing rule set IntegAfterRules... | if: Syntax error: [ | opt(a) ln(x) + opt(b) ln(y) := 2 a esimplify(arctanh(x-1)) | :: a + b = 0 :: nrat(x + y) = 2 || nrat(x - y) = 2, | a * (b + c) := a b + a c :: constant(a) | ] ` -- 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
Re: [gmane.emacs.help] Re: raise frame no go
Eli Zaretskii skrev: Date: Thu, 04 Jan 2007 12:42:19 +0100 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Metacity (the default Gnome window manager) is a complete mess when it comes to raise frame. Some versions works, some don't. Some require the code below, some don't. In some configurations (i.e. focus on click vs. focus on mouse) raise frame works, in some raise frame don't work. We must give up on creating workarounds for Metacity, and just tell people that metacity is buggy. Ufortunately they have to figure out a workaround for themselves and their specific verion/configuration of metacity. How about writing an entry for etc/PROBLEMS about this? Ok, I'll do that. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
