CVS emacs app does not open in 10.4.2
This is on a Apple Macintosh computer running system 10.4.2. I get the latest CVS version. I use the commands: ./configure --enable-carbon-app make bootstrap sudo make install This produces a version of emacs that I can run in the terminal app: GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.2.0, X toolkit) of 2005-07-18 on Gilbert-Harmans-Computer.local But when I try to open Emacs.app I get the message: You cannot open the application Emacs because it may be damaged or incomplete Gil -- Gilbert Harman(609) 258-4301 Department of Philosophy Princeton University Princeton, NJ 08544-1006 http://www.princeton.edu/~harman ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Small gaps beside the scrollbar
Jan D. wrote: In order to make resizing consistent, Emacs keeps the scroll bar at the same width as the character width. Can't see how the scrollbar with can be a problem. Ok, Emacs let's the user resize the window (contents of the window) in character units, but a (GNOME) window can have *any* size. Any window can have any size. But to resize in character units you must impose some restrictions. On the X11 level it is not that hard to make the scroll bar have different width. Internally in Emacs it is harder, as there are places that convert to/from pixels simply by multiplying by the column width. But the GTK scroll bars have a fixed width, which only sometimes are the same width as the Emacs character width. Therefore there are gaps. This is not specific to Emacs compiled with GTK support. The standard X Windows scrollbar has the same problem. The Emacs internal (i.e. non-toolkit) scroll bar does not have this problem, but GTK, Xaw and Lesstif/Motif does. If I understand correctly, you say that (with the scrollbar to the left) the distance between the right edge of the left window border and the left edge of the left fringe, which the scrollbar occupies, must be (evenly) divisible by the character width. I don't understand what causes this restriction when Emacs is not run in console mode. Of course the issue has no practical significance, but it sure looks like a bug. August ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock is broken
As you can see, this function sometimes returns non-nil (i.e. it says it's found a match) but with no begin/end of match 0. Is that incorrect? If so, why did it appear to work ok before? Maybe the criterion for a bad match has to be written differently to accord with the practical rules for code that used to work. I'm tempted to just revert my patch, since it causes constant run-time checks and trips up some pre-existing code, only in the hope of occasionally working around some bugs that would need to be fixed anyway. No, don't do that! Let's see if adapting a little is better. Those bugs are rather painful. I've never bumped into this specific form of an infinite non-interruptible computation. So maybe they're painful but they seem to be much more rare than other similar problems not addressed by the patch. The most common such problem by far is when a regexp hits a pathological exponential-matching behavior. I wish we'd fix that one instead. Also, they're only painful because of Emacs's lack of NMI. I'd rather fix that part instead. E.g. when C-g is pressed, record the time, and if a C-g is pressed again 2 seconds later and the first hasn't been processed yet, then ignore the inhibit-quit flag (i.e. set it back to nil). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Small gaps beside the scrollbar
If I understand correctly, you say that (with the scrollbar to the left) the distance between the right edge of the left window border and the left edge of the left fringe, which the scrollbar occupies, must be (evenly) divisible by the character width. I don't understand what causes this restriction when Emacs is not run in console mode. What causes this restriction is nothing else than old code left over from Emacs-20 where only fixed-width chars were supported. IIRC Kim plans to get rid of those restrictions in Emacs-unicode (which may be released at some point in the distant future as Emacs-23). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Multiple uses of code-conversion-work buffer
Thank you for finding the cause of this bug. I've just installed the attached change. Could you please try it? It seems to have fixed the problem, thank you. It was clearly non-deterministically reproducible, but it occurred fairly frequently and hasn't occurred again since, so it's probably fixed). Stefan ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
scroll-up makes no progress on overtall lines
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: Hi Kim, when I use preview-latex to generate a line that is taller than the buffer and then repeatedly press next, the screen position goes through a somewhat strange circular pattern, but never manages to scroll through it. scroll-down, previous-line and next-line all manage to make it through the image, in contrast. If you need a particular example, just holler. In GNU Emacs 22.0.50.13 (i686-pc-linux-gnu, GTK+ Version 2.6.8) of 2005-07-14 on lola X server distributor `The X.Org Foundation', version 11.0.60802000 configured using `configure '--prefix=/usr/local/emacs-21' '--with-gtk' '--without-toolkit-scroll-bars'' 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: PDFLaTeX Minor modes in effect: reftex-mode: t TeX-PDF-mode: t file-name-shadow-mode: t desktop-save-mode: t iswitchb-mode: t minibuffer-electric-default-mode: t mouse-wheel-mode: t tooltip-mode: t auto-compression-mode: t menu-bar-mode: t blink-cursor-mode: t unify-8859-on-decoding-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t line-number-mode: t next-error-follow-minor-mode: Fol Recent input: next next next next next next next next next next next prior prior prior prior next next next next down prior prior prior next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next next help-echo down-mouse-1 help-echo mouse-movement drag-mouse-1 next next next next next next next next next next next next next next next next next next next M-x r e p o r t - e m a tab return Recent messages: Quit [2 times] Wrote /tmp/junk.tex Applying style hooks... Loading /usr/local/emacs-21/share/emacs/site-lisp/auctex/style/article.elc...done Applying style hooks... done Sorting environment... Removing duplicates... done Wrote /home/dak/range.tex call-interactively: Beginning of buffer [3 times] Loading emacsbug...done -- David Kastrup, Kriemhildstr. 15, 44793 Bochum ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock is broken
Stefan Monnier [EMAIL PROTECTED] writes: Make a buffer with this content: In-reply-to: foo bar of Fri, 15 Jul 2005 20:31:33 EDT (2 lines only) Then M-x mh-letter-mode M-x font-lock-fontify-buffer You get: font-lock-default-fontify-region: Wrong type argument: number-or-marker-p, nil This is introduced by my recent change to font-lock.el which checks that we do not get stuck in an empty match. Problem is that it bumps into a minor bug in mh-font-lock-field-data: (defun mh-font-lock-field-data (limit) ... (if (and field (mh-letter-skipped-header-field-p field)) (set-match-data nil) (set-match-data (list data-begin data-end data-begin data-end))) (goto-char (if (equal point data-end) (1+ data-end) data-end)) t))) As you can see, this function sometimes returns non-nil (i.e. it says it's found a match) but with no begin/end of match 0. Thanks for pointing this out. That should make it easy for us to fix. -- 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-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
transient lossage: I-search
Sorry I have no patch but for the record, here's the bug. Consider three states of searching ... 0) unknown message = I-search: 1) winning message = I-search: 2) losing message = Failing I-search: ... alas, unknown sometimes displays a losing message. This is usually invisible because the message rarely appears long enough to see except in huge buffers: TypeSee === ^X ^R /usr/local/bin/emacs Find file read-only: /usr/local/bin/emacs -- or any enormous file RET Note: file is write protected -- be patient ... Note: file is write protected -- screen fills, after a wait ESC ^R \ ' Failing regexp I-search backward: \'-- good losing message ^S Failing regexp I-search: \' -- BAD! THIS IS UNKNOWN! ... Regexp I-search: \' -- good winning message, after a wait ... take care to type `quote' and not `back quote' while replicating the disconcerting false losing message which eventually goes away by itself when the search wins. Took too long to write this, time is up now. I-search being so hairy, this may never get fixed. Peace --Devon PS: I also tested this on an out-of-the-box emacs 21.3 with squeaky clean command $ emacs -nw -q --no-site-file In GNU Emacs 21.3.50.8 (i386-unknown-freebsd4.10, X toolkit, Xaw3d scroll bars) of 2005-02-13 on grant.org configured using `configure 'CC=gcc'' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: nil locale-coding-system: nil default-enable-multibyte-characters: t Major mode: RMAIL Minor modes in effect: display-time-mode: t global-font-lock-mode: t font-lock-mode: t unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t temp-buffer-resize-mode: t line-number-mode: t transient-mark-mode: t Recent input: k RET C-x k e m SPC C-x C-r ESC p RET C-x k RET C-g C-g C-x C-r ESC p RET ESC C-s \ ' C-r ESC ESC C-s \ ' C-r ESC C-x k RET C-x C-z C-x C-f ESC p C-g C-g C-x C-r ESC p RET ESC C-s \ ' C-r C-e ESC C-r \ ' ESC ESC ESC C-s \ ` C-r C-x k RET C-z C-c C-z C-g C-x C-z RET ESC [ 1 9 ~ ESC x r e p o r t SPC e m SPC SPC RET Recent messages: Note: file is write protected Mark saved where search started Mark set [2 times] Mark saved where search started Quit Getting mail from /var/mail/devon... Counting new messages...done (1) Saving file /home1/devon/RMAIL... Wrote /home1/devon/RMAIL 1 new message read ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
RE: Tramp is keeping ange-ftp from finding .netrc
Michael, Yes it did work. Thanks. -Original Message- From: Michael Albinus [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 19, 2005 3:54 PM To: [EMAIL PROTECTED] Cc: emacs-pretest-bug@gnu.org Subject: Re: Tramp is keeping ange-ftp from finding .netrc [EMAIL PROTECTED] writes: I need to use a .netrc file for several reasons. But I keep running into a problem where ange-ftp fails to read the .netrc. Could you, please, try the following patch: magdalene:~/src/emacs/lisp/net diff -c tramp.el.orig tramp.el *** tramp.el.orig 2005-07-19 22:50:45.0 +0200 --- tramp.el2005-07-19 22:51:23.0 +0200 *** *** 4824,4835 (defun tramp-completion-handle-expand-file-name (name optional dir) Like `expand-file-name' for tramp files. (let ((fullname (concat (or dir default-directory) name))) ! (tramp-drop-volume-letter ! (if (tramp-completion-mode fullname) !(tramp-run-real-handler ! 'expand-file-name (list name dir)) !(tramp-completion-run-real-handler ! 'expand-file-name (list name dir)) ;;; Internal Functions: --- 4824,4834 (defun tramp-completion-handle-expand-file-name (name optional dir) Like `expand-file-name' for tramp files. (let ((fullname (concat (or dir default-directory) name))) ! (if (tramp-completion-mode fullname) ! (tramp-run-real-handler !'expand-file-name (list name dir)) ! (tramp-completion-run-real-handler !'expand-file-name (list name dir) ;;; Internal Functions: Richard Bielawski Best regards, Michael. ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: italic fonts: glyphs overwrite each other
On Tue, 19 Jul 2005 12:50:06 +0100, David Reitter [EMAIL PROTECTED] said: When using an italic font (tested with lucida grande fontset, variable-width), glyphs overwrite parts of previous glyphs. It looks like single glyphs are shown on the screen with a white background color, on top of the previous text. Upon redisplay, everything looks good, which means that this only occurs after typing text as opposed to pasting, or making it italic after typing. Such a chip in overhangs may occur when there is no overhangs in the reported metric. I guess there's no right overhang in the `h' glyph if mac-allow-anti-aliasing is set to nil. So the problem is the renderer puts some dots outside the reported bounding box when Quartz 2D anti-aliasing for QuickDraw Text is enabled. YAMAMOTO Mitsuharu [EMAIL PROTECTED] ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: font-lock is broken
Bill Wohler [EMAIL PROTECTED] writes: Stefan Monnier [EMAIL PROTECTED] writes: Make a buffer with this content: In-reply-to: foo bar of Fri, 15 Jul 2005 20:31:33 EDT (2 lines only) Then M-x mh-letter-mode M-x font-lock-fontify-buffer You get: font-lock-default-fontify-region: Wrong type argument: number-or-marker-p, nil This is introduced by my recent change to font-lock.el which checks that we do not get stuck in an empty match. Problem is that it bumps into a minor bug in mh-font-lock-field-data: (defun mh-font-lock-field-data (limit) ... (if (and field (mh-letter-skipped-header-field-p field)) (set-match-data nil) (set-match-data (list data-begin data-end data-begin data-end))) (goto-char (if (equal point data-end) (1+ data-end) data-end)) t))) As you can see, this function sometimes returns non-nil (i.e. it says it's found a match) but with no begin/end of match 0. Thanks for pointing this out. That should make it easy for us to fix. Thanks to Satyaki Das, this has been fixed in the MH-E repository. It will appear in the Emacs repository in the next week or so when I transition the MH-E project to use the Emacs repository as its master. -- 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-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
