Re: (message (format File %s file))
I do not want to make `message' with one arg inconsistent with the case of multiple args. I would rather put in a compiler warning to detect (message (format ...)). ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Problem with chinese gbk fonts on w32
I think I've found the problem, here is the patch of w32fns.c (against revision 1.256). I don't know the detail, but this patch works. --8-- --- w32fns.c 2005-08-08 09:45:47.0 +0800 +++ w32fns-fix.c 2005-09-06 15:32:01.275812264 +0800 @@ -4545,7 +4545,7 @@ /* Fill out details in lf according to the font that was actually loaded. */ lf.lfHeight = font-tm.tmInternalLeading - font-tm.tmHeight; - lf.lfWidth = font-tm.tmMaxCharWidth; + lf.lfWidth = font-tm.tmAveCharWidth; lf.lfWeight = font-tm.tmWeight; lf.lfItalic = font-tm.tmItalic; lf.lfCharSet = font-tm.tmCharSet; --8-- 2005/8/1, Sun Yijiang [EMAIL PROTECTED]: Sorry, I've reviewed my .emacs and found where the problem is. The problem is NOT mule-gbk, it's create-fontset-from-fontset-spec. Following setting results in double-width Chinese characters: (create-fontset-from-fontset-spec -*-bitstream vera sans mono-normal-r-*-*-14-*-*-*-c-*-fontset-gbk, chinese-gb2312:-*-simsun-normal-r-normal-*-16-*-*-p-*-gb2312*-*, chinese-cns11643-5:-*-simsun-normal-r-normal-*-16-*-*-p-*-gbk*-*, chinese-cns11643-6:-*-simsun-normal-r-normal-*-16-*-*-p-*-gbk*-*, chinese-cns11643-7:-*-simsun-normal-r-normal-*-16-*-*-p-*-gbk*-* t) I think the problem is that I set different fonts for each char set. If I comment out this setting and still use mule-gbk, Chinese characters looks OK. If I use this setting, the Chinese characters looks double-width, either with or without mule-gbk. This setting works for previous CVS Emacs builds and seems to become bad recently. I remember this problem first appeared with a check in of w32bdf.c early this year. The problem can be resolved by rolling back w32bdf.c to revision 1.20 at that time. But now even this rolling back does not work, maybe other changes affects this problem. 2005/8/1, Jason Rumney [EMAIL PROTECTED]: Sun Yijiang [EMAIL PROTECTED] writes: I think this change is probably not fully tested. When I use the mule-gbk package and set font for chinese characters, they look so wide, but when I use emacs -q they look nice, make no difference with previous CVS Emacs. I roll back the src/w32bdf.c to older version, and everything is OK. I think the change of w32bdf.c should be reviewed, since this is really a bug.You seem to be saying that you only see the bug when you loadmule-gbk, which is not part of Emacs. What does mule-gbk do? Does itperhaps try to work around the previous bug by doubling the width of Chinese characters? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: recentf.el - digit shortcuts
On 2005-09-05 04:27 PDT, David Ponce writes: David Hi, Here is another patch (sorry) that isolates files David with shortcuts in front of the dialog list, instead of David mixing them up into sub-menus. This way it is very David easy to locate files with shortcuts when David `recentf-show-file-shortcuts-flag' is non-nil. The files with shortcuts are now unaligned with files without shortcuts. Is that intentional? Otherwise it seems fine. -- Karl 2005-09-06 01:17 ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Calendar, diary, and diary-mode
On 2005-09-05 12:03 PDT, Stefan Monnier writes: Stefan How is diary-mode used? It's defined and seems to Stefan work if I call it manually, but it's not directly used Stefan anywhere. WAIM? There are at least two functions that do basically (find-file-noselect (diary-check-diary-file) t). It might be a good idea to refactor this, creating a function that returns the buffer for the diary file, setting major-mode, etc. when opening. -- Karl 2005-09-06 01:07 ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Problem with chinese gbk fonts on w32
Sun Yijiang wrote: I think I've found the problem, here is the patch of w32fns.c (against revision 1.256). I don't know the detail, but this patch works. --8-- --- w32fns.c2005-08-08 09:45:47.0 +0800 +++ w32fns-fix.c2005-09-06 15:32:01.275812264 +0800 @@ -4545,7 +4545,7 @@ /* Fill out details in lf according to the font that was actually loaded. */ lf.lfHeight = font-tm.tmInternalLeading - font-tm.tmHeight; -lf.lfWidth = font-tm.tmMaxCharWidth; +lf.lfWidth = font-tm.tmAveCharWidth; lf.lfWeight = font-tm.tmWeight; lf.lfItalic = font-tm.tmItalic; lf.lfCharSet = font-tm.tmCharSet; --8-- How can this work? The problem you reported was for BDF fonts used to display the GBK character sets. The fix above affects only Windows system fonts. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
narrow-to-page: when page-delimiter spans lines, exclude if from narrowed bit.
Hi, Emacs! Normally in narrow-to-page, when page-delimiter is something nice and simple like ^^L, the delimiter at the end of the page is excluded from the region narrowed to. A change made in version 1.8 was intended to handle multi-line delimiters, but this change wasn't completed. Currently, when the page delimiter spans line breaks, only the last line of the delimiter gets excluded. The following patch fixes this. 2005-09-06 Alan Mackenzie [EMAIL PROTECTED] * page.el (narrow-to-page): Exclude _entire_ multi-line delimiter from the region narrowed to. *** page.el Mon Sep 5 12:44:15 2005 --- page-1.19.acm.elTue Sep 6 08:10:14 2005 *** *** 112,118 (save-excursion (goto-char (match-beginning 0)) ; was (beginning-of-line) (looking-at page-delimiter))) ! (beginning-of-line)) (narrow-to-region (point) (progn ;; Find the top of the page. --- 112,118 (save-excursion (goto-char (match-beginning 0)) ; was (beginning-of-line) (looking-at page-delimiter))) ! (goto-char (match-beginning 0))) ; was (beginning-of-line) (narrow-to-region (point) (progn ;; Find the top of the page. -- Alan Mackenzie (Munich, Germany) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
Can't you attach a doc-string to an anonymous function, like so? `lambda (e) ,(concat Sort buffer by column) ... (apologies if I am babbling) regards -- tomás signature.asc Description: Digital signature ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
I don't think it is worth spending the time to have a long discussion about whether to use a macro to define these commands, whether they should be lambdas or have names, etc. Does the current version of the patch actually work, or is there a bug in it? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Really Works Good Pharamcy
MeAmLeCeViUlCiVaXaPr ribivileagtrallinaop diaentrabrexraamisumxecia $3$1$3 .33.21.75 http://www.aftepuchasu.com ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Calendar, diary, and diary-mode
Stefan How is diary-mode used? It's defined and seems to Stefan work if I call it manually, but it's not directly used Stefan anywhere. WAIM? There are at least two functions that do basically (find-file-noselect (diary-check-diary-file) t). It might be a good idea to refactor this, creating a function that returns the buffer for the diary file, setting major-mode, etc. when opening. Yes, that's pretty much what I do, locally, but it's obvious enough that I'd like to hear how the current code is actually used. diary-lib.el has many other oddities. E.g. it passes diary-file through substitute-in-file-name sometimes, but not always. Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
NEXT could conceivably be used to access another default. It's a good idea to reserve [next] for a complementary use with [prior] - that's a natural pair, and such pairs are relatively scarce. What's more, their names are perfect for forward-backward operations that do what they say. FWIW, I use [insert], instead of [prior], in the minibuffer for `switch-to-completions'. And I use [insert] in *Completions* to switch back to the minibuffer. Semi-lame mnemonic: insert cursor But I think it would be more convenient to [use M-n to] add [additional default values] to the list for [M-p] to access. It should be the user's acceptance (via RET) of an input candidate that puts an input onto the history list (for use by M-p) - it shouldn't be the mere act of Emacs making an input candidate available or the user's looking at a candidate via M-n. (I think that's already the case - just wanted to emphasize it.) ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
key-binding values
Consider these two definitions: (defcustom my-key [?\C-\ ] My key sequence.) (defcustom my-key \C- My key sequence.) `C-h v' then gives these values: [67108896] and ^@. Is this as good as can be expected - is there no way to get something more readable for [?\C-\ ]? Emacs users learn quickly to read ^@ as control @, and they also learn that this is equivalent to control SPC, but [67108896] is hard to read and digest. Also, correct me if I'm wrong, but my understanding is that the form [?\C- ] is generally preferred over the form \C- , for a key binding. If so, that makes matters worse in cases like this. This form is good: (defcustom my-key [(control ?\ )] My key sequence.) `C-h v' then gives [(control 32)], which is even clearer than ^@. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: key-binding values
Drew Adams [EMAIL PROTECTED] writes: Consider these two definitions: (defcustom my-key [?\C-\ ] My key sequence.) (defcustom my-key \C- My key sequence.) `C-h v' then gives these values: [67108896] and ^@. Is this as good as can be expected - is there no way to get something more readable for [?\C-\ ]? (key-description [67108896]) = C-SPC (key-description \C- ) = C-@ Emacs users learn quickly to read ^@ as control @, and they also learn that this is equivalent to control SPC, but [67108896] is hard to read and digest. Keys are just integers in Emacs. There is nothing that makes any integer special wrt to keys. Also, correct me if I'm wrong, but my understanding is that the form [?\C- ] is generally preferred over the form \C- , for a key binding. These two key sequences represent quite different bindings. You can't get one override the other, it depends on the terminal which key you receive on typing C-space. If so, that makes matters worse in cases like this. This form is good: (defcustom my-key [(control ?\ )] My key sequence.) (key-description [(control ?\ )]) = C-SPC Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Options menu is broken on CVS
Hi all, Options menu no longer works with emacs from CVS. To reproduce open emacs press F10-O and you get : Symbol's value as variable is void: menu-updating-frame Looks like recent changes to lisp/menu-bar.el borked this though I am not 100% certain with that. So wondering if anyone can reproduce this? Regards, ismail ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Paragraphs (and sentences) in Emacs cannot span pages.
This sentence goes over from one page ^L to the next. In my experience, ^L is generally used in Emacs for logical pages, not for physical pages, so a ^L in the middle of a paragraph doesn't make much sense. I guess if you see such a ^L it's inside something like an RFC, where the two pages are separated not just by ^L but also by footerheader so it'd be hard for Emacs to figure out what's a paragraph. Could you give more info about the precise case(s) where you bumped into ^L in the middle of paragraphs? Stefan ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: key-binding values
Is this as good as can be expected - is there no way to get something more readable for [?\C-\ ]? (key-description [67108896]) = C-SPC (key-description \C- ) = C-@ Yes, that's what key-description is for. My question was, is this as good as can be expected from C-h v in this case? I suppose the answer is yes, because there is no way for describe-variable to know that this represents a key sequence and not an arbitrary string or vector. Emacs users learn quickly to read ^@ as control @, and they also learn that this is equivalent to control SPC, but [67108896] is hard to read and digest. Keys are just integers in Emacs. There is nothing that makes any integer special wrt to keys. Characters, not key sequences, are integers. Some key sequences are characters (integers), but others are more complex events. And none of the ouput expressions ^@, [67108896], and [(control 32)], or the input expressions \C- , [?\C-\ ], and [(control ?\ )], is an integer. But this point is valid: There is nothing that makes a vector, string etc. special wrt a key. There is no way for C-h v to know that a given value is intended to represent a key sequence. Also, correct me if I'm wrong, but my understanding is that the form [?\C- ] is generally preferred over the form \C- , for a key binding. These two key sequences represent quite different bindings. You can't get one override the other, it depends on the terminal which key you receive on typing C-space. Whenever either is acceptable, is one of the two preferred in Emacs-Lisp code, for binding keys? My understanding was that the vector form was preferred. If so, that makes matters worse in cases like this. This form is good: (defcustom my-key [(control ?\ )] My key sequence.) Given all of the above, I would think that [(control ?\ )] should be the preferred syntax in code, whenever alternatives are equivalent. Both the source code and the C-h v output are clearer. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Calendar, diary, and diary-mode
There are at least two functions that do basically (find-file-noselect (diary-check-diary-file) t). It might be a good idea to refactor this, creating a function that returns the buffer for the diary file, setting major-mode, etc. when opening. That might not be a bad change. But if there's nothing broken here, I'd rather we leave well enough alone, and focus our attention on other areas where changes would produce real benefit. Have you looked at etc/TODO? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Patch: Follow convention for reading with the minibuffer.
Recently RMS documented in (elisp)Programming Tips a convention for reading with the minibuffer: * When you mention a default value in a minibuffer prompt, put it and the word `default' inside parentheses. It should look like this: Enter the answer: (default 42) Not all files in the Emacs sources follow this convention. The following patch fixes the cases I could find with a simple grep. I'm not sure whether blindly following such a convention is always a Good Thing. For example: Translate buffer from format (default: guess): versus Translate buffer from format: (default guess) I double-checked these changes twice (sic). Nevertheless I would appreciate if somebody else review this patch again before committing. lisp/ChangeLog: 2005-09-06 Emilio C. Lopes [EMAIL PROTECTED] * vc-mcvs.el (vc-mcvs-register): * shadowfile.el (shadow-define-literal-group): * progmodes/antlr-mode.el (antlr-end-of-rule): * woman.el (woman-file-name): * vc.el (vc-version-diff, vc-merge): * textmodes/reftex-index.el (reftex-index-complete-tag): * format.el (format-decode-buffer, format-decode-region): * emulation/viper-cmd.el (viper-read-string-with-history): * emacs-lisp/debug.el (cancel-debug-on-entry): * emacs-lisp/checkdoc.el (checkdoc-this-string-valid-engine): * ediff.el (ediff-merge-revisions) (ediff-merge-revisions-with-ancestor, ediff-revision): * completion.el (interactive-completion-string-reader): * calc/calc-prog.el (calc-user-define-formula): Follow convention for reading with the minibuffer. lisp/gnus/ChangeLog: 2005-09-06 Emilio C. Lopes [EMAIL PROTECTED] * message.el (message-check-news-header-syntax): Follow convention for reading with the minibuffer. diff -rN -c old-emacs-darcs.eclig/lisp/calc/calc-prog.el new-emacs-darcs.eclig/lisp/calc/calc-prog.el *** old-emacs-darcs.eclig/lisp/calc/calc-prog.elTue Sep 6 19:35:56 2005 --- new-emacs-darcs.eclig/lisp/calc/calc-prog.elMon Sep 5 20:23:23 2005 *** *** 197,205 (progn (setq cmd-base-default (concat User- keyname)) (setq cmd (completing-read ! (concat Define M-x command name (default: calc- cmd-base-default ! ): ) obarray 'commandp nil (if (and odef (symbolp (cdr odef))) (symbol-name (cdr odef)) --- 197,205 (progn (setq cmd-base-default (concat User- keyname)) (setq cmd (completing-read ! (concat Define M-x command name: (default calc- cmd-base-default ! ) ) obarray 'commandp nil (if (and odef (symbolp (cdr odef))) (symbol-name (cdr odef)) *** *** 233,240 (setq func (concat calcFunc- (completing-read ! (concat Define algebraic function name (default: ! cmd-base-default ): ) (mapcar (lambda (x) (substring x 9)) (all-completions calcFunc- obarray)) --- 233,240 (setq func (concat calcFunc- (completing-read ! (concat Define algebraic function name: (default ! cmd-base-default ) ) (mapcar (lambda (x) (substring x 9)) (all-completions calcFunc- obarray)) diff -rN -c old-emacs-darcs.eclig/lisp/completion.el new-emacs-darcs.eclig/lisp/completion.el *** old-emacs-darcs.eclig/lisp/completion.elTue Sep 6 19:35:57 2005 --- new-emacs-darcs.eclig/lisp/completion.elMon Sep 5 20:23:25 2005 *** *** 1343,1349 (let* ((default (symbol-under-or-before-point)) (new-prompt (if default ! (format %s: (default: %s) prompt default) (format %s: prompt))) (read (completing-read new-prompt cmpl-obarray))) (if (zerop (length read)) (setq read (or default ))) --- 1343,1349 (let* ((default (symbol-under-or-before-point)) (new-prompt (if default ! (format %s: (default %s) prompt default) (format %s: prompt))) (read (completing-read new-prompt cmpl-obarray))) (if (zerop (length read)) (setq read (or default ))) diff -rN -c old-emacs-darcs.eclig/lisp/ediff.el new-emacs-darcs.eclig/lisp/ediff.el ***
Re: Options menu is broken on CVS
Salı 06 Eylül 2005 20:15 tarihinde şunları yazmıştınız: You might try a bootstrap build. I had problems like this when I attempted to build otherwise. A clean CVS checkout compiled with make bootstrap is showing the same problem. Regards, ismail ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
From: Richard M. Stallman [EMAIL PROTECTED] Date: Tue, 06 Sep 2005 07:22:59 -0400 Cc: [EMAIL PROTECTED], emacs-devel@gnu.org I don't think it is worth spending the time to have a long discussion about whether to use a macro to define these commands, whether they should be lambdas or have names, etc. This discussion was not about whether to use a macro or a function, it is about how to supply a doc string for a particular mouse click. I suggested to use a function as a means to that end, but I won't object to a different solution as long as there's a meaningful string that C-h c and C-h k can display for that click. We had in the past complaints about mouse gestures for which Help commands displayed technobabble understandable only by ELisp gurus. We fixed those bindings by using functions. Why add more causes for users to complain about? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
Why? It is much more convenient to allow users to click on a link. If the user wants to move the header line (which is not something that people do frequently, anyway), all she has to do is to move the mouse two milimeters to the left, outside the button. This is what people are used to in all other graphical applications -- no one sees a button and thinks, Yeah, that's for resizing the window. The choice isn't between clicking or dragging, its between clicking or clicking *and* dragging. You're adding a line of code that just prevents the header line from being dragged at that point. It seems a bit pointless. Alright. I've taken out the part inhibiting down-mouse-1 on the header line. As for not binding to lambda expressions, that will have to wait until someone else comes up with a clean way to do it. Since the patch works, it's better than nothing, so I've checked it in. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Paragraphs (and sentences) in Emacs cannot span pages.
Hi, Stefan. On Tue, 6 Sep 2005, Stefan Monnier wrote: This sentence goes over from one page ^L to the next. In my experience, ^L is generally used in Emacs for logical pages, not for physical pages, so a ^L in the middle of a paragraph doesn't make much sense. In this case, having the ^L in the paragraph-s... variables doesn't add anything. I guess if you see such a ^L it's inside something like an RFC, where the two pages are separated not just by ^L but also by footerheader so it'd be hard for Emacs to figure out what's a paragraph. I suppose one would want an RFC mode there, where page-delimiter is set up to match the footer+header. Could you give more info about the precise case(s) where you bumped into ^L in the middle of paragraphs? I'm documenting what pages, paragraphs and sentences are, in the elisp file searching.texi (page Standard Regexps). I haven't actually come across any difficulty that this paragraph break at ^L causes, yet at the same time, don't really see what its purpose is. I'm thinking about what I should say about this in searching.texi. Stefan -- Alan. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
Eli Zaretskii [EMAIL PROTECTED] writes: When you bind a function to a key, you can't specify any additional arguments to pass to that function. So you have to define one function for each of the possible values of `column' in the code. The only way I can think of to get around this is to bind to a single function that tries to re-construct the value of `column' based on where the mouse was clicked. But that seems like a strange thing to do -- you're throwing away information that you had (i.e., the value of `column'), only to do a lot of work find out what it was later on. There must be some kind of misunderstanding here. I understand that you need to know where the mouse was clicked, but that information is stored in the mouse event that invokes the function, so if you use `(interactive e)', you will have access to that information inside the function. Given this, what information is thrown away? When you're constructing the keymap, you know what the value of `column' is that you want to pass to `(Buffer-menu-sort column)'. Column=1 lists the buffer name, column=2 lists the buffer size, etc. Your suggestion is to bind to a function, e.g., (Buffer-menu-sort-click (e) (interactive e) ...) What this function has to do is reconstruct the value of `column' to pass to `(Buffer-menu-sort column)' -- information that you've thrown away, because all you know is the input event e. To reconstruct `column', you call (pos-row-col (event-start e)), which gives the col (character column -- not the `column' we want). Then you have to figure out that `column=1' spans col X to col Y, `column=2' spans col XX to col YY, etc. Also, you have to substract some value from the result of pos-row-col, depending on whether you are using a header line or not, because the left fringe (if the fringe is activated) and the scroll bar (if the scroll bar is on the left) may take up the first few character columns on the header line. It's a giant headache to code. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Patch: Follow convention for reading with the minibuffer.
* When you mention a default value in a minibuffer prompt, put it and the word `default' inside parentheses. It should look like this: Enter the answer: (default 42) Yuck! I *much* prefer Enter the answer (default 42): which is what is used by pretty much everything except for C-x b (where the default is after the colon by accident AFAICT). Stefan PS: Actually I even prefer Enter the answer [42]: because minibuffer width is limited. I guess I should write a variant of minibuffer-electric-default-mode which rewrites the (default foo) into [foo]. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Options menu is broken on CVS
Options menu no longer works with emacs from CVS. To reproduce open emacs press F10-O and you get : Symbol's value as variable is void: menu-updating-frame Looks like recent changes to lisp/menu-bar.el borked this though I am not 100% certain with that. So wondering if anyone can reproduce this? I don't see this problem on GNU/Linux. menu-updating-frame is a builtin variable. If you use M-x report-emacs-bug (its on the menu-bar!) we can see how your Emacs was built and perhaps why menu-updating-frame has been seemingly left out. Nick ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
Salı 06 Eylül 2005 23:45 tarihinde, Nick Roberts şunları yazmıştı: M-x report-emacs-bug Here it goes : This bug report will be sent to the Free Software Foundation, not to your local site managers! 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: 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 /usr/local/share/emacs/22.0.50/etc/DEBUG for instructions. In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu) of 2005-09-06 on pardus configured using `configure '--without-x'' Important settings: value of $LC_ALL: tr_TR.UTF-8 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: tr_TR.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Lisp Interaction Minor modes in effect: show-paren-mode: t encoded-kbd-mode: t auto-compression-mode: t menu-bar-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t transient-mark-mode: t ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
Tomas Zerolo wrote: Can't you attach a doc-string to an anonymous function, like so? `lambda (e) ,(concat Sort buffer by column) ... Obviously you can include a doc string in a lambda form. The real question is, will Emacs do the right thing with it? It looks pretty good to me in Emacs 21: (documentation (lambda (foo) *Grok FOO. (interactive sGrok: ) (grok foo))) returns: *Grok FOO. And given: (global-set-key \C-cz (lambda (foo) *Grok FOO. (interactive sGrok: ) (grok foo))) ,[ C-h k C-c z ] | C-c z runs the command (lambda (foo) *Grok FOO. (interactive sGrok: ) (grok foo)) |which is an interactive Lisp function. | (anonymous FOO) | | *Grok FOO. ` -- Kevin Rodgers ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: key-binding values
Drew Adams [EMAIL PROTECTED] writes: Also, correct me if I'm wrong, but my understanding is that the form [?\C- ] is generally preferred over the form \C- , for a key binding. These two key sequences represent quite different bindings. You can't get one override the other, it depends on the terminal which key you receive on typing C-space. Whenever either is acceptable, is one of the two preferred in Emacs-Lisp code, for binding keys? My understanding was that the vector form was preferred. IMHO there is no real preference. The string notation can only represent a limited set of keys, but is easier to read when it works. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: key-binding values
IMHO there is no real preference. The string notation can only represent a limited set of keys, but is easier to read when it works. This is why I always use the (kbd ...) notation: represents all keys, and is more readable than the other options. Ted -- Edward O'Connor [EMAIL PROTECTED] Ense petit placidam sub libertate quietem. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
Chong Yidong [EMAIL PROTECTED] writes: Eli Zaretskii [EMAIL PROTECTED] writes: The only way I can think of to get around this is to bind to a single function that tries to re-construct the value of `column' based on where the mouse was clicked. But that seems like a strange thing to do -- you're throwing away information that you had (i.e., the value of `column'), only to do a lot of work find out what it was later on. [...] It's a giant headache to code. Not if you use the right approach. Try this patch (not fully tested, but shows the principle): *** buff-menu.el06 Sep 2005 23:52:33 +0200 1.91 --- buff-menu.el07 Sep 2005 00:57:01 +0200 *** *** 633,660 (insert m2))) (forward-line) (defun Buffer-menu-make-sort-button (name column) (if (equal column Buffer-menu-sort-column) (setq column nil)) (let* ((downname (downcase name)) ! (map (make-sparse-keymap)) ! (fun `(lambda (optional e) ! ,(concat Sort the buffer menu by downname .) ! (interactive (list last-input-event)) ! (if e (mouse-select-window e)) ! (Buffer-menu-sort ,column))) ! (sym (intern (format Buffer-menu-sort-by-%s-%s name column ! ;; Use a symbol rather than an anonymous function, to make the output of ! ;; C-h k less intimidating. ! (fset sym fun) ! (setq fun sym) ;; This keymap handles both nil and non-nil ;; values for Buffer-menu-use-header-line. ! (define-key map [header-line mouse-1] fun) ! (define-key map [header-line mouse-2] fun) ! (define-key map [mouse-2] fun) (define-key map [follow-link] 'mouse-face) ! (define-key map \C-m fun) (propertize name 'help-echo (concat (if Buffer-menu-use-header-line mouse-1, mouse-2: sort by --- 633,658 (insert m2))) (forward-line) + (defun Buffer-menu-sort-by-column (optional e) + Sort the buffer menu by this column. + (interactive e) + (if e (mouse-select-window e)) + (let ((obj (posn-object (event-start e + (Buffer-menu-sort (get-text-property (cdr obj) 'column (car obj) + (defun Buffer-menu-make-sort-button (name column) (if (equal column Buffer-menu-sort-column) (setq column nil)) (let* ((downname (downcase name)) ! (map (make-sparse-keymap))) ;; This keymap handles both nil and non-nil ;; values for Buffer-menu-use-header-line. ! (define-key map [header-line mouse-1] 'Buffer-menu-sort-by-column) ! (define-key map [header-line mouse-2] 'Buffer-menu-sort-by-column) ! (define-key map [mouse-2] 'Buffer-menu-sort-by-column) (define-key map [follow-link] 'mouse-face) ! (define-key map \C-m 'Buffer-menu-sort-by-column) (propertize name + 'column column 'help-echo (concat (if Buffer-menu-use-header-line mouse-1, mouse-2: sort by -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
Emacs CVS Crash
That looks like gcc thats crashed not Emacs. If its a bug with gcc, should you be reporting it to them? Nick Vinicius Jose Latorre writes: Hi Folks, I've just updated Emacs sources from CVS today. Then: $ make maintainer-clean $ ./configure --prefix=/home/download/emacs $ make bootstrap [...skipped for brevity...] gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/home/vinicius/work/emacs/src -D_BSD_SOURCE -I/usr/X11R6/include -g -O2 indent.c gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/home/vinicius/work/emacs/src -D_BSD_SOURCE -I/usr/X11R6/include -g -O2 search.c search.c: In function `Fset_match_data': search.c:2974: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla/ for instructions. make[2]: *** [search.o] Error 1 make[2]: Leaving directory `/home/vinicius/work/emacs/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/home/vinicius/work/emacs' make: *** [bootstrap-build] Error 2 Vinicius ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Emacs CVS Crash
Vinicius Jose Latorre [EMAIL PROTECTED] writes: Hi Folks, I've just updated Emacs sources from CVS today. Then: $ make maintainer-clean $ ./configure --prefix=/home/download/emacs $ make bootstrap [...skipped for brevity...] gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/home/vinicius/work/emacs/src -D_BSD_SOURCE -I/usr/X11R6/include -g -O2 indent.c gcc -c -D_BSD_SOURCE -Demacs -DHAVE_CONFIG_H -DUSE_LUCID -I. -I/home/vinicius/work/emacs/src -D_BSD_SOURCE -I/usr/X11R6/include -g -O2 search.c search.c: In function `Fset_match_data': search.c:2974: internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://bugzilla.redhat.com/bugzilla/ for instructions. make[2]: *** [search.o] Error 1 make[2]: Leaving directory `/home/vinicius/work/emacs/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/home/vinicius/work/emacs' make: *** [bootstrap-build] Error 2 Isn't that the compiler crashing? -- Kim F. Storm [EMAIL PROTECTED] http://www.cua.dk ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Buffer menu fix
Not if you use the right approach. Try this patch (not fully tested, but shows the principle): It works. Very clever! ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
where-is-internal question
I haven't looked into this in detail - forgive my incomplete understanding. I'm looking for help on where-is-internal - as regards command remapping (I guess). In previous Emacs versions, I could do this, to bind stuff that is bound to self-insert-command in the global map: (dolist (key (where-is-internal 'self-insert-command global-map)) (define-key my-map key 'my-command)) Now, however, it looks like I need to do something like the following. Let me know if I'm missing something, and there is a simpler way. (dolist (key (or (condition-case nil (where-is-internal 'self-insert-command global-map nil nil t) (wrong-number-of-arguments nil)) (where-is-internal 'self-insert-command global-map))) ; use old version (define-key my-map key 'my-command)) IIUC (probably not), the 5th arg to where-is-internal is needed here, because of some remapping done to self-insert-command (?). The NEWS file says this, for Emacs 22.1: `where-is-internal' now returns nil for a remapped command (e.g. `kill-line', when `my-mode' is enabled), and the actual key binding for the command it is remapped to (e.g. C-k for my-kill-line). It also has a new optional fifth argument, NO-REMAP, which inhibits remapping if non-nil (e.g. it returns C-k for `kill-line', and kill-line for `my-kill-line') I guess that explains what's going on here, but I don't quite follow it. I also searched NEWS for info on self-insert, but I didn't see anything that I understood as being related. All I know is that if I don't use a non-nil 5th argument, I don't get the bindings I'm after; if I do use it, that works. I'm guessing that self-insert-command must be remapped, and that is why I need to use a non-nil 5th arg - to prevent where-is-internal from returning nil for each of the (remapped) self-insert-command bindings. Could someone please clear up for me just what is going on here? In ignorance, I'm thinking that the new 5th arg should be defined the other way 'round: nil should do what t does now, to give better backward compatibility. That way (I think), I would be able to do just (where-is-internal 'self-insert-command global-map) in all Emacs versions. Please let me know what I'm missing (= 80%, I'm sure). Thanks. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Shall we use etc/images more?
In MH-E, I think I'd like to reference images in etc/images/mail and, say, etc/images/common, instead of lisp/mail and lisp/toolbar. I only see gnus and smilies directories in there now. Is the intent to someday move the images to etc/images? I recall Miles saying he thought that Gnus was a good example to follow. If so, what do people think of me checking in copies of the images in lisp/mail into etc/images/mail and the images in lisp/toolbar into etc/images/common (or nominate your favorite). I'll update MH-E to reference the new location (if necessary). When the others files have been modified (if necessary) to reference the new location, then the images in the old locations can be removed. I'm open to suggestions and concerns. Since I'm making changes to the MH-E distribution now in preparation of using the Emacs repository instead of the SourceForge repository (finally!), now would be a good time to make these sorts of changes. -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian! If you're passed on the right, you're in the wrong lane. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: where-is-internal question
In previous Emacs versions, I could do this, to bind stuff that is bound to self-insert-command in the global map: (dolist (key (where-is-internal 'self-insert-command global-map)) (define-key my-map key 'my-command)) Now, however, it looks like I need to do something like the following. (dolist (key (or (condition-case nil (where-is-internal 'self-insert-command global-map nil nil t) (wrong-number-of-arguments nil)) (where-is-internal 'self-insert-command global-map))) (define-key my-map key 'my-command)) I forgot to mention that, whereas the above code is lightning-quick in Emacs 20 (without the 5th arg), in Emacs 22 it takes about 5 _seconds_ (on a pretty fast machine). Why so slow? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Options menu is broken on CVS
From: Nick Roberts [EMAIL PROTECTED] Date: Wed, 7 Sep 2005 11:01:27 +1200 Cc: emacs-devel@gnu.org It seems to be due to this change: 2004-03-13 Eli Zaretskii [EMAIL PROTECTED] * emacs.c (main): Call syms_of_xmenu only if HAVE_MENUS is defined. I guess it hasn't been noticed before because, although people may use tmm, most use a version of Emacs thats compiled with X (or at least HAVE_MENUS). I haven't reverted this change because it must be there for a reason. Eli? It _was_ for a reason. The 2 related changes I committed at that time were these: 2004-03-13 Eli Zaretskii [EMAIL PROTECTED] * Makefile.in (XMENU_OBJ): Include xmenu.o if HAVE_MENUS is defined. * emacs.c (main): Call syms_of_xmenu only if HAVE_MENUS is defined. I don't remember the details (you will probably find them in emacs-devel or emacs-pretest-bug archives for that period of time), but there was some build failure, I think on MacOS, which these changes were part of fixing. Please don't take out this change without understanding what it was fixing in the first place. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: key-binding values
(key-description [67108896]) = C-SPC (key-description \C- ) = C-@ Emacs users learn quickly to read ^@ as control @, and they also learn that this is equivalent to control SPC, but [67108896] is hard to read and digest. Keys are just integers in Emacs. There is nothing that makes any integer special wrt to keys. It would be feasible to define a custom type that would display these vectors or strings of integers in a way that is convenient when they are really key sequences. It could be called `key-sequence'. I don't plan to do this myself. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: Paragraphs (and sentences) in Emacs cannot span pages.
In printed material, sentences and paragraphs can (and frequently do) start on one page and finish on the next. That's because the pages are broken automatically. That's not how people normally use ^L in files they edit. Could you tell me more about the files you are editing and why they have ^L in the middle of paragraphs? ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
But I think it would be more convenient to [use M-n to] add [additional default values] to the list for [M-p] to access. We seem to be miscommunicating; your additions turn this into something very different from what I was talking about. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
RE: make `occur' use word at point as default
But I think it would be more convenient to [use M-n to] add [additional default values] to the list for [M-p] to access. We seem to be miscommunicating; your additions turn this into something very different from what I was talking about. Sorry; I tried. Could you please rephrase what you meant? We're getting lost in the translations. ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
Re: make `occur' use word at point as default
But I think it would be more convenient to [use M-n to] add [additional default values] to the list for [M-p] to access. We seem to be miscommunicating; your additions turn this into something very different from what I was talking about. Drew's response to your message seems right, but his reconstruction of your message is not. Could you confirm that you really meant this: But I think it would be more convenient to [use M-n to] access [additional default values] from the list [of default values]. -- Juri Linkov http://www.jurta.org/emacs/ ___ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel
