From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: Feature change or bug - Emacs server Date: Sat, 11 Jun 2011 12:48:57 +1000 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=0016369f9ac544484e04a566ba78 X-Trace: dough.gmane.org 1307760561 2221 80.91.229.12 (11 Jun 2011 02:49:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 11 Jun 2011 02:49:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 11 04:49:16 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QVEGB-0007Hn-9F for ged-emacs-devel@m.gmane.org; Sat, 11 Jun 2011 04:49:15 +0200 Original-Received: from localhost ([::1]:34256 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVEGA-0007w3-FB for ged-emacs-devel@m.gmane.org; Fri, 10 Jun 2011 22:49:14 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVEFw-0007vq-7y for emacs-devel@gnu.org; Fri, 10 Jun 2011 22:49:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QVEFu-0003U8-Sn for emacs-devel@gnu.org; Fri, 10 Jun 2011 22:49:00 -0400 Original-Received: from mail-iy0-f169.google.com ([209.85.210.169]:46778) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QVEFu-0003U2-JC for emacs-devel@gnu.org; Fri, 10 Jun 2011 22:48:58 -0400 Original-Received: by iyl8 with SMTP id 8so3648127iyl.0 for ; Fri, 10 Jun 2011 19:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k8RhzOHubgCCNyzkh+vV0BcPTL8/WX6VZEkOjbXGkA4=; b=d3jVUCasMtvYizb2LBeLItE5LKr2H1C9UBVpM37Ian9NwFPNAKAVWFx43mR3LK7Uwn rK4Pfl8R19f7gM92HgCDO2eR3pNO9EJE69LiZqH5J/RHThXs+dnlm1XirP74RkddxHu1 xx12sRWOB0g0/6WwA/S0IpjxOZ6W7RjHyMg9g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dEZvWuW1A8HCz+jjbq+6olmlJAMhxc2O3jgq5b6M0jX1kBFb0n3EZRGDDOZI9bnmMG 3+LxbMDcjp+2/em28i8wKDc1GpWxBylE6pDCAUtldTwAXZzGiLTVtI/qlTF/sR5gauXg 7y04565ci/TYrFW/xQ7mkB1EKoJ2xYkqHBKk8= Original-Received: by 10.231.201.81 with SMTP id ez17mr1098199ibb.156.1307760537126; Fri, 10 Jun 2011 19:48:57 -0700 (PDT) Original-Received: by 10.231.32.72 with HTTP; Fri, 10 Jun 2011 19:48:57 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.169 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140363 Archived-At: --0016369f9ac544484e04a566ba78 Content-Type: text/plain; charset=ISO-8859-1 Thanks everyone for your responses. I will dig deeper. I too suspect it is a difference in window managers. The point about needing -c and -t switches is interesting. That is how I rememberd things having to be in order to have a new frame created (rather than using an existing frame). However, perhaps in error, I distinctly remember being surprised when I noticed new frames being created and then deleted when I finished with them, but was pretty sure I've never used the -c or -t switch except when connecting remotely and wanting to open a frame on an existing local instance. However, given all the changes I've been making lately, I could easily be mistaken. One thing I am sure about is that previously, with no -c or -t, when running something like cron -e or git commit, one of the existing frames would be used BUT would NOT be moved from one virtual deskto to the current desktop. I can live with either the reuse of an existing frame or opening and closing of a new frame, but really don't want an existing frame to be moved from its current virtual desktop to the desktop where I am running the terminal as this wrecks my setup and I then have to manually move the frame back. One of the reasons I asked this question on the list rather than logging a bug report is that I've recently been going through a number of environment changes in a search for a setup I liked. Unfortunately, this also means a much larger set of possible problem/change candidates. So, I was hoping a message here would help me reduce/prioritise the possibilities a bit (which I think it has). For some time, I've been getting increasingly frustrated with the increasing size (both with respect to disk size and memory/cpu footprint) of GNOME and as an old dog who started with X in the mid 80s, what feels like greatly increased complexity with little real increase in functionality. I look at my .xsession-errors file these days with a combination of puzzlement, awe and confusion as its seems to be full of information messages rather than errors. When you ask on forums what they mean, you get vague answers and statements like "Oh, just ignore them". As a consequence, I've been looking at various alternatives. I tried a recent GNOME and compiz - pretty but I think bloated. I looked at unity, but disliked it and hated menu options being in the top task bar rather than the app window. I've looked at some other and am currently using xfce. So far, the two I like most have been xfce and sawfish, though openbox also looks interesting. Of course, if emacs had a decent web browser able to handle javascript etc and there was some way of having multiple virtual desktops, my .Xsession would likely end with something like exec emacs In the meantime, I will experiment with various wm until I find the one that is as light weight as possible while still providing all the features I want. Then I will craft my own .Xsession and hopefully again reclaim at least the feeling I know what is going on and am in control! If anyone has any recommendations on non-GNOME (or KDE for that matter) wm they have found good, I'd be i9nterested in hearing about it (possibly privately to spare the list!). If I am able to confirm significant behavior differences with emacs server, frames and window managers, I'll report back and if significant enough, will log a bug report (even if that report just recommends a note in the manual to alert people to differences in behavior with some window managers). Tim --0016369f9ac544484e04a566ba78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


Thanks everyone for your responses.=A0
I will dig deeper. I too suspect it is a difference in window = managers.=A0
The point about needing -c and -t switches is intere= sting. That is how I rememberd things having to be in order to have a new f= rame created (rather than using an existing frame). However, perhaps in err= or, I distinctly remember being surprised when I noticed new frames being c= reated and then deleted when I finished with them, but was pretty sure I= 9;ve never used the -c or -t switch except when connecting remotely and wan= ting to open a frame on an existing local instance. However, given all the = changes I've been making lately, I could easily be mistaken.=A0

One thing I am sure about is that previously, with no -= c or -t, when running something like cron -e or git commit, one of the exis= ting frames would be used BUT would NOT be moved from one virtual deskto to= the current desktop. I can live with either the reuse of an existing frame= or opening and closing of a new frame, but really don't want an existi= ng frame to be moved from its current virtual desktop to the desktop where = I am running the terminal as this wrecks my setup and I then have to manual= ly move the frame back.=A0

One of the reasons I asked this question on the list ra= ther than logging a bug report is that I've recently been going through= a number of environment changes in a search for a setup I liked. Unfortuna= tely, this also means a much larger set of possible problem/change candidat= es. So, I was hoping a message here would help me reduce/prioritise the pos= sibilities a bit (which I think it has).

For some time, I've been getting increasingly frust= rated with the increasing size (both with respect to disk size and memory/c= pu footprint) of GNOME and as an old dog who started with X in the mid 80s,= what feels like greatly increased complexity with little real increase in = functionality. I look at my .xsession-errors file these days with a combina= tion of puzzlement, awe and confusion as its seems to be full of informatio= n messages rather than errors. When you ask on forums what they mean, you g= et vague answers and statements like "Oh, just ignore them".=A0

As a consequence, I've been looking at various alte= rnatives. I tried a recent GNOME and compiz - pretty but I think bloated. I= looked at unity, but disliked it and hated menu options being in the top t= ask bar rather than the app window. I've looked at some other and am cu= rrently using xfce. So far, the two I like most have been xfce and sawfish,= though openbox also looks interesting.=A0

Of course, if emacs had a decent web browser able to ha= ndle javascript etc and there was some way of having multiple virtual deskt= ops, my .Xsession would likely end with something like

exec emacs=A0

In the meantime, I will experim= ent with various wm until I find the one that is as light weight as possibl= e while still providing all the features I want. Then I will craft my own .= Xsession and hopefully again reclaim at least the feeling I know what is go= ing on and am in control! If anyone has any recommendations on non-GNOME (o= r KDE for that matter) wm they have found good, I'd be i9nterested in h= earing about it (possibly privately to spare the list!).=A0

If I am able to confirm significant behavior difference= s with emacs server, frames and window managers, I'll report back and i= f significant enough, will log a bug report (even if that report just recom= mends a note in the manual to alert people to differences in behavior with = some window managers).


Tim


--0016369f9ac544484e04a566ba78--