Re: Bold font hides end of previous character
On 3/26/07, Lennart Borgman [EMAIL PROTECTED] wrote: See the attached image. Completion is after o. (Which looks like c.) Do you have ClearType on? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: New Emacs pretest
Simon Leinen skrev: From: Chong Yidong [EMAIL PROTECTED] I have rolled the 22.0.96 pretest tarball. The pretest works mostly perfectly for me on Solaris/SPARC, see below for the exception. It builds cleanly (make bootstrap) on the following configurations: Solaris 11 pretest (snv_57) Sun Studio 11 compilers ./configure --without-gcc --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-gtk --enable-font-backend --with-xft both 64- and 32-bit mode Solaris 9 Sun Studio 10 compilers ./configure --without-gcc --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-x-toolkit=lucid 32-bit mode only Minor issue: When I compile a 64-bit version using the older Sun compiler, there is a build error in the bootstrap phase when bytecomp.el is compiled. I assume this is a problem with the old Sun compiler. Major issue: The Gtk version works fine when I display locally on the Sun's X server. But when I try to run it in graphics mode to my Linux laptop's X11 server, it issues a warning about a missing theme engine and crashes. Here is a GDB backtrace: The backtrace is very far inside cairo and Gtk+, so I doubt Emacs can do anything about it. Do you have any X11 extension on the Sun that you don't have on the laptop? You can use xdpyinfo to get a list of extensions. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: New Emacs pretest
Simon Leinen skrev: From: Chong Yidong [EMAIL PROTECTED] I have rolled the 22.0.96 pretest tarball. The pretest works mostly perfectly for me on Solaris/SPARC, see below for the exception. It builds cleanly (make bootstrap) on the following configurations: Solaris 11 pretest (snv_57) Sun Studio 11 compilers ./configure --without-gcc --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-gtk --enable-font-backend --with-xft both 64- and 32-bit mode Solaris 9 Sun Studio 10 compilers ./configure --without-gcc --with-xpm --with-jpeg --with-tiff --with-gif --with-png --with-x-toolkit=lucid 32-bit mode only Minor issue: When I compile a 64-bit version using the older Sun compiler, there is a build error in the bootstrap phase when bytecomp.el is compiled. I assume this is a problem with the old Sun compiler. Major issue: The Gtk version works fine when I display locally on the Sun's X server. But when I try to run it in graphics mode to my Linux laptop's X11 server, it issues a warning about a missing theme engine and crashes. Here is a GDB backtrace: What version of cairo do you have? The new 1.4.2 release fixes 6 crash-related bugs. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Fancy diary display bug
1. Write to your home directory a file named diary containing a valid diary entry dated within a week from today but not today. 2. Let your ~/.emacs file contain only the lines within the following boxquote: ,[ ~/.emacs ] | (diary) | (custom-set-variables | '(diary-display-hook (quote (fancy-diary-display))) | '(number-of-diary-entries 7) | ) ` 3. Start Emacs without any command line arguments. The diary entry is not displayed. If you comment out the diary-display-hook sexp from ~/.emacs and start Emacs again, then the diary entry is displayed (using simple instead of fancy diary display). Alternatively, if you keep the diary-display-hook with fancy-diary-display and add a diary entry dated today, then when you start Emacs again, both diary entries are shown with fancy diary display. In GNU Emacs 22.0.96.3 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-03-21 on escher Windowing system distributor `The X.Org Foundation', version 11.0.70199902 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: Group Minor modes in effect: gnus-topic-mode: t gnus-undo-mode: t tabbar-mwheel-mode: t tabbar-mode: t recentf-mode: t display-time-mode: t show-paren-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 unify-8859-on-encoding-mode: t utf-translate-cjk-mode: t auto-compression-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: identity Recent input: - d C-w C-s help-echo select-window help-echo help-echo down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 C-c , C-c j i n i C-g C-c r i n i return down-mouse-2 mouse-2 down-mouse-2 mouse-2 down-mouse-1 mouse-movement mouse-movement drag-mouse-1 down-mouse-3 mouse-3 C-x s y left C-x C-e S-right C-x k return C-x k return C-c r d i return C-c , j d i tab a tab return down-mouse-4 mouse-4 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 down-mouse-1 mouse-1 C-c , j return down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 help-echo f3 select-window select-window down-mouse-5 mouse-5 down-mouse-5 mouse-5 select-window C-c , j f a n tab d tab return down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 select-window C-x o C-s n u C-g down down down down down down down next up down-mouse-5 mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 down-mouse-5 mouse-5 down-mouse-1 mouse-movement drag-mouse-1 down-mouse-1 mouse-1 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 down-mouse-4 mouse-4 down-mouse-4 mouse-4 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 select-window down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 down-mouse-5 mouse-5 double-down-mouse-5 double-mouse-5 down-mouse-4 mouse-4 double-down-mouse-4 double-mouse-4 f1 help-echo select-window help-echo help-echo select-window help-echo help-echo help-echo M-x g u return J j y down down down down down down down down down down down down up up M-g return return C-s C-q C-j SPC . next prior home C-s d i a r y C-s C-s C-s C-a C-s C-s C-s C-s down up down SPC f1 C-s C-s C-a right SPC down SPC down down SPC down down up SPC down SPC down down down SPC down SPC down down SPC C-x 1 C-s C-s right SPC C-x 1 C-s C-s C-s left SPC C-s C-s C-s C-s f1 C-a end Q y M-x r e p o tab r tab return Recent messages: Loading gnus-cite...done Parsing BBDB... (frobnicating...done) Mark saved where search started Loading flow-fill...done Auto-saving...done Mark saved where search started [3 times] Mark set Discard changes to this group and exit? (y or n) Making completion list... Loading emacsbug...done ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
- Original Message - From: Juanma Barranquero [EMAIL PROTECTED] Date: Monday, March 26, 2007 11:47 am Subject: Re: Bold font hides end of previous character On 3/26/07, Lennart Borgman [EMAIL PROTECTED] wrote: See the attached image. Completion is after o. (Which looks like c.) Do you have ClearType on? Yes, but it still may be a problem with the KVM switch again. Just checked on another display and I do not see that problem there. (However later is w2k and the one where I see the problem is XP.) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: .gif image fails to display correctly
On 3/22/07, Kim F. Storm [EMAIL PROTECTED] wrote: Chong Yidong [EMAIL PROTECTED] writes: Animated gifs aren't supported in Emacs. Mine does :-) ;;; animage.el --- animated image API That's quite nice, but it doesn't work on the high-colour image either. Each frame is cleared before displaying the next. Also, even after killing the image buffer, Emacs continues to use all available CPU time. Shouldn't killing the buffer stop the animation loop from running? And: are you looping all animated gifs? Some aren't supposed to loop, I think. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
Juanma Barranquero wrote: On 3/26/07, LENNART BORGMAN [EMAIL PROTECTED] wrote: Do you have ClearType on? Yes Does it happen also with ClearType off? (I think you could've tried this without me asking it ;-) Ehum, no. I thought there was no use in trying that, but no, it does not happen with ClearType off. So now I have some reasons having ClearType on and at least one having it off ;-| but it still may be a problem with the KVM switch again. Do you mean this: http://en.wikipedia.org/wiki/KVM_switch? Yes. Just checked on another display and I do not see that problem there. (However later is w2k and the one where I see the problem is XP.) So you didn't really check on another display, but another computer setup... And AFAIK, W2K does not support ClearType. Yes, a totally different setup. No ClearType, no KVM, w2k. Does it happen with the stock CVS Emacs too? Five months ago I committed a patch from Ben North that could be related (Ben's patch definitely fixed a problem with bold faces in ClearType-enabled Windows, BTW). Yes, it happens with the stock CVS Emacs too. (I always - tbh nearly - with the stock CVS Emacs first. Even if I see no reason that there should be any difference.) 2006-10-27 Ben North [EMAIL PROTECTED] (tiny change) * w32term.c (x_draw_glyph_string_foreground): Set background mode to TRANSPARENT before using overstrike to simulate bold faces. * xfaces.c (best_matching_font): Fix logic to decide whether to use overstriking to simulate bold-face (it was reversed). CVS Emacs from 2007-03-21. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
On 3/26/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Ehum, no. I thought there was no use in trying that Oh, of course, I asked about ClearType because it obviously had no relation whatsoever... :) So now I have some reasons having ClearType on and at least one having it off ;-| There are issues with ClearType; see for example this item from admin/FOR-RELEASE: ** Drew Adams 12 Aug bug rpt: overlay display artifact: trace left behind Windows only bug. Bug appears only when Cleartype enabled, probably related to the hack introduced on 2005-07-01 to fix some other Cleartype problem. In fact, your problem could be related to the original problem fixed by Jason's original patch of 2005-07-01. BTW, what font are you using in your tests? Or does it happen with any font? Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
Juanma Barranquero wrote: There are issues with ClearType; see for example this item from admin/FOR-RELEASE: ** Drew Adams 12 Aug bug rpt: overlay display artifact: trace left behind Windows only bug. Bug appears only when Cleartype enabled, probably related to the hack introduced on 2005-07-01 to fix some other Cleartype problem. Yes, I have seen some traces of background coloring remaining on the screen, but I wonder whether that is an overlay only thing. I will try to observe it again. BTW, what font are you using in your tests? Or does it happen with any font? The default. I have never tried changing font, actually. If you have any suggestions for testing then please point me to some quick recipe for changing fonts to. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
On 3/26/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, I have seen some traces of background coloring remaining on the screen, but I wonder whether that is an overlay only thing. What do you mean with an overlay only thing? That only happens with overlays? The default. What is the default font? I have never tried changing font, actually. If you have any suggestions for testing then please point me to some quick recipe for changing fonts to. Try the dejavu fonts. They're quite nice. Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
Juanma Barranquero wrote: On 3/26/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: Yes, I have seen some traces of background coloring remaining on the screen, but I wonder whether that is an overlay only thing. What do you mean with an overlay only thing? That only happens with overlays? I just read citation of the bug report you made: ** Drew Adams 12 Aug bug rpt: OVERLAY display artifact: trace left behind The default. What is the default font? -outline-Courier New-normal-r-normal-normal-13-97-96-96-c-*-iso8859-1 I have never tried changing font, actually. If you have any suggestions for testing then please point me to some quick recipe for changing fonts to. Try the dejavu fonts. They're quite nice. Ok, I have downloaded and installed the Dejavu LGC TT fonts. But what do I do now? In Emacs on w32? ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Bug in facemenu?
I just tried from the menus Edit - Text Properties - Face - Italic This is entry is enabled even when fontification-functions is non nil in the buffer. That seems a bit too optimistic to me. In GNU Emacs 22.0.96.1 (i386-mingw-nt5.1.2600) of 2007-03-21 ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
font-lock bug in cc-mode (was: this is a bug?)
[ Added meaningful subject and redirected to appropriate mailing-list. Alin, please be careful about those things. Using M-x report-emacs-bug takes care of the second point and is generally recommended. I also added bug-cc-mode in Cc. ] I report again, becuase this bug was ignored. I rewrite it into an easier to reproduce form: 1. Emacs -Q 2. M-. Lisp_Type RET Select then the path to your TAGS file of your emacs. The first 4 members of this enumeration are listed in yellow color to me . The last 4 members in black color . An easier way to reproduce: emacs -Q +132 .../emacs/src/lisp.h Inserting space + undoing will sort it out, so it might be triggered by the chunking done by jit-lock. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Regular expression too big
hey stefan, thank you for your response. it was helpful to know that this isn't going to be an easy fix. we're already using regexp-opt, which is supposed to optimize and shrink the regex. i can anticipate the regexes getting much much bigger, and i'm keen to avoid having to dig into the guts of the regexp C code, so i think we're going to figure out a way to do our regexing outside of emacs. thanks again, greg Stefan Monnier wrote: I'm writing a new mode for Emacs that involves a massive regular expression, auto-generated from a list of files in the directory. If the number of files is too large (c. 1500, depending on the length of the filenames), then the regular expression that gets built is too big, and Emacs flashes up an error: Invalid regexp: regular expression too big. So it looks as though this is a known issue, and that the solution was just to hardcode a ceiling on regexp size. This is a showstopper for us. At the moment, the only workaround that we can think of would be to chop the regexp into multiple pieces, run them separately, and then somehow combine the results. As you can imagine, this is going to be much slower, and much much uglier. Is there anything that can be done to extend the allowed size of the regexp? Well, you can rewrite regexp.c if you want. Currently it works by compiling your regexp to a non-deterministic (i.e. backtracking) byte-code machine, which uses 2-byte offsets to jump around, so it makes it difficult to write regexps much larger than about 32KB (after compilation). There could be various ways to change regexp.c so as to allow larger regexps. One would be to make the too large check more precise (right now, I believe it just complains as soon as the whole compiled regexp exceeds 32KB, but we could allow larger ones, as long as all offsets fit within the ±32KB limit), or one could add long jumps with 4byte offsets and try to insert them were needed, or one could make all offsets 4bytes, or one could rewrite regexp.c completely (ideally just adapting GNU libc's regexp engine or some other). But maybe you can circumvent the limit without removing it. Tell us more about your regexps: maybe we can optimize them. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Make install cannot handle directory names with a SPC in it
Chong Yidong wrote: This seems to be a limitation of the venerable mkinstalldirs program. I wonder how other projects handle this problem? We could replace the mkinstalldirs in Emacs with one from a recent automake, which seems to have addressed this issue. But I think that trying to use paths with spaces will still not work, because there are many many places in the Emacs Makefile where paths are used without quoting. So paths with spaces will be split by the build process before even being passed to mkinstalldirs. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Regular expression too big
Thank you for your response. It was helpful to know that this isn't going to be an easy fix. We're already using regexp-opt, which is supposed to optimize and shrink the regex. In that case I don't think there's much you can do (you may be able to tweak regexp-opt to reduce the compiled regexp size, but you'll just get a few percent further, which probably isn't of any use to you). I can anticipate the regexes getting much much bigger, and I'm keen to avoid having to dig into the guts of the regexp C code, so I think we're going to figure out a way to do our regexing outside of Emacs. Looks like your best/only option. Of course you may also be able to do it all in Emacs by not using regexps. E.g. if your code looks anything like (re-search-forward (concat foo (regexp-opt mighty-big-list) bar)) you may be able to use (while (and (re-search-forward (concat foo\(.*\)bar)) (not (member (match-string 1) mighty-big-list And of course, use a hash-table rather than a list. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Regular expression too big
thanks, stefan. that makes sense. but it would need to run within the fontification function, so we'd like it to be speedy... g Stefan Monnier wrote: Thank you for your response. It was helpful to know that this isn't going to be an easy fix. We're already using regexp-opt, which is supposed to optimize and shrink the regex. In that case I don't think there's much you can do (you may be able to tweak regexp-opt to reduce the compiled regexp size, but you'll just get a few percent further, which probably isn't of any use to you). I can anticipate the regexes getting much much bigger, and I'm keen to avoid having to dig into the guts of the regexp C code, so I think we're going to figure out a way to do our regexing outside of Emacs. Looks like your best/only option. Of course you may also be able to do it all in Emacs by not using regexps. E.g. if your code looks anything like (re-search-forward (concat foo (regexp-opt mighty-big-list) bar)) you may be able to use (while (and (re-search-forward (concat foo\(.*\)bar)) (not (member (match-string 1) mighty-big-list And of course, use a hash-table rather than a list. Stefan -- --- Greg Detre cell: 617 642 3902 email: [EMAIL PROTECTED] web: http://www.gregdetre.co.uk ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Toolbar and info mode (and others)
On Mon, Mar 26 2007, Richard Stallman wrote:
* Maybe we should reduce the number of toolbar buttons in the
default configuration.
I think the current icons are quite reasonable for an editor (and
comparable to gedit or kwrite).
Except for...
tool-bar help: popping up a menu is not very useful for a toolbar
icon (exception: context menus with mouse-3). [1]
... and maybe...
tool-bar customize: I don't think that opening the top level
customization group is frequently used. [2]
* If we assume that the global toolbar buttons are in order
of decreasing importance, we can discard the last few
so as to make room for all the buffer-specific toolbar buttons.
I don't think that icons are or should be ordered by importance.
Related actions should be grouped ({new file, open file, ...}, {save,
save as}, {cut, copy, paste}, ...) and there are some conventions in
the order of the groups as well.
At least save-buffer, write-file, undo, cut, paste are
neither important nor useful (IMHO) in info mode.
That is true for Info mode, but may not be true for other specialized
modes. But it suggests an idea: to have a feature for the mode to
specify which buttons to retain from the global toolbar, or which
buttons to discard.
There's such code in Gnus' gmm-utils.el[3]. In most Gnus modes, we
use a complete new tool bar. But in message mode, we retain some
editing icons and remove other icons:
(defcustom message-tool-bar-zap-list
'(new-file open-file dired kill-buffer write-file
print-buffer customize help) ...)
An advantage of the code in gmm-utils.el is that the user can
easily customize the tool bars.
All this is for after the release.
Of course.
Bye, Reiner.
[1] In Gnus, the help button opens a mode specific info node:
,[ f1 v gnus-info-nodes RET ]
| gnus-info-nodes is a variable defined in `gnus'.
| Its value is
| ((gnus-group-mode (gnus)Group Buffer)
| (gnus-summary-mode (gnus)Summary Buffer)
| (gnus-article-mode (gnus)Article Buffer)
| (gnus-server-mode (gnus)Server Buffer)
| (gnus-browse-mode (gnus)Browse Foreign Server)
| (gnus-tree-mode (gnus)Tree Display))
|
| Documentation:
| Alist of major modes and related Info nodes.
`
[2] In Gnus, this icon opens the mode's custom group.
[3]
(defun gmm-tool-bar-from-list (icon-list zap-list default-map)
Make a tool bar from ICON-LIST.
Within each entry of ICON-LIST, the first element is a menu
command, the second element is an icon file name and the third
element is a test function. You can use \\[describe-key]
menu-entry to find out the name of a menu command. The fourth
and all following elements are passed as the PROPS argument to the
function `tool-bar-local-item'.
If ZAP-LIST is a list, remove those item from the default
`tool-bar-map'. If it is t, start with a new sparse map. You
can use \\[describe-key] icon to find out the name of an icon
item. When \\[describe-key] icon shows \tool-bar new-file
runs the command find-file\, then use `new-file' in ZAP-LIST.
DEFAULT-MAP specifies the default key map for ICON-LIST.
...)
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Make install cannot handle directory names with a SPC in it
This seems to be a limitation of the venerable mkinstalldirs program. I wonder how other projects handle this problem? We could replace the mkinstalldirs in Emacs with one from a recent automake, which seems to have addressed this issue. But I think that trying to use paths with spaces will still not work, because there are many many places in the Emacs Makefile where paths are used without quoting. So paths with spaces will be split by the build process before even being passed to mkinstalldirs. That should be fixed as well. Maybe not right now (i.e. can wait after Emacs-22, since those bugs have been with us for ever), but these are bugs. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Regular expression too big
Thanks, Stefan. That makes sense. But it would need to run within the fontification function, so we'd like it to be speedy... Try it. It's not at all obvious to me that performance will be a problem. I'm often surprised at how much work one can do within font-lock without it having any noticeable impact. Stefan ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Regular expression too big
Greg Detre [EMAIL PROTECTED] writes: Looks like your best/only option. Of course you may also be able to do it all in Emacs by not using regexps. E.g. if your code looks anything like (re-search-forward (concat foo (regexp-opt mighty-big-list) bar)) you may be able to use (while (and (re-search-forward (concat foo\(.*\)bar)) (not (member (match-string 1) mighty-big-list And of course, use a hash-table rather than a list. thanks, stefan. that makes sense. but it would need to run within the fontification function, so we'd like it to be speedy... The approach Stefan suggested, using a hash table, may very well be faster than scanning for an enormous regular expression. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: New Emacs pretest
Jan Djärv writes: What version of cairo do you have? The new 1.4.2 release fixes 6 crash-related bugs. According to pkg-config, I run cairo 1.2.4 on both the Solaris 11 system and my Debian GNU/Linux laptop: : [EMAIL PROTECTED]; uname -a SunOS hadron 5.11 snv_57 sun4u sparc SUNW,Sun-Blade-2500 Solaris : [EMAIL PROTECTED]; pkg-config --modversion cairo 1.2.4 : [EMAIL PROTECTED]; uname -a Linux agathe 2.6.20-web100-agathe.1 #1 PREEMPT Mon Feb 26 23:36:24 CET 2007 i686 GNU/Linux : [EMAIL PROTECTED]; pkg-config --modversion cairo 1.2.4 I only get the crashes with the combination of Solaris GNU Emacs 23 prerelease (Gtk version) vs. GNU/Linux X11 server. -- Simon. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
On 3/26/07, Lennart Borgman (gmail) [EMAIL PROTECTED] wrote: I just read citation of the bug report you made: Yes, sorry. -outline-Courier New-normal-r-normal-normal-13-97-96-96-c-*-iso8859-1 I can see the problem with Courier New. It doesn't happen for me with DejaVu. Ok, I have downloaded and installed the Dejavu LGC TT fonts. But what do I do now? In Emacs on w32? What I do is to define a fontset in the registry (HKLM\Software\GNU\Emacs), i.e., an Emacs.Fontset-0 string value with -*-DejaVu Sans Mono-normal-r-normal-*-13-*-*-*-c-*-fontset-dejavu and Emacs.Font = fontset-dejavu Juanma ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Bold font hides end of previous character
Juanma Barranquero wrote: Ok, I have downloaded and installed the Dejavu LGC TT fonts. But what do I do now? In Emacs on w32? What I do is to define a fontset in the registry (HKLM\Software\GNU\Emacs), i.e., an Emacs.Fontset-0 string value with -*-DejaVu Sans Mono-normal-r-normal-*-13-*-*-*-c-*-fontset-dejavu and Emacs.Font = fontset-dejavu Thanks. I do not see the problem with this font either. Now I just have to get used to it... ;-) ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Make install cannot handle directory names with a SPC in it
During 'make isntall' the path name /Library/Application Support is split at the SPC character, so a directory /Library/Application and a local directory ./Support are created. This seems to be a limitation of the venerable mkinstalldirs program. I wonder how other projects handle this problem? Is this a bug in mkinstalldirs? Could it be fixed without changing the interface specs of mkinstalldirs? If so, let's just report it to the developers of mkinstalldirs. It is not urgent that we work around the problem in Emacs before they fix it. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
