Mac port: startup failure when in non-ASCII path
Emacs (Carbon port) is unable to deal with path names that contain non-ASCII characters. Symptoms: If a (self-containing) Emacs.app is put in /Applications/Emacs ƒ/ or /Applications/Emacs ö/ Emacs won't start up. Starting the binary inside the bundle directly yields the error message Cannot open load file: term/mac-win which becomes Cannot open load file: disp-table when started with -batch. This is last night's Emacs CVS (and an older compile as well), running on OS X 10.4.3. Note that the first option for the directory name (ƒ) is actually a not untypical choice for Mac users (for history reasons). An actual Aquamacs user has reported a startup failure, which turned out to be due to his choice of path name. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: menu-updating-frame is nil on X
In Emacs configured with '--with-x-toolkit=no' on i686-pc-linux-gnu and run with `emacs -Q', `menu-updating-frame' is nil. This causes some menu items to be permanently disabled due to the condition in `menu-bar-menu-frame-live-and-visible-p' where `(display-multi-frame-p)' returns `t'. The theory behind that code was that menu-updating-frame cannot possibly be nil on a display that supports multiple frames visible at the same time. How come the non-toolkit version doesn't bind menu-updating-frame to something non-nil? Can you please investigate? Emacs built without a X toolkit doesn't have a separate frame for the menu bar. What do you think about the following change? Would it work in all cases? Index: lisp/menu-bar.el === RCS file: /cvsroot/emacs/emacs/lisp/menu-bar.el,v retrieving revision 1.278 diff -c -r1.278 menu-bar.el *** lisp/menu-bar.el1 Nov 2005 23:21:39 - 1.278 --- lisp/menu-bar.el8 Nov 2005 12:43:03 - *** *** 1424,1431 (defun menu-bar-menu-frame-live-and-visible-p () Return non-nil if the menu frame is alive and visible. The menu frame is the frame for which we are updating the menu. ! (let ((menu-frame (if (display-multi-frame-p) menu-updating-frame ! (selected-frame (and (frame-live-p menu-frame) (frame-visible-p menu-frame --- 1424,1430 (defun menu-bar-menu-frame-live-and-visible-p () Return non-nil if the menu frame is alive and visible. The menu frame is the frame for which we are updating the menu. ! (let ((menu-frame (or menu-updating-frame (selected-frame (and (frame-live-p menu-frame) (frame-visible-p menu-frame -- 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: key bindings for flyspell-mode that work on terminals
All solutions based on reading the next event have the usual problems that they interact poorly with post-command-hooks, input methods, key-translation-map, function-key-map, ... I agree. In places where this technique is used it causes too much problems (for example, completion in *shell* is still klugey). Better would be a hack that sets a transient minor mode (with M-TAB bound appropriately) and adds a pre-command-hook which disables the minor mode as soon as we use something else than M-TAB. Or as a simpler solution we could leave the last overlay undeleted (but unhighlighted) until the user tries to correct another word. -- 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: key bindings for flyspell-mode that work on terminals
I am not so sure. Some symbols are not correct words. For example if you have in a buffer: ;; dabbrev and do M-TAB at the end of that word, you wouldn't want flyspell to try to fix the spelling for dabbrev. Actually this will work as you want. With M-TAB defined in `flyspell-mouse-map', M-TAB at the end of that word will call `lisp-complete-symbol', and inside the word - flyspell completion. -- 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
Info node on prefix keymaps
The second paragraph of the info node titled ``56.4.2 Prefix Keymaps'' states this: Thus, the binding of `C-x' is the symbol `Ctl-X-Prefix', whose function definition is the keymap for `C-x' commands. The symbol Ctl-X-Prefix doesn't exist: C-u M-x apropos RET Ctl-X-Prefix RET No apropos matches for `Ctl-X-Prefix' The Elisp manual (in ``22.5 Prefix Keys'') says that it should be Control-X-prefix, which does exist. This is with Emacs 22.0.50, checked out of CVS 2005-11-07. -- http://www.fastmail.fm - Email service worth paying for. Try it for free ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
For this reason, I think its important that find-dired can add to dired-buffers. If I understood correctly, this requires reverting an old change by Richard. In that case, Richard should tell us whether that is OK or not. Also did you check that the way you want to do it works correctly if you delete a file whose directory is not the *Find* buffer's directory, but a subdirectory of it, that is, a file listed as subdir/filename? I've just created such a buffer, deleted the file in a buffer using normal dired and the *Find* buffer updates correctly. I've not done an exhaustive analysis but using dired-buffers seems to follow the idiom. delete-region could be used for locate, of course, I guess one could also make dired-fun-in-all-buffers automatically check all *Locate* buffers, so that *Locate* buffers would also be updated, even if the file got deleted in another Dired buffer. But maybe that might be more complicated. *Locate* differs from *Find* in that it has its own mode and doesn't use dired-mode but copies the keymap. I'm not sure that the dired analogy carries over so fully. It uses absolute filenames for a start. possibly conditioned on major-mode not being dired-mode to make sure nothing gets deleted twice. I do not believe that my patch deletes anything twice. dired-fun-in-all-buffers can not delete anything that is not there any more. Probably not but theres no harm in conditioning it, and it might make it more future proof. Actually requiring major-mode to be locate-mode would also explain when it was needed better perhaps than a comment could. Nick ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Can you answer Richard's question, since you are the one proposing the revert? Could you provide a self-contained description of what the issue is? Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Can you answer Richard's question, since you are the one proposing the revert? Could you provide a self-contained description of what the issue is? I don't know what's to cover that hasn't already been said: If you delete a file with D, or m (dired-mark) in a *Locate* buffer or a *Find* buffer then the buffer does not automatically update in 22.0.50 whereas it did in 21.3. The patch below seems to fix this. The change for find-dired.el is for *Find* and that for dired.el is for *Locate*. However, find-dired deliberately shadowed the variable dired-buffers so I am uneasy about reverting that change. Actually, as Luc says, eventually it would probably be best to use dired-mode for *Locate*. Nick *** find-dired.el 03 Sep 2005 14:05:24 +1200 1.51 --- find-dired.el 09 Nov 2005 08:15:12 +1300 *** *** 97,103 (interactive (list (read-file-name Run find in directory: nil t) (read-string Run find (with args): find-args '(find-args-history . 1 - (let ((dired-buffers dired-buffers)) ;; Expand DIR ( means default-directory), and make sure it has a ;; trailing slash. (setq dir (file-name-as-directory (expand-file-name dir))) --- 97,102 *** *** 167,173 (set-process-sentinel proc (function find-dired-sentinel)) ;; Initialize the process marker; it is used by the filter. (move-marker (process-mark proc) 1 (current-buffer))) ! (setq mode-line-process '(:%s (defun kill-find () Kill the `find' process running in the current buffer. --- 166,172 (set-process-sentinel proc (function find-dired-sentinel)) ;; Initialize the process marker; it is used by the filter. (move-marker (process-mark proc) 1 (current-buffer))) ! (setq mode-line-process '(:%s))) (defun kill-find () Kill the `find' process running in the current buffer. *** dired.el24 Oct 2005 20:21:15 +1300 1.329 --- dired.el09 Nov 2005 08:21:09 +1300 *** *** 2403,2408 --- 2403,2412 ;; if we get here, removing worked (setq succ (1+ succ)) (message %s of %s deletions succ count) + (if (eq major-mode 'locate-mode) + (delete-region (progn (beginning-of-line) (point)) +(progn (forward-line 1) (point))) + (dired-clean-up-after-deletion fn)) (dired-fun-in-all-buffers (file-name-directory fn) (file-name-nondirectory fn) (function dired-delete-entry) fn)) ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: key bindings for flyspell-mode that work on terminals
Richard M. Stallman wrote: Emacs can't read your mind. Another item for etc/TODO? ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Roomity.com v 1.5 is a web 2.01
I was interested in getting feedback from current mail group users.We have mirrored your mail list in a new application that provides a more aggregated and safe environment which utilizes the power of broadband.Roomity.com v 1.5 is a web 2.01 community webapp. Our newest version adds broadcast video and social networking such as favorite authors and an html editor.It?s free to join and any feedback would be appreciated.S.Broadband interface (RIA) + mail box saftey = Emacs_Pretest_Bug_List.roomity.com*Your* clubs, no sign up to read, ad supported; try broadband internet. ~~1131486764981~~___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Partial completion and completions-first-difference.
An easy fix is to turn off the boldening if partial-completion-mode is ON and the string starts with a - (or maybe even turn it OFF altogether whenever partial-completion-mode is ON). A week from now, if nobody has proposed a better solution, would you please do that? How 'bout the patch below? It does the following: - try and fix the problem with the leading - - add a reminder about the fact that it's the wrong place to fix the problem. - change handling of the completion-base-size-function property so it's also obeyed if minibuffer-completing-file-name. - add a comment about the fact that completion-base-size-function receives very little info, making it potentially difficult for it to do its job. Regarding this last point, we could use a convention like all-completions can return a list whose last cdr is not nil but an integer (the completion-base-size) or some other way to return that info on the side. Stefan PS: guaranteed 100% untested patch: *** simple.el 03 nov 2005 23:31:05 -0500 1.761 --- simple.el 08 nov 2005 17:10:41 -0500 *** *** 4908,4938 (setq default-directory (file-name-directory mbuf-contents ;; If partial-completion-mode is on, point might not be after the ;; last character in the minibuffer. ! ;; FIXME: This still doesn't work if the text to be completed ! ;; starts with a `-'. ! (when (and partial-completion-mode (not (eobp))) (setq common-string-length ! (- common-string-length (- (point) (point-max) (with-current-buffer standard-output (completion-list-mode) (set (make-local-variable 'completion-reference-buffer) mainbuf) - (if minibuffer-completing-file-name - ;; For file name completion, - ;; use the number of chars before the start of the - ;; last file name component. (setq completion-base-size (with-current-buffer mainbuf (save-excursion (goto-char (point-max)) (skip-chars-backward completion-root-regexp) ! (- (point) (minibuffer-prompt-end) ;; Otherwise, in minibuffer, the whole input is being completed. ! (if (minibufferp mainbuf) (if (and (symbolp minibuffer-completion-table) (get minibuffer-completion-table 'completion-base-size-function)) (setq completion-base-size ! (funcall (get minibuffer-completion-table 'completion-base-size-function))) ! (setq completion-base-size 0 ;; Put faces on first uncommon characters and common parts. (when (or completion-common-substring completion-base-size) (setq common-string-length --- 4908,4949 (setq default-directory (file-name-directory mbuf-contents ;; If partial-completion-mode is on, point might not be after the ;; last character in the minibuffer. ! ;; FIXME: This hack should be moved to complete.el's where we call ! ;; display-completion-list. ! (when partial-completion-mode (setq common-string-length ! (if (eq (char-after (field-beginning)) ?-) ! ;; If the text to be completed starts with a `-', there is no ! ;; common prefix. ! ;; FIXME: this probably still doesn't do the right thing ! ;; when completing file names. It's not even clear what ! ;; is TRT. ! 0 ! (- common-string-length (- (point) (point-max)) (with-current-buffer standard-output (completion-list-mode) (set (make-local-variable 'completion-reference-buffer) mainbuf) (setq completion-base-size + (if minibuffer-completing-file-name + ;; For file name completion, use the number of chars before + ;; the start of the last file name component. (with-current-buffer mainbuf (save-excursion (goto-char (point-max)) (skip-chars-backward completion-root-regexp) ! (- (point) (minibuffer-prompt-end ;; Otherwise, in minibuffer, the whole input is being completed. ! (if (minibufferp mainbuf) 0))) (if (and (symbolp minibuffer-completion-table) (get minibuffer-completion-table 'completion-base-size-function)) (setq completion-base-size ! ;; FIXME: without any extra arg, how is this function ! ;; expected to return anything else than a constant ! ;; In most cases this value would better be computed and ! ;; returned at the same time as the list of all-completions ! ;; is computed. --Stef ! (funcall (get minibuffer-completion-table !
Re: menu-updating-frame is nil on X
From: Juri Linkov [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Date: Tue, 08 Nov 2005 14:43:43 +0200 In Emacs configured with '--with-x-toolkit=no' on i686-pc-linux-gnu and run with `emacs -Q', `menu-updating-frame' is nil. This causes some menu items to be permanently disabled due to the condition in `menu-bar-menu-frame-live-and-visible-p' where `(display-multi-frame-p)' returns `t'. The theory behind that code was that menu-updating-frame cannot possibly be nil on a display that supports multiple frames visible at the same time. How come the non-toolkit version doesn't bind menu-updating-frame to something non-nil? Can you please investigate? Emacs built without a X toolkit doesn't have a separate frame for the menu bar. I think we are miscommunicating: I didn't mean to say that the menu bar is a separate frame, I meant to say that a windowed Emacs session sets menu-updating-frame to the frame from which the menu was invoked. In xmenu.c the function set_frame_menubar binds menu-updating-frame to the frame passed to it as argument. Could you please look and see why this isn't working as intended? What do you think about the following change? Would it work in all cases? Without a clear understanding what happens in the non-toolkit case, I cannot really answer that. And I don't like working around a problem I don't understand. Using selected-frame is okay for the case of a character terminal, since there we _know_ that the selected frame is the one which invoked the menu (usually via tmm). But that logic doesn't work on X. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Two buglets in diary-list-entries
(i) In my init-file default-major-mode is set to text-mode and as a result, since diary-list-entries only checks for fundamental-mode, my diary file isn't automatically visited in diary-mode. (ii) In the diary display (I use fancy-diary-display) there are unwanted blank lines between entries from the same day, which arise when the last line of the diary file or of any included files is a newline. I usually don't add a newline myself when making a diary entry, so these seem to be coming from somewhere else. The following patch fixes these two problems for me, but I don't know if it's free of undesirable side effects or otherwise suboptimal. *** lisp/calendar/diary-lib.el 2005-10-25 09:55:17.0 +0200 orig --- lisp/calendar/diary-lib.el 2005-11-09 00:08:48.0 +0100 fix *** *** 378,384 (or (verify-visited-file-modtime diary-buffer) (revert-buffer t t ;; Setup things like the header-line-format and invisibility-spec. ! (when (eq major-mode 'fundamental-mode) (diary-mode)) ;; d-s-p is passed to the diary display function. (let ((diary-saved-point (point))) (save-excursion --- 378,384 (or (verify-visited-file-modtime diary-buffer) (revert-buffer t t ;; Setup things like the header-line-format and invisibility-spec. ! (when (eq major-mode default-major-mode) (diary-mode)) ;; d-s-p is passed to the diary display function. (let ((diary-saved-point (point))) (save-excursion *** *** 456,461 --- 456,463 (unless list-only (remove-overlays date-start (point) 'invisible 'diary)) +(when (and (eobp) (looking-at ^$)) + (delete-char -1)) (setq entry (buffer-substring entry-start (point)) temp (diary-pull-attrs entry file-glob-attrs) entry (nth 0 temp)) In GNU Emacs 22.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.8.3) of 2005-10-26 on escher X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--with-x-toolkit=gtk'' 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: en_US.UTF-8 locale-coding-system: utf-8 default-enable-multibyte-characters: t Major mode: Emacs-Lisp Minor modes in effect: eldoc-mode: t senator-minor-mode: t semantic-idle-summary-mode: t semantic-idle-scheduler-mode: t tabbar-mwheel-mode: t tabbar-mode: t recentf-mode: t show-paren-mode: t display-time-mode: t tool-bar-mode: t mouse-wheel-mode: t tooltip-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 column-number-mode: t line-number-mode: t transient-mark-mode: identity Recent input: e d i f f return return M-b M-n down down up C-e M-n up d i tab ~ return D switch-frame C-x k return C-x k return f1 M-x up return up return up up up return D switch-frame switch-frame f1 C-x b up up up down down return f2 S-up C-c j e d tab return S-up S-up S-right S-up S-up C-c j d tab i backspace f tab return f12 M-g M-g 3 7 8 return C-M-a select-window down-mouse-1 mouse-1 double-down-mouse-1 double-mouse-1 f1 M-x e m a tab M-backspace r e p o tab r tab return Recent messages: Reading file /usr/local/share/emacs/22.0.50/lisp/calendar/diary-lib.el~ ... Reading file /usr/local/share/emacs/22.0.50/lisp/calendar/diary-lib.el ... Computing differences between diary-lib.el~ and diary-lib.el ... Buffer A: Processing difference region 0 of 2 Buffer B: Processing difference region 0 of 2 Processing difference regions ... done next-history-element: Beginning of history; no preceding item Making completion list... Loading emacsbug...done Loading dabbrev...done ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Info node on prefix keymaps
Thus, the binding of `C-x' is the symbol `Ctl-X-Prefix', whose function definition is the keymap for `C-x' commands. The symbol Ctl-X-Prefix doesn't exist: Thanks. I will fix that. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Could you provide a self-contained description of what the issue is? I don't know what's to cover that hasn't already been said: I didn't ask for anything that hasn't already been said. I asked for a self-contained description of what has been said. I cannot remember the reason in 1998 for binding dired-buffers. But it looks like the goal was to prevent these find-dired buffers from being included in that list. Probably because there was something that did not work right if they were included in that list. Perhaps the thing that did not work is what you are fixing now. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Richard Stallman wrote: Perhaps the thing that did not work is what you are fixing now. I do not immediately understand. Nick is proposing to revert the 1998 change and do essentially nothing else, so any problem the 1998 change fixed will reappear, unless it has been undeliberately fixed in the meantime by some other change. Or was the original problem that for some reason people did not _want_ the results in their *Find* buffers to be automatically changed when the file system changed as a result of operations in another Dired buffer? The only additional thing I could find that might be relevant to the present discussion is that find-lisp.el contains code completely similar to the one in find-dired (see line 191 and following). So _if_ the code in find-dired should be changed, then it seems likely that the one in find-lisp should be changed too, although I did not check this. Quoted from find-lisp.el, starting at line 191: ;; Most of this is lifted from find-dired.el ;; (defun find-lisp-find-dired-internal (dir file-predicate directory-predicate buffer-name) Run find (Lisp version) and go into Dired mode on a buffer of the output. (let ((dired-buffers dired-buffers) Sincerely, Luc. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
Could you provide a self-contained description of what the issue is? I don't know what's to cover that hasn't already been said: I didn't ask for anything that hasn't already been said. I asked for a self-contained description of what has been said. The thread is only about two days old. I cannot remember the reason in 1998 for binding dired-buffers. But it looks like the goal was to prevent these find-dired buffers from being included in that list. Probably because there was something that did not work right if they were included in that list. I can guess that much. Perhaps the thing that did not work is what you are fixing now. I'm not fixing anything for *Find* buffers, as Luc says, I'm proposing to revert your change. However, _after_ your change dired-internal-do-deletions was changed to use dired-buffers through dired-fun-in-all-buffers (so that all dired buffers got updated). This change was also made by you, but four years later (14-Mar-02). I think my change won't make things worse, probably better. If it's wrong, and people are using it, that presumably should get picked up in the pretest. Shall I install my patch? Nick ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: M-x locate regression
The only additional thing I could find that might be relevant to the present discussion is that find-lisp.el contains code completely similar to the one in find-dired (see line 191 and following). So _if_ the code in find-dired should be changed, then it seems likely that the one in find-lisp should be changed too, although I did not check this. Quoted from find-lisp.el, starting at line 191: Can you get find-lisp-find-dired to work? It requires dired: Symbol's value as variable is void: dired-buffers doesn't like some input: Find files in directory: ~/emacs/lisp/progmodes/ Matching regexp: gud.el gives Wrong type argument: number-or-marker-p, nil (even if I've misunderstood the arguments it shouldn't give an error, gud\\.el gives an empty buffer) and I can't get it to list any files in the buffer. Nick ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
