guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EXWM


From: André A . Gomes
Subject: Re: EXWM
Date: Mon, 18 Oct 2021 19:44:09 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

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 via email to

[Prev in Thread] Current Thread [Next in Thread]