Re: tool-bar doesn't work on the trunk with (default) GTK build
Richard Stallman skrev: Well, at least I now can see it too. Focus is definitly shifted away, but where and why? I'll have to come back to this. Could you please put a note in FOR-RELEASE so we will know this is still pending? Done. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
Nick Roberts skrev: > > > > Dou you have click to focus or focus follows mouse or something else? Do > you > > use metacity? It sounds like after the first click, GUD does something > that > > moves the focus away from the tool bar. > > I'm fairly sure it's metacity. I just use the default desktop which is Gnome. > I don't even know how to change the window manager. Metacity it is then :-) > > I use click to focus (default again) but if I change to focus follows mouse > then I can indeed click on a toolbar button again without moving it away > first. > There's still something a bit odd though because the highlighting around the > button still disappears after the first click. This is not the case if I look > at another GTK application with a toolbar, e.g., Firefox. Well, at least I now can see it too. Focus is definitly shifted away, but where and why? I'll have to come back to this. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
Nick Roberts skrev: > > > Does the clicks show up in C-h l? That > is > > if you do two rapid clicks, do you get two tool bar events or just one? > > Interestingly if they are rapid I do get two tool bar events and the button > remains active. However, if I just do one click the highlighting around the > button disappears and I can't activate it again without moving it away first. > > Does anybody else see this? (I'm using Ubuntu 7.4, if that's relevant) You mean 7.04 I guess? > > It looks to me like some kind of timing problem and presumably it doesn't > respond nicely to running an underlying asynchronous process. > Dou you have click to focus or focus follows mouse or something else? Do you use metacity? It sounds like after the first click, GUD does something that moves the focus away from the tool bar. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
I can't reproduce this on HEAD or EMACS_22_BASE. What version of Gtk do you have? Does the clicks show up in C-h l? That is if you do two rapid clicks, do you get two tool bar events or just one? Jan D. Nick Roberts skrev: > > > > > I don't think this is the right fix. On some of the GUD toolbar > > > > > icons in a debug session, if I don't move the mouse pointer off the > > > > > tool-bar button and click again, e.g., next, step nothing happens. > I > > > > > have to move the pointer away and back again to activate the button. > > > > > Oddly, there doesn't seem to be a problem with other buttons like > > > > > Info-next in Info. > > > > > > > > > > > > > That is another bug. It only shows up in Gnus. > > > > > > The report above demonstrates that it doesn't only show up in Gnus. Does > > > it occur on EMACS_22_BASE with a GTK build too? I find it quite > > > inconvenient and a reason to revert to the Lucid toolkit. Are you saying > > > that it can't be fixed? > > > > > > > No, I'm not saying it can't be fixed. Which GUD toolbar icons have this > bug? > > In addition to the ones I've already mentioned above (we seem to have a very > poor line!), gud-stepi, gud-nexti, perhaps gud-finish but not gud-up or > gud-down. It looks like the ones which restart execution of the program being > debugged. Perhaps the problem in Gnus involves another process too. > > ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
Reiner Steib skrev: On Sat, Aug 04 2007, Jan Djärv wrote: Nick Roberts skrev: On some of the GUD toolbar icons in a debug session, if I don't move the mouse pointer off the tool-bar button and click again, e.g., next, step nothing happens. I have to move the pointer away and back again to activate the button. Oddly, there doesn't seem to be a problem with other buttons like Info-next in Info. That is another bug. It only shows up in Gnus. What is the bug showing up in Gnus? Sorry, I meant GUD. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
Nick Roberts skrev: > > > Now fixed, please test it. > > > > I don't think this is the right fix. On some of the GUD toolbar icons in > > a debug session, if I don't move the mouse pointer off the tool-bar button > > and click again, e.g., next, step nothing happens. I have to move the > > pointer away and back again to activate the button. Oddly, there doesn't > > seem to be a problem with other buttons like Info-next in Info. > > > > That is another bug. It only shows up in Gnus. The report above demonstrates that it doesn't only show up in Gnus. Does it occur on EMACS_22_BASE with a GTK build too? I find it quite inconvenient and a reason to revert to the Lucid toolkit. Are you saying that it can't be fixed? No, I'm not saying it can't be fixed. Which GUD toolbar icons have this bug? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
Nick Roberts skrev: Jan Djärv writes: > Nick Roberts skrev: > > If I click on tool-bar buttons e.g. when the *scratch* buffer is current, I > > get messages like: > > > > is undefined > > is undefined > > > > I don't know if this is particular to the trunk, using GTK, or my build. > > > > > > Now fixed, please test it. I don't think this is the right fix. On some of the GUD toolbar icons in a debug session, if I don't move the mouse pointer off the tool-bar button and click again, e.g., next, step nothing happens. I have to move the pointer away and back again to activate the button. Oddly, there doesn't seem to be a problem with other buttons like Info-next in Info. That is another bug. It only shows up in Gnus. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: tool-bar doesn't work on the trunk with (default) GTK build
Nick Roberts skrev: > If I click on tool-bar buttons e.g. when the *scratch* buffer is current, I > get messages like: > > is undefined > is undefined > > I don't know if this is particular to the trunk, using GTK, or my build. > > Now fixed, please test it. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs trunk needs to increase PURESIZE
Tassilo Horn skrev: Katsumi Yamaoka <[EMAIL PROTECTED]> writes: The value of PURESIZE needs to be increased for at least the Fedora 7 system: [...] Dumping under names emacs and emacs-22.1.50.1 emacs:0:Pure Lisp storage overflow (approx. 1120140 bytes needed) 144 pure bytes used [...] It's the same for my Gentoo GNU/Linux box. Ditto Fedora 7. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Crash: XSetWMIconName, x_set_name_internal, prepare_menu_bars
YAMAMOTO Mitsuharu skrev: >> On Fri, 01 Jun 2007 18:42:57 -0400, Chong Yidong <[EMAIL PROTECTED]> >> said: > >> I looked at the GTK+ sources. Apparently, if we don't set >> WM_ICON_NAME ourselves, gtk_window_set_icon_name sets WM_ICON_NAME >> for us. So I think we are perfectly safe. > No, I don't think it does, from the Gtk+ documentation: "Sets the icon for the window from a named themed icon. See the docs for GtkIconTheme for more details. Note that this has nothing to do with the WM_ICON_NAME property which is mentioned in the ICCCM." What we could use is gdk_window_set_icon_name (Note gdk_, not gtk_). It is available in Gtk+ 2.4 and onwards, 2.4 is the minimum Emacs require. But this function blindly assumes the name passed is in UTF-8 and sets both _NET_WM_ICON_NAME and WM_ICON_NAME to that. x_set_name_internal at least tries to decode things correctly for the window manager. > But now we can't set the icon title separately from the frame title > using the `icon-name' frame parameter on GTK+ builds. > > `icon-name' > The name to use in the icon for this frame, when and if the icon > appears. If this is `nil', the frame's title is used. > > Even with non-GTK+ builds, setting this parameter might not affect the > icon title for some window managers. But at least, CDE on Solaris > respects this. > > Maybe we can use gtk_window_set_icon_name for this purpose, but it is > available only on GTK+ 2.6 and later, so some check will be necessary > and it is definitely after-the-release matter. > > So I propose undoing the latest change for x_set_name_internal for > now. The reason for using gtk functions (gtk_window_set_title) is that the information is saved in Gtk+, and also that the function sets _NET_WM_ICON_NAME. But it also sets WM_ICON_NAME, but with a possible wrong encoding, so we call XSetWMIconName to fix that. Come to think of it, all builds should set _NET_WM_ICON_NAME to the UTF-8 encoded icon name. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: no device event controller found
Gary Lawrence Murphy skrev: > 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: > > This is new with the emacs that I built from the CVS sources a few days ago, > I think it may be related to the gnus agent doing background polling of the > IMAP host, but I periodically get the following message in the console > window: > > ** (emacs-22-1-50:2180): WARNING **: failure: no device event controller > found. > This looks like an ALSA (i.e. sound) message. Does alsaplay work on your system? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs deadlock: malloc inside signal handler inside malloc ...
Joe Wells skrev: Dear Emacs gurus, I just observed an interesting Emacs deadlock. It is for a 2-year-old CVS version, but it seems like it is worth mentioning in case the design still allows this deadlock. There has been work done in this area since then. As with all deadlocks, it is not that easy to reproduce, but no bug reports about this has been seen lately, so I think it is fixed. I strongly suggest you upgrade your version, many bug fixes has been made in 2 years. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: emacs-22.0.99 configure problem
Hiroshi Fujishima skrev: I run ./configure with FreeBSD 6.2 machine. It outputs following error: % ./configure as_func_failure succeeded. as_func_failure succeeded. No shell found that supports shell functions. Please tell [EMAIL PROTECTED] about your system, including any error possibly output before this message checking build system type... i386-unknown-freebsd6.2 checking host system type... i386-unknown-freebsd6.2 It seems that ./configure use /usr/local/bin/zsh... % ps PID TT STAT TIME COMMAND 26328 p0 Ss 0:00.06 -zsh (zsh) 42802 p0 T 0:00.15 /usr/local/bin/zsh ./configure 43323 p0 T 0:00.00 /usr/local/bin/zsh ./configure 43324 p0 T 0:00.00 gcc -o conftest -g -O2 -I/usr/X11R6/include -I/usr/lo 43328 p0 R+ 0:00.00 ps Does it work if you do % /bin/sh configure or % bash configure if you have bash? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Jan Djärv skrev: Richard Stallman skrev: Actually I think I found a safe fix. If there is no negative feedback, I'll add it to HEAD. I'm not sure who decides if it should go to the 22.1 branch. I think it should go in 22.1 as well as in the trunk. Checked in in 22.1 and branch. ^^-- trunk. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Richard Stallman skrev: Actually I think I found a safe fix. If there is no negative feedback, I'll add it to HEAD. I'm not sure who decides if it should go to the 22.1 branch. I think it should go in 22.1 as well as in the trunk. Checked in in 22.1 and branch. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Richard Stallman skrev: I'd say this is a bug in QtCurve. I can not find a way to undo that effect from within Emacs. Apart from the obvious, always update menus deep. But I don't think we want to do that just for one theme. Not that I think it would break anything, it would just make menu bar updating a bit slower. Can you please add an entry to PROBLEMS? Actually I think I found a safe fix. If there is no negative feedback, I'll add it to HEAD. I'm not sure who decides if it should go to the 22.1 branch. I think it is a relative minor issue, even if it is annoying for the people that sees it. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Jan Djärv skrev:
I'd say this is a bug in QtCurve. I can not find a way to undo that
effect from within Emacs. Apart from the obvious, always update menus
deep. But I don't think we want to do that just for one theme. Not
that I think it would break anything, it would just make menu bar
updating a bit slower.
I found an easier way. Can you try the attached patch?
Thanks,
Jan D.
Index: src/gtkutil.c
*** src/gtkutil.c.~1.106.~ 2007-04-22 20:23:08.0 +0200
--- src/gtkutil.c 2007-04-25 20:00:05.0 +0200
***
*** 2192,2198
cl_data,
&group);
! if (item->contents)
{
GtkWidget *submenu = create_menus (item->contents,
f,
--- 2192,2198
cl_data,
&group);
! if (item->contents || menu_bar_p)
{
GtkWidget *submenu = create_menus (item->contents,
f,
***
*** 2479,2486
--- 2479,2490
cl_data,
&group);
+ GtkWidget *submenu = create_menus (NULL, f,
+ select_cb, NULL, highlight_cb,
+ 0, 0, 0, 0, cl_data, 0);
gtk_widget_set_name (w, MENU_ITEM_NAME);
gtk_menu_shell_insert (GTK_MENU_SHELL (menubar), w, pos);
+ gtk_menu_item_set_submenu (GTK_MENU_ITEM (w), submenu);
g_list_free (*list);
*list = iter = gtk_container_get_children (GTK_CONTAINER (menubar));
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Stephen Berman skrev: On Mon, 23 Apr 2007 22:09:36 +0200 Jan Djärv <[EMAIL PROTECTED]> wrote: When Emacs updates the menu bar, it usually just puts empty menus behind the menu bar entries. This is to avoid updating the whole menu tree every time we just change buffer. When we click on the menu bar, Emacs does update the whole menu tree (i.e. updates deep). It seems that QtCurve can not handle non-deep menu bar entries. [...] I'd say this is a bug in QtCurve. I can not find a way to undo that effect from within Emacs. Apart from the obvious, always update menus deep. But I don't think we want to do that just for one theme. Not that I think it would break anything, it would just make menu bar updating a bit slower. Your analysis seems plausible to me, and I agree Emacs shouldn't be changed to accommodate QtCurve. Do you know if the Emacs treatment of updating the menu bar is more or less unique to Emacs? I haven't observed "sticky highlighting" with QtCurve with any other Gtk+ apps under KDE (e.g., Gimp, Eclipse). If it is standard procedure in Gtk+ to always do deep updating of the menu bar, then that could account for the asymmetry (and also for why QtCurve fails to handle the Emacs case). We could for the Gtk+ case add one dummy entry, or perhaps the real tear-off entry will do. I'll try that when I come back to the machine where QtCurve is installed. Emacs treatment is quite unique. Most applications have (mostly) static menu trees that just get initialized once. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Stephen Berman skrev: On Sun, 22 Apr 2007 20:36:31 +0200 Jan Djärv <[EMAIL PROTECTED]> wrote: The GNUS menus are defined with easy-menu, thats about all I can think of that differs from "regular" menus. Can you define a small menu with easy.menu and see if the problem is there then? It turns out the problem is not confined to easymenu: I made the following file, ,[ srb-km.el ] | (define-key global-map [menu-bar SRB] | (cons "SRB" (make-sparse-keymap "SRB"))) ` and then did this: emacs -Q -l srb-km.el which brings up the *scratch* buffer with a menu bar whose first menu is labelled `SRB'. When I move the mouse over this menu bar, menu label SRB, and only this menu label, gets sticky highlighting (again, only with the GTK Style QtCurve under KDE). When Emacs updates the menu bar, it usually just puts empty menus behind the menu bar entries. This is to avoid updating the whole menu tree every time we just change buffer. When we click on the menu bar, Emacs does update the whole menu tree (i.e. updates deep). It seems that QtCurve can not handle non-deep menu bar entries. If I click on the SRB menu entry in your example, thus forcing a deep update, the highlight problem goes away. When Emacs creates the menu bar for the first time, it does so deep, so the error is not seen for the standard Emacs menu bar entries. A special handling is for Gtk+ detached menus. If there is a detached menu, Emacs always updates deep, since the detached menu could possibly change. So we can se this bug easy. C-h i The Info menu now has the sticky highlight. But if you kill that buffer, detach the File menu, and then to C-h i again. the sticky highlightning is gone. I'd say this is a bug in QtCurve. I can not find a way to undo that effect from within Emacs. Apart from the obvious, always update menus deep. But I don't think we want to do that just for one theme. Not that I think it would break anything, it would just make menu bar updating a bit slower. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Thanks for the test case. I'll try to debug this. Jan D. Stephen Berman skrev: I made the file srb.el (attached) and did the following (again, only with QtCurve in KDE): 1. emacs -Q -l srb.el 2. Moving the mouse over the menu bar in *scratch* does not induce the "sticky" highlighting problem. 3. C-x C-f test.srb brings up a buffer in SRB mode with a menu SRB in the menu bar. When I move the mouse over the menu bar in this buffer, as soon as it moves over and off of SRB the highlighting sticks to this menu bar item. If I switch to *scratch* and then back to test.srb, the sticky highlighting is gone, but I get it again by moving the mouse over and off of SRB. I can repeat this ad infinitum. I can also reliably get the sticky highlighting with the following recipe: 1. emacs -Q 2. Moving the mouse over the menu bar in *scratch* does not induce the "sticky" highlighting problem. 3. Do `M-x gnus RET y RET y RET n' to get the Gnus *Group* buffer. When I move the mouse over the menu bar, the four menues Gnus, Groups, Group, Agent get "sticky" highlighting. 4. If I now switch back to *scratch* and move the mouse over the menu bar, the Edit menu gets sticky highlighting. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build: some menus in the menu bar stay highlighted
Stephen Berman skrev: > On Sun, 22 Apr 2007 12:58:46 +0200 "Franz Häuslschmid" <[EMAIL PROTECTED]> > wrote: > >> Using the GTK build, it always happens that menus entries of the menu >> bar, that are dynamically added or removed depending on the currently >> active frame (e.g. Gnus or AUCTeX), stay highlighted when the mouse >> cursor moves over them. As I am writing this text and having moved the >> mouse cursor over all items of the menu bar, the menus "Edit", "Headers" >> and "Mail" are highlighted. This accentuation of menus is lost, when I >> switch to another buffer not having those menus associated. > > I have noticed the same thing with my Emacs (currently GNU Emacs > 22.0.98.2 (i686-pc-linux-gnu, GTK+ Version 2.10.6) of 2007-04-20 but > I've noticed this for a long time), but only when running under KDE > using the GTK Style QtCurve. This is on openSUSE 10.2 using kcm_gtk, > "the KDE control module for switching GTK+ style", which I think is > the openSUSE substitute for (or version of) the gtk-qt engine. I > attach a picture showing the problem. It looks bad indeed. However, this is all done in Gtk+, I don't even have a theme that highlights the menu bar like that. Does only QtCurve do that? Or are there other Gtk+-themes that highlights like that but doesn't have the same problem? The GNUS menus are defined with easy-menu, thats about all I can think of that differs from "regular" menus. Can you define a small menu with easy.menu and see if the problem is there then? Thanks, Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Compile failure due to Xaw3d include file issues
Chong Yidong skrev: Ulrich Mueller <[EMAIL PROTECTED]> writes: Hi, not entirely sure if this is really an Emacs bug (or if X.Org is to blame): Emacs 22.0.97 compilation fails on a system where: - Xaw3d is installed, - libXaw is not installed. Thanks for the bug report. Could you test the following patch? If you could take the time, please see if it works as expected with all 4 combinations of Xaw3d and libXaw installed/not installed. But that is only on Gentoo. Who knows how many Xaw3d variats there are out there? A configure test seems better to me. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: expand-file-name leaves "/../" in expansions at times
Miles Bader skrev: Chong Yidong <[EMAIL PROTECTED]> writes: On the other hand, I just checked, and this behavior seems to have been around since at least Emacs 20. Glancing through the source code, this behavior seems to be deliberate---something to do with the "superroot directory". Maybe someone on this list can elucidate? I don't know anything about the Emacs code, but CMU CS had a networked filesystem (the mach/spice project vaxes) which had the concept of a super-root above /, accessed via "/..". E.g. to access file "/x/y" on machine "blargh", you'd use "/../blargh/x/y" (IIRC, "/.." was a real directory so you could do "cd /..", "ls /.." to see all machines, etc).. I always thought it was a rather clever idea. It certainly messes up assumptions some programs make, but I think the "/.." == "/" assumption is generally rather rare in practice. [Compare to the microsoftian "//" superroot syntax, which messes up the far more common "//" == "/" assumption, and just generally feels a lot more arbitrary.] Apollo also had // as superroot if my memory is correct. You could do % ls // to see all machines there as well. I don't know if this predates Microsofts usage, but I suspect it does, this was late 80:s, early 90:s. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [emacs-xft] Segmentation fault 0x081b3df2 in xftfont_draw
Leo skrev: Hello, Software: GNU Emacs 23.0.0.11 (i686-pc-linux-gnu, X toolkit) of 2007-04-11 Here is a backtrace of an Emacs crash. One can encounter this often by moving cursor over links etc. It only happens when using xft font. If you are using the unicode2 branch, please put that in the subject. If you are not using that, please try that branch instead, it has had a lot more development. Jan D. ___ emacs-pretest-bug mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [xft-emacs] XFT font in menu-bar
Kenichi Handa skrev: In article <[EMAIL PROTECTED]>, Leo <[EMAIL PROTECTED]> writes: In addition, as far as I know, the menu bar is impleneted by using some toolkit (gtk, lucid, or ?). I think the font used in the menu bar is decided by which toolkit you compiled Emacs with. I am using Lucid toolkit. Then, I think there's no way to make it use Xft fonts. If you like Xft fonts, how about using gtk toolkit? Except adding the C code that is. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [xft-emacs] XFT font in menu-bar
Leo skrev: [GNU Emacs 23.0.0.7 (i686-pc-linux-gnu, X toolkit) of 2007-03-29] The default menu bar in Emacs started with --enable-font-backend is using X core font. Is this a known problem? It is a known limitation. Since GTK supports XFT-fonts, I am not sure it is worth the trouble to make X/Lucid/Lesstif/Motif widgets use XFT fonts. FWIW, I caught a screen shot in XEmacs list and it seems it is possible to use XFT in Lucid menu-bar. http://people.exactcode.de/~rene/xemacs-beta-xft-off-by-one.png I'm not sure if we can use that code. Can we? Jan D. ___ 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)
Leo skrev: On 2007-03-29, Jan Djärv said: Leo skrev: Hello, Jan! The plan is to make Emacs use stock items when built with Gtk+ at least, so when icons changes due to a Gnome upgrade or a theme change, Emacs changes accordingly. This is more or less automatically done in Gtk+. But it is planned for after the release. Jan D. That would make users suffer for the next release cycle. But anyway, just a suggestion. You have a point, but changing things now will delay the release even further. Users have suffered with gnome 1.x icons for some time now. And I think the hope is that the next release will be done much faster than the time it has taken to do the upcoming release. I am not quite sure about the delay. I can replace the icons with those from gnome 2.18 and submit to you, which probably only takes a few hours. My concern is a lot of users who want to learn Emacs will be driven off by the ugly GUI interface. And convert them to xpm, and make black and white variants and low color variants, and test them all on at least 24 bit color display, 8 bit color display and a black and white display. A few hours is not enough. Jan D. ___ 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)
Leo skrev: Hello, Jan! The plan is to make Emacs use stock items when built with Gtk+ at least, so when icons changes due to a Gnome upgrade or a theme change, Emacs changes accordingly. This is more or less automatically done in Gtk+. But it is planned for after the release. Jan D. That would make users suffer for the next release cycle. But anyway, just a suggestion. You have a point, but changing things now will delay the release even further. Users have suffered with gnome 1.x icons for some time now. And I think the hope is that the next release will be done much faster than the time it has taken to do the upcoming release. Jan D. ___ 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)
Leo skrev: Hello, Jan! On 2007-03-28, Jan Djärv said: Richard Stallman skrev: A suggestion is that Info should use some sort of Quit icon instead of the delete, like for example http://developer.gnome.org/doc/API/2.0/gtk/gtk-quit.png. That sounds good, if there is no copyright issue for the icon. Can we use it without a delay? I think so. This is a stock GTK icon and we use a lot of other stock GTK icons, see emacs/etc/images/README. Jan D. Any plan to update the icons taken from gnome-icon-themes? I think those icons are taken from gnome <= 2.14. Now 2.18 was out and >= 2.20 will be once emacs 22.1 is ready to release. They look outdated. See these screenshots: ... It is more user friendly if Emacs 22.1 fit well in the major desktop environment namely Gnome. The plan is to make Emacs use stock items when built with Gtk+ at least, so when icons changes due to a Gnome upgrade or a theme change, Emacs changes accordingly. This is more or less automatically done in Gtk+. But it is planned for after the release. Jan D. ___ 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)
Richard Stallman skrev: A suggestion is that Info should use some sort of Quit icon instead of the delete, like for example http://developer.gnome.org/doc/API/2.0/gtk/gtk-quit.png. That sounds good, if there is no copyright issue for the icon. Can we use it without a delay? I think so. This is a stock GTK icon and we use a lot of other stock GTK icons, see emacs/etc/images/README. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Menu bar display bug
Chong Yidong skrev: Stephen Berman <[EMAIL PROTECTED]> writes: 3. Make a header line in the window of the Gnus Summary buffer, e.g. by doing `M-x ruler-mode' (other header lines will also do, e.g. `M-: (setq header-line-format default-mode-line-format)'). Then do 'C-x o' to switch to the Gnus Article buffer and then make a header line in that window. Now when you do `C-x o' to switch back to the Summary buffer you should see the following (I turned off the tool bar to make smaller pictures for this report, but I also get the same display bug when it is enabled): Please be more explicit: it took me a while to figure out, even from your screenshot that the bug are you referring to is that two "Help" menus show up. FWIW, I don't see this on a GNU/Linux GTK build: it's probably a bug in the Windows menu code. Well, he used a GTK build on GNU/Linux :-). But I suspect it is a GNUS bug, I'll try to reproduce it if I can. There have been other reports of bugs with GNUS, so far I havent been able to reproduce any of them. 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: Jan Djärv writes: Ok, it sounds like a X11 server mismatch. Do other Gnome/Cairo applications run fine in that combination? Oops. It had never occurred to me to try anything other than GNU Emacs. But indeed, all the applications using Cairo that I just tried (gnibbles, gnome-printinfo, gnome-search-tool) have the same problem, i.e. they dump core, apparently when they try to output their first text characters. So this problem is not specific to Emacs at all. Sorry for the noise! You could file a bug on Gnome here: http://bugzilla.gnome.org/, or on cairo here [EMAIL PROTECTED] or here http://bugs.freedesktop.org. Not sure whos bug it is, sounds like cairo. 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: 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. Ok, it sounds like a X11 server mismatch. Do other Gnome/Cairo applications run fine in that combination? Jan D. ___ 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)
Richard Stallman skrev: And at least Gtk Emacs does the right thing if there are two many buttons by placing a button on the right edge which pops up the toolbar buttons that couldn't fit. That is an interesting issue. If the other toolkits do this, there is no reason to discard any buttons; it is just a matter of what order to show them in. Does the Lucid widget version do this? No. The tool bar used by the Lucid version of Emacs is not part of the Lucid widget set, it is the same internal tool bar used by all builds, except Gtk+. Talking about confusing: the button that resembles an `x' runs kill-this-buffer on the global toolbar; the same button runs Info-exit in Info mode. The former kills the buffer, the latter merely buries it. They do have something in common. I see how this could be confusing if you look at them in different terms, but You thought you removed Info from the buffer list, and then it shows up unexpectedly as you move around your buffers. it seems to me one has to get rather advanced to notice the difference, and by that time I expect you would not have trouble coping. A suggestion is that Info should use some sort of Quit icon instead of the delete, like for example http://developer.gnome.org/doc/API/2.0/gtk/gtk-quit.png. 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
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: x-display-list on the Mac
YAMAMOTO Mitsuharu skrev:
Can the notion of "display" (X) approximate each monitor? In a
situation with two monitors, one could have x-display-list return
three displays: a main one ("Mac"), and then "1" and "2" or so for
the other two, separately. Then, x-display-mm/pixel-width/height
could either return the dimensions of the total area, or of only one
of the screens.
According to the manual page of X, "the phrase `display' is usually
used to refer to collection of monitors that share a common keyboard
and pointer (mouse, tablet, etc.)." In that sense, there's only one
"display" on a Mac regardless of the number of monitors.
"Display" and "screen" are established terms in X11, and I think we
should not abuse them. As I mentioned earlier, the concept you want
has another name "framebuffer" in the X11 (Xinerama) world, and I
think the right thing is to support them in a consistent way on the
relevant platforms.
The term monitor is better IMHO, it is already used in the xorg.conf file that
defines your configuration.
Jan D.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: x-display-list on the Mac
YAMAMOTO Mitsuharu skrev: On Sat, 24 Mar 2007 10:10:38 +0100, Jan Djärv <[EMAIL PROTECTED]> said: The concept of "screen" in X11 is different from what you are thinking about. One window cannot span multiple "screen"s. I guess you are thinking about a "framebuffer" in Xinerama extension. The build he had done was --without-x. I meant that we should not assign a different meaning to "screen" in the Carbon port while there is a counterpart in X11. This is probably wise. As a side note, Emacs already has a different meaning for window than X11 has, but we should keep the difference to a minimum. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: x-display-list on the Mac
YAMAMOTO Mitsuharu skrev:
On Fri, 23 Mar 2007 16:19:14 +, David Reitter <[EMAIL PROTECTED]> said:
(x-display-screens) returns 1, and (x-display-list) returns only
("Mac"), despite me running two monitors with the desktop spanning
across them. That's odd - I would expect to see both displays
listed.
The concept of "screen" in X11 is different from what you are thinking
about. One window cannot span multiple "screen"s. I guess you are
thinking about a "framebuffer" in Xinerama extension.
The build he had done was --without-x.
Also, (x-display-pixel-width) returns 1280, which is the width of
the display on the left (main screen). How would I find out the
total desktop area and the screen a particular frame is on? Can I
address the different displays (or screens?) somehow?
No. Because there is no Xinerama support in the X11 version, Emacs
doesn't have a concept to distinguish multiple framebuffers yet.
Right, but if you have one X11 screen on two monitors, it should return the
total width. This seems to not be the case when compiling for native OSX.
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 is the message exactly? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Frame doesn't get focused
See http://bugzilla.gnome.org/show_bug.cgi?id=392889. My last comment was that we may enable _NET_ACTIVATE_WINDOW, but it has been postponed to after the release. Jan D. Katsumi Yamaoka skrev: I stripped [Unicode-2] from the subject line because I realized now the problem is also in Emacs 22. It is due to the --with-gtk build option and probably to the Fecora Core 6 Linux which runs the metacity window manager. Anyway I must apologize for having reported it vaguely. In article <[EMAIL PROTECTED]>, Katsumi Yamaoka <[EMAIL PROTECTED]> writes: --8<---cut here---start->8--- (defun test () (interactive) (let ((frame (make-frame))) (select-frame frame) (select-window (frame-first-window frame))) (switch-to-buffer "*foo*")) (local-set-key [f1] 'test) --8<---cut here---end--->8--- To reproduce the problem, select the frame by clicking the mouse on the rim (not on an Emacs buffer) of the frame after selecting another X-frame, and type the [f1] key (not `M-x test RET'). In my case, the new frame is neither selected nor focused. Let me correct it; the problem happens with Emacs 22 and 23 built with the --with-gtk option and run in the Fedora Core 6 Linux (which I update every day). In <[EMAIL PROTECTED]> Kenichi Handa wrote: That's very strange because Emacs 22 and 23 should not be different in the codes handling that kind of thing. Handa-san, thank you for the comment. The reason I misunderstood that it occurs only with Emacs 23 is that I only tested it with Emacs 23 built with GTK and Emacs 22 built with LUCID then (I usually use Emacs 22 LUCID). A solution is to use `select-frame-set-input-focus' instead of `select-frame'. So, I'd like to modify gnus-win.el so as to use `select-frame-set-input-focus'[1] if it is not a bug of Emacs 23. It will arise to all those who use GTK Emacs and at least the Fedora Core Linux, so such a workaround is quite insufficient. While I don't have a skill to fix this unfortunately, I hope it is solved before releasing. Regards, ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: configure script, line #11.741
Peter Dyballa skrev: > Hello! > > The code around this line is: > > 11740 if test "$HAVE_XFT" != no; then > 11741OLD_CFLAGS="$CPPFLAGS" > 11742OLD_CFLAGS="$CFLAGS" > 11743OLD_LIBS="$LIBS" > 11744CPPFLAGS="$CPPFLAGS $XFT_CFLAGS" > 11745CFLAGS="$CFLAGS $XFT_CFLAGS" > 11746LIBS="$XFT_LIBS $LIBS" > > Line #11741 looks suspicious, at least useless. Otherwise it should be > corrected to OLD_ CPPFLAGS=... > Thanks for pointing that out. Now corrected. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mode-line face and window manager
Richard Stallman skrev: > I don't know who to write to, but I'm not sure that we would ask the right > question anyway (a mode-line for a buffer without focus is presumably the > same kind of widget yet it's face is unaffected by Metacity for some > reason). > > These are not widgets, they are Emacs faces. It sets up a resource > for one face and not for the other. > > I understand this problem and I know what to do. All I need is to > find out where to write about this to reach the Metacity maintainers. > Would someone please find out and tell me? I think the proper channel is to file a bug report here: http://bugzilla.gnome.org/ Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: infinite loop in alsa_write
Andrea Russo skrev: 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 I type `M-: (play-sound-file "/usr/share/sounds/gaim/receive.wav") ' Emacs enters an infinite loop in the C function `alsa_write'. Thanks for the report and analysis, I've checked in a fix. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc
Richard Stallman skrev: > What should we do so as to fix both bugs? The fix installed is OK, that is, keep LIB_X11_LIB defined to -lX11. In the cases where XFT_LIBS also includes -lX11, we will have two -lX11 in the link command. Ok, but I am still puzzled by one thing. I thought that the more recent fix consisted of reverting the change you had previously made. How come that didn't bring back the old bug? Is it the case that the more recent fix did NOT revert your change? The more recent fix did not revert my fix. My fix was to add XFT_LIB and #undef:ing LIB_X11_LIB. The #undef:ing was done to avoid two -lX11 in the link command. The recent fix is to not #undef LIB_X11_LIB, the XFT_LIB part (the important part) is still kept. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc
Jan Djärv skrev: Chong Yidong skrev: Problem seems to be that LIB_XFT on Solaris 10 does NOT include -lX11, despite what it says in src/Makefile.in. This patch (reverts Jan 26 change) fixes it for me on Solaris 10, don't know if it breaks anything else. It can't hurt to include -lX11 twice, can it? *** Makefile.in 17 Feb 2007 02:36:10 - 1.338 --- Makefile.in 2 Mar 2007 22:48:07 - *** *** 403,410 #endif /* not USE_X_TOOLKIT */ #if HAVE_XFT - #undef LIB_X11_LIB /* XFT_LIBS includes -lX11 */ - #define LIB_X11_LIB [EMAIL PROTECTED]@ #endif /* HAVE_XFT */ --- 403,408 Jan, this was your patch. Can you comment on the proposed fix? What is the point of not having -lX11 in XFT_LIBS? Sounds like a bug in the installed Xft to me. Where did it come from, is it part of Solaris 10 or added on later. I guess two -lX11 couldn't hurt. I see that pkg-config --libs gtk+-2.0 on GNU/Linux does not include -lX11, yet it gets linked in because of implicit dependencies. It may be that pkg-config relies on this, but the Solaris ld does not handle this the same way as GNU ld. After all, the Solaris ld does seem to know which library is missing. Anyway, the patch installed is OK, but I wonder if we will see more of these errors if Emacs starts to use pkg-config for more packages? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc
Richard Stallman skrev: The bug was that Emacs crashes when some gnome themes are used. This is because Xft gets loaded and unloaded with dlopen, but pointers to its internal data remain. There is a bug filed on Xft/fontconfig. As a workaround we link Emacs with Xft to keep it from being unloaded. As long as we link the same libraries we should be fine. I am not sure what that last sentence means. As long as we link both Xft and X11 the bug is fixed. It does not matter if -lX11 is there twice in the link command, although it may look a bit strange. What should we do so as to fix both bugs? The fix installed is OK, that is, keep LIB_X11_LIB defined to -lX11. In the cases where XFT_LIBS also includes -lX11, we will have two -lX11 in the link command. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc
Richard Stallman skrev: This patch (reverts Jan 26 change) fixes it for me on Solaris 10, don't know if it breaks anything else. It can't hurt to include -lX11 twice, can it? Jan made that change in Makefile.in, probably to fix a bug. Just removing it is probably not a good idea. Jan, what was that bug? The bug was that Emacs crashes when some gnome themes are used. This is because Xft gets loaded and unloaded with dlopen, but pointers to its internal data remain. There is a bug filed on Xft/fontconfig. As a workaround we link Emacs with Xft to keep it from being unloaded. As long as we link the same libraries we should be fine. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 22.0.95 fails to link (missing -lX11) on Solaris with Sun cc
Chong Yidong skrev: Problem seems to be that LIB_XFT on Solaris 10 does NOT include -lX11, despite what it says in src/Makefile.in. This patch (reverts Jan 26 change) fixes it for me on Solaris 10, don't know if it breaks anything else. It can't hurt to include -lX11 twice, can it? *** Makefile.in 17 Feb 2007 02:36:10 - 1.338 --- Makefile.in 2 Mar 2007 22:48:07 - *** *** 403,410 #endif /* not USE_X_TOOLKIT */ #if HAVE_XFT - #undef LIB_X11_LIB /* XFT_LIBS includes -lX11 */ - #define LIB_X11_LIB [EMAIL PROTECTED]@ #endif /* HAVE_XFT */ --- 403,408 Jan, this was your patch. Can you comment on the proposed fix? What is the point of not having -lX11 in XFT_LIBS? Sounds like a bug in the installed Xft to me. Where did it come from, is it part of Solaris 10 or added on later. I guess two -lX11 couldn't hurt. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK Toolbar Annoyance
Thomas Christensen skrev: I have this in my .emacs: (custom-set-variables '(tool-bar-mode nil)) I start emacs with emacs-snapshot-gtk -g 80x40, and the frame that opens is 80x37 (I presume it is made 3 shorter due to the toolbar removal). Then I press C-x 5 2, and a new frame is spawned with the proper 80x40. If I do this with emacs-snapshot-x -g 80x40 (non-gtk emacs snapshot) the first frame opens with 80x40, and C-x 5 2 spawn the new frame with 80x40 as well. Which I presume is the "right" behavior. Yes, that is a known annoyance. We have to revisit this after the release. A workaround is to do it with X resources instead, i.e.: % emacs -xrm 'Emacs.toolBar: 0' or put it in .Xdefaults. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mention lgrep and rgrep in the docstring for grep
Kim F. Storm skrev: Jan Djärv <[EMAIL PROTECTED]> writes: But then I think that "For running `grep' in the current directory see `lgrep'." is badly worded. M-x grep also runs grep in the current directory. I have fixed lgrep so that it prompts for the directory just like rgrep. And fixed the reference from `grep' accordingly. Looks fine to me. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mention lgrep and rgrep in the docstring for grep
Kim F. Storm skrev: > Jan Djärv <[EMAIL PROTECTED]> writes: > >> Richard Stallman skrev: >>> For doing a recursive `grep', sure the `rgrep' command. For running >>> `grep' in the current directory sure `lgrep'. >>> >>> If we change that to >>> >>> For doing a recursive `grep', see the `rgrep' command. For running >>> `grep' in the current directory see `lgrep'. >>> >>> then it would be good. >> I am confused. What does lgrep really do that grep doesn't? "in the >> current directory" doesn't seem to be the case, specifying */* to >> lgrep is perfectly OK. lgrep seems to set -i (case independent) by >> default whereas grep doesn't. Is that the difference? > > That is one difference (actually, -i is set conditionally from case-fold-search). > > Also M-x lgrep works more like C-u M-x grep, than a plain grep. > > But the main reason for lgrep is it's interface is modelled after the rgrep > interface, prompting (and using different input histories) for each argument. > > So some of the specific aspects of rgrep also applies to lgrep > (such as the grep-files-aliases feature). Ok, thanks for the explanation. But then I think that "For running `grep' in the current directory see `lgrep'." is badly worded. M-x grep also runs grep in the current directory. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: mention lgrep and rgrep in the docstring for grep
Richard Stallman skrev: For doing a recursive `grep', sure the `rgrep' command. For running `grep' in the current directory sure `lgrep'. If we change that to For doing a recursive `grep', see the `rgrep' command. For running `grep' in the current directory see `lgrep'. then it would be good. I am confused. What does lgrep really do that grep doesn't? "in the current directory" doesn't seem to be the case, specifying */* to lgrep is perfectly OK. lgrep seems to set -i (case independent) by default whereas grep doesn't. Is that the difference? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
Jan Djärv skrev: > Katsumi Yamaoka skrev: >>>>>>> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: >>> Oops. Now I don't see the tool bar flickering, and all seem to be >>> going well. I will report if I find the condition to reproduce it. >> I found. I attached two Lisp forms below. To reproduce it, >> eval the form1 first and eval the form2 several times. (I've >> made a similar code in the emacs-w3m CVS, however I might have >> to delete it.) >> >> --8<---cut here---start->8--- >> ;; form1 >> (let ((buf (get-buffer-create "*testing*")) >> (cur (selected-frame))) >> (select-frame (make-frame)) >> (switch-to-buffer buf) >> (make-local-variable 'tool-bar-button-margin) >> (select-frame-set-input-focus cur)) >> >> ;; form2 >> (with-current-buffer "*testing*" >> (setq tool-bar-button-margin (random 10))) >> --8<---cut here---end--->8--- >> >> This is a special case anyway, so I don't mind even though it is >> not fixed. > > It seems that wen random returns 4 or less (i.e. Gtk+ margin 0) I get no > flickering. But everything above 4 gives some flickering. I'll see if I can > find it. It might not make it to the release though. > It seems as update_frame_tool_bar is called several times with different buffers. So for example, the minibuffer still has margin 0, but your other buffer has (say) 5. Then the redraw flickers between 5 and 0 for a while. You really need frame local variables here. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
Katsumi Yamaoka skrev: >> In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: > >> Oops. Now I don't see the tool bar flickering, and all seem to be >> going well. I will report if I find the condition to reproduce it. > > I found. I attached two Lisp forms below. To reproduce it, > eval the form1 first and eval the form2 several times. (I've > made a similar code in the emacs-w3m CVS, however I might have > to delete it.) > > --8<---cut here---start->8--- > ;; form1 > (let ((buf (get-buffer-create "*testing*")) > (cur (selected-frame))) > (select-frame (make-frame)) > (switch-to-buffer buf) > (make-local-variable 'tool-bar-button-margin) > (select-frame-set-input-focus cur)) > > ;; form2 > (with-current-buffer "*testing*" > (setq tool-bar-button-margin (random 10))) > --8<---cut here---end--->8--- > > This is a special case anyway, so I don't mind even though it is > not fixed. It seems that wen random returns 4 or less (i.e. Gtk+ margin 0) I get no flickering. But everything above 4 gives some flickering. I'll see if I can find it. It might not make it to the release though. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: set-frame-parameter fullscreen
[EMAIL PROTECTED] skrev: > GNU Emacs 22.0.93.1 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) > of 2007-01-29 on quant8 > > 1. (set-frame-parameter nil 'fullscreen 'fullheight) >takes a noticeable time to execute (few seconds). There is quite a bit of send client events, get properties and stuff going on, but it is according to the Extended Window Manager Hints Specification. I have seen that it is very slow when running on a remote display over a not so fast connection. When I run locally it is very fast (maybe 0.1 second). We could implement some sort of caching of the query where we find out what the window manager supports. But I think that is something for after the release, and the initial fullscreen would then be as slow as before anyway. > > 2. there is no way to undo its effects (the emacs frame - the window >from the Gnome's POV - becomes unresizeable in the vertical direction) > > That was a bug, (set-frame-parameter nil 'fullscreen nil) should work now. The "unresizable" property is a thing your window manager decides. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
Katsumi Yamaoka skrev: In <[EMAIL PROTECTED]> Katsumi Yamaoka wrote: Oops. Now I don't see the tool bar flickering, and all seem to be going well. I will report if I find the condition to reproduce it. I found. I attached two Lisp forms below. To reproduce it, eval the form1 first and eval the form2 several times. (I've made a similar code in the emacs-w3m CVS, however I might have to delete it.) --8<---cut here---start->8--- ;; form1 (let ((buf (get-buffer-create "*testing*")) (cur (selected-frame))) (select-frame (make-frame)) (switch-to-buffer buf) (make-local-variable 'tool-bar-button-margin) (select-frame-set-input-focus cur)) ;; form2 (with-current-buffer "*testing*" (setq tool-bar-button-margin (random 10))) --8<---cut here---end--->8--- This is a special case anyway, so I don't mind even though it is not fixed. Doesn't this use different tool-bar-button-margins for different buffers? It should really be per frame. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
Katsumi Yamaoka skrev: tool-bar-button-margin to zero was a bug, I've fixed that. However, the default for Gtk is 0, it looks best. Thank you for fixing it. Although it takes time to settle the shape when I change the value of `tool-bar-button-margin', and the value 4 or less seems to be treated as 0. That's ok. I can't see any "settling" at all when changing tool-bar-button-margin. It is very fast. Maybe there is a difference in Gtk+-versions? The default tool-bar-button-margin is 4 for the native tool bar, but that looks horrible with the Gtk tool bar. So 4 and below is really 0. 5 is really 1 and so on. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: (setq tool-bar-button-margin 0) makes GTK Emacs go crazy
Katsumi Yamaoka skrev: > Hi, > > I recently built Emacs configured with the --with-gtk option and > noticed I must not set `tool-bar-button-margin' to zero (I do so > for LUCID Emacs to make the tool bar compact). It causes Emacs > to go on and off wildly. If you try it, launch another Emacs. > > Although it might be impossible to make `tool-bar-button-margin' > and `tool-bar-button-relief' affect the GTK tool bar, I hope it > is improved in the future. tool-bar-button-relief will probably not bel implemented for the Gtk version of Emacs. The main point for having Gtk in Emacs in the first place, IMHO, is that it looks like the rest of the Gtk/Gnome applications, and shall reflect the theme you choose on a desktop level. We are not quite there yet. tool-bar-button-margin to zero was a bug, I've fixed that. However, the default for Gtk is 0, it looks best. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Richard Stallman skrev: So, in order for BLOCK_INPUT to work reliably, it seems that interrupt_input_blocked should be declared as volatile (or maybe `volatile sig_atomic_t' instead of `volatile int') because it is accessed from a signal handler. Isn't it the case that the C spec calls for this to be volatile? Quote form the C standard: "The type defined is sig_atomic_t which is the (possibly volatile-qualified) integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts." However, Neither glibc or Solaris has volatile in the definition. I think the thing guaranteed is "accessed", not "modified". Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs build does not finish
Kenichi Handa skrev: In article <[EMAIL PROTECTED]>, Miles Bader <[EMAIL PROTECTED]> writes: Ralf Angeli <[EMAIL PROTECTED]> writes: The build process, however, now is really slow. Probably twice the time it took before. Is the slowness restricted to the abnormally large files in the leim subdirectory, such as ZIRANMA.el and ja-dic.el, or is it all lisp files? As the outout of make messages are not shown, I'm not sure which files are re-created, but I suspect that the slowness is because of regeneration of those Lisp files from big dictionary files under CXTERM-DIC and MISC-IDC that is caused by my recent update. The process of byte compiling them is, I think, not that slow; for instance, I can byte-compile ZIRANMA.el in 1.5 second. This takes a very long time for me (> 20 minutes, previously under 30 seconds): sed -n '/^[^;]/ p' < /home/jhd/src/emacs/leim/leim-ext.el >> leim-list.el EMACSLOADPATH=/home/jhd/src/emacs/leim/../lisp LC_ALL=C ../src/emacs -batch --no-init-file --no-site-file --multibyte -f batch-byte-compile /home/jhd/src/emacs/leim/ja-dic/ja-dic.el 1 entries 2 entries 3 entries 4 entries It goes to 4 in about the same time as before, but then is seems to hang. As, those dictionary files are updated very very rarely, I don't think it's a big problem. And a tarball contains generated *.el files. It is a huge problem when you develop in Emacs. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
YAMAMOTO Mitsuharu skrev: So, in order for BLOCK_INPUT to work reliably, it seems that interrupt_input_blocked should be declared as volatile (or maybe `volatile sig_atomic_t' instead of `volatile int') because it is accessed from a signal handler. I think volatile int is OK, I'm sure some systems don't define sig_atomic_t. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
I think you should file a bug report on libXft or possibly fontconfig. Jan D. Benjamin Riefenstahl skrev: Hi Stephen, all, Stephen Berman writes: Program received signal SIGSEGV, Segmentation fault. 0xb74b88fa in strcmp () from /lib/libc.so.6 (gdb) bt #0 0xb74b88fa in strcmp () from /lib/libc.so.6 #1 0xb79c1b45 in FcObjectToPtr () from /usr/lib/libfontconfig.so.1 #2 0xb79c5741 in FcPatternAddWithBinding () from /usr/lib/libfontconfig.so.1 [...] #41 0xb7df2c9c in gtk_widget_size_request () from /opt/gnome/lib/libgtk-x11-2.0.so.0 #42 0x080f181c in xg_update_frame_menubar (f=0x8644250) at /home/steve/emacs-22.0.90/src/gtkutil.c:2924 #43 0x0808bb95 in set_frame_menubar (f=0x8644250, first_time=1, deep_p=1) at /home/steve/emacs-22.0.90/src/xmenu.c:2098 #44 0x0808bd90 in initialize_frame_menubar (f=0x8644250) at /home/steve/emacs-22.0.90/src/xmenu.c:2495 #45 0x080d6735 in Fx_create_frame (parms=139409981) at /home/steve/emacs-22.0.90/src/xfns.c:3368 #46 0x08159461 in Ffuncall (nargs=2, args=0xbfe1dfa8) at /home/steve/emacs-22.0.90/src/eval.c:2997 I got a crash in the same spot with the latest pretest and I found this thread in the mail archive. I analysed it like this: - The crash occurs because Fontconfig's (libfontconfig.so) data structures are corrupted, more specifically this involves a linked list in Fontconfig's fcname.c. - That linked list is built from data that is passed-in through a Fontconfig API and used unchecked. - The caller that registered this particular piece of data is Xft (libXft.so), called through the QT library linked in by gtk-qt-engine. gtk-qt-engine seems to be a Gnome theme, probably used to coordinate settings of Gnome clients with KDE (my main desktop). - gtk-qt-engine is loaded during Emacs' call to gtk_settings_set_string_property() in gtkutil.c:xg_initialize(). - When the crash occurs, gtk-qt-engine is not loaded any more. It seems to get unloaded after the settings have been determined. Xft is loaded (through Pango), but it is in a different place now than it used to be before, because Pango has re-loaded it on-demand long after it was already unloaded together with gtk-qt-engine. The root cause seems to be that the Xft shared library is not unloadable, it doesn't cleanup and unregister the data that it has passed to fontconfig. Work-arounds that fix it for me: - Uninstall gtk-qt-engine. - Preload Xft using LD_PRELOAD. Possible work-around in Emacs: - Link to Xft and call XftInit(0) in gtkutil.c:xg_initialize() or even before that. I'm not sure where exactly the problem *should* be fixed. - Fontconfig could copy the data that comes in. - Xft could allocate the data on the heap instead of using a static structure. - Xft could prevent unloading of itself. - Xft could provide a cleanup routine for QT and/or gtk-qt-engine to use. - gtk-qt-engine could prevent unloading of Xft. It makes things unusually complicated by combining the two toolkits in one process. benny ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev: Jan Djärv <[EMAIL PROTECTED]> writes: By using sigblock/sigunblock we make sure that counter isn't touched, so it fixes this particular case. However, why the counter gets the wrong value is still not known. Can anyone even reproduce the bug other than me? Well, I can't. If not, I'm more than happy to run any test cases you would like me to try. I've tried debugging it in various ways myself, but the timing seems to be so touchy that any attempt to observe what's going on changes things. Great. However, I still have nothing new :-( Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Stefan Monnier skrev: it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! Are you sure it fixes it? It may just hide it by slightly changing the timing. The bug occurs because revoke_input_signal is called when it should not be. Somehow the counter used by UNBLOCK/BLOCK_INPUT gets the wrong value, becoming negative. By using sigblock/sigunblock we make sure that counter isn't touched, so it fixes this particular case. However, why the counter gets the wrong value is still not known. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: X protocol error:
Sam Steingold skrev: > Jan Djärv wrote: >> [EMAIL PROTECTED] skrev: >>> GNU Emacs 22.0.92.5 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) >>> of 2007-01-08 on quant8 >>> >>> Just got this: >> ... >>> (gdb) c >>> Continuing. >>> X protocol error: BadFont (invalid Font parameter) on protocol >>> request 55 >>> >>> Dunno what this might mean, nor how to reproduce this. >>> >> >> It means that somewhere you (or someone else) gave Emacs a font name >> that does >> not exist on your system. > > a crash on invalid argument in the middle of an interactive work (as > opposed to startup) is kind of ungraceful. > I thought that if an invalid font it supplied, something else is > substituted instead (e.g., plain if no italic, or similar size if the > specific size if not found...) It could be a bad face specification, or it could even be a bug in the X server. If an X font server is used, it is possible it did not answer (network problems?). Usually we should catch these, but if it isn't reproduceable, it is hard to debug. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: X protocol error:
[EMAIL PROTECTED] skrev: > GNU Emacs 22.0.92.5 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars) > of 2007-01-08 on quant8 > > Just got this: ... > (gdb) c > Continuing. > X protocol error: BadFont (invalid Font parameter) on protocol request 55 > > Dunno what this might mean, nor how to reproduce this. > It means that somewhere you (or someone else) gave Emacs a font name that does not exist on your system. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev: Jan Djärv <[EMAIL PROTECTED]> writes: It is probably very timing related. A small change changes the timing. Can you try the attachet patch? That fixes the problem. Good. I ran the patched program 4 times, each time clicking the first icon a lot of times to see if I could provoke a crash and I couldn't. The first time I clicked the icon in the first run, however, I saw a CRITICAL message in the terminal I ran it from: [EMAIL PROTECTED]:~/programs/emacs$ emacs -Q (emacs:16263): libgnomevfs-CRITICAL **: gnome_vfs_get_uri_from_local_path: assertion `g_path_is_absolute (local_full_path)' failed [EMAIL PROTECTED]:~/programs/emacs$ emacs -Q [EMAIL PROTECTED]:~/programs/emacs$ emacs -Q [EMAIL PROTECTED]:~/programs/emacs$ emacs -Q [EMAIL PROTECTED]:~/programs/emacs$ This may of course be completely irrelevant. The Gtk+ file dialog wants only absolute file names. Maybe tehre is some case where we set the default file/directory to something non-absolute? I'll investigate. Thanks, Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Richard Stallman skrev: > * running the same build on the same debian sid machine under KDE > when you run it under KDE, is that the GTK build of Emacs? It's the same build in all cases. The same binary files. I make a ".deb" package from the results of the build and install that same package on both machines, and run that same package under the various desktop environments. So in all cases it's using GTK. How bizarre. I don't know if you saw the silly patch for the problem which I posted earlier today, but adding a static integer variable and incrementing it before incrementing interrupt_input_blocked in the #define for BLOCK_INPUT fixes the bug! This suggests to me that it has something to do with multithreading. I have a vague memory that GTK uses multithreading. It is the file dialog in Gtk+ that uses several threads. Jan, do you get any ideas from this? Some, but the root cause is still unknown. It seems UNBLOCK_INPUT gets called more than BLOCK_INPUT, so the counter goes below zero and Emacs aborts (in UNBLOCK_INPUT). Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev:
Richard Stallman <[EMAIL PROTECTED]> writes:
* running the same build on the same debian sid machine under KDE
when you run it under KDE, is that the GTK build of Emacs?
It's the same build in all cases. The same binary files. I make a
".deb" package from the results of the build and install that same
package on both machines, and run that same package under the various
desktop environments. So in all cases it's using GTK.
Unfortunately, the comparison between the two machines is not very
conclusive because so many things could be different between them.
I don't know if you saw the silly patch for the problem which I posted
earlier today, but adding a static integer variable and incrementing
it before incrementing interrupt_input_blocked in the #define for
BLOCK_INPUT fixes the bug!
I arrived at that fix through a process of trial and error, not
through any understand at all of what's going on.
It is probably very timing related. A small change changes the timing. Can
you try the attachet patch?
Jan D.
Index: alloc.c
*** alloc.c.~1.405.~ 2007-01-01 19:19:05.0 +0100
--- alloc.c 2007-01-11 08:44:47.0 +0100
***
*** 130,137
#define BLOCK_INPUT_ALLOC \
do\
{ \
! if (pthread_self () == main_thread) \
! BLOCK_INPUT;\
pthread_mutex_lock (&alloc_mutex); \
} \
while (0)
--- 130,137
#define BLOCK_INPUT_ALLOC \
do\
{ \
! if (pthread_equal (pthread_self (), main_thread)) \
! sigblock (sigmask (SIGIO)); \
pthread_mutex_lock (&alloc_mutex);\
} \
while (0)
***
*** 139,146
do\
{ \
pthread_mutex_unlock (&alloc_mutex); \
! if (pthread_self () == main_thread) \
! UNBLOCK_INPUT;\
} \
while (0)
--- 139,146
do\
{ \
pthread_mutex_unlock (&alloc_mutex); \
! if (pthread_equal (pthread_self (), main_thread)) \
! sigunblock (sigmask (SIGIO)); \
} \
while (0)
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev: In my original report I mentioned that when I click the first icon, one of three things happens: 1) Emacs aborts 2) I see "Xlib: unexpected async reply" 3) It works as expected Your change seems to have eliminated number 3 in the above list. It now aborts almost every time I click the first icon, and about 1 in 4 times displays the Xlib error message. Well, it is progress of some sort... Incidentally, which file(s) did you edit? I had a look at some Changelog files but can't see anything that looks relevant. I simply initialized some variables in keyboard.c (interrupt_input_blocked and interrupt_input_pending) which wasn't explicitly initialized. Here's new output from gdb: Thanks. Somehow the thread detection thingy isn't working correctly. While I try to figure this out, please try the patch suggested by YAMAMOTO Mitsuharu. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: 4 week-old pretest bugs
Chris Moore skrev: > Jan Djärv <[EMAIL PROTECTED]> writes: > >> Can you run emacs in gdb and do a backtrace when this (Abort) >> happens? > > Sure: Thanks for the info. I've checked in a change, can you test it? Jan D. > > Breakpoint 1, abort () at emacs.c:431 > 431 kill (getpid (), SIGABRT); > (gdb) where > #0 abort () at emacs.c:431 > #1 0x08147f7b in emacs_blocked_malloc (size=16, ptr=0xb793c0b6) > at alloc.c:1268 > #2 0xb7642c05 in malloc () from /lib/tls/libc.so.6 > #3 0xb793c0b6 in g_malloc () from /usr/lib/libglib-2.0.so.0 > #4 0xb7e7dbcc in _gtk_tree_data_list_header_new () >from /usr/lib/libgtk-x11-2.0.so.0 > #5 0xb7dc9b77 in gtk_list_store_clear () from /usr/lib/libgtk-x11-2.0.so.0 > #6 0xb7dc9e6f in gtk_list_store_new () from /usr/lib/libgtk-x11-2.0.so.0 > #7 0xb7d6ddf7 in _gtk_file_chooser_entry_set_base_folder () >from /usr/lib/libgtk-x11-2.0.so.0 > #8 0xb79c4057 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 > #9 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #10 0xb79c4000 in g_source_set_closure () from /usr/lib/libgobject-2.0.so.0 > #11 0xb7932da1 in g_source_is_destroyed () from /usr/lib/libglib-2.0.so.0 > #12 0xb7934b21 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 > #13 0xb7937b96 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 > #14 0xb7938117 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0 > #15 0xb7dcc0e5 in gtk_main_iteration () from /usr/lib/libgtk-x11-2.0.so.0 > #16 0x080c90ae in XTread_socket (sd=0, expected=1, hold_quit=0xbfc06b04) > at xterm.c:7078 > #17 0x080fb72d in read_avail_input (expected=1) at keyboard.c:6823 > #18 0x080fb92a in handle_async_input () at keyboard.c:6969 > #19 0x08148095 in emacs_blocked_free (ptr=0xb6005ba0, ptr2=0xb793bf21) > at alloc.c:1223 > #20 0xb76408f5 in free () from /lib/tls/libc.so.6 > #21 0xb793bf21 in g_free () from /usr/lib/libglib-2.0.so.0 > #22 0xb701caac in gnome_vfs_make_uri_canonical () >from /usr/lib/libgnomevfs-2.so.0 > #23 0xb706957f in fs_module_init () >from /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so > #24 0xb7d836b4 in gtk_file_system_uri_to_path () >from /usr/lib/libgtk-x11-2.0.so.0 > #25 0xb7069169 in fs_module_init () >from /usr/lib/gtk-2.0/2.4.0/filesystems/libgnome-vfs.so > #26 0xb7d83416 in gtk_file_system_list_bookmarks () >from /usr/lib/libgtk-x11-2.0.so.0 > #27 0xb7d73fb5 in _gtk_file_chooser_default_new () >from /usr/lib/libgtk-x11-2.0.so.0 > #28 0xb7d74201 in _gtk_file_chooser_default_new () >from /usr/lib/libgtk-x11-2.0.so.0 > #29 0xb7d742df in _gtk_file_chooser_default_new () >from /usr/lib/libgtk-x11-2.0.so.0 > #30 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () >from /usr/lib/libgobject-2.0.so.0 > #31 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 > #32 0xb79aca7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #33 0xb79bd3b8 in g_signal_chain_from_overridden () >from /usr/lib/libgobject-2.0.so.0 > #34 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > #35 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #36 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 > #37 0xb7d3f5a5 in gtk_container_child_type () from > /usr/lib/libgtk-x11-2.0.so.0 > #38 0xb7d020d0 in gtk_box_pack_start_defaults () >from /usr/lib/libgtk-x11-2.0.so.0 > #39 0xb7d3cecc in gtk_container_forall () from /usr/lib/libgtk-x11-2.0.so.0 > #40 0xb7d3f559 in gtk_container_child_type () from > /usr/lib/libgtk-x11-2.0.so.0 > #41 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () >from /usr/lib/libgobject-2.0.so.0 > #42 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 > #43 0xb79aca7c in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #44 0xb79bd3b8 in g_signal_chain_from_overridden () >from /usr/lib/libgobject-2.0.so.0 > #45 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > #46 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #47 0xb7ec1eef in gtk_widget_map () from /usr/lib/libgtk-x11-2.0.so.0 > #48 0xb7d6c933 in gtk_file_chooser_dialog_new () >from /usr/lib/libgtk-x11-2.0.so.0 > #49 0xb79b9e1b in g_cclosure_marshal_VOID__VOID () > #50 0xb79aaf49 in g_value_set_boxed () from /usr/lib/libgobject-2.0.so.0 > #51 0xb79ac98b in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0 > #52 0xb79bd3b8 in g_signal_chain_from_overridden () >from /usr/lib/libgobject-2.0.so.0 > #53 0xb79be429 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0 > #54 0xb79be5d9 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0 > #55 0xb7ec1eef in gtk_
Re: 4 week-old pretest bugs
Chris Moore skrev: 2. running 'emacs -Q' and then clicking the first gtk icon sometimes causes a crash: Fatal error (6)Aborted other times it causes this to be printed in the starting terminal, leaving Emacs hung up: Xlib: unexpected async reply (sequence 0x11b5)! (emacs:19157): Gdk-CRITICAL **: gdk_window_set_geometry_hints: assertion `GDK_IS_WINDOW (window)' failed (emacs:19157): Gdk-CRITICAL **: gdk_window_move_resize: assertion `GDK_IS_WINDOW (window)' failed other times it just displays the 'find file' dialog as it should. Can you run emacs in gdb and do a backtrace when this (Abort) happens? Also, when it happens, do info threads and then for each thread (say you have three threads) do: thr 1 bt thr 2 bt thr 3 bt What version of Gtk+ do you have? Are you using some Gtk-qt theme? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [gmane.emacs.help] Re: raise frame no go
Eli Zaretskii skrev: Date: Thu, 04 Jan 2007 12:42:19 +0100 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <[EMAIL PROTECTED]> Cc: emacs-pretest-bug@gnu.org Metacity (the default Gnome window manager) is a complete mess when it comes to raise frame. Some versions works, some don't. Some require the code below, some don't. In some configurations (i.e. focus on click vs. focus on mouse) raise frame works, in some raise frame don't work. We must give up on creating workarounds for Metacity, and just tell people that metacity is buggy. Ufortunately they have to figure out a workaround for themselves and their specific verion/configuration of metacity. How about writing an entry for etc/PROBLEMS about this? Ok, I'll do that. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [gmane.emacs.help] Re: raise frame no go
Leo skrev: * Jan Djärv (2007-01-04 12:42 +0100) said: ^ Metacity (the default Gnome window manager) is a complete mess when it comes to raise frame. Some versions works, some don't. Some require the code below, some don't. In some configurations (i.e. focus on click vs. focus on mouse) raise frame works, in some raise frame don't work. We must give up on creating workarounds for Metacity, and just tell people that metacity is buggy. Ufortunately they have to figure out a workaround for themselves and their specific verion/configuration of metacity. Havoc Pennington from Redhat has commented on this bug¹: "I don't know if it's the problem, but the timestamp sent by that Emacs code is gibberish, which could break something even if it isn't the issue here. (Assuming I understand the Emacs code.) I don't believe raise-frame is intended to unconditionally work in metacity, btw. This is legitimate window manager behavior and no spec requires that the WM unconditionally honors a raise request." I've added to this bug: Emacs first sent timestamp 0, but metacity complained about that, so we tried something else. The timestamp is not clearly defined in the extended window manager hints specification. Note that Emacs in the current CVS (which will be released soon) does not send _NET_ACTVATE_WINDOW (the code is commented out) as some Metacity version hanged when we did that. So currently there is only a call to XRaiseWindow/XFlush. Is there a way to make Metacity raise windows or shall Emacs just document the fact that Metacity does not honor XRaiseWindow? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [gmane.emacs.help] Re: raise frame no go
Metacity (the default Gnome window manager) is a complete mess when it comes
to raise frame. Some versions works, some don't. Some require the code
below, some don't. In some configurations (i.e. focus on click vs. focus on
mouse) raise frame works, in some raise frame don't work.
We must give up on creating workarounds for Metacity, and just tell people
that metacity is buggy. Ufortunately they have to figure out a workaround for
themselves and their specific verion/configuration of metacity.
Jan D.
Leo skrev:
Ämne:
Re: raise frame no go
Från:
Mathias Dahl <[EMAIL PROTECTED]>
Datum:
Thu, 04 Jan 2007 02:34:48 +0100
Diskussionsgrupper:
gmane.emacs.help
Leo <[EMAIL PROTECTED]> writes:
I want to use emacsclient to bring Emacs frame to the front. I tried
several functions including raise-frame, x-focus-frame etc, but none
of them worked. All they do is causing the Emacs frame to flash in
the taskbar. Any ideas?
This is tested in Gnome 2.16 in Fedora 6.
Emacs 23: 20061218.
I just wanted to mention that I have the same problem. Running CVS
Emacs as of 2007-01-1 under Mandriva GNU/Linux, using GNOME with its
Metacity window manager. What I do is this:
$ emacsclient -e "(my-function)"
and my-function is:
(defun my-function ()
(select-frame-set-input-focus (selected-frame)))
(well, of course it does more than that but...)
Up until today I haven't played with emacsclient under GNU/Linux. I
have just used gnuclient & friends under w32. I am currently coding a
small command/url/hatever launcher in Emacs, and the current behavior
is quite frustrating (when Emacs is not the topmost window).
I see this code in xterm.c:
XTframe_raise_lower (f, raise_flag)
FRAME_PTR f;
int raise_flag;
{
if (raise_flag)
{
/* The following code is needed for `raise-frame' to work on
some versions of metacity; see Window Manager
Specification/Extended Window Manager Hints at
http://freedesktop.org/wiki/Standards_2fwm_2dspec
However, on other versions (metacity 2.17.2-1.fc7), it
reportedly causes hangs when resizing frames. */
/* Lisp_Object frame;
const char *atom = "_NET_ACTIVE_WINDOW"; */
x_raise_frame (f);
/* XSETFRAME (frame, f);
Fx_send_client_event (frame, make_number (0), frame,
make_unibyte_string (atom, strlen (atom)),
make_number (32),
Fcons (make_number (1),
Fcons (make_number (time (NULL) * 1000),
Qnil))); */
}
else
x_lower_frame (f);
}
Is is that piece of code that fails? My version of metaciy is 2.16.1.
/Mathias
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
Leo skrev: * Chris Moore (2007-01-04 10:45 +0100) said: ^^^ On 1/4/07, Leo <[EMAIL PROTECTED]> wrote: It turns out all hard links will be deleted after user log off. The file system is: `type ncpfs (rw,nosuid,nodev)' as I am running Emacs on my Univ's server. Is there any reason to choose hard link over symbolic link? All regular files are hard links. A hard link is just a name for a file on disk. "emacs" is one name for the executable and "emacs-22.0.92" is another name for the same executable. There's no concept of one being a link to the other, they are both names for the same file on disk. If "all hard links" are deleted, then both "emacs" and "emacs-22.0.92" will be deleted, along with all your other files. Then I don't know what's going on. 'emacs' is deleted but 'emacs-22.0.92' is not. Any other files I created using 'ln' will also be deleted. "Hard link" usually means a file with a link count greater than 1. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Executable deleted after first run
Leo skrev: > Hi all, > > To reproduce, > > 1. compile and install Emacs in dir "~/packages/emacs22" > > 2. go to ~/packages/emacs22/bin and run Emacs with ./emacs > > 3. Quit Emacs and executable emacs is gone. > > I am left with these files in bin dir: > /home/leo/packages/emacs22/bin/ (allfiles) > |-(f)b2m > |-(f)ctags > |-(f)ebrowse > |-(f)emacs-22.0.92 > |-(f)emacsclient > |-(f)etags > |-(f)grep-changelog > +-(f)rcs-checkin > > Tested on: GNU Emacs 22.0.92.1 (i686-pc-linux-gnu, GTK+ Version 2.6.4) > of 2006-12-30 on soup > I can't reproduce this on GNU/Linux. Does this happen if you run with ./emacs -Q as well ? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: National Language Support Functions
Lennart Borgman (gmail) skrev: What does GNOME do in this area? Does it allow the user to use a Swedish keyboard layout but still have English as the preferred language for text to show? Of course. There is no connection between keyboard layout and language text. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Richard Stallman skrev: > ** Most important: >- Alt-Tab, Alt-Shift-Tab >- Ctrl-Esc, Ctrl-Shift-Esc >- Ctrl-Alt-Delete >- Ctrl-Tab, Ctrl-Shift-Tab >- Ctrl-C, Ctrl-X, Ctrl-V, Ctrl-Z >- Ctrl-A >- Alt-Space >- Esc >- Tab, Shift-Tab > > That is really disastrous. I am surprised anyone can find Emacs useful > on Windows if it interferes with such important keys. > > Anyway, Windows users can suggest some recommendation to make. Isn't it so that these keys are passed down to Emacs? I used Emacs on W32, and Ctrl-C was not captured. Neither was Ctrl-X, Ctrl-Z, Tab, Esc. We are not talking about keys which are commonly used for other things, but keys which are captured on a higher level and never reaches Emacs at all. This is the case for Alt-Tab for example. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Richard Stallman skrev: > Ctrl-Alt-D, Ctrl-Alt-L, Alt-SPC are defined by Gnome (metacity). > > Is GNOME the ONLY system which defines those keys? As far as I know, yes. KDE dows not have them. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Richard Stallman skrev: > So a brief list of key kombinations to avoid using would be: > > Alt-Tab, Alt-Shift-Tab, Ctrl-Tab, Ctrl-Shift-Tab > Ctrl-Alt-Left/Right/Up/Down, Ctrl-Shift-Alt-Left/Right/Up/Down > Alt-Escape, Ctrl-Alt-Escape > Alt-Print, Ctrl-Print > Ctrl-Alt-Delete > Alt-Fkey (i.e. F1, F2, ...) > Ctrl-Fkey > Ctrl-Shift-Fkey > Ctrl-Alt-D > Cltr-Alt-L > Alt-Space Of all those, the ones that would actually interfere with Emacs seem to be: Alt-TAB, Ctrl-Alt-D, Ctrl-Alt-L, Alt-SPC. Are there any others? We should recommend that Emacs users turn off those keys in their window managers. Which window managers define these by default? Alt-TAB: almost all new WM:s these days (including Gnome and KDE). Ctrl-Alt-D, Ctrl-Alt-L, Alt-SPC are defined by Gnome (metacity). Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Emacs Manual: G.5 Keyboard Usage on MS-Windows
Eli Zaretskii skrev: > > Jan, could you perhaps post a list of keys that are frequently in > conflict with various window managers? M-TAB is only one of them, > IIRC; there are others. > > That list could be a beginning of a node Richard talks about, perhaps > in some appendix to the manual. If you look at Gnome and KDE I guess you will cover the majority of users and key bindings. Generally, any Alt/Ctrl/Shift-F* or any combination thereof (i.e. Alt-F1, Ctrl-F2, Ctrl-Alt-F2, and so on) are reserved in KDE and Gnome to window functions (move, resize, etc.). You mentioned Alt-Tab, but also Alt-Shift-Tab, Ctrl-Tab. and Ctrl-Shift-Tab are used to move focus between windows in various ways. Ctrl-Alt-Delete of course. Alt-escape, Alt-Print and Ctrl-Print are also common. Ctrl-Alt-Left/Right/up/Down and Ctrl-Shift-Alt-Left/Right/Up/Down are used to navigate between desktops. Then Ctrl-Alt-L to lock the screen, Ctrl-Alt-D to hide/show all windows (show desktop). So a brief list of key kombinations to avoid using would be: Alt-Tab, Alt-Shift-Tab, Ctrl-Tab, Ctrl-Shift-Tab Ctrl-Alt-Left/Right/Up/Down, Ctrl-Shift-Alt-Left/Right/Up/Down Alt-Escape, Ctrl-Alt-Escape Alt-Print, Ctrl-Print Ctrl-Alt-Delete Alt-Fkey (i.e. F1, F2, ...) Ctrl-Fkey Ctrl-Shift-Fkey Ctrl-Alt-D Cltr-Alt-L Alt-Space I can send a more detailed list what these usually does if you need it, but now it is christmas, so this is all I have time for :-) Merry Christmas all, Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sound problem with SUSE x86_64
[EMAIL PROTECTED] skrev: > Jan, > > I had not copied in sound.c. > > Emacs 22.0.92 now configures, compiles and can play sound files using the > latest CVS configure and the sound.c files. > That is good, thanks. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sound problem with SUSE x86_64
[EMAIL PROTECTED] skrev:
[t901353]alnx004[101]% pkg-config alsa --libs
-L/usr/lib64 -lasound -lm -ldl -lpthread
[t901353]alnx004[102]%
Config.log:
configure:5642: result: no
configure:5663: checking for pkg-config
configure:5681: found /usr/bin/pkg-config
configure:5694: result: /usr/bin/pkg-config
configure:5708: checking for alsa >= 1.0.0
configure:5712: result: yes
configure:5716: checking ALSA_CFLAGS
configure:5719: result:
configure:5722: checking ALSA_LIBS
configure:5725: result: -L/usr/lib64 -lasound -lm -ldl -lpthread
configure:5806: checking sys/select.h usability
configure:5818: gcc -c -O2 -D_BSD_SOURCE conftest.c >&5
configure:5824: $? = 0
configure:5828: test -z
|| test ! -s conftest.err
You cut this too short, where is the error?
Jan D.
Jan Djärv <[EMAIL PROTECTED]>
12/20/2006 04:02 PM To
[EMAIL PROTECTED]
cc
emacs-pretest-bug@gnu.org, [EMAIL PROTECTED]
Subject
Re: Sound problem with SUSE x86_64
[EMAIL PROTECTED] skrev:
Jan,
I looked in /usr/lib/pkgconfigthe dir is empty. Are files supposed to be
in there? Where do said files come from?
The new configure.in file did not find the asoundlib.h file...
What does config.log look like (just the alsa relevant parts)?
What does
% pkg-config alsa --libs
output?
Jan D.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sound problem with SUSE x86_64
[EMAIL PROTECTED] skrev: > Jan, > > I looked in /usr/lib/pkgconfigthe dir is empty. Are files supposed to be > in there? Where do said files come from? > > The new configure.in file did not find the asoundlib.h file... What does config.log look like (just the alsa relevant parts)? What does % pkg-config alsa --libs output? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sound problem with SUSE x86_64
[EMAIL PROTECTED] skrev:
> Is this my system setup that should have this variable set? Or is
> configure.in supposed
> to find it and set it?
Your setup (more specific /usr/lib/pkgconfig/alsa.pc) is supposed to have
Cflags: -I${includedir} -I${includedir}/alsa
I've added a configure check for this, please try it (from CVS).
Jan D.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sound problem with SUSE x86_64
[EMAIL PROTECTED] skrev: The output of the "pkg-config --cflags alsa" is just a single space. That is not right, it should be -I/usr/include/alsa. Maybe I can do a configure.in test for this brokeness. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Sound problem with SUSE x86_64
Tom Wurgler skrev: > I have SuSE Linux Enterprise 9.1 X86_64. If I just configure with only a > prefix, when I run make it fails to compile sound.c, because if can't find > asoundlib.h. If I hardcode the path to the file, all compiles fine and sound > files play. I changed src/sound.c: > > #ifdef HAVE_ALSA > #include< /* #include "/usr/include/alsa/asoundlib.h" */ < #endif > > Is this just my setup or did configure not find the file correctly? What is the output of % pkg-config --cflags alsa ? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Hello. This is so far inside fontconfig and the theme engine that you use, so I suspect nothing Emacs does can help. It seem to crash on /usr/X11R6/lib/X11/fonts/misc/cu12.pcf.gz, have you tried to remove that file? It may be a bad font (I don't know what cu12.pcf is, Courier 12?). An idea why Emacs crashes and no other may be that Emacs uses only non-AA fonts, whereas Firefox and other uses AA fonts mostly. But it is hard to tell. If removing that file doesn't help, you could try to switch to a more basic theme. But all this is just shots in the dark, I'm afraid. Jan D. Stephen Berman skrev: > On Fri, 08 Dec 2006 08:05:56 +0100 Jan Djärv <[EMAIL PROTECTED]> wrote: > >> Stephen Berman skrev: >>> Well, now I can get GTK-Emacs to segfault again :-). I noticed that >>> the desktop fonts didn't look as sharp as they normally do (it took me >>> a while to notice this, probably because the fonts in Emacs are always >>> not so sharp :-), so I ran fc-cache, exited KDE and logged on again. >>> Now my desktop fonts are back to their previous sharpness, but >>> Emacs-GTK segfaults again with the standard invocation (but I can >>> start it by setting LD_LIBRARY_PATH to /usr/local/lib). So if someone >>> is able to advise me how to debug this, I can try to do it. >>> >> It is hard if Emacs doesn't fail with the debug-compiled fontconfig. >> Does wxGTK install fonts? > > No, AFAICT (and a wxwidget developer told me it does not alter pango > or fontconfig). > >>The cache handling seems to have some bug >> in it. As it only fails sometimes it might be that the code that >> builds or reads the cache have some uninitialized variable that gets >> random garbage. Sometimes that garbage is OK, sometimes it isn't. > > This may well be the case, as I'm getting rather unpredictable > behavior. The next time I started GTK-Emacs (without setting > LD_LIBRARY_PATH to /usr/local/lib) after writing the above, it came up > fine, no segfault. Then I updated the Nvidia-driver for my graphic > card, and the next time I booted and started Emacs (last night), the > GTK build segfaulted again. But this time, it also segfaulted even > after setting LD_LIBRARY_PATH to /usr/local/lib, i.e., I could not > started the GTK build at all (neither the CVS nor first pretest > builds; the Lucid build was as usual unaffected). Fortunately, this > time the gdb full backtrace (appended to the end of this post) > includes values from the fontconfig source, though lots are optimized > out; still perhaps you can get some useful information out of it. > BTW, notice that this backtrace is quite different from the one I > originally sent (and had gotten on every previous segfault). > > A further datapoint: When I booted SUSE 10.1 this morning, X started > and the kdm login screen came up, but I could not start any desktop (I > tried KDE several times, Gnome, and FVWM), restarting X didn't help. > Then I noticed that ~/.fonts.cache-2 was again very large, ~1.8MB, and > the timestamp was from just after booting. I deleted this file, ran > fc-cache as root, went back to the kdm screen, and could start KDE as > usual. I then invoked Emacs-GTK, and it started without a problem! > >> If you rebuild the cache several times with the same fontconfig, are >> the ~/.fonts.cache-2 then identical? And are they different if you >> rebuild with the fontconfig you compiled? > > After running fc-cache again this morning, ~/.fonts.cache-2 was not > recreated. This was with /usr/local/bin/fc-cache, i.e., the one I > compiled. I haven't tried again with /usr/bin/fc-cache, as I'm a > little afraid of the consequences, given what I described above. If > (or when) I have problems again with Emacs starting, I'll try to do > both and compare. > >>Does any other Gnome/GTK >> application fail when Emacs fails or is it just Emacs? > > I've only had problems with Emacs. I mostly use KDE, but aside from > Emacs, no other GTK application I use (mostly Firefox and several > games, Eclipse, Gimp) has segfaulted AFAICR, at least not the way > Emacs has been doing, right on startup, since I first installed wxGTK. > (There are at least two other issues I've had with GTK-Emacs that I've > not had with any other GTK application, but they have to do > specifically with KDE and not with wxGTK or fonts, so I assume they > are not related to this problem, except (and that in itself is perhaps > significant) for being restricted to Emacs.) > > Steve Berman > ___ > He
Re: using the first three buttons in the tool bar
Olivier Lecarme skrev: > I'm testing Emacs 22 on a Debian Sid PC installation. > > I just tried the first three buttons in the tool bar, with some > difficulties. The same occurs with the first three entries in the File > menu. I have had no problem with C-x C-f or C-x C-d, which I normally > use. This explains why I'm discovering the problem after several days of > daily use. > > The symptoms are various: > > - first symptom: > >> Xlib: unexpected async reply (sequence 0x210f)! >> >> (emacs:28050): Gdk-CRITICAL **: gdk_window_set_geometry_hints: assertion >> `GDK_IS_WINDOW (window)' failed >> >> (emacs:28050): Gdk-CRITICAL **: gdk_window_move_resize: assertion >> `GDK_IS_WINDOW (window)' failed > > and Emacs hangs and must be killed. > > - second symptom: > >> Xlib: unexpected async reply (sequence 0x3a9e)! >> Xlib: sequence lost (0x19cc0 > 0x9cc1) in reply type 0xa! >> Connection lost to X server `:0.0' >> zsh: exit 70./emacs > > and Emacs terminates immediately. > > - third symptom: the selection dialogue opens, but hangs shortly after > that; this can be when I use the C-l command, or when I accept the > chose file; the dialogue window does not close, and the Emacs window > displays a rotating circle; in the xterm calling Emacs there is the > following message: > >> Xlib: unexpected async reply (sequence 0xd2c1)! > > How should I provide more information? > Use report-emacs-bug for starters. Then make sure your Emacs is up to date. Emacs 22 has not been released yet, so a date when you got it from CVS would be fine. Or if it a pretest, what pretest version. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Eli Zaretskii skrev:
Date: Fri, 08 Dec 2006 08:27:21 +0100
From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], emacs-pretest-bug@gnu.org
Alas, I couldn't find any documentation of the *.pc files' format, so
that I could edit the files.
It is in the man page for pkg-config.
What man page? I'm quite sure I tried "man pkg-config" and didn't
find it there.
Hmm, there may be version differences. Here is what my man-page says:
METADATA FILE SYNTAX
To add a library to the set of packages pkg-config knows about, simply
install a .pc file. You should install this file to libdir/pkgconfig.
Here is an example file:
# This is a comment
prefix=/home/hp/unst # this defines a variable
exec_prefix=${prefix} # defining another variable in terms of the first
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: GObject# human-readable name
Description: Object/type system for GLib # human-readable description
Version: 1.3.1
URL: http://www.gtk.org
Requires: glib-2.0 = 1.3.1
Conflicts: foobar <= 4.5
Libs: -L${libdir} -lgobject-1.3
Libs.private: -lm
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib/include
You would normally generate the file using configure, of course, so
that the prefix, etc. are set to the proper values.
Files have two kinds of line: keyword lines start with a keyword plus a
colon, and variable definitions start with an alphanumeric string plus
an equals sign. Keywords are defined in advance and have special mean-
ing to pkg-config; variables do not, you can have any variables that
you wish (however, users may expect to retrieve the usual directory
name variables).
Note that variable references are written "${foo}"; you can escape lit-
eral "${" as "$${".
Name: This field should be a human-readable name for the package. Note
that it is not the name passed as an argument to pkg-config.
Description:
This should be a brief description of the package
URL: An URL where people can get more information about and download
the package
Version:
This should be the most-specific-possible package version
string.
Requires:
This is a comma-separated list of packages that are required by
your package. Flags from dependent packages will be merged in to
the flags reported for your package. Optionally, you can specify
the version of the required package (using the operators =, <,
>, >=, <=); specifying a version allows pkg-config to perform
extra sanity checks. You may only mention the same package one
time on the Requires: line. If the version of a package is
unspecified, any version will be used with no checking.
Conflicts:
This optional line allows pkg-config to perform additional san-
ity checks, primarily to detect broken user installations. The
syntax is the same as Requires: except that you can list the
same package more than once here, for example "foobar = 1.2.3,
foobar = 1.2.5, foobar >= 1.3", if you have reason to do so. If
a version isn’t specified, then your package conflicts with all
versions of the mentioned package. If a user tries to use your
package and a conflicting package at the same time, then pkg-
config will complain.
Libs: This line should give the link flags specific to your package.
Don’t add any flags for required packages; pkg-config will add
those automatically.
Libs.private:
This line should list any private libraries in use. Private
libraries are libraries which are not exposed through your
library, but are needed in the case of static linking.
Cflags:
This line should list the compile flags specific to your pack-
age. Don’t add any flags for required packages; pkg-config will
add those automatically.
Jan D.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Eli Zaretskii skrev: Date: Thu, 07 Dec 2006 08:55:06 +0100 From: =?ISO-8859-1?Q?Jan_Dj=E4rv?= <[EMAIL PROTECTED]> Cc: Henrik Enberg <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org "PKG_CONFIG_PATH=/path/to/dir/with/foo.pc ./configure" Thanks, but this only works if the package installed privately installs foo.pc. Not every package does, since not every package supports pkg-config in its source distribution. That is true. A workaround woould be to copy the .pc-file that mentions foo to a private directory, edit it to point to your private foo, and then set PKG_CONFIG_PATH. Alas, I couldn't find any documentation of the *.pc files' format, so that I could edit the files. It is in the man page for pkg-config. pkg-config needs some kind of --use or --override switch so we could do this easier. Indeed. As things are now, it looks like the maintainers of pkg-config didn't _want_ you to have the freedom to point it to the non-default installation directories. Its origin is form the Gnome project after all... Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Eli Zaretskii skrev: Do we document the LDFLAGS-trick somewhere? Yes, in INSTALL. I've added some text about PKG_CONFIG_PATH also. In summary, pkg-config is a very helpful tool, but you have to get use to it. It is indeed useful, but only as long as your installation doesn't need to do something extraordinary. This seems to be in line with where Gnome seems to be going, less user customizations. Not that I agree with that philosophy. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Stephen Berman skrev: On Thu, 07 Dec 2006 11:11:18 +0100 Stephen Berman wrote: This was the state of things last night. This morning I wanted to pursue it but, to my surprise, I now cannot get GTK-Emacs to segfault. I first started it with no ~/.fonts.cache-2 and no /var/cache/fontconfig (and without setting LD_LIBRARY_PATH to /usr/local/lib) and, as last night, it started slow and a ~1.6 MB large ~/.fonts.cache-2 was rebuilt. But then I could start further instances without deleting ~/.fonts.cache-2, unlike last night. Moreover, when I moved fontconfig back into /var/cache/, I still could start GTK-Emacs (and a big ~/.fonts.cache-2 was again rebuilt). That's the current situation. So, I'm pleased that I have GTK-Emacs back again, but I would still like to know why I lost it in the first place, so if anyone has an suggestions, I'd be grateful. Well, now I can get GTK-Emacs to segfault again :-). I noticed that the desktop fonts didn't look as sharp as they normally do (it took me a while to notice this, probably because the fonts in Emacs are always not so sharp :-), so I ran fc-cache, exited KDE and logged on again. Now my desktop fonts are back to their previous sharpness, but Emacs-GTK segfaults again with the standard invocation (but I can start it by setting LD_LIBRARY_PATH to /usr/local/lib). So if someone is able to advise me how to debug this, I can try to do it. It is hard if Emacs doesn't fail with the debug-compiled fontconfig. Does wxGTK install fonts? The cache handling seems to have some bug in it. As it only fails sometimes it might be that the code that builds or reads the cache have some uninitialized variable that gets random garbage. Sometimes that garbage is OK, sometimes it isn't. If you rebuild the cache several times with the same fontconfig, are the ~/.fonts.cache-2 then identical? And are they different if you rebuild with the fontconfig you compiled? Does any other Gnome/GTK application fail when Emacs fails or is it just Emacs? Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Eli Zaretskii skrev: Date: Wed, 6 Dec 2006 21:05:29 +0100 From: Henrik Enberg <[EMAIL PROTECTED]> Cc: Jan =?iso-8859-1?Q?Dj=E4rv?= <[EMAIL PROTECTED]>, emacs-pretest-bug@gnu.org "PKG_CONFIG_PATH=/path/to/dir/with/foo.pc ./configure" Thanks, but this only works if the package installed privately installs foo.pc. Not every package does, since not every package supports pkg-config in its source distribution. That is true. A workaround woould be to copy the .pc-file that mentions foo to a private directory, edit it to point to your private foo, and then set PKG_CONFIG_PATH. pkg-config needs some kind of --use or --override switch so we could do this easier. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Eli Zaretskii skrev:
Btw, this pkg-config thingy is a terrible nuisance. I recently had to
build some package on a RH box, and was amazed to find that all the
``usual'' tricks of getting `configure' to use non-default include and
library paths simply don't work, because that package's `configure'
script used pkg-config to find all the headers and libraries, and as
you say above, what pkg-config returns cannot be overridden easily.
For example, "LDFLAGS=-L/whatever ./configure" cannot override the
places where the linker run by `configure' looks for libraries. This
means, for example, that if you are an underprivileged user who
installs packages and libraries under ~/, you have no hope of getting
the compiler and the linker to use headers and libraries in those
private directories, since pkg-config doesn't know about them and
keeps pointing the build process to the public directories.
It can be a pain sometimes, but for the most part it works quite well.
(If there's a reasonable way of working around this, please let me
know.)
As Henrik Enberg pointed out:
"PKG_CONFIG_PATH=/path/to/dir/with/foo.pc ./configure"
PKG_CONFIG_PATH can be set like PATH, and pkg-config will search those
directories for foo.pc. This file defines what foo needs to compile and link,
like for example gtk+-2.0.pc:
Requires: gdk-${target}-2.0 atk cairo
${target} expands to x11 in my case.
Then pkg-config searches for gdk-x11-2.0.pc, atk.pc and pango.pc, using the
same PKG_CONFIG_PATH.
Do we document the LDFLAGS-trick somewhere? We should add something about
PKG_CONFIG_PATH there.
I hope Emacs will _never_ use pkg-config for anything serious, because
otherwise I will be at the mercy of the sysadmins on too many systems
I work on, where I cannot become a superuser and "make install" the
optional image libraries needed by Emacs. (Also, most of the Emacs
INSTALL file will become incorrect if we ever start using pkg-config,
and even now the GTK build is already hit by this problem.)
Why in the world would GNU/Linux developers wish to use such a
restrictive tool? Do they somehow miss the non-freedom of MS-Windows?
:-) AFAIK pkg-config is available for MS-Windows.
The initial motivation (I think) was that the thing pkg-config does was too
complicated for configure. For example, if lib A needs lib X and Y, and lib B
also needs X, you would before pkg-config have two -l/path/to/X -lX in your
link command line. And this would multiply. I've seen command lines with the
same stuff repeated over and over again so eventually the line was too long to
execute.
It also manages cascading dependencies, i.e. A depends on X but X itself
depends on B and maybe C if X version is > 1.4. Then C depends on D and E.
This is too complicated for configure, so here pkg-config does a really nice
job.
It is also very nice to be able to write in your Makefile:
PKG = libgnomeui-2.0
prog: $(OBJ)
$(CXX) -o $@ $(OBJS) `pkg-config $(PKG) --libs`
and you get all required stuff linked in.
Also, you can easily query for required version, like Emacs does in
configure.in:
pkg-config --exists "gtk+-2.0 >= 2.4 glib-2.0 > 2.4"
In summary, pkg-config is a very helpful tool, but you have to get use to it.
Jan D.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Hmm, modifying the Makefile wont do, as pango dynamically links in fontconfig at runtime. If you built fontconfig under /usr/local/lib and the libfontconfig.so file is in /usr/local/lib, you should be able to do % LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH % export LD_LIBRARY_PATH % emacs or % gdb emacs to get Emacs to use the fontconfig you have compiled. I haven't tried this though. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: GTK build crashes under X
Stephen Berman skrev: CPPFLAGS='-I/usr/local/include/fontconfig' LDFLAGS='-L/usr/local/lib' LIBS='-llibfontconfig' ../emacs-22.0.90/configure --with-x-toolkit=gtk make then built emacs without error, and as expected, it still segfaults. But when I run it under gdb, I still get the same backtrace as before: #0 0xb75748fa in strcmp () from /lib/libc.so.6 No symbol table info available. #1 0xb7a7db45 in FcObjectToPtr () from /usr/lib/libfontconfig.so.1 No symbol table info available. #2 0xb7a81741 in FcPatternAddWithBinding () from /usr/lib/libfontconfig.so.1 No symbol table info available. #3 0xb7a81df8 in FcPatternAdd () from /usr/lib/libfontconfig.so.1 No symbol table info available. #4 0xb7a81e84 in FcPatternBuild () from /usr/lib/libfontconfig.so.1 No symbol table info available. It seems that the variable LIBS I passed to configure (following the example in etc/INSTALL) wasn't used by make. Did I do something wrong? How do I get emacs to use the libfontconfig I built? (I also tried LIBS='-l/usr/local/lib/libfontconfig.so.1' but that makes configure fail.) When building for Gtk, Emacs uses the libs given by pkg-config. You can not override it easily. I guess you have to do configure the normal way, and then edit src/Makefile and put in your fontconfig library there. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Mysterious fontification/C++ context issue
martin rudalics skrev: >> I see this too a lot, even in plain C files. A backtrace when this >> happen looks like this: >> >> Debugger entered--Lisp error: (scan-error "Containing expression ends >> prematurely" 107612 107612) >> scan-lists(107699 -1 0) >> forward-list(-1) >> backward-list(1) >> beginning-of-defun-raw(nil) >> beginning-of-defun() >> c-get-fallback-start-pos(108117) >> c-parse-state() >> c-electric-semi&comma(nil) >> call-interactively(c-electric-semi&comma) >> call-last-kbd-macro(nil kmacro-loop-setup-function) >> kmacro-call-macro(nil nil) >> kmacro-end-and-call-macro(nil) >> call-interactively(kmacro-end-and-call-macro) >> >> Usually moving the cursor up a few lines, hitting tab to indent that >> line, and then move back to the offending line cures it. > > It's a consequence of the recent change to `beginning-of-defun-raw'. > Compare the threads "font-locking and open parens in column 0" and > "emacs hangs in jit-lock". Ok. IMHO this must be fixed before release, editing C/C++ is very hard with this error. I haven't been able to find a short test case that triggers it though. Jan D. ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
