Re: Updated: emacs*-24.2.90-1 (TEST)

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/2/2012 6:35 PM, Jim Reisert AD1C wrote:
> On Sun, Dec 2, 2012 at 5:43 AM, Ken Brown <kbrown@cornell.edu> wrote:
>> In this release, for the first time, I've been able to build Cygwin's
>> emacs-X11 with all of the upstream defaults.  In particular, the build uses
>> GTK+-3 instead of GTK+-2, and it supports GNOME's GSettings and GConf
>> features.  A minor consequence of this is that you might see a GTK warning
>> about gtk_window_parse_geometry; this can be ignored.  A more important
>> consequence is that you should have a D-Bus session daemon running before
>> starting emacs under X11.  The simplest way to achieve this is to put the
>> following line at the beginning of your ~/.startxwinrc file:
>>
>>    eval `dbus-launch --sh-syntax`
>>
>> See /usr/share/doc/emacs/README.Cygwin for more information.

 > Hi Ken,
 >
 > After installing, I got these warnings error when I first started Emacs:
 >
 > [JJR:~] $ emacs
 >
 > (emacs:5940): GLib-WARNING **: In call to g_spawn_sync(), exit status
 > of a child process was requested but SIGCHLD action was set to SIG_IGN
 > and ECHILD was received by waitpid(), so exit status can't be
 > returned. This is a bug in the program calling g_spawn_sync(); either
 > don't request the exit status, or don't set the SIGCHLD action.
 >
 > ** (emacs:5940): WARNING **: Abnormal program termination spawning
 > command line `dbus-launch
 > --autolaunch=d4e8d39fb9cc546947a687f94fa28e98 --binary-syntax
 > --close-stderr':
 >
 >

Hi Jim,

Yes, that's why you should have a D-Bus session daemon running before 
starting emacs.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/3/2012 12:53 PM, Jim Reisert AD1C wrote:
> On Mon, Dec 3, 2012 at 10:48 AM, Jim Reisert AD1C
> <jjreisert@alum.mit.edu> wrote:
>
>>> Yes, that's why you should have a D-Bus session daemon running before
>>> starting emacs.
>>
>> And that's why I should read the entire release note.  Working find now, thanks!
>
> I started emacs, exited, then started it again. the second time I got
> this same stuff:
>
> (emacs:1672): GLib-WARNING **: In call to g_spawn_sync(), exit status
> of a child process was requested but SIGCHLD action was set to SIG_IGN
> and ECHILD was received by waitpid(), so exit status can't be
> returned. This is a bug in the program calling g_spawn_sync(); either
> don't request the exit status, or don't set the SIGCHLD action.
>
> ** (emacs:1672): WARNING **: Abnormal program termination spawning
> command line `dbus-launch
> --autolaunch=3f052ecf1e24145e3fdb40554f55370e --binary-syntax
> --close-stderr':
>
>
> Could the dBus daemon have crashed?  I do see dbus stuff running in
> the Windows 7 task manager.

Let's keep this discussion on the list, because I'm sure there will be 
other people having trouble with the new dbus requirement.

I doubt if the dbus daemon crashed.  How did you start emacs the second 
time?  Did you do it by typing `emacs' in an xterm window?  If so, you 
shouldn't have gotten those error messages (assuming you started the 
D-Bus daemon the way I suggested in the release announcement).

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/3/2012 1:28 PM, Ken Brown wrote:
> On 12/3/2012 12:53 PM, Jim Reisert AD1C wrote:
>> On Mon, Dec 3, 2012 at 10:48 AM, Jim Reisert AD1C
>> <jjreisert@alum.mit.edu> wrote:
>>
>>>> Yes, that's why you should have a D-Bus session daemon running before
>>>> starting emacs.
>>>
>>> And that's why I should read the entire release note.  Working find
>>> now, thanks!
>>
>> I started emacs, exited, then started it again. the second time I got
>> this same stuff:
>>
>> (emacs:1672): GLib-WARNING **: In call to g_spawn_sync(), exit status
>> of a child process was requested but SIGCHLD action was set to SIG_IGN
>> and ECHILD was received by waitpid(), so exit status can't be
>> returned. This is a bug in the program calling g_spawn_sync(); either
>> don't request the exit status, or don't set the SIGCHLD action.
>>
>> ** (emacs:1672): WARNING **: Abnormal program termination spawning
>> command line `dbus-launch
>> --autolaunch=3f052ecf1e24145e3fdb40554f55370e --binary-syntax
>> --close-stderr':
>>
>>
>> Could the dBus daemon have crashed?  I do see dbus stuff running in
>> the Windows 7 task manager.
>
> Let's keep this discussion on the list, because I'm sure there will be
> other people having trouble with the new dbus requirement.
>
> I doubt if the dbus daemon crashed.  How did you start emacs the second
> time?  Did you do it by typing `emacs' in an xterm window?  If so, you
> shouldn't have gotten those error messages (assuming you started the
> D-Bus daemon the way I suggested in the release announcement).

I'm also assuming that you started xterm in ~/.startxwinrc.  If you have 
some other preferred way of starting your X applications, there's a 
different way of starting the D-Bus daemon that might work better for 
you.  See /usr/share/doc/emacs/README.Cygwin.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Ken Brown writes:
> I think it's time to take this to the emacs list.  I've just filed a
> bug report (bug#13112) in order to focus the discussion.

Thanks, I'll follow up there if necessary.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/7/2012 2:37 AM, Achim Gratz wrote:
> Thanks.  Now, after I set "DejaVu Sans Mono" for X11 and "Consolas" for W32, the
> problem with emacs hanging up on me is gone as well.  So it seems that the
> invocation of the xft(?) stuff was to blame...

This shouldn't happen.  Daniel, shouldn't *all* the X11 stuff be 
disabled in the cygw32 build?  The GSettings and GConf problems I 
mentioned earlier in the thread wouldn't have occurred if this were done.

I think it's time to take this to the emacs list.  I've just filed a bug 
report (bug#13112) in order to focus the discussion.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Ken Brown <kbrown <at> cornell.edu> writes:
> Emacs will *try* to autolaunch a D-Bus session if it doesn't find one, 
> but this feature is broken in the emacs-24 branch (and the problem is 
> not Cygwin-specific).  This is Emacs bug #8855.  It's been fixed in the 
> trunk, but the fix is complicated and probably won't be backported to 
> the emacs-24 branch.

OK, that explains why I don't see it on Linux, I'm currently using trunk there.

> I didn't want to complicate the release 
> announcement by giving all this information; I thought it would be 
> enough to say, "... you should have a D-Bus session daemon running 
> before starting emacs under X11."

Understood. s/should/must/

BTW, as noted elsewhere in the thread, the hang was apparently triggered by the
attempt to use an X11 font in the W32 build via custom-set-faces (due to the
fact that both builds used the same .emacs and customization), so it does not
happen with emacs -Q.  In fact, I've not been able to even try using that font
any other way so far, both "--font" and "--eval '(set-default-font" correctly
refuse to use this undefined font.  Why it manages to bypass that guard when
invoked via custom-set-faces I need to check again.


Regards,
Achim.






--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Daniel Colascione <dancol <at> dancol.org> writes:
> > I need to keep the emacs-w32 and emacs-gtk under cygwin apart and AFAIK
> > they both get reported as 'cygwin.  So I was looking for a way to know
> > this other than by looking at the build string.
> 
> Ah. You want (window-system) then.

Thanks.  Now, after I set "DejaVu Sans Mono" for X11 and "Consolas" for W32, the
problem with emacs hanging up on me is gone as well.  So it seems that the
invocation of the xft(?) stuff was to blame...  I would use Consolas for X11,
but it renders horribly (like a bold font) with xft and I've not been able to
fix it.


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

On 12/6/12 7:13 PM, Ken Brown wrote:> And I've just discovered what
that something is:  After the cygw32
> build is configured, HAVE_GSETTINGS and HAVE_GCONF are defined to be 1
> in src/config.h (assuming you have the relevant -devel packages
> installed).  And GSettings and GConf are Glib features that require a
> D-Bus daemon.
>
> A workaround is to add the configure options --without-gsettings and
> --without-gconf, but that shouldn't be necessary.  If the --with-w32
> option is given, then configure shouldn't even be checking for
> GSettings and GConf.  Can you fix this?

Will do. I suspect it's because I simply don't have these libraries
installed that the problem doesn't show up in my build.

I'll see whether I can fix the icon issue before the final release too.

Thanks for tracking down the problem.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/6/2012 4:25 PM, Daniel Colascione wrote:
> Thanks for highlighting the issue.
>
> On 12/6/12 1:00 PM, Ken Brown wrote:
>> On 12/6/2012 1:47 PM, Achim Gratz wrote:
>>> Ken Brown writes:
>>>> emacs-w32 shouldn't require dbus-daemon, as far as I know.  This
>>>> sounds like a bug.  Could you give me a specific recipe for
>>>> reproducing the problem?
>>>
>>> Just make sure Cygwin has cleanly terminated, then open a mintty (I use
>>> tcsh if that has a bearing on this bug) and start emacs-w32 from it.
>>> Toggle the menu bar if it's not already on an select File->Open from
>>> it.
>>> Open another mintty and try to kill the hanging emacs process from it.
>
> Works fine for me, albeit using kill -9, not regular kill. What
> exactly do you see? According to a message upthread, Emacs hangs hard
> any time you try to open a dialog box. Can you please attach gdb to
> Emacs when it's in this state and get a backtrace?
>
> If these problems persist, my first instinct would be to not support
> dbus in cygw32 builds of Emacs. People mostly use dbus to integrate
> components of a Unixish desktop environment, and I imagine users of
> cygw32 want to use Cygwin Emacs as part of a Windowsish desktop
> environment, which uses USER32 facilities to do what other
> environments do with dbus.

D-Bus support is not the issue.  Even emacs-nox supports D-Bus, and it 
has done so for more than 2 years.  In other words, you can use all the 
features of dbus.el if you want.

The issue here is completely different.  It's that something in the 
cygw32 build of emacs is making emacs think it *needs* a D-Bus daemon, 
even though the user has not tried to use dbus.el, and even though the 
cygw32 build should work without a D-Bus daemon.

And I've just discovered what that something is:  After the cygw32 build 
is configured, HAVE_GSETTINGS and HAVE_GCONF are defined to be 1 in 
src/config.h (assuming you have the relevant -devel packages installed). 
  And GSettings and GConf are Glib features that require a D-Bus daemon.

A workaround is to add the configure options --without-gsettings and 
--without-gconf, but that shouldn't be necessary.  If the --with-w32 
option is given, then configure shouldn't even be checking for GSettings 
and GConf.  Can you fix this?  I thought the following patch would fix 
it, but it doesn't:

=== modified file 'configure.ac'
--- configure.ac        2012-12-05 04:05:57 +0000
+++ configure.ac        2012-12-07 03:02:33 +0000
@@ -1603,6 +1603,8 @@
  if test "${HAVE_W32}" = "yes"; then
    window_system=w32
    with_xft=no
+  with_gsettings=no
+  with_gconf=no
  fi

  ## $window_system is now set to the window system we will

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/6/2012 4:37 PM, Achim Gratz wrote:
> Ken Brown writes:
>> I don't see the issue here.  I said in the release announcement that
>> you need to have a D-Bus daemon running before starting emacs-X11
>> under X.
>
> On all other system Emacs successfully finds an existing or autolaunches
> a new dbus session in this case and doesn't hang with no way to even
> kill it (yes, task manager will do it eventually, but that is from
> outside Cygwin).  The problem is not that it does need dbus, but that it
> actually starts without it but will then not be working correctly.
> Whether this is an issue with Emacs, Cygwin or libdbus I don't know.

Emacs will *try* to autolaunch a D-Bus session if it doesn't find one, 
but this feature is broken in the emacs-24 branch (and the problem is 
not Cygwin-specific).  This is Emacs bug #8855.  It's been fixed in the 
trunk, but the fix is complicated and probably won't be backported to 
the emacs-24 branch.  I didn't want to complicate the release 
announcement by giving all this information; I thought it would be 
enough to say, "... you should have a D-Bus session daemon running 
before starting emacs under X11."

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1022 bytes --]

On 12/6/12 1:51 PM, Achim Gratz wrote:
> Daniel Colascione writes:
>>>> Open another mintty and try to kill the hanging emacs process from it.
>>
>> Works fine for me, albeit using kill -9, not regular kill. What
>> exactly do you see?
> 
> The kill command (with -KILL or any other signal) never returns until I
> terminate emacs from task manager.  I then often see some error message
> about "broken pipe" in the mintty that issued the kill, presumably from
> a failed attempt to connect to a dbus session via pipes.
> 
>> According to a message upthread, Emacs hangs hard
>> any time you try to open a dialog box. Can you please attach gdb to
>> Emacs when it's in this state and get a backtrace?
> 
> Will try later, I can't promise when I get to it.

Thanks. Make sure you grab all threads.

> Here's one other thing I forgot to mention: this emacs shows up in the
> task pane with a generic icon, not as Emacs.

That's a known bug. I haven't had a chance to look at it, unfortunately.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Updated: emacs*-24.2.90-1 (TEST)

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 665 bytes --]

On 12/6/12 1:54 PM, Achim Gratz wrote:
> Daniel Colascione writes:
>> Under Cygwin, the variable system-type will be 'cygwin; under Windows,
>> it will be 'windows-nt. You can perform conditional initialization as
>> follows:
>>
>> (cond ((eq system-type 'cygwin) (cygwin-specific-initialization))
>>       ((eq system-type 'windows-nt) (windows-specific-initialization))
>>       (t (default-initialization))
> 
> I need to keep the emacs-w32 and emacs-gtk under cygwin apart and AFAIK
> they both get reported as 'cygwin.  So I was looking for a way to know
> this other than by looking at the build string.

Ah. You want (window-system) then.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Daniel Colascione writes:
> Under Cygwin, the variable system-type will be 'cygwin; under Windows,
> it will be 'windows-nt. You can perform conditional initialization as
> follows:
>
> (cond ((eq system-type 'cygwin) (cygwin-specific-initialization))
>       ((eq system-type 'windows-nt) (windows-specific-initialization))
>       (t (default-initialization))

I need to keep the emacs-w32 and emacs-gtk under cygwin apart and AFAIK
they both get reported as 'cygwin.  So I was looking for a way to know
this other than by looking at the build string.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Daniel Colascione writes:
>>> Open another mintty and try to kill the hanging emacs process from it.
>
> Works fine for me, albeit using kill -9, not regular kill. What
> exactly do you see?

The kill command (with -KILL or any other signal) never returns until I
terminate emacs from task manager.  I then often see some error message
about "broken pipe" in the mintty that issued the kill, presumably from
a failed attempt to connect to a dbus session via pipes.

> According to a message upthread, Emacs hangs hard
> any time you try to open a dialog box. Can you please attach gdb to
> Emacs when it's in this state and get a backtrace?

Will try later, I can't promise when I get to it.

Here's one other thing I forgot to mention: this emacs shows up in the
task pane with a generic icon, not as Emacs.

> If these problems persist, my first instinct would be to not support
> dbus in cygw32 builds of Emacs. People mostly use dbus to integrate
> components of a Unixish desktop environment, and I imagine users of
> cygw32 want to use Cygwin Emacs as part of a Windowsish desktop
> environment, which uses USER32 facilities to do what other
> environments do with dbus.

Turning the tables: what is dbus integration useful for in that build?
If it isn't something really compelling, then I'd think it should be
left out since this emacs will be most useful when no X session has been
started (and hence most likely no dbus either).  At least that is what I
am going to do.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

On 12/6/12 1:37 PM, Achim Gratz wrote:
> Yes, either that or via site-init.el.  Currently when it reads in the
> customization it finds a default font that doesn't make any sense in
> Win32 and it ends up using Arial (probably because its the first on the
> list, so it seems it doesn't even bother to look for a fixed-width
> font).  Trying to set the font on the command line doesn't seem to work
> or gets later overridden by customization (I haven't had the time to
> debug this yet).

Under Cygwin, the variable system-type will be 'cygwin; under Windows,
it will be 'windows-nt. You can perform conditional initialization as
follows:

(cond ((eq system-type 'cygwin) (cygwin-specific-initialization))
      ((eq system-type 'windows-nt) (windows-specific-initialization))
      (t (default-initialization))




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Ken Brown writes:
> I'm not sure about the dbus-launch issue, since I always use bash.
> But here's the output I get from `dbus-launch --csh-syntax':
>
> setenv DBUS_SESSION_BUS_ADDRESS
> unix:path=/tmp/dbus-wCGlBfQgo6,guid=f3e1dad82fc7ce9eff209b9300000000';
> set DBUS_SESSION_BUS_PID=5020;
>
> What's the problem with that?  As I understand csh syntax, the second
> line sets a variable but doesn't export it.  Do you have some reason
> to think that's the wrong thing to do?  If so, it's a D-bus issue and
> should be reported in a different thread.

I was under the impression that the second variable also needed to be in
the environment, but its apparently not used by libdbus.  So please
disregard.

> I don't see the issue here.  I said in the release announcement that
> you need to have a D-Bus daemon running before starting emacs-X11
> under X.

On all other system Emacs successfully finds an existing or autolaunches
a new dbus session in this case and doesn't hang with no way to even
kill it (yes, task manager will do it eventually, but that is from
outside Cygwin).  The problem is not that it does need dbus, but that it
actually starts without it but will then not be working correctly.
Whether this is an issue with Emacs, Cygwin or libdbus I don't know.

>> One other thing: how to tell this emacs apart from the Gtk build so that
>> I can switch the default font for each?
>
> I'm out of time right now, but I'll be able to answer this later.
> Just to make sure I understand, you want to be able to do this in your
> ~/.emacs, right?

Yes, either that or via site-init.el.  Currently when it reads in the
customization it finds a default font that doesn't make any sense in
Win32 and it ends up using Arial (probably because its the first on the
list, so it seems it doesn't even bother to look for a fixed-width
font).  Trying to set the font on the command line doesn't seem to work
or gets later overridden by customization (I haven't had the time to
debug this yet).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]

Thanks for highlighting the issue.

On 12/6/12 1:00 PM, Ken Brown wrote:
> On 12/6/2012 1:47 PM, Achim Gratz wrote:
>> Ken Brown writes:
>>> emacs-w32 shouldn't require dbus-daemon, as far as I know.  This
>>> sounds like a bug.  Could you give me a specific recipe for
>>> reproducing the problem?
>>
>> Just make sure Cygwin has cleanly terminated, then open a mintty (I use
>> tcsh if that has a bearing on this bug) and start emacs-w32 from it.
>> Toggle the menu bar if it's not already on an select File->Open from
>> it.
>> Open another mintty and try to kill the hanging emacs process from it.

Works fine for me, albeit using kill -9, not regular kill. What
exactly do you see? According to a message upthread, Emacs hangs hard
any time you try to open a dialog box. Can you please attach gdb to
Emacs when it's in this state and get a backtrace?

If these problems persist, my first instinct would be to not support
dbus in cygw32 builds of Emacs. People mostly use dbus to integrate
components of a Unixish desktop environment, and I imagine users of
cygw32 want to use Cygwin Emacs as part of a Windowsish desktop
environment, which uses USER32 facilities to do what other
environments do with dbus.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/6/2012 1:47 PM, Achim Gratz wrote:
> Ken Brown writes:
>> emacs-w32 shouldn't require dbus-daemon, as far as I know.  This
>> sounds like a bug.  Could you give me a specific recipe for
>> reproducing the problem?
>
> Just make sure Cygwin has cleanly terminated, then open a mintty (I use
> tcsh if that has a bearing on this bug) and start emacs-w32 from it.
> Toggle the menu bar if it's not already on an select File->Open from it.
> Open another mintty and try to kill the hanging emacs process from it.
> Then use the task mamanger to really kill it and get a "broken pipe"
> message in the second mintty.  Now dbus-launch in the first mintty and
> set the two environment variables (btw, here's another bug: if you
> specify csh-style, you'll get the first one for csh alright, but the
> second one is still in shell syntax).  Start emacs-w32 again and observe
> that you now get a functional W32 file open dialog.  You can also kill
> emacs from the second mintty with no ill effects (well, poor emacs dies,
> but that's expected).

I can reproduce this.  (I use bash, so tcsh isn't the issue.)  I'll see 
if I can debug it, but I'm copying Daniel in the hope that he gets to it 
first.

I'm not sure about the dbus-launch issue, since I always use bash.  But 
here's the output I get from `dbus-launch --csh-syntax':

setenv DBUS_SESSION_BUS_ADDRESS 
'unix:path=/tmp/dbus-wCGlBfQgo6,guid=f3e1dad82fc7ce9eff209b9300000000';
set DBUS_SESSION_BUS_PID=5020;

What's the problem with that?  As I understand csh syntax, the second 
line sets a variable but doesn't export it.  Do you have some reason to 
think that's the wrong thing to do?  If so, it's a D-bus issue and 
should be reported in a different thread.

>
>>> manager (the Gtk build will also hang up on you in a slightly different way
>>> after you close the dialog box it has shown).  I believe this is related to pipe
>>> handling as you'll get messages about broken pipes sometimes.
>>
>> Again, please send a recipe for producing the problem with the Gtk build.
>
> Same thing as above, just with emacs-gtk, after having started
> multiwindow X11 and setting DISPLAY environment in the shell.  Unless
> dbus is started and emacs can connect to it, emacs hangs up when you
> cancel the file open dialog (obviously from Gtk).

I don't see the issue here.  I said in the release announcement that you 
need to have a D-Bus daemon running before starting emacs-X11 under X.

> One other thing: how to tell this emacs apart from the Gtk build so that
> I can switch the default font for each?

I'm out of time right now, but I'll be able to answer this later.  Just 
to make sure I understand, you want to be able to do this in your 
~/.emacs, right?

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Ken Brown writes:
> emacs-w32 shouldn't require dbus-daemon, as far as I know.  This
> sounds like a bug.  Could you give me a specific recipe for
> reproducing the problem?

Just make sure Cygwin has cleanly terminated, then open a mintty (I use
tcsh if that has a bearing on this bug) and start emacs-w32 from it.
Toggle the menu bar if it's not already on an select File->Open from it.
Open another mintty and try to kill the hanging emacs process from it.
Then use the task mamanger to really kill it and get a "broken pipe"
message in the second mintty.  Now dbus-launch in the first mintty and
set the two environment variables (btw, here's another bug: if you
specify csh-style, you'll get the first one for csh alright, but the
second one is still in shell syntax).  Start emacs-w32 again and observe
that you now get a functional W32 file open dialog.  You can also kill
emacs from the second mintty with no ill effects (well, poor emacs dies,
but that's expected).

>> manager (the Gtk build will also hang up on you in a slightly different way
>> after you close the dialog box it has shown).  I believe this is related to pipe
>> handling as you'll get messages about broken pipes sometimes.
>
> Again, please send a recipe for producing the problem with the Gtk build.

Same thing as above, just with emacs-gtk, after having started
multiwindow X11 and setting DISPLAY environment in the shell.  Unless
dbus is started and emacs can connect to it, emacs hangs up when you
cancel the file open dialog (obviously from Gtk).

> If it turns out to be necessary, which I doubt, you can simply put the
> following in your .bashrc (assuming you use bash as your shell):
>
> if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
>     eval `dbus-launch --sh-syntax`
> fi

I don't normally, and the real problem will be shortcuts that so far
fired up a mintty with emacs-nox in it.  I was hoping they could simply
start emacs-w32, but I'll have to figure out how not to start a new dbus
session for each of them when it turns out that this is necessary (I
still hope it's not).

One other thing: how to tell this emacs apart from the Gtk build so that
I can switch the default font for each?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/6/2012 3:21 AM, Achim Gratz wrote:
>> Ken Brown <kbrown <at> cornell.edu> writes:
>>> Thanks to the efforts of Daniel Colascione, there is also a new package
>>>
>>> *** emacs-w32-24.2.90-1,
>>>
>>> again a test release, for users who want to use the native Windows GUI
>>> for display.
>
> I've encountered only one problem so far:
>
> If I start emacs-w32 from a mintty without launching dbus-daemon first and use
> any command that should bring up a dialog box, then Emacs hangs up hard and
> can't even be killed from Cygwin.  You have to end its misery from the task

emacs-w32 shouldn't require dbus-daemon, as far as I know.  This sounds 
like a bug.  Could you give me a specific recipe for reproducing the 
problem?  And it couldn't hurt to send cygcheck output also.

> manager (the Gtk build will also hang up on you in a slightly different way
> after you close the dialog box it has shown).  I believe this is related to pipe
> handling as you'll get messages about broken pipes sometimes.

Again, please send a recipe for producing the problem with the Gtk build.

> Anyway, since it's not obvious that and why emacs-w32 would need dbus to
> function I thought I should mention it here.  I would prefer if it was only
> needed for the Gtk build, otherwise I'll have to come up with a wrapper script
> that ensures dbus is started.

If it turns out to be necessary, which I doubt, you can simply put the 
following in your .bashrc (assuming you use bash as your shell):

if [ -z "$DBUS_SESSION_BUS_ADDRESS" ] ; then
     eval `dbus-launch --sh-syntax`
fi

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

> Ken Brown <kbrown <at> cornell.edu> writes:
> > Thanks to the efforts of Daniel Colascione, there is also a new package
> > 
> > *** emacs-w32-24.2.90-1,
> > 
> > again a test release, for users who want to use the native Windows GUI 
> > for display.

I've encountered only one problem so far: 

If I start emacs-w32 from a mintty without launching dbus-daemon first and use
any command that should bring up a dialog box, then Emacs hangs up hard and
can't even be killed from Cygwin.  You have to end its misery from the task
manager (the Gtk build will also hang up on you in a slightly different way
after you close the dialog box it has shown).  I believe this is related to pipe
handling as you'll get messages about broken pipes sometimes.

Anyway, since it's not obvious that and why emacs-w32 would need dbus to
function I thought I should mention it here.  I would prefer if it was only
needed for the Gtk build, otherwise I'll have to come up with a wrapper script
that ensures dbus is started.


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Jim Reisert AD1C writes:
> When I start my X server, I see one dbus-daemon.exe process running.
> As soon as I start "emacs" the first time, there is a second
> dbus-daemon.exe as well as a dbus-launch.exe.

Emacs must see the DBUS_SESSION_BUS_ADDRESS environment variable that
tells it how to connect to the existing dbus session, otherwise it will
try to start another dbus session.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/3/2012 1:50 PM, Jim Reisert AD1C wrote:
> I started emacs, exited, then started it again. the second time I got
> this same stuff, as if the dbus-daemon had crashed:
>
> (emacs:1672): GLib-WARNING **: In call to g_spawn_sync(), exit status
> of a child process was requested but SIGCHLD action was set to SIG_IGN
> and ECHILD was received by waitpid(), so exit status can't be
> returned. This is a bug in the program calling g_spawn_sync(); either
> don't request the exit status, or don't set the SIGCHLD action.
>
> ** (emacs:1672): WARNING **: Abnormal program termination spawning
> command line `dbus-launch
> --autolaunch=3f052ecf1e24145e3fdb40554f55370e --binary-syntax
> --close-stderr':
>
> When I start my X server, I see one dbus-daemon.exe process running.

That's the way it should be.

> As soon as I start "emacs" the first time, there is a second
> dbus-daemon.exe as well as a dbus-launch.exe.

That shouldn't happen.  Can you show me the contents of ~/.startxwinrc? 
  And exactly how are you starting emacs?  Is it from an xterm that is 
started in ~/.startxwinrc?  If not, then the method I suggested for 
starting a D-Bus daemon might not work for you.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Jim Reisert AD1C]

I started emacs, exited, then started it again. the second time I got
this same stuff, as if the dbus-daemon had crashed:

(emacs:1672): GLib-WARNING **: In call to g_spawn_sync(), exit status
of a child process was requested but SIGCHLD action was set to SIG_IGN
and ECHILD was received by waitpid(), so exit status can't be
returned. This is a bug in the program calling g_spawn_sync(); either
don't request the exit status, or don't set the SIGCHLD action.

** (emacs:1672): WARNING **: Abnormal program termination spawning
command line `dbus-launch
--autolaunch=3f052ecf1e24145e3fdb40554f55370e --binary-syntax
--close-stderr':

When I start my X server, I see one dbus-daemon.exe process running.
As soon as I start "emacs" the first time, there is a second
dbus-daemon.exe as well as a dbus-launch.exe.

Something is not quite right here...

--
Jim Reisert AD1C, <jjreisert@alum.mit.edu>, http://www.ad1c.us

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/3/2012 8:09 AM, Achim Gratz wrote:
> Ken Brown <kbrown <at> cornell.edu> writes:
>> I'm not sure what you mean by "without Gtk".  Do you want some other X
>> toolkit, such as Lucid or Motif?  Or no X toolkit?  What would be the
>> advantage of that?  The emacs build uses Gtk by default, so I would need
>> a good reason to do something different on Cygwin.
>
> openSUSE offers emacs-nox, emacs-x11 and emacs-gtk binaries and subpackages;
> emacs-x11 is built with Athena Widgets IIRC and does so precisely to avoid
> forcing the many dbus/Gtk dependencies onto systems that have no use for it
> otherwise.  I've been trying to keep a "lean" X11 alternative for my Cygwin
> installation here that does not pull in all that desktop infrastructure, but it
> seems I'm losing that battle anyway (both on the Gnome and the KDE/Qt front).

I can understand the motivation, but I really don't think Cygwin needs 
yet another emacs package, especially if it differs from the upstream 
defaults.  FWIW, I just checked Fedora 17.  On that system, `yum install 
emacs' gives you Emacs 24.1 with GTK+-2, which was the upstream default 
when Emacs 24.1 was released.  I also saw an emacs-nox package, but I 
didn't see Emacs built with an X toolkit other than Gtk.

Ken


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Ken Brown <kbrown <at> cornell.edu> writes:
> M-x xterm-mouse-mode

Thank you, this works great -- need to hack my .emacs a bit to do this
automatically.
 
> I'm not sure what you mean by "without Gtk".  Do you want some other X 
> toolkit, such as Lucid or Motif?  Or no X toolkit?  What would be the 
> advantage of that?  The emacs build uses Gtk by default, so I would need 
> a good reason to do something different on Cygwin.

openSUSE offers emacs-nox, emacs-x11 and emacs-gtk binaries and subpackages;
emacs-x11 is built with Athena Widgets IIRC and does so precisely to avoid
forcing the many dbus/Gtk dependencies onto systems that have no use for it
otherwise.  I've been trying to keep a "lean" X11 alternative for my Cygwin
installation here that does not pull in all that desktop infrastructure, but it
seems I'm losing that battle anyway (both on the Gnome and the KDE/Qt front).


Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Ken Brown]

On 12/3/2012 4:44 AM, Achim Gratz wrote:
> Ken Brown <kbrown <at> cornell.edu> writes:
>> and the Cygwin build of emacs-nox.exe now has mouse
>> support, as requested in
>>
>>     http://cygwin.com/ml/cygwin/2012-10/msg00027.html
>
> Are there some special settings to make this useable in mintty?  I've been
> trying to move the cursor around in a dired, but obviously it doesn't recognize
> this yet.

M-x xterm-mouse-mode

>> In this release, for the first time, I've been able to build Cygwin's
>> emacs-X11 with all of the upstream defaults.  In particular, the build
>> uses GTK+-3 instead of GTK+-2, and it supports GNOME's GSettings and
>> GConf features.
>
> Would it be possible to build emacs-X11 without Gtk and provide emacs-Gtk as an
> additional package, like some Linux distributions do?

I'm not sure what you mean by "without Gtk".  Do you want some other X 
toolkit, such as Lucid or Motif?  Or no X toolkit?  What would be the 
advantage of that?  The emacs build uses Gtk by default, so I would need 
a good reason to do something different on Cygwin.

Ken

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Updated: emacs*-24.2.90-1 (TEST)

[Achim Gratz]

Ken Brown <kbrown <at> cornell.edu> writes:
> Thanks to the efforts of Daniel Colascione, there is also a new package
> 
> *** emacs-w32-24.2.90-1,
> 
> again a test release, for users who want to use the native Windows GUI 
> for display.

Great stuff.  Many thanks to Daniel and you for providing this.

> This release is a pretest for the upcoming emacs-24.3.  It contains 
> bugfixes as well as new features.  In particular, the bug reported in
> 
>    http://cygwin.com/ml/cygwin/2012-10/msg00375.html
> 
> has been fixed,

Works great for me so far.  Thank you!

> and the Cygwin build of emacs-nox.exe now has mouse 
> support, as requested in
> 
>    http://cygwin.com/ml/cygwin/2012-10/msg00027.html

Are there some special settings to make this useable in mintty?  I've been
trying to move the cursor around in a dired, but obviously it doesn't recognize
this yet.

> In this release, for the first time, I've been able to build Cygwin's 
> emacs-X11 with all of the upstream defaults.  In particular, the build 
> uses GTK+-3 instead of GTK+-2, and it supports GNOME's GSettings and 
> GConf features.

Would it be possible to build emacs-X11 without Gtk and provide emacs-Gtk as an
additional package, like some Linux distributions do?



Regards,
Achim.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple