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.
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
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
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
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
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
Nick Roberts skrev:
If I click on tool-bar buttons e.g. when the *scratch* buffer is current, I
get messages like:
write-file is undefined
dired 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.
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:
write-file is undefined
dired is undefined
I don't know if this is particular to the trunk, using GTK, or my build
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
11745
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
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
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
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
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.
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
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'.
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
[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
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
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
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
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
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.
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
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
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
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
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 ()
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
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
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
[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.
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
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
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
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
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
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
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
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
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/
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.
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
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
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
[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
[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
[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
%
.
Jan Djärv [EMAIL PROTECTED
[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
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
.
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
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
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
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
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
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
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
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
%
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
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
Tim Van Holder skrev:
For a few weeks now, I've had intermittent issues editing C++ code in
Emacs; I was hoping to find some minimal reproducible case, but have
been unable to do so.
The symptoms are that while editing a C++ source file (typically
happens when killing or yanking, but I think
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)
Robert Marshall skrev:
On Sat, 02 Dec 2006, Chong Yidong wrote:
robert marshall [EMAIL PROTECTED] writes:
I'm using the mail reader vm (version 7.19), start up emacs -Q, add the
vm directory to the load path M-x vm-visit-folder and selected a mail
folder and then used v (bound to
Chong Yidong skrev:
There was one controversial patch
applied to src/xterm.c at the beginning of November, which may have
some bearing on this. This is just a hunch, but could you apply the
reversed patch and see if the problem persists?
Applying that patch fixed the problem. I'm much
Jonathan Corbet skrev:
Jan Dj채rv [EMAIL PROTECTED] wrote:
I'd say it is a bug in metacity (there are
plenty already ...), but I've changed that bit in Emacs so we only send
_NET_ACTIVATE_WINDOW on explicit raise-frame calls.
I have no trouble believing that it could be a metacity bug - but
Chris Moore skrev:
According to the documentation string, make-frame-visible will Make
the frame FRAME visible (assuming it is an X window).
If the frame is iconized, then make-frame-visible restores it, so it's
visible. But if the frame is just covered by other windows,
make-frame-visible
Chris Moore skrev:
Jan Djärv [EMAIL PROTECTED] writes:
It is the intended behaviour. Visible means not iconified and not
withdrawn.
OK, I was working with the more traditional definition:
perceptible to the eye.
I don't know how common your definition is, but I would suggest
Stephen Berman skrev:
fc-cache: /usr/X11R6/lib/X11/fonts/uni: skipping, looped directory detected
fc-cache: /opt/kde3/share/fonts/override: skipping, looped directory detected
fc-cache: /usr/lib/ooo-2.0/share/fonts: skipping, 0 fonts, 1 dirs
fc-cache: /usr/lib/ooo-2.0/share/fonts/truetype:
Chris Moore skrev:
Jan Djärv [EMAIL PROTECTED] writes:
It is commin X11 terminology at least. And it is even used in the
documentation for raise-frame:
If frame is invisible or iconified, make it visible
The difference there is that if the window is 'buried' then it is
shown, ie. made
Chris Moore skrev:
Stefan Monnier [EMAIL PROTECTED] writes:
What term do you propose to distinguish between a window which is
displayed but cannot be seen because it's hidden by others, and a
window which is not even displayed?
That's a good question. mapped perhaps? Or does that mean
Stephen Berman skrev:
I've been using the GTK build of the first pretest tarball for almost
three weeks without any serious problems. But as of today it
immediately segfaults when I start it under X. The only change to my
system (SUSE 10.1) between today and the last time I started this
Jan Djärv skrev:
Hello.
If I set c-backslash-column to 79, I don't get backslahses at column 79,
but at column 72. Cc-mode silently truncates the column to an even
tab-width. I could not find any documentation on this behaviour, nor is
there any way to turn it off, so I can get
Hello.
If I set c-backslash-column to 79, I don't get backslahses at column 79, but
at column 72. Cc-mode silently truncates the column to an even tab-width. I
could not find any documentation on this behaviour, nor is there any way to
turn it off, so I can get backslashes at column 79.
A similar bug was fixed some days ago, make sure your CVS is up to date.
Jan D.
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Tetsurou Okazaki skrev:
Hi,
My environment, gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-98),
requires the following patch to build CVS-head Emacs again.
Please apply this.
Applied.
Jan D.
2006-11-17 Tetsurou Okazaki [EMAIL PROTECTED] (tiny change)
* xterm.c
Tim Van Holder skrev:
3) If the O_NONBLOCK flag actually gets set on the socket, emacslient
no longer works - emacs gets the request, opens the file, then
immediately
closes it again (presumably because the client is gone). This does not
happen when the O_NONBLOCK/O_NDELAY flag is
1 - 100 of 132 matches
Mail list logo
