unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "André A. Gomes" <andremegafone@gmail.com>
To: Jan Nieuwenhuizen <janneke@gnu.org>
Cc: guix-devel@gnu.org
Subject: Re: EXWM
Date: Mon, 18 Oct 2021 19:44:09 +0300	[thread overview]
Message-ID: <878ryqe10m.fsf@gmail.com> (raw)
In-Reply-To: <87pms2529l.fsf@gnu.org> (Jan Nieuwenhuizen's message of "Mon, 18 Oct 2021 07:29:42 +0200")

Jan Nieuwenhuizen <janneke@gnu.org> writes:

> Arun Isaac writes:
>
> Hello,
>
>>> My suggestion is simple: remove the added layer of complexity introduced
>>> by the .exwm file; don't force a default Exwm config on the user.
>>
>> I think I agree with you now. I checked, and exwm indeed does not run
>> when emacs is opened in the console even though my exwm config is
>> defined in my ~/.emacs.
>
> Interesting.  So the extra, unneccesary initialization code does not
> hurt there.
>
> I just tried adding my ~/.exwm into my init.el and running a nested
> emacs and now I get a GUI dialog:
>
>     Replace existing window manager? Y/N
>
> Not great!  Not very suprisingly, the extra unnecessary initialization
> /does/ hurt here.

Isn't exwm doing precisely what it's supposed to do?  Isn't it fair that
the newly spawned (nested) Emacs has the right to take control over the
"older" Emacs?

It does so in a very polite way, by asking what should be done.  If you
disagree with the default behaviour, you can change the value of the
variable exwm-replace.

>> So, I see no reason to continue having ~/.exwm. If no one else has any
>> objections, please do send a patch fixing this.
>
> I would very much like for this nested emacs issue to be addressed
> first.
>
> I just don't really see the point in mixing two bits of code that are
> meant to run in different scenarios, and then disabling one of them.

I don't see how it could possibly qualify as an issue, and what those
"different scenarios" are.

There's one and only one scenario.  The user launches emacs.  Emacs
reads the user's init file, and carries out the instructions.

The confusion arises from thinking about Exwm as a "session", with a
.desktop file associated with it.  But that's a special case of
something more general and simple.

Exwm is an Emacs extension, requiring a graphical X session.  After all,
it manages X windows "à la Emacs".

If you try to start Exwm from the console, it will handle it.

If you start Exwm from DEs or WMs (GNOME, i3, whatever), it will handle
it (on Guix, that requires running xhost).  Yes, this is a good middle
ground for "beginners" that aren't ready to fully convert themselves to
the Light.

If you start Exwm from Exwm itself, it will handle it as well.

The so-called "emacs-exwm" session is nothing but a convenience to
handle a common scenario.  If Exwm handles X windows, then it makes
sense to start a graphical session and IMMEDIATELY start Emacs so that
Exwm kicks in.

What happens if Exwm doesn't kick in, btw?  You get a bunch of X windows
floating around, and you won't be able to handle them with ease.  Makes
sense.

What should the "emacs-exwm" session do, then?  With some
simplifications, nothing but this:

--8<---------------cut here---------------start------------->8---
dbus-launch --exit-with-session emacs -mm --debug-init
--8<---------------cut here---------------end--------------->8---

Yes, there shouldn't even be any "exwm" logic in it.  The user knows
better.  Let the user's init file be in charge. 

I did my best to show my point of view, and I won't press on it anymore.
The decision is on the community's side.

The patch the trivial.  Acceptance isn't.


--
André A. Gomes
"Free Thought, Free World"


  reply	other threads:[~2021-10-18 16:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-04 14:33 EXWM André A. Gomes
2021-10-08  9:57 ` EXWM Arun Isaac
2021-10-08 10:21   ` EXWM Jan Nieuwenhuizen
2021-10-08 10:55     ` EXWM Arun Isaac
2021-10-10 13:16       ` EXWM Ludovic Courtès
2021-10-15  7:15         ` EXWM André A. Gomes
2021-10-15  6:54     ` EXWM André A. Gomes
2021-10-08 10:59 ` EXWM Arun Isaac
2021-10-15  7:38   ` EXWM André A. Gomes
2021-10-16 16:03     ` EXWM Arun Isaac
2021-10-18  5:29       ` EXWM Jan Nieuwenhuizen
2021-10-18 16:44         ` André A. Gomes [this message]
2021-10-20  7:27           ` EXWM Jan Nieuwenhuizen
2021-10-22 10:25             ` EXWM André A. Gomes
2021-10-22 10:37               ` EXWM Arun Isaac
2021-10-22 10:52                 ` EXWM André A. Gomes
2021-10-22 18:55               ` EXWM Ricardo Wurmus
2021-10-22 19:36                 ` EXWM André A. Gomes
2021-10-22 20:15                   ` EXWM André A. Gomes
2021-10-23 15:02                     ` EXWM André A. Gomes
  -- strict thread matches above, loose matches on Subject: below --
2022-01-01 19:19 EXWM calcium
2022-01-03 20:03 ` EXWM André A. Gomes

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://guix.gnu.org/

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

  git send-email \
    --in-reply-to=878ryqe10m.fsf@gmail.com \
    --to=andremegafone@gmail.com \
    --cc=guix-devel@gnu.org \
    --cc=janneke@gnu.org \
    /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/guix.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).