unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Tim Cross <theophilusx@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Feature change or bug - Emacs server
Date: Sat, 11 Jun 2011 12:48:57 +1000	[thread overview]
Message-ID: <BANLkTi=-aNGPhsCmEdSoDPD9ZKjDqsp0hw@mail.gmail.com> (raw)
In-Reply-To: <jwv4o3zrpye.fsf-monnier+emacs@gnu.org>

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

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

[-- Attachment #2: Type: text/html, Size: 3917 bytes --]

  reply	other threads:[~2011-06-11  2:48 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-09  6:47 Feature change or bug - Emacs server Tim Cross
2011-06-09  7:17 ` Tassilo Horn
2011-06-09  8:13   ` chad
2011-06-09 15:21 ` Stefan Monnier
2011-06-11  2:48   ` Tim Cross [this message]
2011-06-11 10:39     ` Ted Zlatanov
2011-06-13  2:09       ` Tim Cross
2011-06-13  4:53         ` Now: Emacs<->Mozilla Integration -- Was: " Mohsen BANAN
2011-06-13  7:37           ` chad
2011-06-14  3:57             ` Tim Cross
2011-06-14  3:53           ` Tim Cross
2011-06-14  8:37           ` Daniel Colascione
2011-06-13 15:47         ` Ted Zlatanov
2011-06-14  3:42           ` Tim Cross
2011-06-14 14:53             ` Lars Magne Ingebrigtsen
2011-06-14 15:01               ` Julien Danjou
2011-06-14 17:08                 ` joakim
2011-06-14 16:17             ` Ted Zlatanov
  -- strict thread matches above, loose matches on Subject: below --
2011-06-13 16:49 T.V Raman
2011-06-13 17:11 ` Mohsen BANAN
2011-06-13 17:18 ` Ted Zlatanov
2011-06-13 17:36   ` Michael Albinus
2011-06-13 23:45   ` Antoine Levitt
2011-06-14  0:57     ` Ted Zlatanov
2011-06-14  3:12       ` Tim Cross
2011-06-14  7:49       ` Antoine Levitt
2011-06-14  9:45         ` joakim
2011-06-14  8:22       ` Michael Albinus
2011-06-13 18:31 ` joakim
2011-06-14  3:18 ` Tim Cross

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTi=-aNGPhsCmEdSoDPD9ZKjDqsp0hw@mail.gmail.com' \
    --to=theophilusx@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).