Re: Emacs 24.1
On Tue, Jun 26, 2012 at 11:14 AM, Manuel Giraud man...@ledu-giraud.fr wrote: Antoine Jacoutot ajacou...@bsdfrog.org writes: So obviously OK for me but I don't think my vote counts. I like that too because if one has dbus installed via a dependency it seems reasonable to start it in the xsession as an application might need it later (it is obviously the case for emacs). The ones with stripped-down configuration won't have a dbus dependency in the first place. (next time I need an issue to be fixed I'll say that gnome sucks on a public mailing list :-) -- Manuel Giraud hi, what's happening with this port effort? i'm using emacs 24 since this port was sent out and it works just fine for me. can we please get it in soon? cheers
Re: Emacs 24.1
Antoine Jacoutot ajacou...@bsdfrog.org writes: So obviously OK for me but I don't think my vote counts. I like that too because if one has dbus installed via a dependency it seems reasonable to start it in the xsession as an application might need it later (it is obviously the case for emacs). The ones with stripped-down configuration won't have a dbus dependency in the first place. (next time I need an issue to be fixed I'll say that gnome sucks on a public mailing list :-) -- Manuel Giraud
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 04:58:22AM +0200, Juan Francisco Cantero Hurtado wrote: I've wasted one hour installing gnome and updating the other packages. I've compiled the original port without my one-line change, i.e. with gsettings enabled. I've open/close (exactly) 50 times emacs with C-x C-c. I'm writing this mail with emacs on gnome. *All works OK*. Also, it's not my port. The author is Manuel. I don't know if the port is right or if is broken. I don't care. I can't judge the quality of this port because I haven't read the ports documentation (but is in my todo). Sometimes, I test some ports of this list because I think that the tests are very important, but I never talk about quality of the ports. I've been fighting (as a user) with compilations and dependencies for almost 13 years, so I think that I can be a good tester for the ports. I just wanted give a advice to other developers based on my experience. The first was a bad advice, the later is correct in my opinion. The developers are free of to listen my advice or not. I'll not change my opinion about gsetting/gnome-setting-daemon for a long time (despite of my very good experience with gnome on openbsd). Again, emacs and other gtk3 applications are broken but the fix is very simple. I never said that gnome or gsettings are a bad thing. I said that gsettings is the usual culprit because a lot of applications have a broken implementation of gsettings. Also, usually gsettings is not essential for the applications. Despite of the possible interpretations of my mail, I'm not upset or something similar. Just this type of threads are very frustrating for me. I waste a lots of time on tests for demostrating something obvious for me and also is very exhausting for me to discuss in English. Look I am not saying you were upset or anything. But for some reason you do not want to trust me. I just tried emacs with gtk3 in fvwm and it works fine. The reason it probably does not work for you is that you don't have a dbus user session started up (gnome does this for you automatically). So, open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... C-x C-c And I will repeat again that your issue has _nothing_ to do with gnome nor gnome-settings-daemon whatsoever. Gsettings writes its stuffs in dconf; dconf is automatically started by dbus. I am not saying that is clever nor convenient but this is how it works. So don't blame gsettings itself if you do not fulfill its requirements. It would be like saying that mail/roundcube does not work because you didn't start a web server. That said, I have nothing against disabling gsettings in Emacs, I just wanted to explain how things worked. Cheers! -- Antoine
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: On Sun, Jun 24, 2012 at 04:58:22AM +0200, Juan Francisco Cantero Hurtado wrote: I've wasted one hour installing gnome and updating the other packages. I've compiled the original port without my one-line change, i.e. with gsettings enabled. I've open/close (exactly) 50 times emacs with C-x C-c. I'm writing this mail with emacs on gnome. *All works OK*. Also, it's not my port. The author is Manuel. I don't know if the port is right or if is broken. I don't care. I can't judge the quality of this port because I haven't read the ports documentation (but is in my todo). Sometimes, I test some ports of this list because I think that the tests are very important, but I never talk about quality of the ports. I've been fighting (as a user) with compilations and dependencies for almost 13 years, so I think that I can be a good tester for the ports. I just wanted give a advice to other developers based on my experience. The first was a bad advice, the later is correct in my opinion. The developers are free of to listen my advice or not. I'll not change my opinion about gsetting/gnome-setting-daemon for a long time (despite of my very good experience with gnome on openbsd). Again, emacs and other gtk3 applications are broken but the fix is very simple. I never said that gnome or gsettings are a bad thing. I said that gsettings is the usual culprit because a lot of applications have a broken implementation of gsettings. Also, usually gsettings is not essential for the applications. Despite of the possible interpretations of my mail, I'm not upset or something similar. Just this type of threads are very frustrating for me. I waste a lots of time on tests for demostrating something obvious for me and also is very exhausting for me to discuss in English. Look I am not saying you were upset or anything. It was just a comment because sometimes my mails seem a little upset. But for some reason you do not want to trust me. I trust you. I just tried emacs with gtk3 in fvwm and it works fine. The reason it probably does not work for you is that you don't have a dbus user session started up (gnome does this for you automatically). So, open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... C-x C-c I have dbus_daemon running but not a user session. With your suggestion, emacs works OK. And I will repeat again that your issue has _nothing_ to do with gnome nor gnome-settings-daemon whatsoever. I resolved other issues running gnome-settings-daemon (the dbus user session was not the issue). I just blamed (wrongly) to the usual suspect. Gsettings writes its stuffs in dconf; dconf is automatically started by dbus. I am not saying that is clever nor convenient but this is how it works. So don't blame gsettings itself if you do not fulfill its requirements. It would be like saying that mail/roundcube does not work because you didn't start a web server. You're right. That said, I have nothing against disabling gsettings in Emacs, I just wanted to explain how things worked. Thanks for the explanation. If emacs works without problems, I'm not against of the gsetting support. Cheers! If all the applications with gsettings support require a dbus user session, the FAQ should mention this, right?. It's better than my advice to other maintainers for to try the packages outside of gnome. If all people know this requirement, the extra tests are unnecessary. Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: So, open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... Maybe it's time to add something like that in the default session scripts (untested): Index: app/xinit/xinitrc.cpp === RCS file: /cvs/OpenBSD/xenocara/app/xinit/xinitrc.cpp,v retrieving revision 1.6 diff -u -r1.6 xinitrc.cpp --- app/xinit/xinitrc.cpp 19 Mar 2011 15:40:02 - 1.6 +++ app/xinit/xinitrc.cpp 24 Jun 2012 12:23:20 - @@ -51,6 +51,11 @@ ssh-add /dev/null fi +if test -x /usr/local/bin/dbus-launch -a -z $DBUS_SESSION_BUS_ADDRESS ; then + ## if not found, launch a new one +eval `dbus-launch --sh-syntax --exit-with-session` +fi + XCOMM start some nice programs XCLOCK -geometry 50x50-1+1 Index: app/xdm/config/Xsession.cpp === RCS file: /cvs/OpenBSD/xenocara/app/xdm/config/Xsession.cpp,v retrieving revision 1.9 diff -u -r1.9 Xsession.cpp --- app/xdm/config/Xsession.cpp 3 Dec 2011 13:46:00 - 1.9 +++ app/xdm/config/Xsession.cpp 24 Jun 2012 12:23:20 - @@ -101,6 +101,9 @@ exec `eval $XDESKTOP` } #endif + if [ -x /usr/local/bin/dbus-launch ]; then + eval `dbus-launch --sh-syntax --exit-with-session` + fi BINDIR/xterm BINDIR/fvwm fi -- Matthieu Herrb
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: So, open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... Maybe it's time to add something like that in the default session scripts (untested): That's exactly what I documented under ports/x11/dbus/pkg/README so I cannot say I am not all for it ;-) That said, I didn't want to be the one pushing it because people would have yelled that I am trying to enforce stuffs on everyone because of gnome (of course nothing to do with gnome but people tend to blame gnome each time they have an issue with a gtk app). So obviously OK for me but I don't think my vote counts. Index: app/xinit/xinitrc.cpp === RCS file: /cvs/OpenBSD/xenocara/app/xinit/xinitrc.cpp,v retrieving revision 1.6 diff -u -r1.6 xinitrc.cpp --- app/xinit/xinitrc.cpp 19 Mar 2011 15:40:02 - 1.6 +++ app/xinit/xinitrc.cpp 24 Jun 2012 12:23:20 - @@ -51,6 +51,11 @@ ssh-add /dev/null fi +if test -x /usr/local/bin/dbus-launch -a -z $DBUS_SESSION_BUS_ADDRESS ; then + ## if not found, launch a new one +eval `dbus-launch --sh-syntax --exit-with-session` +fi + XCOMM start some nice programs XCLOCK -geometry 50x50-1+1 Index: app/xdm/config/Xsession.cpp === RCS file: /cvs/OpenBSD/xenocara/app/xdm/config/Xsession.cpp,v retrieving revision 1.9 diff -u -r1.9 Xsession.cpp --- app/xdm/config/Xsession.cpp 3 Dec 2011 13:46:00 - 1.9 +++ app/xdm/config/Xsession.cpp 24 Jun 2012 12:23:20 - @@ -101,6 +101,9 @@ exec `eval $XDESKTOP` } #endif + if [ -x /usr/local/bin/dbus-launch ]; then + eval `dbus-launch --sh-syntax --exit-with-session` + fi BINDIR/xterm BINDIR/fvwm fi -- Matthieu Herrb -- Antoine
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 02:29:48PM +0200, Antoine Jacoutot wrote: On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: So, open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... Maybe it's time to add something like that in the default session scripts (untested): Thanks Matthieu. That's exactly what I documented under ports/x11/dbus/pkg/README so pkg-readmes is better for this info. Yesterday, after of install gnome, I was seeing the files on pkg-readmes for to prevent that I was skipping something. I think that only the developers read pkg/. I cannot say I am not all for it ;-) That said, I didn't want to be the one pushing it because people would have yelled that I am trying to enforce stuffs on everyone because of gnome (of course nothing to do with gnome but people tend to blame gnome each time they have an issue with a gtk app). So obviously OK for me but I don't think my vote counts. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 03:40:42PM +0200, Juan Francisco Cantero Hurtado wrote: On Sun, Jun 24, 2012 at 02:29:48PM +0200, Antoine Jacoutot wrote: On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: So, open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... Maybe it's time to add something like that in the default session scripts (untested): Thanks Matthieu. That's exactly what I documented under ports/x11/dbus/pkg/README so pkg-readmes is better for this info. Yesterday, after of install gnome, I was seeing the files on pkg-readmes for to prevent that I was skipping something. I think that only the developers read pkg/. You are confused again... ports/x11/dbus/pkg/README gets installed as /usr/local/share/doc/pkg-readmes/dbus-1.4.20v0 -- Antoine
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 03:57:30PM +0200, Antoine Jacoutot wrote: On Sun, Jun 24, 2012 at 03:40:42PM +0200, Juan Francisco Cantero Hurtado wrote: On Sun, Jun 24, 2012 at 02:29:48PM +0200, Antoine Jacoutot wrote: On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: So, open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... Maybe it's time to add something like that in the default session scripts (untested): Thanks Matthieu. That's exactly what I documented under ports/x11/dbus/pkg/README so pkg-readmes is better for this info. Yesterday, after of install gnome, I was seeing the files on pkg-readmes for to prevent that I was skipping something. I think that only the developers read pkg/. You are confused again... ports/x11/dbus/pkg/README gets installed as /usr/local/share/doc/pkg-readmes/dbus-1.4.20v0 OK. I need sleep. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 03:40:42PM +0200, Juan Francisco Cantero Hurtado wrote: On Sun, Jun 24, 2012 at 02:29:48PM +0200, Antoine Jacoutot wrote: On Sun, Jun 24, 2012 at 02:24:18PM +0200, Matthieu Herrb wrote: On Sun, Jun 24, 2012 at 10:13:33AM +0200, Antoine Jacoutot wrote: So, open a terminal then: $ eval `dbus-launch --auto-syntax` $ emacs ... Maybe it's time to add something like that in the default session scripts (untested): Thanks Matthieu. That's exactly what I documented under ports/x11/dbus/pkg/README so pkg-readmes is better for this info. Yesterday, after of install gnome, I was seeing the files on pkg-readmes for to prevent that I was skipping something. I think that only the developers read pkg/. And where do you think pkg/README is installed when installing a package ? Landry
Re: Emacs 24.1
On Sat, Jun 23, 2012 at 12:50:14AM +0200, Juan Francisco Cantero Hurtado wrote: I know. Probably the problem is different for each application, but I've had a lots of problems with Gtk3 applications on other OS. All related to gnome-settings-daemon. Let me explain my experience with other OSs. I use various WM that don't run the gnome daemons. Some gtk3 applications don't start and others run with problems. I run gnome-settings-daemon and the most of the programs run OK. Yes that is a very common issue with gnome applications running outside of gnome. But it is not related to gsettings nor gtk+3 ; there was the exact same issue with gnome2 apps. I want use Gtk3, I really like, but I don't want use gsettings if is problematic. And I will not run a gnome daemon (or other daemon) just You do _not_ need to run gnome-settings-daemon. Just do you know, as soon as you have gtk+3 in the dependency chain, you get gsettings for free (dconf included); so enabling gsettings in an applications will not cost any more dependency. for that a application reads a few config options. In the emacs case, I think that the gsettings support is innecessary. This I cannot comment on. I just don' like this comment: Note for the rest of maintainers: if you are importing new software that permits to disable the gsettings support, please use this option. because there is no technical argument and it has to be a base by case decisioa anyway. The same for me with OpenBSD. How many non-gnome applications are using gsettings on OpenBSD right now?. Maybe the number is too low for to see the problems. They are using gsettings through glib+dconf. Does this new emacs install any schemas? If so did you add proper goos to the PLIST? Was dconf running? - Yes, but in the wrong directory. /usr/ports/pobj/emacs-24.1-gtk3/fake-amd64-gtk3/usr/local/share/emacs/24.1/etc/schema/schemas.xml Then it is a _porting_ problem; unrelated to emacs/gsettings. Fix the port so that is installs things in the correct dirs. If you want gsettings, you need the devel/dconf MODULE and the corresponding goos. Obviously emacs is broken and also other applications. Some day the upstream will fix the bugs, but disabling the gsettings support is the quick fix for problematic applications. The applications can use other backend for the configuration. Sure but advising people to disable gsettings everywhere when the issue is that your port installs things in the wrong directory is not really a good excuse to disable it. I don't want that the OpenBSD developers waste their time fixing this type of stupid problems :) OpenBSD developers can waste their time the way they want to :) I'm the one who worked and imported all the pieces for gsettings in OpenBSD -- so if something is broken I want to know it instead of people trying to hide the issue. We may eventually discover this is a bug in OpenBSD itself... that happened to me several times and I am happy I just didn't disable something because my opinion was that is was broken; but instead hunt for the issue. -- Antoine
Re: Emacs 24.1
On Sat, Jun 23, 2012 at 09:33:08AM +0200, Antoine Jacoutot wrote: On Sat, Jun 23, 2012 at 12:50:14AM +0200, Juan Francisco Cantero Hurtado wrote: I know. Probably the problem is different for each application, but I've had a lots of problems with Gtk3 applications on other OS. All related to gnome-settings-daemon. Let me explain my experience with other OSs. I use various WM that don't run the gnome daemons. Some gtk3 applications don't start and others run with problems. I run gnome-settings-daemon and the most of the programs run OK. Yes that is a very common issue with gnome applications running outside of gnome. But it is not related to gsettings nor gtk+3 ; there was the exact same issue with gnome2 apps. In my experience the issue is more usual with the gtk3 applications. The last years I haven't had problems with gtk2 applications related to gconf. I want use Gtk3, I really like, but I don't want use gsettings if is problematic. And I will not run a gnome daemon (or other daemon) just You do _not_ need to run gnome-settings-daemon. Just do you know, as soon as you have gtk+3 in the dependency chain, you get gsettings for free (dconf included); so enabling gsettings in an applications will not cost any more dependency. I was not speaking about the dependencies. I have no problems with a few extra dependencies. for that a application reads a few config options. In the emacs case, I think that the gsettings support is innecessary. This I cannot comment on. I just don' like this comment: Note for the rest of maintainers: if you are importing new software that permits to disable the gsettings support, please use this option. because there is no technical argument and it has to be a base by case decisioa anyway. Right. The comment is too generic and subjetive. Let me try again: If you're importing new software that uses gsetting, test the software on a non-gnome WM. If you have problems, try disabling temporarily gsettings in the package. Better, right? :) The same for me with OpenBSD. How many non-gnome applications are using gsettings on OpenBSD right now?. Maybe the number is too low for to see the problems. They are using gsettings through glib+dconf. Does this new emacs install any schemas? If so did you add proper goos to the PLIST? Was dconf running? - Yes, but in the wrong directory. /usr/ports/pobj/emacs-24.1-gtk3/fake-amd64-gtk3/usr/local/share/emacs/24.1/etc/schema/schemas.xml Then it is a _porting_ problem; unrelated to emacs/gsettings. Fix the port so that is installs things in the correct dirs. If you want gsettings, you need the devel/dconf MODULE and the corresponding goos. OK. I'll try again this afternoon. Obviously emacs is broken and also other applications. Some day the upstream will fix the bugs, but disabling the gsettings support is the quick fix for problematic applications. The applications can use other backend for the configuration. Sure but advising people to disable gsettings everywhere when the issue is that your port installs things in the wrong directory is not really a good excuse to disable it. My advice was due my bad experience with gsetting. It's not related to the broken port of emacs. I don't want that the OpenBSD developers waste their time fixing this type of stupid problems :) OpenBSD developers can waste their time the way they want to :) I'm the one who worked and imported all the pieces for gsettings in I know. I read the commits. Thanks for your hard work on gnome/gtk :) OpenBSD -- so if something is broken I want to know it instead of people trying to hide the issue. We may eventually discover this is a bug in OpenBSD itself... that happened to me several times and I am happy I just didn't disable something because my opinion was that is was broken; but instead hunt for the issue. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
On Sat, Jun 23, 2012 at 12:50:14AM +0200, Juan Francisco Cantero Hurtado wrote: On Fri, Jun 22, 2012 at 11:08:29PM +0200, Antoine Jacoutot wrote: Does this new emacs install any schemas? If so did you add proper goos to the PLIST? Was dconf running? - Yes, but in the wrong directory. /usr/ports/pobj/emacs-24.1-gtk3/fake-amd64-gtk3/usr/local/share/emacs/24.1/etc/schema/schemas.xml I was wrong, the schema is not a gsettings schema. It's a docbook schema. I found yesterday the schema just with a quick search with find but I didn't look the content. I've revised with tree the files of the emacs tarball and I can't found any gsetting (or gconf) schema. Probably, disable gsetting is the better for now. Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
On Sat, Jun 23, 2012 at 07:23:25PM +0200, Juan Francisco Cantero Hurtado wrote: because there is no technical argument and it has to be a base by case decisioa anyway. Right. The comment is too generic and subjetive. Let me try again: If you're importing new software that uses gsetting, test the software on a non-gnome WM. If you have problems, try disabling temporarily gsettings in the package. Better, right? :) Again this has _nothing_ to do with gnome. I can bet that if I try your emacs port in port I will see the same bug as you do outside of gnome. -- Antoine
Re: Emacs 24.1
On Sun, Jun 24, 2012 at 12:37:39AM +0200, Antoine Jacoutot wrote: On Sat, Jun 23, 2012 at 07:23:25PM +0200, Juan Francisco Cantero Hurtado wrote:because there is no technical argument and it has to be a base by case decisioa anyway. Right. The comment is too generic and subjetive. Let me try again: If you're importing new software that uses gsetting, test the software on a non-gnome WM. If you have problems, try disabling temporarily gsettings in the package. Better, right? :) Again this has _nothing_ to do with gnome. I can bet that if I try your emacs port in port I will see the same bug as you do outside of gnome. I've wasted one hour installing gnome and updating the other packages. I've compiled the original port without my one-line change, i.e. with gsettings enabled. I've open/close (exactly) 50 times emacs with C-x C-c. I'm writing this mail with emacs on gnome. *All works OK*. Also, it's not my port. The author is Manuel. I don't know if the port is right or if is broken. I don't care. I can't judge the quality of this port because I haven't read the ports documentation (but is in my todo). Sometimes, I test some ports of this list because I think that the tests are very important, but I never talk about quality of the ports. I've been fighting (as a user) with compilations and dependencies for almost 13 years, so I think that I can be a good tester for the ports. I just wanted give a advice to other developers based on my experience. The first was a bad advice, the later is correct in my opinion. The developers are free of to listen my advice or not. I'll not change my opinion about gsetting/gnome-setting-daemon for a long time (despite of my very good experience with gnome on openbsd). Again, emacs and other gtk3 applications are broken but the fix is very simple. I never said that gnome or gsettings are a bad thing. I said that gsettings is the usual culprit because a lot of applications have a broken implementation of gsettings. Also, usually gsettings is not essential for the applications. Despite of the possible interpretations of my mail, I'm not upset or something similar. Just this type of threads are very frustrating for me. I waste a lots of time on tests for demostrating something obvious for me and also is very exhausting for me to discuss in English. So, we should not waste more time with this discusion :) -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
On Fri, Jun 22, 2012 at 10:18:39AM +0200, Manuel Giraud wrote:
Juan Francisco Cantero Hurtado i...@juanfra.info writes:
OK, I was wrong. Ctrl-x Ctrl-c doesn't close the emacs window (gtk3
flavor). The same behavior with File-Quit. It works with the CLI
version of emacs (emacs -nw).
Ouch, you're right. I seems to work ok for the athena flavor. I'll look
into it but I think it is a tough one for me.
http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg21576.html
The culprit is the usual suspect: gsettings. I like Gtk3 but my
experience with gsettings is horrible. I've had a lots of problems with
software that uses gsettings on other OS, with and without
gnome-settings-daemon running, with gnome and other WMs.
Note for the rest of maintainers: if you are importing new software that
permits to disable the gsettings support, please use this option.
--- Makefile.orig Fri Jun 22 22:29:13 2012
+++ MakefileFri Jun 22 22:11:11 2012
@@ -53,6 +53,9 @@
# Suggestion from Mike Belopuhov to remove liboss dependency
CONFIGURE_ARGS += --without-sound
+# gsettings is always problematic if your WM is not gnome
+CONFIGURE_ARGS += --without-gsettings
+
.if ${FLAVOR:Mno_x11}
. if ${FLAVOR:Mathena}
ERRORS = Fatal: athena and no_x11 flavors are mutually
exclusive
Re: Emacs 24.1
On Fri, Jun 22, 2012 at 10:50:43PM +0200, Juan Francisco Cantero Hurtado wrote:
On Fri, Jun 22, 2012 at 10:18:39AM +0200, Manuel Giraud wrote:
Juan Francisco Cantero Hurtado i...@juanfra.info writes:
OK, I was wrong. Ctrl-x Ctrl-c doesn't close the emacs window (gtk3
flavor). The same behavior with File-Quit. It works with the CLI
version of emacs (emacs -nw).
Ouch, you're right. I seems to work ok for the athena flavor. I'll look
into it but I think it is a tough one for me.
http://www.mail-archive.com/cygwin-xfree@cygwin.com/msg21576.html
The culprit is the usual suspect: gsettings. I like Gtk3 but my
experience with gsettings is horrible. I've had a lots of problems with
software that uses gsettings on other OS, with and without
gnome-settings-daemon running, with gnome and other WMs.
I think you are confusinf things here.
As a matter of fact, gnome-settings-daemon is a gsettings _user_, not the other
way around.
gsettings is related to glib and not specific to gnome.
Note for the rest of maintainers: if you are importing new software that
permits to disable the gsettings support, please use this option.
Why? I've never had any issue with it.
Does this new emacs install any schemas? If so did you add proper goos to the
PLIST? Was dconf running?
Maybe it's not gsettings but emacs that is broken.
--- Makefile.orig Fri Jun 22 22:29:13 2012
+++ Makefile Fri Jun 22 22:11:11 2012
@@ -53,6 +53,9 @@
# Suggestion from Mike Belopuhov to remove liboss dependency
CONFIGURE_ARGS +=--without-sound
+# gsettings is always problematic if your WM is not gnome
+CONFIGURE_ARGS +=--without-gsettings
+
.if ${FLAVOR:Mno_x11}
. if ${FLAVOR:Mathena}
ERRORS = Fatal: athena and no_x11 flavors are mutually
exclusive
--
Antoine
Re: Emacs 24.1
On Wed, Jun 20, 2012 at 04:22:38AM +0200, Juan Francisco Cantero Hurtado wrote: On Tue, Jun 19, 2012 at 02:45:29PM +0200, Manuel Giraud wrote: Hi, Here is another try, with: - a gtk3 flavor - xdg-utils run dependency (not for no_x11) - no more liboss - more correct PLIST I've spotted an issue: M-x report-emacs-bug doesn't work if the -el subpackage is not installed (don't know why maybe it's a bug to be reported). Do you think -main and -el subpackages could be merged into one big jumbo pack? Gtk3 flavor tested on amd64. All seems OK. I agree with the removing of the -el subpackage, but wait to the reply of a developer. OK, I was wrong. Ctrl-x Ctrl-c doesn't close the emacs window (gtk3 flavor). The same behavior with File-Quit. It works with the CLI version of emacs (emacs -nw). -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
Hi, Here is another try, with: - a gtk3 flavor - xdg-utils run dependency (not for no_x11) - no more liboss - more correct PLIST I've spotted an issue: M-x report-emacs-bug doesn't work if the -el subpackage is not installed (don't know why maybe it's a bug to be reported). Do you think -main and -el subpackages could be merged into one big jumbo pack? emacs24.tgz Description: Unix tar archive -- Manuel Giraud
Re: Emacs 24.1
On Tue, Jun 19, 2012 at 02:45:29PM +0200, Manuel Giraud wrote: Hi, Here is another try, with: - a gtk3 flavor - xdg-utils run dependency (not for no_x11) - no more liboss - more correct PLIST I've spotted an issue: M-x report-emacs-bug doesn't work if the -el subpackage is not installed (don't know why maybe it's a bug to be reported). Do you think -main and -el subpackages could be merged into one big jumbo pack? Gtk3 flavor tested on amd64. All seems OK. I agree with the removing of the -el subpackage, but wait to the reply of a developer. Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: Emacs 24.1
Stuart Henderson s...@spacehopper.org writes:
On 2012/06/11 10:22, Manuel Giraud wrote:
Hi,
Here's a port of the new version of emacs. Currently testing on
i386.
A couple of things I noticed reading the port,
- missing desktop/icon-cache dependencies and @exec/unexec lines
What is this? I've done a make lib-depends-check and it seems happy.
- mandoc isn't expected to handle gzipped manpages; /etc/man.conf does have
settings to handle compressed manpages which work OK, but in general we don't
use gzipped manpages in OpenBSD.
So you mean that this port's manpages should stay gzipped or is it ok to
gunzip them? By the way, I think it ought to be gunzip
{realnames}.1.gz instead of gunzip *.1.gz, no?
- minor but we don't generally start a new version with anything in
REVISION-xx
Ok.
- is there anything to indicate that the amd64/mips64 gzip tsang-b5.el parts
are no longer needed?
It seems that all .el files are gzipped upon installation so I've just
removed this part.
FWIW, I'm all for killing the emacs 23 port in the process.
Is there a reason to have more than a current version and 21.x anyway?
i.e. would it make sense to just have editors/emacs21 and
editors/emacs?
I follow you on this. The point to have emacs23 not replacing emacs22 is
that it seems to be a PITA to upgrade .emacs file from 22 to 23. I don't
know if the point still stands from 23 to 24 (in fact, it worked
gracefully for me).
--
Manuel Giraud
Re: Emacs 24.1
On Mon, Jun 11, 2012 at 10:22:47AM +0200, Manuel Giraud wrote: Hi, Here's a port of the new version of emacs. Currently testing on i386. FWIW, I'm all for killing the emacs 23 port in the process. Hi. I'm reading the file NEWS.24.1 of emacs. I have a few comments: - Emacs can be compiled with Gtk+ 3.0 if you pass --with-x-toolkit=gtk3 to configure. Any chance for a gtk3 flavor?. - Typing C-c m in the buffer made by M-x report-emacs-bug transfers the report to your desktop's preferred mail client, if there is one. This uses either the xdg-email utility, or Mac OS's open command.. I don't see the runtime dep in the Makefile. - The default browser used by the package is now the xdg-open program, on platforms that support it. This calls your desktop's preferred browser. Also related to xdg-utils. Cheers. -- Juan Francisco Cantero Hurtado http://juanfra.info
