On Wed, 13 Dec 2023 14:10:12 +0100
Didier Kryn <kryn@???> wrote:

> Le 13/12/2023 à 11:27, Alexandros Prekates via Dng a écrit :
> > On Wed, 13 Dec 2023 00:36:56 +0100
> > Didier Kryn<kryn@???> wrote:
> ...
> >     I'm curious to learn in what sense the emacs experience would
> > be different, if it was provided by a permanently running emacs
> > server to which users would connect through dbus? Appart from being
> > complicated and fragile.
> > I agree. "The very existence of /usr/bin/emacs *is* a great service
> > provided to the user".
> >
> > I try to frame the discussion in the Desktop User workFlow setup ,
> > Management and supervision (DUFM) umbrella term.
>
>     ...
>
>     Alexandros,
>
>     I use to not read when its too long and when I find no concern;
> therefore I may have missed the practical utility of your
> questionning. However, when asked directly, you still failed to tell
> it. I personnaly don't give a dam of this DUFM contraption and
> theories about it. I just want computers to provide the services I
> need or like. I mean services in a very general acception, like the
> bare existence of an application like Emacs. And have control on it
> all.
>
>     I like very much Emacs and I know it can do much more than I use
> it f.or. I know some people are extremely fan of it, even to the
> point of doing all their computing activity from within it. However I
> would never have imagined they developped such a thing as an /emacs
> server/! I write a /thing/; I couldn't possibly name this an
> /utility/.
>
> --     Didier
>

Sorry if not answered directly nevertheless i have answered in
another reply. I will try to answer how i view this emacs server thing.

Emacs as a service is a mild misnomer . I would prefer the term user
workflow nucleus or flownucleus for short.
Now the purpose is not to change the emacs experience but the
integration of emacs in larger desktop user workflows where many
programs take part. So being able to integrate emacs in larger workflows
it would entail ways for a supervisor (or the workflow maestro) to
control emacs . In that lense emacs being supervised even in basic
terms or being more easily discoverable and being able to start from
another app that need it facilites the setup of workflows.

I guess an analogy would be between a solo piano player and a piano
player that has learned to play as part of an orchestra and has learned
to follow the maestro tempo and instructions.

Emacs is the piano and a user with skills to set up her/his workflows
in an orchestrated coordinated way would be the maestro.
So using emacs hasnt change. But being part of a workflow need emacs
to be responsive to a set of supervisor - workflow signals instructions
with the most basic being start - stop .

Of course the analogy is not complete. Orchestra's instrument players
dont exchange instructions but i think it helps.


Alexandros.