D-Bus integration into Emacs

D-Bus integration into Emacs

[Michael Albinus]

Hi,

I wrote some code to integrate D-Bus into Emacs. It's far from being
complete, but some basic functionality like synchronous method calls and
sending/receiving signals is running quite stable in my local
environment. At least it is sufficient to get an idea what it is and how
it works, I believe.

The implementation consists mainly of src/dbusbindings.c,
lisp/net/dbus.el and doc/misc/dbus.texi. All other modifications (in
src/Makefile.in, src/config.in, src/emacs.c, src/keyboard.c and
src/termhooks.h) are wrapped by the "#ifdef USE_DBUS" directive. This
macro is defined only if the Emacs configure script did run with
parameter "--with-dbus". By this, the D-Bus code is not seen by default,
which should avoid collateral damages until it has been proven stable.
I've developed and tested it under GNU/Linux; but D-Bus implementations
exist also for Win32 and MacOS.

An overview of D-Bus can be found at http://dbus.freedesktop.org. I've
summarized it also in a previous message
(http://lists.gnu.org/archive/html/emacs-devel/2007-09/msg00315.html).
doc/misc/dbus.texi contains several examples showing what is possible
already.

Are there any objections to install it in the trunk?

Best regards, Michael.

Re: D-Bus integration into Emacs

[Michael Albinus]

I wrote:

> I wrote some code to integrate D-Bus into Emacs. It's far from being
> complete, but some basic functionality like synchronous method calls and
> sending/receiving signals is running quite stable in my local
> environment. At least it is sufficient to get an idea what it is and how
> it works, I believe.

I've committed the files to the trunk. In order to activate D-Bus
integration, one must apply "./configure --with-dbus". It's tested under
GNU/Linux only, but there seem to exist D-Bus implementations for Mac OS
X and Win32 as well.

The corresponding info page provides some examples to start with.

Best regards, Michael.

Re: D-Bus integration into Emacs

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sun, 02 Dec 2007 18:28:49 +0100
> 
> I've committed the files to the trunk.

Thanks.

However, this part of your changes:

    RCS file: /sources/emacs/emacs/doc/misc/Makefile.in,v
    retrieving revision 1.4
    retrieving revision 1.5
    diff -u -b -r1.4 -r1.5
    --- Makefile.in	23 Nov 2007 19:38:49 -0000	1.4
    +++ Makefile.in	2 Dec 2007 16:56:53 -0000	1.5
    @@ -79,6 +79,10 @@
	    $(infodir)/widget \
	    $(infodir)/woman

    +ifeq (@DBUS_INFO@, dbus)
    +  INFO_TARGETS += $(infodir)/dbus
    +endif
    +
     DVI_TARGETS = \
	    ada-mode.dvi \
	    autotype.dvi \
    @@ -120,6 +124,10 @@
	    widget.dvi \
	    woman.dvi

    +ifeq (@DBUS_INFO@, dbus)
    +  DVI_TARGETS += dbus.dvi
    +endif
    +

     TEXI2DVI = texi2dvi

needs to be redone: ifeq is a GNU Make feature, and I don't think we
want to require GNU Make for building Emacs.

I think the easiest way to do this portably is use a shell feature of
some sort.  Or just generate info/dbus and dbus.dvi unconditionally
(it cannot hurt).

Re: D-Bus integration into Emacs

[Jason Rumney]

Eli Zaretskii wrote:
> needs to be redone: ifeq is a GNU Make feature, and I don't think we
> want to require GNU Make for building Emacs.
>
> I think the easiest way to do this portably is use a shell feature of
> some sort.  Or just generate info/dbus and dbus.dvi unconditionally
> (it cannot hurt).
>   

Don't we distribute Emacs with prebuilt manuals? If so, then building
unconditionally is a requirement.

Re: D-Bus integration into Emacs

[Michael Albinus]

Jason Rumney <jasonr@gnu.org> writes:

>> I think the easiest way to do this portably is use a shell feature of
>> some sort.  Or just generate info/dbus and dbus.dvi unconditionally
>> (it cannot hurt).
>
> Don't we distribute Emacs with prebuilt manuals? If so, then building
> unconditionally is a requirement.

I've changed it accordingly.

Best regards, Michael.

Re: D-Bus integration into Emacs

[Christian Faulhammer]

[-- Attachment #1.1: Type: text/plain, Size: 611 bytes --]

Michael Albinus <michael.albinus@gmx.de>:

> I've committed the files to the trunk. In order to activate D-Bus
> integration, one must apply "./configure --with-dbus". It's tested
> under GNU/Linux only, but there seem to exist D-Bus implementations
> for Mac OS X and Win32 as well.

 Gentoo users can have D-Bus support with
app-editors/emacs-cvs-23.0.50-r1 and USE=dbus.  So this will get some
testing as dbus is turned on by default.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: D-Bus integration into Emacs

[Nick Roberts]

 > I've committed the files to the trunk. In order to activate D-Bus
 > integration, one must apply "./configure --with-dbus". It's tested under
 > GNU/Linux only, but there seem to exist D-Bus implementations for Mac OS
 > X and Win32 as well.

If someone has D-Bus on their OS would they want to configure Emacs without
it?  Shouldn't configure just check for this feature and configure Emacs
to use it if found, as is done with most other features?

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: D-Bus integration into Emacs

[Christian Faulhammer]

[-- Attachment #1.1: Type: text/plain, Size: 779 bytes --]

Nick Roberts <nickrob@snap.net.nz>:

>  > I've committed the files to the trunk. In order to activate D-Bus
>  > integration, one must apply "./configure --with-dbus". It's tested
>  > under GNU/Linux only, but there seem to exist D-Bus
>  > implementations for Mac OS X and Win32 as well.
> If someone has D-Bus on their OS would they want to configure Emacs
> without it?  Shouldn't configure just check for this feature and
> configure Emacs to use it if found, as is done with most other
> features?

 Yes, maybe they want Emacs without it, so please make it selectable
without automagic detection.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: D-Bus integration into Emacs

[Nick Roberts]

Christian Faulhammer writes:
 > Nick Roberts <nickrob@snap.net.nz>:
 > 
 > >  > I've committed the files to the trunk. In order to activate D-Bus
 > >  > integration, one must apply "./configure --with-dbus". It's tested
 > >  > under GNU/Linux only, but there seem to exist D-Bus
 > >  > implementations for Mac OS X and Win32 as well.
 > > If someone has D-Bus on their OS would they want to configure Emacs
 > > without it?  Shouldn't configure just check for this feature and
 > > configure Emacs to use it if found, as is done with most other
 > > features?
 > 
 >  Yes, maybe they want Emacs without it, so please make it selectable
 > without automagic detection.

I'm starting from a position of ignorance, but perhaps resolve that by
explaining in simple terms both what dbus would give me and why I might not
want it.  The reality is that if it's off by default, most users won't be aware
of it to turn it on.  However, if it's on by default, presumably only users who
already knew about it would want to turn it off.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: D-Bus integration into Emacs

[Christian Faulhammer]

[-- Attachment #1.1: Type: text/plain, Size: 1859 bytes --]

Nick Roberts <nickrob@snap.net.nz>:

> Christian Faulhammer writes:
>  > Nick Roberts <nickrob@snap.net.nz>:
>  > >  > I've committed the files to the trunk. In order to activate
>  > >  > D-Bus integration, one must apply "./configure --with-dbus".
>  > >  > It's tested under GNU/Linux only, but there seem to exist
>  > >  > D-Bus implementations for Mac OS X and Win32 as well.
>  > > If someone has D-Bus on their OS would they want to configure
>  > > Emacs without it?  Shouldn't configure just check for this
>  > > feature and configure Emacs to use it if found, as is done with
>  > > most other features?
>  >  Yes, maybe they want Emacs without it, so please make it
>  > selectable without automagic detection.
> I'm starting from a position of ignorance, but perhaps resolve that by
> explaining in simple terms both what dbus would give me and why I
> might not want it.  The reality is that if it's off by default, most
> users won't be aware of it to turn it on.  However, if it's on by
> default, presumably only users who already knew about it would want
> to turn it off.

 Most people who build a D-Bus aware Emacs will follow the commits and
mailing lists closely.  So they know how they do...in Gentoo (which is
source-based, so build on the user's system) people can have D-Bus
globally but only deactivated for Emacs for whatever reason.
Auto-detection will switch it on even if USE=dbus is not activated, we
patch ALSA detection out to give users control if they want to have
ALSA everywhere except Emacs.
 So mostly it reduces hassle for packagers.  People using Emacs CVS on
Gentoo see the option dbus and can choose if they activate it.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: D-Bus integration into Emacs

[Nick Roberts]

 > > I'm starting from a position of ignorance, but perhaps resolve that by
 > > explaining in simple terms both what dbus would give me and why I
                   ^^^^^^^^^^^^
 > > might not want it.  The reality is that if it's off by default, most
 > > users won't be aware of it to turn it on.  However, if it's on by
 > > default, presumably only users who already knew about it would want
 > > to turn it off.
 > 
 >  Most people who build a D-Bus aware Emacs will follow the commits and
 > mailing lists closely.  So they know how they do...in Gentoo (which is
 > source-based, so build on the user's system) people can have D-Bus
 > globally but only deactivated for Emacs for whatever reason.
 > Auto-detection will switch it on even if USE=dbus is not activated, we
 > patch ALSA detection out to give users control if they want to have
 > ALSA everywhere except Emacs.
 >  So mostly it reduces hassle for packagers.  People using Emacs CVS on
 > Gentoo see the option dbus and can choose if they activate it.

Phew, I'm glad I didn't ask for the advanced explanation!

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: D-Bus integration into Emacs

[Andreas Schwab]

Christian Faulhammer <v-li@gmx.de> writes:

>  Most people who build a D-Bus aware Emacs will follow the commits and
> mailing lists closely.  So they know how they do...in Gentoo (which is
> source-based, so build on the user's system) people can have D-Bus
> globally but only deactivated for Emacs for whatever reason.
> Auto-detection will switch it on even if USE=dbus is not activated, we
> patch ALSA detection out to give users control if they want to have
> ALSA everywhere except Emacs.

You can always use --without-dbus.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: D-Bus integration into Emacs

[Christian Faulhammer]

[-- Attachment #1.1: Type: text/plain, Size: 878 bytes --]

Andreas Schwab <schwab@suse.de>:

> Christian Faulhammer <v-li@gmx.de> writes:
> 
> >  Most people who build a D-Bus aware Emacs will follow the commits
> > and mailing lists closely.  So they know how they do...in Gentoo
> > (which is source-based, so build on the user's system) people can
> > have D-Bus globally but only deactivated for Emacs for whatever
> > reason. Auto-detection will switch it on even if USE=dbus is not
> > activated, we patch ALSA detection out to give users control if
> > they want to have ALSA everywhere except Emacs.
>
> You can always use --without-dbus.

 Then I may have understood it incorrectly as I though D-BUS should be
autodetected regardless of any option.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: D-Bus integration into Emacs

[Richard Stallman]

     Yes, maybe they want Emacs without it, so please make it selectable
    without automagic detection.

Why do you think people are likely to want that?
And why do you think we should go out of our way
to cater to such a possible desire?
I do not see it.

Re: D-Bus integration into Emacs

[Ulrich Mueller]

>>>>> On Tue, 04 Dec 2007, Richard Stallman wrote:

>      Yes, maybe they want Emacs without it, so please make it
>     selectable without automagic detection.

> Why do you think people are likely to want that?

I think what Christian is asking for is the following:
  - Automagic detection is the default if no option is specified,
  - but it should be possible to override it with configure
    options --with-dbus or --without-dbus.

> And why do you think we should go out of our way to cater to such a
> possible desire?

But it is done in the above-mentioned way for most Emacs features.
Consider the case that someone builds Emacs on a computer where
libdbus is installed, but wants to copy the binary to another computer
where it isn't (or where no D-BUS daemon is running).

Ulrich

Re: D-Bus integration into Emacs

[Michael Albinus]

Ulrich Mueller <ulm@gentoo.org> writes:

> Consider the case that someone builds Emacs on a computer where
> libdbus is installed, but wants to copy the binary to another computer
> where it isn't (or where no D-BUS daemon is running).

libdbus-1 is linked statically. As long as nobody loads dbus.el on that
other computer, it doesn't harm. And even if she does, there will be a
dbus-error, like any other error. No crash or so.

I haven't tested it, but at least that's what I wrote.

> Ulrich

Best regards, Michael.

Re: D-Bus integration into Emacs

[Ulrich Mueller]

>>>>> On Tue, 04 Dec 2007, Michael Albinus wrote:

> libdbus-1 is linked statically.

This seems not to be the case here:

   $ scanelf -n /usr/bin/emacs-23 | sed 's/,/\n/g' | grep dbus
   libdbus-1.so.3

Ulrich

Re: D-Bus integration into Emacs

[Michael Albinus]

Ulrich Mueller <ulm@gentoo.org> writes:

>> libdbus-1 is linked statically.
>
> This seems not to be the case here:
>
>    $ scanelf -n /usr/bin/emacs-23 | sed 's/,/\n/g' | grep dbus
>    libdbus-1.so.3

Oops. I stand corrected.

> Ulrich

Best regards, Michael.

Re: D-Bus integration into Emacs

[Magnus Henoch]

Michael Albinus <michael.albinus@gmx.de> writes:

> libdbus-1 is linked statically. As long as nobody loads dbus.el on that
> other computer, it doesn't harm. And even if she does, there will be a
> dbus-error, like any other error. No crash or so.
>
> I haven't tested it, but at least that's what I wrote.

I get the opposite result.  Using an emacs compiled with D-Bus, when the
environment variable DBUS_SESSION_BUS_ADDRESS is unset, "emacs -Q" will
give an emacs that just beeps and doesn't react to input.  (At least on
a tty; I'm unable to test with X right now)

Magnus

Re: D-Bus integration into Emacs

[Richard Stallman]

    I think what Christian is asking for is the following:
      - Automagic detection is the default if no option is specified,
      - but it should be possible to override it with configure
	options --with-dbus or --without-dbus.

I have nothing against --without-dbus.

I thought we were talking about whether dbus support should be
enabled by default or disabled by default.  I think it should be
enabled by default (on systems that have dbus).

Re: D-Bus integration into Emacs

[Michael Albinus]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > I've committed the files to the trunk. In order to activate D-Bus
>  > integration, one must apply "./configure --with-dbus". It's tested under
>  > GNU/Linux only, but there seem to exist D-Bus implementations for Mac OS
>  > X and Win32 as well.
>
> If someone has D-Bus on their OS would they want to configure Emacs without
> it?  Shouldn't configure just check for this feature and configure Emacs
> to use it if found, as is done with most other features?

I agree, this should be the target. But I've made it configurable for
two reasons:

- The integration touches sensible parts of Emacs, like event
  handling. I didn't want to stall everybody due to a possible
  error. It works stable in my local environment, but before enabling
  it wherever D-Bus exist, there should be kind of feedback from other
  people.

- I've tested it only for GNU/Linux (Ubuntu 7.04/7.10, to be precise).
  I have no idea how it works on other platforms, like Mac OS X or
  Win32. For example, the D-Bus API offers Win32 specific functions
  I'll never be able to test. See dbus_connection_get_unix_user vs
  dbus_connection_get_windows_user in the API.

So I propose to wait at least some weeks (until the end of this
year?), whether there are serious drawbacks. If not, we could remove
the configuration option "with-dbus".

Best regards, Michael.

Re: D-Bus integration into Emacs

[Richard Stallman]

    - I've tested it only for GNU/Linux (Ubuntu 7.04/7.10, to be precise).
      I have no idea how it works on other platforms, like Mac OS X or
      Win32.

In hacker terminology, calling something a "win" is a form of praise.
If you wish to praise Microsoft Windows, you're free to do so; but in
the context of Emacs, we don't want to do that.  So please don't use
the term "win32" here.

Re: D-Bus integration into Emacs

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     - I've tested it only for GNU/Linux (Ubuntu 7.04/7.10, to be precise).
>       I have no idea how it works on other platforms, like Mac OS X or
>       Win32.
>
> In hacker terminology, calling something a "win" is a form of praise.
> If you wish to praise Microsoft Windows, you're free to do so; but in
> the context of Emacs, we don't want to do that.  So please don't use
> the term "win32" here.

No, I don't want to praise that company. Especially, since I've involved
partly in  an trial my former company has been accused by MS violating a
software patent. Real hassle.

I meant w32.

Best regards, Michael.

Re: D-Bus integration into Emacs

[Magnus Henoch]

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

Michael Albinus <michael.albinus@gmx.de> writes:

> I've committed the files to the trunk. In order to activate D-Bus
> integration, one must apply "./configure --with-dbus". It's tested under
> GNU/Linux only, but there seem to exist D-Bus implementations for Mac OS
> X and Win32 as well.

It doesn't compiler under NetBSD, as D-Bus is installed under /usr/pkg
instead of /usr.  How about this patch?  It makes configure use
pkg-config to find the proper compiler and linker flags.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: configure.in.patch --]
[-- Type: text/x-patch, Size: 742 bytes --]

diff --git a/configure.in b/configure.in
index c372f5c..b791842 100644
--- a/configure.in
+++ b/configure.in
@@ -2264,13 +2264,9 @@ dnl other platforms.  Support for higher D-Bus versions but 1.0 is
 dnl also not configured.
 HAVE_DBUS=no
 if test "${with_dbus}" = "yes"; then
-   AC_CHECK_LIB(dbus-1, dbus_bus_get, HAVE_DBUS=yes)
+   PKG_CHECK_MODULES(DBUS, dbus-1, HAVE_DBUS=yes, HAVE_DBUS=no)
    if test "$HAVE_DBUS" = yes; then
       AC_DEFINE(HAVE_DBUS, 1, [Define to 1 if using D-Bus.])
-      DBUS_CFLAGS="-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include"
-      AC_SUBST(DBUS_CFLAGS)
-      DBUS_LIBS="-ldbus-1"
-      AC_SUBST(DBUS_LIBS)
       DBUS_INFO="dbus"
    fi
 fi


Diffs between working revision and workfile end here.

[-- Attachment #3: Type: text/plain, Size: 8 bytes --]


Magnus

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: D-Bus integration into Emacs

[Jan Djärv]

Magnus Henoch skrev:
> Michael Albinus <michael.albinus@gmx.de> writes:
> 
>> I've committed the files to the trunk. In order to activate D-Bus
>> integration, one must apply "./configure --with-dbus". It's tested under
>> GNU/Linux only, but there seem to exist D-Bus implementations for Mac OS
>> X and Win32 as well.
> 
> It doesn't compiler under NetBSD, as D-Bus is installed under /usr/pkg
> instead of /usr.  How about this patch?  It makes configure use
> pkg-config to find the proper compiler and linker flags.
> 

You should make that something like:

   PKG_CHECK_MODULES(DBUS, dbus-1 >= 1.1, HAVE_DBUS=yes, HAVE_DBUS=no)

or whatever version is required (FWIW, I have dbus in /opt on some machines).

BTW, does anybody know why we have

   AC_INIT(src/lisp.h)

at the begining of configure.in?  The documentation says:

   AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME])

	Jan D.

Re: D-Bus integration into Emacs

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> BTW, does anybody know why we have
>
>   AC_INIT(src/lisp.h)
>
> at the begining of configure.in?  The documentation says:
>
>   AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME])

See (autoconf)Obsolete Macros.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: D-Bus integration into Emacs

[Jan Djärv]

Andreas Schwab skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> BTW, does anybody know why we have
>>
>>   AC_INIT(src/lisp.h)
>>
>> at the begining of configure.in?  The documentation says:
>>
>>   AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME])
> 
> See (autoconf)Obsolete Macros.
> 

Thanks for the pointer.  But it would be OK for us to change to the 
non-obsolete version?

	Jan D.

Re: D-Bus integration into Emacs

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Andreas Schwab skrev:
>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>
>>> BTW, does anybody know why we have
>>>
>>>   AC_INIT(src/lisp.h)
>>>
>>> at the begining of configure.in?  The documentation says:
>>>
>>>   AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME])
>>
>> See (autoconf)Obsolete Macros.
>>
>
> Thanks for the pointer.  But it would be OK for us to change to the
> non-obsolete version?

Sure, we require a modern version of autoconf anyway.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: D-Bus integration into Emacs

[Jan Djärv]

Andreas Schwab skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Andreas Schwab skrev:
>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>>
>>>> BTW, does anybody know why we have
>>>>
>>>>   AC_INIT(src/lisp.h)
>>>>
>>>> at the begining of configure.in?  The documentation says:
>>>>
>>>>   AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME])
>>> See (autoconf)Obsolete Macros.
>>>
>> Thanks for the pointer.  But it would be OK for us to change to the
>> non-obsolete version?
> 
> Sure, we require a modern version of autoconf anyway.
> 

OK, I did that.

	Jan D.

Re: D-Bus integration into Emacs

[Andreas Schwab]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Andreas Schwab skrev:
>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>
>>> Andreas Schwab skrev:
>>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>>>
>>>>> BTW, does anybody know why we have
>>>>>
>>>>>   AC_INIT(src/lisp.h)
>>>>>
>>>>> at the begining of configure.in?  The documentation says:
>>>>>
>>>>>   AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME])
>>>> See (autoconf)Obsolete Macros.
>>>>
>>> Thanks for the pointer.  But it would be OK for us to change to the
>>> non-obsolete version?
>>
>> Sure, we require a modern version of autoconf anyway.
>>
>
> OK, I did that.

That means that the version number is now duplicated in configure.in,
and AC_CONFIG_SRCDIR is lost.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: D-Bus integration into Emacs

[Jan Djärv]

Andreas Schwab skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Andreas Schwab skrev:
>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>>
>>>> Andreas Schwab skrev:
>>>>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>>>>
>>>>>> BTW, does anybody know why we have
>>>>>>
>>>>>>   AC_INIT(src/lisp.h)
>>>>>>
>>>>>> at the begining of configure.in?  The documentation says:
>>>>>>
>>>>>>   AC_INIT (PACKAGE, VERSION, [BUG-REPORT], [TARNAME])
>>>>> See (autoconf)Obsolete Macros.
>>>>>
>>>> Thanks for the pointer.  But it would be OK for us to change to the
>>>> non-obsolete version?
>>> Sure, we require a modern version of autoconf anyway.
>>>
>> OK, I did that.
> 
> That means that the version number is now duplicated in configure.in,

It is too bad, I agree.  But using obsolete macros is no good either, sooner 
or later they are removed.  Ideally we should generate lisp/version.el and 
doc/emacs/emacs.texi from configure so the version number is only in 
configure.in.  But that would not be OK where configure is not used. 
Suggestions anyone?

> and AC_CONFIG_SRCDIR is lost.

That is easily fixed.

	Jan D.

Re: D-Bus integration into Emacs

[Glenn Morris]

Jan Djärv wrote:

>> That means that the version number is now duplicated in configure.in,
>
> It is too bad, I agree. But using obsolete macros is no good either,
> sooner or later they are removed. Ideally we should generate
> lisp/version.el and doc/emacs/emacs.texi from configure so the
> version number is only in configure.in. But that would not be OK
> where configure is not used. Suggestions anyone?

The version number exists in a number of places. It's no big deal; M-x
set-version from admin/admin.el updates them all.

Re: D-Bus integration into Emacs

[Thien-Thi Nguyen]

() Jan Djärv <jan.h.d@swipnet.se>
() Thu, 06 Dec 2007 08:05:13 +0100

   But that would not be OK where configure is not used.

do you mean on non-unixoid platforms?  speaking as a casual vms for emacs
dabbler, i would welcome motion of version info into configure.in.

   Suggestions anyone?

go for it.

thi

Re: D-Bus integration into Emacs

[Jan Djärv]

Thien-Thi Nguyen skrev:
> () Jan Djärv <jan.h.d@swipnet.se>
> () Thu, 06 Dec 2007 08:05:13 +0100
> 
>    But that would not be OK where configure is not used.
> 
> do you mean on non-unixoid platforms?  speaking as a casual vms for emacs
> dabbler, i would welcome motion of version info into configure.in.
> 
>    Suggestions anyone?
> 
> go for it.
> 

Glenn Morris has updated admin/admin.el to update the configure.in version also.

	Jan D.

Re: D-Bus integration into Emacs

[Richard Stallman]

    Thanks for the pointer.  But it would be OK for us to change to the 
    non-obsolete version?

This isn't a user-level feature, so compatibility with past Emacs
versions does not apply.  The only kind of reason that would stand
against the change would be if it somehow fails to work.

Re: D-Bus integration into Emacs

[Michael Albinus]

Jan Djärv <jan.h.d@swipnet.se> writes:

>> It doesn't compiler under NetBSD, as D-Bus is installed under /usr/pkg
>> instead of /usr.  How about this patch?  It makes configure use
>> pkg-config to find the proper compiler and linker flags.
>
> You should make that something like:
>
>   PKG_CHECK_MODULES(DBUS, dbus-1 >= 1.1, HAVE_DBUS=yes, HAVE_DBUS=no)
>
> or whatever version is required (FWIW, I have dbus in /opt on some machines).

      PKG_CHECK_MODULES(DBUS, dbus-1 >= 1.0, HAVE_DBUS=yes, HAVE_DBUS=no)

seems to fit best. I've developped with D-Bus 1.0, and this is the
stable version distributed since Nov 2006.

D-Bus 1.1 is a developer version. D-Bus 1.2, the next stable version, is
expected to be released soon. Its new features shall be visible as
subfeatures of dbus.el, still providing backwards compatibility to D-Bus 1.0.

Magnus, it's your patch. I believe it is worth to be installed.

> 	Jan D.

Best regards, Michael.

Re: D-Bus integration into Emacs

[Magnus Henoch]

Michael Albinus <michael.albinus@gmx.de> writes:

> Magnus, it's your patch. I believe it is worth to be installed.

Done.

Magnus

Re: D-Bus integration into Emacs

[Jan Djärv]

Michael Albinus skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>>> It doesn't compiler under NetBSD, as D-Bus is installed under /usr/pkg
>>> instead of /usr.  How about this patch?  It makes configure use
>>> pkg-config to find the proper compiler and linker flags.
>> You should make that something like:
>>
>>   PKG_CHECK_MODULES(DBUS, dbus-1 >= 1.1, HAVE_DBUS=yes, HAVE_DBUS=no)
>>
>> or whatever version is required (FWIW, I have dbus in /opt on some machines).
> 
>       PKG_CHECK_MODULES(DBUS, dbus-1 >= 1.0, HAVE_DBUS=yes, HAVE_DBUS=no)
> 
> seems to fit best. I've developped with D-Bus 1.0, and this is the
> stable version distributed since Nov 2006.
> 
> D-Bus 1.1 is a developer version. D-Bus 1.2, the next stable version, is
> expected to be released soon. Its new features shall be visible as
> subfeatures of dbus.el, still providing backwards compatibility to D-Bus 1.0.
> 

Okay.  I just looked at what I had in front of me (Fedora 8) and that was 
1.1.2.  So they ship a development version, didn't expect that.

	Jan D.

Re: D-Bus integration into Emacs

[Johan Bockgård]

Michael Albinus <michael.albinus@gmx.de> writes:

> I've committed the files to the trunk.

I think dbus-register-signal should not extract the symbol function of
the HANDLER argument, but instead use the symbol directly (and should
maybe also accept an anonymous function).  This interacts better with
redefinition, advice and debugging.

I'm talking about this line:

   Ffset (result, Fsymbol_function (handler));


-- 
Johan Bockgård

Re: D-Bus integration into Emacs

[Michael Albinus]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> I think dbus-register-signal should not extract the symbol function of
> the HANDLER argument, but instead use the symbol directly (and should
> maybe also accept an anonymous function).  This interacts better with
> redefinition, advice and debugging.

As recommended by Richard, I've just changed the internal location of
callback functions from obarray to hash table. By this, I've also fixed
your request.

Best regards, Michael.

Re: D-Bus integration into Emacs

[Johan Bockgård]

+      (dbus-*-event, dbus-event-*): Rewritten, due to new structure of
+      `dbus-event'.

Please always spell out identifiers in full in the change log.

-- 
Johan Bockgård

Re: D-Bus integration into Emacs

[Michael Albinus]

[message resent; Cc was lost]

Magnus Henoch <mange@freemail.hu> writes:

>> libdbus-1 is linked statically. As long as nobody loads dbus.el on that
>> other computer, it doesn't harm. And even if she does, there will be a
>> dbus-error, like any other error. No crash or so.
>>
>> I haven't tested it, but at least that's what I wrote.
>
> I get the opposite result.  Using an emacs compiled with D-Bus, when the
> environment variable DBUS_SESSION_BUS_ADDRESS is unset, "emacs -Q" will
> give an emacs that just beeps and doesn't react to input.  (At least on
> a tty; I'm unable to test with X right now)

Have you tried the patch I've checked in yesterday evening? It should
have solved this issue (I have seen it as well).

There is another weakness left: if you load dbus.el when D-Bus isn't
reachable (unsetting DBUS_SESSION_BUS_ADDRESS, as you have done),
emacs is blocked again. I will work on this today.

> Magnus

Best regards, Michael.

Re: D-Bus integration into Emacs

[Magnus Henoch]

Michael Albinus <michael.albinus@gmx.de> writes:

> Have you tried the patch I've checked in yesterday evening? It should
> have solved this issue (I have seen it as well).
>
> There is another weakness left: if you load dbus.el when D-Bus isn't
> reachable (unsetting DBUS_SESSION_BUS_ADDRESS, as you have done),
> emacs is blocked again. I will work on this today.

This seems to work now.

Magnus