[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Concurrency, again
From: |
Stefan Huchler |
Subject: |
Re: Concurrency, again |
Date: |
Fri, 14 Oct 2016 19:01:18 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Hello guys,
I want to add something to that conversation,
John Wiegley <address@hidden> writes:
> And yet, this list is *about it* for me, and I practically live in Emacs. I'm
> not even completely sure yet that solving these would appreciably benefit my
> workflow. I don't mind the occasional coffee break.
I gone from gnome to various tiling wms to finaly when it came up land
in Exwm, for those who dont know it a emacs based window manager.
It improved my workflow cause I dont have to handle a 2 layer
applcation/buffer layout, I dont have to think that complex do I know
change to other program like lets say thunderbird, or do I only have to
change to another buffer like gnus (or *Groups*).
I also dont have to switch first to emacs and then in a second step to
gnus.
I am shure many of you know think how does that relate to that topic,
well if you use exwm, emacs is basicly your complete desktop. So
concurency or parralism is much of a bigger problem. If you use a
external browser you can do things there if emacs freezes, in exwm you
cant.
Also its nearly impossible for me to start a 2nd emacs for gnus inside exwm at
least with the same configuration, cause it would eat the shortcuts to
switch back to the "primary" emacs session.
But gnus has on the one hand great usability and features on the other
hand is a pain in the ass, using it on 2 different machines is difficult
to setup, also the window configuration with constant resizing or
creating many new buffers causes problems at least for my usecase, when
I then switch to another buffer it gets not resised to full screen
automaticly and when I switch back to gnus it does not rearange the
buffers (or windows).
So I question the quality of that package itself, and maybe hacking gnus
itself would be a better way to make things better than rewrite emacs
with some multithread magic.
But yes I want a emacs browser and also instead of running this monstres
proprietary javascript programs that makes us want to use 8 cpu cores, I
would rather have better ways to extract the data from websites, and
beeing able to answer to comments on websites with something like gnus
groups.
Also even I use keyboard driven browsers like conkeror or qutebrowser a
native emacs browser would still be better.
I maybe give a bit a mixed message, but my main points are that having a
second emacs instance is not always a (easy) option, 2nd people like me
want to use emacs as desktop, I think there locking is even a bigger
issue.
Maybe a middle step would be to integrate XELB/EXWM and just have more
than one instance of emacs running but INSIDE emacs. so that you dont
have 2 windows and then make them play better together with each other?
Communicate between them?
Maybe have single-progamm emacs instances tat then is a buffer in the
master-emacs, that would also solve the problem with rearanging windows
in gnus.
Hope I did not talk to much unrelated stuff. But it gives you maybe a
different perspective of a slightly different use case.
> I just want to make sure we're not try to solve the technical problem just
> because it's solvable; we should only solve it if it's a real problem that is
> getting in people's way, or is stopping us from doing the Next Cool
> Thing
Yes I agree to that, there would be other places where a bit love would
help. solving the browser-mess as example (luckily we see here movement
with ewb and emacs xwidget/webkit.
- Re: Concurrency, again, (continued)
- Re: Concurrency, again, John Wiegley, 2016/10/13
- Re: Concurrency, again, Ted Zlatanov, 2016/10/14
- Re: Concurrency, again, Michael Albinus, 2016/10/14
- Re: Concurrency, again, John Wiegley, 2016/10/14
- Re: Concurrency, again, John Wiegley, 2016/10/14
- Re: Concurrency, again, Ted Zlatanov, 2016/10/14
- Re: Concurrency, again, Michael Albinus, 2016/10/15
- Re: Concurrency, again, Ted Zlatanov, 2016/10/17
- Re: Concurrency, again, Ken Raeburn, 2016/10/17
- Re: Concurrency, again, Stefan Monnier, 2016/10/17
- Re: Concurrency, again,
Stefan Huchler <=
- Re: Concurrency, again, Perry E. Metzger, 2016/10/17
- Re: Concurrency, again, Eli Zaretskii, 2016/10/17
- Re: Concurrency, again, Perry E. Metzger, 2016/10/17
- Re: Concurrency, again, Eli Zaretskii, 2016/10/17
- Re: Concurrency, again, Perry E. Metzger, 2016/10/17
- Re: Concurrency, again, Lars Ingebrigtsen, 2016/10/17
- Re: Concurrency, again, Stefan Huchler, 2016/10/17
- Re: Concurrency, again, Lars Ingebrigtsen, 2016/10/18
- Re: Concurrency, again, Eli Zaretskii, 2016/10/18
- Re: Concurrency, again, Lars Ingebrigtsen, 2016/10/18