nyc4...@aol.com writes:
> I was trying out Emacs and dbus-send and ran int a minor
> problem.
>
> I sent the following:
>
> dbus-send --session --print-reply --dest=org.gnu.emacs.TextEditor \
>/org/gnu/emacs/TextEditor org.gnu.emacs.TextEditor
>
> It sucessfully created an emacs process.
>
> H
that emacs:
> (dbus-get-unique-name :session)
> ":1.0"
>
> load-file /usr/share/emacs/23.2/lisp/net/dbus.el.gz
>
> Hangs emacs after the "done" message...
Likely, you didn't start the system bus (the scenario is only about the
session bus).
I've comm
Ken Brown writes:
> So I think the bottom line is that, at least under Cygwin, users
> should make sure the system bus is running before loading dbus.el.
That's recommended under any system.
Btw, in order to play with a "real" application, I've tried secrets.el
from the trunk, combined with ema
Ken Brown writes:
>> Yep. Reading the code, I have the feeling, that the following patch
>> should help:
> [...]
>
> No, I still get the freeze if I load dbus and the system bus isn't running.
That's strange. Today, I could test under cygwin. I've recompiled the
sources from the emacs-23 branch,
Ken Brown writes:
>>> I haven't the cygwin notebook with me, next access for me is tomorrow.
>>> I'll check then.
I couldn't do it today, unfortunately.
>> Yes, that's it. Emacs does freeze if I load dbus.el and the system bus
>> isn't running. But the problem doesn't occur in a build of Emac
Ken Brown writes:
>> The binary has the following checksum:
>>
>> $ cksum /usr/bin/emacs
>> 658187514 16254990 /usr/bin/emacs
>
> That's not actually the binary; it's a symlink that resolves to either
> /usr/bin/emacs-X11.exe or /usr/bin/emacs-nox.exe, depending on whether
> or not you've install
Ken Brown writes:
>> Maybe you could also try to send a notification:
>>
>> (notifications-notify :title "Hello world" :body "from Emacs")
>
> This results in the error "The name org.freedesktop.Notifications was
> not provided by any .service files", as you predicted. So I don't
> think it poin
Ken Brown writes:
> It doesn't seem to be a problem under Cygwin either. I just tried
> loading notifications.el, and Emacs didn't freeze. So I guess we'll
> have to wait for a more detailed problem report from the OP saying
> exactly what he did.
Maybe you could also try to send a notificatio
Ken Brown writes:
> So if you're trying to use a library from the Emacs 24 trunk, it's
> possible that it's simply not compatible with Emacs 23.
Under GNU/Linux, I've shortly tested notifications.el (taken from the
trunk) in the emacs-23 branch; it works w/o problem. This does not seem
to be the
Ken Brown writes:
>> I tried to use notifiations.el (from the Emacs 24 trunk).
Could you, please, eval
(setq dbus-debug t)
before loading the package? This shall give us more information.
> 4. In a different shell, set (and export) $DBUS_SESSION_BUS_ADDRESS to
> this value, and run dbus-mon
Ken Brown writes:
> Hi Michael,
Hi Ken,
>> I do not understand all details of keyboard.c. Is there something I need
>> to set in order to urge the call of xd_read_queued_messages (via
>> gobble_input)? Or do I need to suppress further polling? What is the
>> difference for Emacs running with cy
Ken Brown writes:
> I suspect we can't go any further with this until you return from your
> trip and start debugging.
Yes, I'm sorry. Let's continue in September.
> Ken
Best regards, Michael.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/f
Ken Brown writes:
>> This is also a D-Bus client, which connects to the *same* session bus as
>> Emacs did due to $DBUS_SESSION_BUS_ADDRESS. Now you should see the
>> signal sent by dbus-monitor in Emacs.
>
> OK, I started the session bus the right way this time, but I still
> didn't see any sign
Ken Brown writes:
>> Now that that's fixed, it still says:
>>
>>This is GNU Emacs 23.2.1
>>of 2010-08-16
>>
>> I assume that's the new version, why does it still say 23.2.1?
>
> The '.1' at the end is added by Emacs. I don't know why. This has
> nothing to do with the fact that from Cyg
Ken Brown writes:
>> I'm confused: do you mean, the problem is happening when the system bus
>> is running, or when it is *not* running? I suspect the latter case.
>
> I really meant it the way I said it: The problem occurs if the system
> bus *is* running. I've done some further testing, and he
Ken Brown writes:
>> The blocking you observed when dbus.el is loaded doesn't occur with a
>> build from the Emacs trunk (r101187).
>
> Correction: It occurs if and only if the system messagebus service is
> running.
I'm confused: do you mean, the problem is happening when the system bus
is runn
Ken Brown writes:
> Hi Michael,
Hi Ken,
> The blocking you observed when dbus.el is loaded doesn't occur with a
> build from the Emacs trunk (r101187). But I don't know how to test
> the dbus functionality after loading dbus.el.
There is a manual, open it with (info "(dbus)")
You could check
Ken Brown writes:
>> After installing that library, Emacs did start. How ever, it blocks
>> when loading dbus.el.
>
> Don't you normally have to start a D-BUS session before loading
> dbus.el? Maybe one of the Cygwin people who uses D-BUS can tell us how
> to do that.
I've started the session bu
Ken Brown writes:
Hi Ken,
>> It's some years ago I have used Cygwin. But if you have uploaded the
>> build already, I could check, whether I have problems running Emacs +
>> D-Bus under Cygwin.
>
> Yes, it's uploaded. See
>
> http://cygwin.com/ml/cygwin-announce/2010-08/msg00020.html
Unfortu
Ken Brown writes:
> Thanks, Michael. I don't use D-BUS myself, but I hope the OP will
> test it and report back.
It's some years ago I have used Cygwin. But if you have uploaded the
build already, I could check, whether I have problems running Emacs +
D-Bus under Cygwin.
> Ken
Best regards, M
Ken Brown writes:
> Yes, I've just checked that it builds with D-Bus. I'll upload a test
> release in a few days. BTW, the configure script gives the following
> warning:
>
> D-Bus integration has been tested for GNU/Linux only.
>
> So I don't know if it will work.
This message is from me (I
21 matches
Mail list logo