Re: [e-users] emacs problem persists
Hello, Sorry for late reply. I've been sutudysing in accordance with your advice. In the Message; Subject: Re: [e-users] emacs problem persists Message-ID : <20210823092101.b8d757c7c00edd3c6cbb8...@rasterman.com> Date & Time: Mon, 23 Aug 2021 09:21:01 +0100 [CH] == Carsten Haitzler has written: CH> Ummm look at this thread. CH> When windows are "hidden" (iconified, window on another virtual desktop etc.) CH> enlightenment will set the: CH> _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN [...] CH> Notice that the property appears while it's iconified and goes away when not. CH> You commented out the code in E that modifies this property (adds it and CH> removes it). The fact that this property is not set at all anymore points to CH> code in emacs somewhere that is responding to this property change and then CH> stops rendering, but when the property goes away it doesn't START rendering CH> again. Now, I fully understand the debugging method. Thanks, a lot! The comitter showd a patch, I'll check it. Regards. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "Three young men died for Rationalization. Yet, Margaret Bloody Thatcher LIVES!" 'Brassed Off' ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
On Sun, 22 Aug 2021 17:51:03 +0900 Masaru Nomiya said: Ummm look at this thread. When windows are "hidden" (iconified, window on another virtual desktop etc.) enlightenment will set the: _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN property. you can see it if you use the xprop tool to look at window properties. (xprop then click on a window - but it'll be visible so it won't be there. xprop -d 0x1234 etc. will get properties of a specific window). This property is set so the client application knows it's window is not normally visible to the user. Some applications stop rendering when this is set to save CPU and overhead. Why render updates the user will not see? When the window is visible again E will remove this property. You can watch the properties on your emacs window. e.g.: while [ 1 ]; do sleep 1; date; xprop -id 0x12345678 | grep _NET_WM_STATE; done and you will get times and the line from the xprop output. you can get window id by running xwininfo then clicking on a window. so for example here is a window I iconified then un-iconified: while [ 1 ]; do sleep 1; date; xprop -id 0x2e2 | grep _NET_WM_STATE; done Mon Aug 23 09:14:12 AM BST 2021 Mon Aug 23 09:14:13 AM BST 2021 Mon Aug 23 09:14:14 AM BST 2021 Mon Aug 23 09:14:15 AM BST 2021 Mon Aug 23 09:14:16 AM BST 2021 _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN Mon Aug 23 09:14:17 AM BST 2021 _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN Mon Aug 23 09:14:18 AM BST 2021 _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN Mon Aug 23 09:14:19 AM BST 2021 _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN Mon Aug 23 09:14:20 AM BST 2021 _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN Mon Aug 23 09:14:21 AM BST 2021 _NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN Mon Aug 23 09:14:22 AM BST 2021 Mon Aug 23 09:14:23 AM BST 2021 Mon Aug 23 09:14:24 AM BST 2021 Mon Aug 23 09:14:25 AM BST 2021 Notice that the property appears while it's iconified and goes away when not. You commented out the code in E that modifies this property (adds it and removes it). The fact that this property is not set at all anymore points to code in emacs somewhere that is responding to this property change and then stops rendering, but when the property goes away it doesn't START rendering again. > Hello, > > Just like an errand. (^^;; > > In the Message; > > Subject : Re: [e-users] emacs problem persists > Message-ID : <20210821072303.ead4637113305e2e51893...@rasterman.com> > Date & Time: Sat, 21 Aug 2021 07:23:03 +0100 > > [CH] == Carsten Haitzler has written: > > CH> On Sat, 21 Aug 2021 13:55:37 +0900 Masaru Nomiya > CH> said: > > [...] > CH> It doesn't handle the hidden state changes properly and chooses > CH> to not render updates. :) But you can now tell them what the bug is. > > I posted, but the committer can't understand. > Says with irony; > > >> Could you please ask the developer what the bug really is? Which are > >> the hidden changes and in which sense do we not render updates? What > >> should we do better? > > >> Thank you for any enlightenment in this area. > > So sorry, but how can I do? > > Thanks. > > --- > ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp > ┃＼／彡 > ┗━━┛ "Three young men died for Rationalization. >Yet, Margaret Bloody Thatcher LIVES!" > 'Brassed Off' > > > ___ > enlightenment-users mailing list > enlightenment-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-users > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
Hello, Just like an errand. (^^;; In the Message; Subject: Re: [e-users] emacs problem persists Message-ID : <20210821072303.ead4637113305e2e51893...@rasterman.com> Date & Time: Sat, 21 Aug 2021 07:23:03 +0100 [CH] == Carsten Haitzler has written: CH> On Sat, 21 Aug 2021 13:55:37 +0900 Masaru Nomiya said: [...] CH> It doesn't handle the hidden state changes properly and chooses CH> to not render updates. :) But you can now tell them what the bug is. I posted, but the committer can't understand. Says with irony; >> Could you please ask the developer what the bug really is? Which are >> the hidden changes and in which sense do we not render updates? What >> should we do better? >> Thank you for any enlightenment in this area. So sorry, but how can I do? Thanks. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "Three young men died for Rationalization. Yet, Margaret Bloody Thatcher LIVES!" 'Brassed Off' ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
Hello, In the Message; Subject: Re: [e-users] emacs problem persists Message-ID : <20210821072303.ead4637113305e2e51893...@rasterman.com> Date & Time: Sat, 21 Aug 2021 07:23:03 +0100 [CH] == Carsten Haitzler has written: CH> On Sat, 21 Aug 2021 13:55:37 +0900 Masaru Nomiya said: [...] MN> > Fixed! MN> > MN> > Many, many thanks, indeed. CH> This is not a fix. it is a test. You have an emacs bug. It CH> doesn't handle the hidden state changes properly and chooses to CH> not render updates. :) But you can now tell them what the bug is. I'll report this, soon. Thanks!! --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "Three young men died for Rationalization. Yet, Margaret Bloody Thatcher LIVES!" 'Brassed Off' ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
On Sat, 21 Aug 2021 13:55:37 +0900 Masaru Nomiya said: > Hello, > > In the Message; > > Subject : Re: [e-users] emacs problem persists > Message-ID : <20210820223253.b1d45376c2a8715c9ac2c...@rasterman.com> > Date & Time: Fri, 20 Aug 2021 22:32:53 +0100 > > [CH] == Carsten Haitzler has written: > > [...] > CK> > This is with emacs 27.1, as packaged in 1:27.1+1-3ubuntu3. > > CH> well to rule out it being the hidden property. > > CH> src/bin/e_hints.c > > CH> line 613 + 614. these: > > CH> if (ec->netwm.state.hidden) > CH> state[num++] = ECORE_X_WINDOW_STATE_HIDDEN; > > CH> comment those out. like: > > CH> // if (ec->netwm.state.hidden) > CH> // state[num++] = ECORE_X_WINDOW_STATE_HIDDEN; > > CH> and rebuild and see. > > Fixed! > > Many, many thanks, indeed. This is not a fix. it is a test. You have an emacs bug. It doesn't handle the hidden state changes properly and chooses to not render updates. :) But you can now tell them what the bug is. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
On Fri, 20 Aug 2021 19:23:13 -0400 Conrad Knight said: > On Fri, Aug 20, 2021 at 5:33 PM Carsten Haitzler wrote: > > well to rule out it being the hidden property. > > src/bin/e_hints.c > >if (ec->netwm.state.hidden) > > state[num++] = ECORE_X_WINDOW_STATE_HIDDEN; > > comment those out. like: > > Yup, that "fixed" the problem. What else is likely to be affected, though? Congrats. You found an emacs bug. :) -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
Hello, In the Message; Subject: Re: [e-users] emacs problem persists Message-ID : <20210820223253.b1d45376c2a8715c9ac2c...@rasterman.com> Date & Time: Fri, 20 Aug 2021 22:32:53 +0100 [CH] == Carsten Haitzler has written: [...] CK> > This is with emacs 27.1, as packaged in 1:27.1+1-3ubuntu3. CH> well to rule out it being the hidden property. CH> src/bin/e_hints.c CH> line 613 + 614. these: CH> if (ec->netwm.state.hidden) CH> state[num++] = ECORE_X_WINDOW_STATE_HIDDEN; CH> comment those out. like: CH> // if (ec->netwm.state.hidden) CH> // state[num++] = ECORE_X_WINDOW_STATE_HIDDEN; CH> and rebuild and see. Fixed! Many, many thanks, indeed. --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "Bill! You married with Computer. Not with Me!" "No..., with money." ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
On Fri, Aug 20, 2021 at 5:33 PM Carsten Haitzler wrote: > well to rule out it being the hidden property. > src/bin/e_hints.c >if (ec->netwm.state.hidden) > state[num++] = ECORE_X_WINDOW_STATE_HIDDEN; > comment those out. like: Yup, that "fixed" the problem. What else is likely to be affected, though? -Conrad. -- Shine like thunder Cry like rain ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
On Fri, 20 Aug 2021 10:22:57 -0400 Conrad Knight said: > > From: Carsten Haitzler > > I wonder if they are using the netwm visibility state oddly? E will set > > the netwm state to invisible if a window is iconified or when screen blanks > > and set it back when it is uniconified or screen unblanks. Also if you > > switch virtual desktops windows on other desktops get the hidden state set > > and removed when they appear again. When does it freeze and stop rendering? > > what do you do before that to make it happen? > > Just to throw another data point in here... this is exactly what i'm > seeing since using the git version of enlightenment (it was fine with > e 0.24.2). If i move to another virtual desktop, and then return to > the one with the emacs window, it looks like emacs never gets focus. > Enlightenment's borders do change colours to indicate it has focus, > but the cursor remains an empty box instead of a solid rectangle. > Typing in the window also shows nothing happening. Until... If i > minimize the window and bring it back, or if i shade and unshade the > window, it all looks ok again, and everything i typed is there! So i > can be typing blindly with nothing appearing in the window, then shade > and unshade, and see that everything i typed (more often than not on > the wrong line, because i couldn't see it). > > This is with emacs 27.1, as packaged in 1:27.1+1-3ubuntu3. well to rule out it being the hidden property. src/bin/e_hints.c line 613 + 614. these: if (ec->netwm.state.hidden) state[num++] = ECORE_X_WINDOW_STATE_HIDDEN; comment those out. like: // if (ec->netwm.state.hidden) // state[num++] = ECORE_X_WINDOW_STATE_HIDDEN; and rebuild and see. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
> From: Carsten Haitzler > I wonder if they are using the netwm visibility state oddly? E will set > the netwm state to invisible if a window is iconified or when screen blanks > and > set it back when it is uniconified or screen unblanks. Also if you switch > virtual desktops windows on other desktops get the hidden state set and > removed when they appear again. When does it freeze and stop rendering? what > do > you do before that to make it happen? Just to throw another data point in here... this is exactly what i'm seeing since using the git version of enlightenment (it was fine with e 0.24.2). If i move to another virtual desktop, and then return to the one with the emacs window, it looks like emacs never gets focus. Enlightenment's borders do change colours to indicate it has focus, but the cursor remains an empty box instead of a solid rectangle. Typing in the window also shows nothing happening. Until... If i minimize the window and bring it back, or if i shade and unshade the window, it all looks ok again, and everything i typed is there! So i can be typing blindly with nothing appearing in the window, then shade and unshade, and see that everything i typed (more often than not on the wrong line, because i couldn't see it). This is with emacs 27.1, as packaged in 1:27.1+1-3ubuntu3. -Conrad. -- Shine like thunder Cry like rain ___ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Re: [e-users] emacs problem persists
On Thu, 19 Aug 2021 16:39:16 +0900 Masaru Nomiya said:
I wonder if they are using the netwm visibility state oddly? E will set
the netwm state to invisible if a window is iconified or when screen blanks and
set it back when it is uniconified or screen unblanks. Also if you switch
virtual desktops windows on other desktops get the hidden state set and
removed when they appear again. When does it freeze and stop rendering? what do
you do before that to make it happen?
ie you will see:
_NET_WM_STATE(ATOM) = _NET_WM_STATE_HIDDEN
if you use xprop on a window if its iconified, on a non-visible virtual desktop
or when screen blanking starts. that property will be deleted/removed when it is
uniconified or otherwise visible again.
> Hello,
>
> In the Message;
>
> Subject: Re: [e-users] How to prevent the sudden appear of screenshot
> panel Message-ID : <87y298jnlu.wl-nom...@galaxy.dti.ne.jp>
> Date & Time: Wed, 11 Aug 2021 19:13:17 +0900
>
> [MN] == Masaru Nomiya has written:
>
> [...]
> MN> My issue seeems to occur with my hardware problem.
>
> MN> That is, I'm using the PS/2 USB conversion adapter for my keyboard.
> MN> It's wired no matter how it often requires the "taking out and putting
> MN> in of USB connection" operation.
>
> MN> I'll change the adapter.
>
> I's this!
>
> Sorry for the noise.
>
> BTW.
>
> Still now, emacs problem persists;
>
> 1. Emacs built with '--with-x-toolkit=lucid' option DOES shrink.
>
> 2. Emacs built with '--with-x-toolkit=gtk3' never shrinked, but got
> another problem. That is, Emacs got a quasi freeze since May 8th.
> I reported this issue to the bug-gnu-emacs ML, and yesterday was
> suggested to check my WM. That's it. The git head of enlightenment is
> causing the problem, I found.
> Then, I try to dig out the cause, and detected.
>
> The triiger of this issue is;
>
> commit 483c5e953c12a95382bef4a3b6769a680c32fe86
> Author: Martin Rudalics
> Date: Wed May 5 10:26:32 2021 +0200
>
> Fix two GTK3 event handling issues
>
> * src/xterm.c (handle_one_xevent): For GTK3 PropertyNotify and
> MapNotify events explicitly request the stored frame sizes when
> the frame changes from iconified to a non-hidden state
> (Bug#24526). For Expose events do not change the frame's
> visibility or iconified state. For FocusIn events on GTK3 do
> not apply the fix for Bug#42655. The latter two changes are to
> avoid that plain invisible frames get reported as iconified.
>
> That is, this patch is the cause.
>
> --- xterm.c.orig 2021-05-16 11:13:56.013376500 +0900
> +++ xterm.c 2021-08-19 16:17:49.823963974 +0900
> @@ -8181,12 +8181,8 @@
> #if defined USE_GTK && defined HAVE_GTK3
> /* If GTK3 wants to impose some old size here (Bug#24526),
>tell it that the current size is what we want. */
> - if (f->was_invisible)
> - {
> - xg_frame_set_char_size
> - (f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
> - f->was_invisible = false;
> - }
> + xg_frame_set_char_size
> + (f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
> #endif
> XSETFRAME (inev.ie.frame_or_window, f);
> }
> @@ -8447,12 +8443,8 @@
> #if defined USE_GTK && defined HAVE_GTK3
> /* If GTK3 wants to impose some old size here (Bug#24526),
>tell it that the current size is what we want. */
> - if (f->was_invisible)
> - {
> - xg_frame_set_char_size
> - (f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
> - f->was_invisible = false;
> - }
> + xg_frame_set_char_size
> + (f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
> #endif
> f->output_data.x->has_been_visible = true;
> }
> @@ -9343,11 +9335,6 @@
>goto OTHER;
>
> case VisibilityNotify:
> - f = x_top_window_to_frame (dpyinfo, event->xvisibility.window);
> - if (f && (event->xvisibility.state == VisibilityUnobscured
> - || event->xvisibility.state == VisibilityPartiallyObscured))
> - SET_FRAME_VISIBLE (f, 1);
> -
>goto OTHER;
>
> case MappingNotify:
> @@ -9604,12 +9591,11 @@
>/* The foreground of cursor_gc is typically the same as the normal
> background color, which can cause the cursor box to be invisible. */
>xgcv.foreground = f->output_data.x->cursor_pixel;
> - xgcv.line_width = 1;
>if (dpyinfo->scratch_cursor_gc)
> -XChangeGC (dpy, dpyinfo->scratch_cursor_gc, GCForeground | GCLineWidth,
> );
> +XChangeGC (dpy, dpyinfo->scratch_cursor_gc, GCForeground, );
>else
> dpyinfo->scratch_cursor_gc = XCreateGC (dpy, FRAME_X_DRAWABLE (f),
> - GCForeground | GCLineWidth,
> );
> + GCForeground, );
>gc = dpyinfo->scratch_cursor_gc;
>
>
[e-users] emacs problem persists
Hello,
In the Message;
Subject: Re: [e-users] How to prevent the sudden appear of screenshot
panel
Message-ID : <87y298jnlu.wl-nom...@galaxy.dti.ne.jp>
Date & Time: Wed, 11 Aug 2021 19:13:17 +0900
[MN] == Masaru Nomiya has written:
[...]
MN> My issue seeems to occur with my hardware problem.
MN> That is, I'm using the PS/2 USB conversion adapter for my keyboard.
MN> It's wired no matter how it often requires the "taking out and putting
MN> in of USB connection" operation.
MN> I'll change the adapter.
I's this!
Sorry for the noise.
BTW.
Still now, emacs problem persists;
1. Emacs built with '--with-x-toolkit=lucid' option DOES shrink.
2. Emacs built with '--with-x-toolkit=gtk3' never shrinked, but got
another problem. That is, Emacs got a quasi freeze since May 8th.
I reported this issue to the bug-gnu-emacs ML, and yesterday was
suggested to check my WM. That's it. The git head of enlightenment is
causing the problem, I found.
Then, I try to dig out the cause, and detected.
The triiger of this issue is;
commit 483c5e953c12a95382bef4a3b6769a680c32fe86
Author: Martin Rudalics
Date: Wed May 5 10:26:32 2021 +0200
Fix two GTK3 event handling issues
* src/xterm.c (handle_one_xevent): For GTK3 PropertyNotify and
MapNotify events explicitly request the stored frame sizes when
the frame changes from iconified to a non-hidden state
(Bug#24526). For Expose events do not change the frame's
visibility or iconified state. For FocusIn events on GTK3 do
not apply the fix for Bug#42655. The latter two changes are to
avoid that plain invisible frames get reported as iconified.
That is, this patch is the cause.
--- xterm.c.orig2021-05-16 11:13:56.013376500 +0900
+++ xterm.c 2021-08-19 16:17:49.823963974 +0900
@@ -8181,12 +8181,8 @@
#if defined USE_GTK && defined HAVE_GTK3
/* If GTK3 wants to impose some old size here (Bug#24526),
tell it that the current size is what we want. */
- if (f->was_invisible)
- {
- xg_frame_set_char_size
- (f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
- f->was_invisible = false;
- }
+ xg_frame_set_char_size
+ (f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
#endif
XSETFRAME (inev.ie.frame_or_window, f);
}
@@ -8447,12 +8443,8 @@
#if defined USE_GTK && defined HAVE_GTK3
/* If GTK3 wants to impose some old size here (Bug#24526),
tell it that the current size is what we want. */
- if (f->was_invisible)
- {
- xg_frame_set_char_size
- (f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
- f->was_invisible = false;
- }
+ xg_frame_set_char_size
+ (f, FRAME_PIXEL_WIDTH (f), FRAME_PIXEL_HEIGHT (f));
#endif
f->output_data.x->has_been_visible = true;
}
@@ -9343,11 +9335,6 @@
goto OTHER;
case VisibilityNotify:
- f = x_top_window_to_frame (dpyinfo, event->xvisibility.window);
- if (f && (event->xvisibility.state == VisibilityUnobscured
- || event->xvisibility.state == VisibilityPartiallyObscured))
- SET_FRAME_VISIBLE (f, 1);
-
goto OTHER;
case MappingNotify:
@@ -9604,12 +9591,11 @@
/* The foreground of cursor_gc is typically the same as the normal
background color, which can cause the cursor box to be invisible. */
xgcv.foreground = f->output_data.x->cursor_pixel;
- xgcv.line_width = 1;
if (dpyinfo->scratch_cursor_gc)
-XChangeGC (dpy, dpyinfo->scratch_cursor_gc, GCForeground | GCLineWidth,
);
+XChangeGC (dpy, dpyinfo->scratch_cursor_gc, GCForeground, );
else
dpyinfo->scratch_cursor_gc = XCreateGC (dpy, FRAME_X_DRAWABLE (f),
- GCForeground | GCLineWidth, );
+ GCForeground, );
gc = dpyinfo->scratch_cursor_gc;
/* When on R2L character, show cursor at the right edge of the
Does this give you any clue?
Regards.
---
┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp
┃＼／彡
┗━━┛ "Bill! You married with Computer.
Not with Me!"
"No..., with money."
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
