Emacs as WM

Emacs as WM

[Matthew Plant]

I was curious about what people on this list thought about application
embedding in Emacs. To a degree this is already supported with ansi
term, but this obviously doesn't extend to GUI applications. For those
of you familiar with Plan 9, think of how programs use the window the
terminal they're launched in; embedding GUI apps in Emacs would force
the program to run in a window owned by Emacs and fitted into a buffer.

The reason why I bring this up is because it would be relatively easy to
do in a way that's not very platform agnostic. It's really easy to
replace the X libarary (forgive me for not using proper nomenclature;
it'd lengthen this email tenfold) window creation functions with one
that extends contol over the window. The degree of integration can be
controlled by the number of replaced functions. If drawn text wants to
be handled specially, those functions would be replaced. Some method can
be specified for switching between emacs and the application controlling
user input.

This has some obvious advantages; for one, Emacs automatically subsumes
all editors, including more WYSIWYG editors. Not only that, but Emacs
essentially becomes a window manager, which I personally would
love. Because some apps, particular web browsers, do not always require
special handling of the keyboard, switching between regular Emacs
buffers and the special app buffers would be generally seamless. I could
imagine myself typing away in one Emacs buffer, momentarily moving to
the mouse to click throught some online doxygen in my web browser in the
buffer to the right.

There are also a lot of disadvantages to this. For one, the applications
would be pretty buggy without some effort to re-implement X
functions. Also, my co-worker points out that this would be incongrous
with the current capabilities of Emacs, one of which is the easy
transfer of text betwixt buffers. Getting these two features to work
harmoniously would be kind of difficult; lots of wrappers to
X/Gnome/whatever text writing functions would have to be made. However,
copy and paste would work (I'm guessing) out of the box.

I suppose it all boils down to what people want with the future of
Emacs. Personally, I would love to turn on my computer and have Emacs be
there every step of the way. I genuinely think that Emacs is a great
full interface to an OS. It is not a full OS however and never should
be, which is why I like this idea as an in-between.

-M

Re: Emacs as WM

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 2772 bytes --]

Personally I regularly have the opposite itch: wanting to replace emacs's
frustrating window management with an external tiling WM (in my case
awesome).

/john


On Fri, Aug 8, 2014 at 4:35 PM, Matthew Plant <maplant2@illinois.edu> wrote:

> I was curious about what people on this list thought about application
> embedding in Emacs. To a degree this is already supported with ansi
> term, but this obviously doesn't extend to GUI applications. For those
> of you familiar with Plan 9, think of how programs use the window the
> terminal they're launched in; embedding GUI apps in Emacs would force
> the program to run in a window owned by Emacs and fitted into a buffer.
>
> The reason why I bring this up is because it would be relatively easy to
> do in a way that's not very platform agnostic. It's really easy to
> replace the X libarary (forgive me for not using proper nomenclature;
> it'd lengthen this email tenfold) window creation functions with one
> that extends contol over the window. The degree of integration can be
> controlled by the number of replaced functions. If drawn text wants to
> be handled specially, those functions would be replaced. Some method can
> be specified for switching between emacs and the application controlling
> user input.
>
> This has some obvious advantages; for one, Emacs automatically subsumes
> all editors, including more WYSIWYG editors. Not only that, but Emacs
> essentially becomes a window manager, which I personally would
> love. Because some apps, particular web browsers, do not always require
> special handling of the keyboard, switching between regular Emacs
> buffers and the special app buffers would be generally seamless. I could
> imagine myself typing away in one Emacs buffer, momentarily moving to
> the mouse to click throught some online doxygen in my web browser in the
> buffer to the right.
>
> There are also a lot of disadvantages to this. For one, the applications
> would be pretty buggy without some effort to re-implement X
> functions. Also, my co-worker points out that this would be incongrous
> with the current capabilities of Emacs, one of which is the easy
> transfer of text betwixt buffers. Getting these two features to work
> harmoniously would be kind of difficult; lots of wrappers to
> X/Gnome/whatever text writing functions would have to be made. However,
> copy and paste would work (I'm guessing) out of the box.
>
> I suppose it all boils down to what people want with the future of
> Emacs. Personally, I would love to turn on my computer and have Emacs be
> there every step of the way. I genuinely think that Emacs is a great
> full interface to an OS. It is not a full OS however and never should
> be, which is why I like this idea as an in-between.
>
> -M
>
>

[-- Attachment #2: Type: text/html, Size: 3320 bytes --]

Re: Emacs as WM

[joakim]

Matthew Plant <maplant2@illinois.edu> writes:

> I was curious about what people on this list thought about application
> embedding in Emacs. To a degree this is already supported with ansi
> term, but this obviously doesn't extend to GUI applications. For those
> of you familiar with Plan 9, think of how programs use the window the
> terminal they're launched in; embedding GUI apps in Emacs would force
> the program to run in a window owned by Emacs and fitted into a buffer.

Please see the Emacs Xwidget project, which has a somewhat rambling
overview here:
http://www.verona.se/thoughts/2013/10/24_xwidget-emacs.html

>
> The reason why I bring this up is because it would be relatively easy to
> do in a way that's not very platform agnostic. It's really easy to
> replace the X libarary (forgive me for not using proper nomenclature;
> it'd lengthen this email tenfold) window creation functions with one
> that extends contol over the window. The degree of integration can be
> controlled by the number of replaced functions. If drawn text wants to
> be handled specially, those functions would be replaced. Some method can
> be specified for switching between emacs and the application controlling
> user input.
>
> This has some obvious advantages; for one, Emacs automatically subsumes
> all editors, including more WYSIWYG editors. Not only that, but Emacs
> essentially becomes a window manager, which I personally would
> love. Because some apps, particular web browsers, do not always require
> special handling of the keyboard, switching between regular Emacs
> buffers and the special app buffers would be generally seamless. I could
> imagine myself typing away in one Emacs buffer, momentarily moving to
> the mouse to click throught some online doxygen in my web browser in the
> buffer to the right.
>
> There are also a lot of disadvantages to this. For one, the applications
> would be pretty buggy without some effort to re-implement X
> functions. Also, my co-worker points out that this would be incongrous
> with the current capabilities of Emacs, one of which is the easy
> transfer of text betwixt buffers. Getting these two features to work
> harmoniously would be kind of difficult; lots of wrappers to
> X/Gnome/whatever text writing functions would have to be made. However,
> copy and paste would work (I'm guessing) out of the box.
>
> I suppose it all boils down to what people want with the future of
> Emacs. Personally, I would love to turn on my computer and have Emacs be
> there every step of the way. I genuinely think that Emacs is a great
> full interface to an OS. It is not a full OS however and never should
> be, which is why I like this idea as an in-between.
>
> -M
>

-- 
Joakim Verona

Re: Emacs as WM

[Feng Shu]

John Yates <john@yates-sheets.org> writes:

> Personally I regularly have the opposite itch: wanting to replace
> emacs's frustrating window management with an external tiling WM (in
> my case awesome).

I use stumpwm, which is like emacs.

>
> /john
>
> On Fri, Aug 8, 2014 at 4:35 PM, Matthew Plant <maplant2@illinois.edu>
> wrote:
>
>     I was curious about what people on this list thought about
>     application
>     embedding in Emacs. To a degree this is already supported with
>     ansi
>     term, but this obviously doesn't extend to GUI applications. For
>     those
>     of you familiar with Plan 9, think of how programs use the window
>     the
>     terminal they're launched in; embedding GUI apps in Emacs would
>     force
>     the program to run in a window owned by Emacs and fitted into a
>     buffer.
>     
>     The reason why I bring this up is because it would be relatively
>     easy to
>     do in a way that's not very platform agnostic. It's really easy to
>     replace the X libarary (forgive me for not using proper
>     nomenclature;
>     it'd lengthen this email tenfold) window creation functions with
>     one
>     that extends contol over the window. The degree of integration can
>     be
>     controlled by the number of replaced functions. If drawn text
>     wants to
>     be handled specially, those functions would be replaced. Some
>     method can
>     be specified for switching between emacs and the application
>     controlling
>     user input.
>     
>     This has some obvious advantages; for one, Emacs automatically
>     subsumes
>     all editors, including more WYSIWYG editors. Not only that, but
>     Emacs
>     essentially becomes a window manager, which I personally would
>     love. Because some apps, particular web browsers, do not always
>     require
>     special handling of the keyboard, switching between regular Emacs
>     buffers and the special app buffers would be generally seamless. I
>     could
>     imagine myself typing away in one Emacs buffer, momentarily moving
>     to
>     the mouse to click throught some online doxygen in my web browser
>     in the
>     buffer to the right.
>     
>     There are also a lot of disadvantages to this. For one, the
>     applications
>     would be pretty buggy without some effort to re-implement X
>     functions. Also, my co-worker points out that this would be
>     incongrous
>     with the current capabilities of Emacs, one of which is the easy
>     transfer of text betwixt buffers. Getting these two features to
>     work
>     harmoniously would be kind of difficult; lots of wrappers to
>     X/Gnome/whatever text writing functions would have to be made.
>     However,
>     copy and paste would work (I'm guessing) out of the box.
>     
>     I suppose it all boils down to what people want with the future of
>     Emacs. Personally, I would love to turn on my computer and have
>     Emacs be
>     there every step of the way. I genuinely think that Emacs is a
>     great
>     full interface to an OS. It is not a full OS however and never
>     should
>     be, which is why I like this idea as an in-between.
>     
>     -M

-- 

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I'd like Emacs to do word processing and be able to share documents
with other users through a P2P mechanism.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

document sharing (was Re: Emacs as WM)

[Nic Ferrier]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I'd like Emacs to do word processing and be able to share documents
> with other users through a P2P mechanism.

I am going to look into the webrtc protocols to see if Emacs could
support them and implement some document sharing on that (if it can be
done).

You talked before about Word Processing, it doesn't mean much to me
anymore. I associate it with printing documents, not electronic
transfer.

Do you mean something different from that?


Nic

Re: Emacs as WM

[Samuel El-Borai]

[-- Attachment #1: Type: text/plain, Size: 4262 bytes --]

Other projects of the same kind:

Guile-WM (Guile scheme)
-------------------------------------
From the README:
    "Guile-WM is a framework for creating an X window manager (or any other
X
application, really) and a set of useful modules designed for that purpose.

[...]

    Guile-WM relies /heavily/ on its user init file. In fact, it won't
do anything on

    its own without one. The intention is to provide something 100%

    configurable."


Link: https://github.com/mwitmer/guile-wm


# The Deep Space Window Manager (Common Lisp)

From the README:
    "DSWM is a fork of StumpWM, so have most of all features, which have
StumpWM, but it designed for better usability and better integration with
emacs."

Link: https://github.com/dss-project/dswm


You can also read a discussion about those here:
https://news.ycombinator.com/item?id=8160968



2014-08-09 1:04 GMT+02:00 Feng Shu <tumashu@gmail.com>:

> John Yates <john@yates-sheets.org> writes:
>
> > Personally I regularly have the opposite itch: wanting to replace
> > emacs's frustrating window management with an external tiling WM (in
> > my case awesome).
>
> I use stumpwm, which is like emacs.
>
> >
> > /john
> >
> > On Fri, Aug 8, 2014 at 4:35 PM, Matthew Plant <maplant2@illinois.edu>
> > wrote:
> >
> >     I was curious about what people on this list thought about
> >     application
> >     embedding in Emacs. To a degree this is already supported with
> >     ansi
> >     term, but this obviously doesn't extend to GUI applications. For
> >     those
> >     of you familiar with Plan 9, think of how programs use the window
> >     the
> >     terminal they're launched in; embedding GUI apps in Emacs would
> >     force
> >     the program to run in a window owned by Emacs and fitted into a
> >     buffer.
> >
> >     The reason why I bring this up is because it would be relatively
> >     easy to
> >     do in a way that's not very platform agnostic. It's really easy to
> >     replace the X libarary (forgive me for not using proper
> >     nomenclature;
> >     it'd lengthen this email tenfold) window creation functions with
> >     one
> >     that extends contol over the window. The degree of integration can
> >     be
> >     controlled by the number of replaced functions. If drawn text
> >     wants to
> >     be handled specially, those functions would be replaced. Some
> >     method can
> >     be specified for switching between emacs and the application
> >     controlling
> >     user input.
> >
> >     This has some obvious advantages; for one, Emacs automatically
> >     subsumes
> >     all editors, including more WYSIWYG editors. Not only that, but
> >     Emacs
> >     essentially becomes a window manager, which I personally would
> >     love. Because some apps, particular web browsers, do not always
> >     require
> >     special handling of the keyboard, switching between regular Emacs
> >     buffers and the special app buffers would be generally seamless. I
> >     could
> >     imagine myself typing away in one Emacs buffer, momentarily moving
> >     to
> >     the mouse to click throught some online doxygen in my web browser
> >     in the
> >     buffer to the right.
> >
> >     There are also a lot of disadvantages to this. For one, the
> >     applications
> >     would be pretty buggy without some effort to re-implement X
> >     functions. Also, my co-worker points out that this would be
> >     incongrous
> >     with the current capabilities of Emacs, one of which is the easy
> >     transfer of text betwixt buffers. Getting these two features to
> >     work
> >     harmoniously would be kind of difficult; lots of wrappers to
> >     X/Gnome/whatever text writing functions would have to be made.
> >     However,
> >     copy and paste would work (I'm guessing) out of the box.
> >
> >     I suppose it all boils down to what people want with the future of
> >     Emacs. Personally, I would love to turn on my computer and have
> >     Emacs be
> >     there every step of the way. I genuinely think that Emacs is a
> >     great
> >     full interface to an OS. It is not a full OS however and never
> >     should
> >     be, which is why I like this idea as an in-between.
> >
> >     -M
>
> --
>
>
>

[-- Attachment #2: Type: text/html, Size: 7837 bytes --]

Re: Emacs as WM

[Stefan Monnier]

> I'd like Emacs to do word processing

I like LaTeX (and its Emacs support packages) for that.

> and be able to share documents with other users through
> a P2P mechanism.

Not sue what you mean by that.  If you mean "on the fly", GNU ELPA has
Rudel which lets you share the contents of a buffer between different
Emacs sessions via TCP connections.

Otherwise, you can share by pushing to VCS repositories, most of whom
can happen via SSH so don't need any centralized server.


        Stefan

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I'd like Emacs to do word processing

    I like LaTeX (and its Emacs support packages) for that.

Word processing is what LibreOffice does.  It means you see the
formatted text, edit the formatted text, and save the formatted text
in a format such as ODF.

    > and be able to share documents with other users through
    > a P2P mechanism.

    Not sue what you mean by that.  If you mean "on the fly", GNU ELPA has
    Rudel which lets you share the contents of a buffer between different
    Emacs sessions via TCP connections.

Maybe that does the job I have in mind.  That is nice.  Can you email
me its docs?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as WM

[Stefan Monnier]

>> I'd like Emacs to do word processing
>     I like LaTeX (and its Emacs support packages) for that.
> Word processing is what LibreOffice does.

Well, that depends on one's definition of word processing.  For me,
LaTeX is at least as much word processing as LibreOffice.

But if you want WYSIWYG-style word processing, then no, there's still no
such functionality in Emacs, AFAIK.

>     Not sue what you mean by that.  If you mean "on the fly", GNU ELPA has
>     Rudel which lets you share the contents of a buffer between different
>     Emacs sessions via TCP connections.
> Maybe that does the job I have in mind.  That is nice.  Can you email
> me its docs?

I don't see any obvious docs in its repository, sorry.  I just quote the
description from http://elpa.gnu.org/packages/rudel.html below.


        Stefan


* INTRODUCTION

  Rudel is a collaborative editing environment for GNU Emacs. Its
  purpose is to share buffers with other users in order to edit the
  contents of those buffers collaboratively. Rudel supports multiple
  backends to enable communication with other collaborative editors
  using different protocols, though currently Obby (for use with the
  Gobby editor) is the only fully-functional one.

  Since Rudel is not an application, but an extension to Emacs, it is
  not started and used like most applications (not even Emacs
  applications like Gnus). Rudel mostly works in the background to
  change the behavior of the set of Emacs buffers for which it has
  been activated.

  The user interface consists of a set of key bindings, a menu entry
  and some visual status indicators, which are added to the text,
  header line and/or mode line of buffers for which Rudel has been
  activated.

* GETTING STARTED

  Assuming Rudel has already been installed (see file:INSTALL) and
  auto loading has been set up, a global Rudel mode can be enabled as
  follows:

  : M-x global-rudel-minor-mode

  This will enable key bindings to list available backends, join, and
  host Rudel sessions (see below). To enable this mode permanently,
  the following fragment can be added to the Emacs initialization
  file (usually file:~/.emacs):

  #+BEGIN_SRC emacs-lisp
  (global-rudel-minor-mode 1)
  #+END_SRC

** LISTING BACKENDS

   : M-x rudel-backend-dump 

   This command is available through the Rudel drop down menu.
   However, typically this is only used for debugging, since backends
   are chosen automatically when joining or hosting a session.

** JOINING A SESSION

   : M-x rudel-join-session [ C-c c j ]

   Depending on the installed Rudel backends, system environment and
   configuration, a number of questions will be asked, followed by an
   attempt to join session described by your answers.

   A typical example of the questions asked when joining a session may
   look like this:

   #+BEGIN_EXAMPLE
   Server: localhost RET
   Port (default 6522): RET
   Username: jan RET
   Color: light sky blue RET
   Use Encryption (y or n): n RET
   Global Password: RET
   User Password: RET
   #+END_EXAMPLE

   *IMPORTANT*: For sessions using the obby backend (like in the
   example above), the following restriction has to be taken into
   account:

   + When the server is Rudel inside an Emacs process:
     Encryption cannot be used currently in this case. Consequently
     the answer to the `Use Encryption (y or n):' prompt above has to
     be `n RET'.
   + When the server is a Gobby process:
     Gobby only supports encrypted connections. So the answer has to
     be `y RET' is this case.

   It is possible to configure frequently used sessions using the
   customization options `rudel-configured-sessions'. When one or more
   sessions are configured, `rudel-join-session' will provide choices
   like "my-configured-session", ... and "ask-protocol". Selecting
   "ask-protocol" invokes the behavior described above. Selecting one
   of the configured sessions connects to that session without asking
   for all the data.

*** SAVING AND REUSING CONFIGURED SESSIONS

   Each session is described as a plist (a list of keys and values
   see Info node `(elisp)Property Lists'). Keys are specified using
   keywords and look like this: :host, :username, :color. Values are
   mostly strings, but symbols and numbers are possible as well.

   The following keys are required for any session:

   * :name              (string)
   * :transport-backend (string or symbol)
   * :protocol-backend  (string or symbol)

   Other keys are optional and depend on the selected
   backend. Required keys for which no value is specified will be
   prompted for when selecting the session. The values of the :name
   properties have to be distinct for all configured sessions.

   Additional keys required by most backends:

   * :host     (string)
   * :port     (number)
   * :username (string)
   * :color    (string)

   Here is a complete example of customized values for the obby
   backend:

   * :name              "sonian"
   * :transport-backend tcp
   * :protocol-backend  obby
   * :host              "sobby"
   * :port              6522
   * :encryption        t
   * :username          "phil"
   * :color             "white"
   * :global-password   ""         (this means "no password")
   * :user-password     ""

   The programmatic equivalent looks like this:

   #+BEGIN_SRC emacs-lisp
   (add-to-list
    'rudel-configured-sessions
    (list :name              "myserver"
          :protocol-backend  'tcp
          :transport-backend 'obby
          :host              "my.sobby-server.net"
          :username          user-login-name
          ;; Use M-x list-colors-display to see color choices.
          :color             "white"
          :encryption        t
          :port              6522
          ;; empty string means no password
          :global-password   ""
          :user-password     ""))
   #+END_SRC

** WORKING WITHIN A CONNECTED SESSION

*** SHARING BUFFERS

    : M-x rudel-publish-buffer [ C-c c p ]

    Make a buffer available for subscription to peers in a
    collaborative editing session.

    : M-x rudel-subscribe [ C-c c s ]

    Subscribe to a document offered by a peer in a collaborative
    editing session. Invoking this command will prompt for the name
    of the document to subscribe to; TAB will show a list of
    available documents.

    : M-x rudel-unsubscribe [ C-c c u ]

    Detaches the current buffer from the collaborative editing
    session. The most recent version of the content will remain in
    the buffer but not be affected by future changes from other
    peers.

*** CHANGING COLORS

    : M-x rudel-change-color [ C-c c c ]

    Change the color associated with your edits.

*** LEAVING A SESSION

    : M-x rudel-end-session [ C-c c e ]

    Exit the current collaborative editing session.

** HOSTING A SESSION

   : M-x rudel-host-session [ C-c c h ]

   Note that the session starts out without any participating users
   (This is sometimes referred to as being a dedicated server). If you
   want to participate in the session you host, you have to join it as
   described above.

* EXTRA MINOR MODES

** [Global] Header Subscriptions minor mode

   : rudel-header-subscriptions-minor-mode
   
   Displays subscribed users and information concerning their
   respective status in the header line of a buffer.

   : global-rudel-header-subscriptions-mode

   Enables or disables rudel-header-subscriptions-minor-mode
   automatically for all buffers.

** [Global] Mode line publish state minor mode

   : rudel-mode-line-publish-state-minor-mode

   Displays an indicator of the publication status of a buffer in its
   mode line. This indicator is similar to the read-only
   vs. read-write and the remote vs. local indicators. Publication is
   indicated by a the letter P. Buffers that are not published have
   an - indicator.

   : global-rudel-mode-line-publish-state-mode

   Enables or disables rudel-mode-line-publish-state-minor-mode
   automatically for all buffers.

* REPORTING BUGS AND GETTING HELP

** EmacsWiki

   The EmacsWiki page about Rudel has
   [[http://www.emacswiki.org/emacs/Rudel#toc8][a section for feedback and questions]].
   Feel free leave feedback or ask questions there. If a reply does
   not occur promptly, try writing to the mailing list of visiting the
   IRC channel.

** Issue Tracker

   Bugs can be reported using the issue tracker on the sourceforge
   project page: http://sourceforge.net/tracker/?group_id=249139

** Mailing List

   Another possibility for getting help and reporting problems is
   writing to the Rudel mailing list:
   http://sourceforge.net/mail/?group_id=249139

** IRC Channel

   Rudel users and developers can also be reached on the #rudel IRC
   channel on the freenode network: irc:/irc.freenode.net:6667/#rudel

* KNOWN ISSUES

  + Publishing eshell buffers will cause your session to be
    disconnected since eshell disables the hooks that Rudel uses to
    catch changes to the buffer. As a workaround, you can use M-x
    ansi-term or another terminal emulator.

* LICENSE

  This file is part of Rudel.

  Rudel is free software: you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by
  the Free Software Foundation, either version 3 of the License, or
  (at your option) any later version.

  Rudel is distributed in the hope that it will be useful, but WITHOUT
  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
  or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
  License for more details.

  You should have received a copy of the GNU General Public License
  along with Rudel.  If not, see <http://www.gnu.org/licenses/>.

#+TITLE:   Rudel README
#+AUTHOR:  Jan Moringen
#+STARTUP: showeverything

# Local variables:
# mode: org
# end:

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Rudel seems very useful.  I think it should be documented in the 
Emacs manual and included as a standard part of Emacs.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as WM

[Stefan Monnier]

> Rudel seems very useful.  I think it should be documented in the 
> Emacs manual and included as a standard part of Emacs.

Could be, but it needs some serious loving for that.  Currently it has
no maintainer.


        Stefan

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Would anyone like to do more work on Rudel?
Pretty please?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as WM

[Matthew Plant]

I could potentially help out; but is there really any work to be done on Rudel?
Seems stable enough.

-M

On Wed, Aug 13, 2014 at 5:48 PM, Richard Stallman <rms@gnu.org> wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Would anyone like to do more work on Rudel?
> Pretty please?
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
>

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    I could potentially help out; but is there really any work to be done on Rudel?
    Seems stable enough.

Stefan, what's the work you think is needed on Rudel
to include it standardly in Emacs?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as WM

[Stefan Monnier]

>     I could potentially help out; but is there really any work to be
>     done on Rudel?  Seems stable enough.
> Stefan, what's the work you think is needed on Rudel
> to include it standardly in Emacs?

It should use open-network-stream's TLS support, for one.
I found the handling of encryption rather annoying (from the user's view
point), so improvements in this area are important.
It needs some further documentation.
It needs an active maintainer.
IIUC the protocols it support might need to be revisited, since Gobby is
rather dated and Rudel doesn't support more recent protocols.

But FWIW I don't see the benefit of having it included in Emacs:
So far its use has been rather marginal, so while I think it's a neat
package (which is why I went to the trouble of including it in GNU ELPA),
I'm not convinced it deserves to be bundled with Emacs.
It's easy enough to install it via GNU ELPA.


        Stefan

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    But FWIW I don't see the benefit of having it included in Emacs:

You're thinking of it in temrs of convenience for Emacs users.
I'm think of it as a base for attacking Google Drive.
Google Drive's use has not been marginal, sad to say.
Let's see what we can do to compete with it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as WM

[Stefan Monnier]

>     But FWIW I don't see the benefit of having it included in Emacs:
> You're thinking of it in terms of convenience for Emacs users.
> I'm think of it as a base for attacking Google Drive.

I completely fail to see how Rudel can be a substitute for Google Drive.
But then I don't know much about Google Drive.  Yet any solution based
on Emacs sounds like a non-starter, since most GNu/Linux users are not
Emacs users.


        Stefan

Re: Emacs as WM

[Matthew Plant]

[-- Attachment #1: Type: text/plain, Size: 690 bytes --]

Google docs is now google drive, so Richard is referring to competing with
the web fronted to google drive. So not the hd dealership part of drive.

-M

On Friday, August 15, 2014, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> >     But FWIW I don't see the benefit of having it included in Emacs:
> > You're thinking of it in terms of convenience for Emacs users.
> > I'm think of it as a base for attacking Google Drive.
>
> I completely fail to see how Rudel can be a substitute for Google Drive.
> But then I don't know much about Google Drive.  Yet any solution based
> on Emacs sounds like a non-starter, since most GNu/Linux users are not
> Emacs users.
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 960 bytes --]

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    I completely fail to see how Rudel can be a substitute for Google Drive.
    But then I don't know much about Google Drive.

It is a server that lets various people edit the same document together.
Previously called Google Docs.

      Yet any solution based
    on Emacs sounds like a non-starter, since most GNu/Linux users are not
    Emacs users.

Most users want WYSIWYG word processing, and that's why I want
Emacs to provide a way to do that.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as WM

[Ashton Kemerling]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>     I completely fail to see how Rudel can be a substitute for Google Drive.
>     But then I don't know much about Google Drive.
>
> It is a server that lets various people edit the same document together.
> Previously called Google Docs.
>
>       Yet any solution based
>     on Emacs sounds like a non-starter, since most GNu/Linux users are not
>     Emacs users.
>
> Most users want WYSIWYG word processing, and that's why I want
> Emacs to provide a way to do that.

I really don't see that ever happening. Google drive is used heavily in
mixed editor environments, by people not familiar with more traditional
editors, and in areas where editing or viewing on a computer other than
your own (e.g. conference room machine or phone).

In many ways, Google Drive is a more flexible replacement for MS Office,
which in itself was used in a very different way from Emacs for 90%+ of
the userbase. I'm sure that many of us in this group are a bit over the
top using Emacs for everything, I for one read and write to this group
with gnus, I think there is a danger in assuming that this is the
standard use case. If Rudel is seeing marginal usage, then the only
question is whether that is because Rudel simply is insufficient, or if
it fundamentally isn't what the user base needs.

-- 
Ashton Kemerling

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    In many ways, Google Drive is a more flexible replacement for MS Office,
    which in itself was used in a very different way from Emacs for 90%+ of
    the userbase.

This is exactly my point.  I want Emacs to offer the facilities of
an Office program.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as WM

[andres.ramirez]

Hi.

org mode can do that job see:
http://draketo.de/english/emacs/writing-papers-in-org-mode-acpd
probably a simple tutorial could help a little bit more. I am writing letters with it.

Also rudel is not "so used" cos nobody has used it for collaborating
editing documents (buffers, or whatever).

Also I see a different use case:

Just when You want to share smth with somebody remotely, right now options:
1. gnu/screen
2. vnc, skype or something like that. I have not tried tox yet.

the third option could be start emacs and evaluate this expression to
see what i am editing remotely (connect as a rudel client to a host machine).

Another more marginal option could be to share text parts among emacs
sessions (daemons) without X. My personal case 2 emacs sessions
because email is blocking your regular workflow (waiting for emacs 25
and multi processor emacs :) ).

Best Regards
At Sun, 17 Aug 2014 21:07:04 -0400,
Richard Stallman wrote:
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     In many ways, Google Drive is a more flexible replacement for MS Office,
>     which in itself was used in a very different way from Emacs for 90%+ of
>     the userbase.
> 
> This is exactly my point.  I want Emacs to offer the facilities of
> an Office program.
> 
> -- 
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
> 
> 
> 

Re: Emacs as WM

[Eli Zaretskii]

> Date: Sun, 17 Aug 2014 21:39:51 -0500
> From: andres.ramirez <andres.ramirez@kipuamutay.com>
> Cc: maplant2@illinois.edu, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
> 	Ashton Kemerling <ashtonkemerling@gmail.com>
> 
> org mode can do that job see:
> http://draketo.de/english/emacs/writing-papers-in-org-mode-acpd

But that's not WYSIWYG, is it?

Re: Emacs as WM

[andres.ramirez]

No. It isn't.
At Mon, 18 Aug 2014 17:41:43 +0300,
Eli Zaretskii wrote:
> 
> > Date: Sun, 17 Aug 2014 21:39:51 -0500
> > From: andres.ramirez <andres.ramirez@kipuamutay.com>
> > Cc: maplant2@illinois.edu, emacs-devel@gnu.org, monnier@iro.umontreal.ca,
> > 	Ashton Kemerling <ashtonkemerling@gmail.com>
> > 
> > org mode can do that job see:
> > http://draketo.de/english/emacs/writing-papers-in-org-mode-acpd
> 
> But that's not WYSIWYG, is it?

Re: Emacs as WM

[Glenn Morris]

andres.ramirez wrote:

>> > org mode can do that job see:
>> > http://draketo.de/english/emacs/writing-papers-in-org-mode-acpd
>> 
>> But that's not WYSIWYG, is it?

Pretty sure this was all covered the last time this came up

http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html

(but I find the thread fairly unreadable)

Re: Emacs as WM

[Ashton Kemerling]

I think at this point Emacs is about as far from a WYSIWYG editor as you
can get, and that is what attracts a fair amount of its users. Despite
constant competitive pressure from prettier and more specialized editors
like RubyMine, Eclipse, and similar; Emacs continues to survive due to
the depth of its customizability and community.

I guess its customizability means that there is nothing stopping anyone
from making a WYSIWYG plugin, but I would be shocked if it got a lot of
usage for two reasons:

1) A lot of the people choosing Emacs use it because it isn't WYSIWYG.
2) Most people who are a fan of WYSIWYG want a shallow learning curve
with a shallow product. They aren't interested in dedicating lots of
time to master a product that they might not use enough to justify it.

But hey, I could be wrong.

-- 
Ashton Kemerling

Re: Emacs as WM

[Eli Zaretskii]

> From: Ashton Kemerling <ashtonkemerling@gmail.com>
> Date: Mon, 18 Aug 2014 19:04:08 -0600
> Cc: emacs-devel@gnu.org
> 
> I think at this point Emacs is about as far from a WYSIWYG editor as you
> can get

Not true.  It's only not WYSIWYG when editing human-readable text.

> 2) Most people who are a fan of WYSIWYG want a shallow learning curve
> with a shallow product.

If you ever used Office, you know that's about as far from truth as
far can get.

Re: Emacs as WM

[Ashton Kemerling]

Agree with you on office, which is why Google Docs (Drive, whatever) is taking over.

-- 
Ashton Kemerling

Re: Emacs as WM

[Tom]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 
> > 2) Most people who are a fan of WYSIWYG want a shallow learning curve
> > with a shallow product.
> 
> If you ever used Office, you know that's about as far from truth as
> far can get.
> 

It's well known that most users of Office use only a fraction of
its capabilities, mainly those which are accessible from toolbar
icons and top level menus and do not even know about its advances
features.

So while Office is a very sophisticated product, most users prefer
it because of the simple point and click interface which does
not require much learning to use.

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    Just when You want to share smth with somebody remotely, right now options:
    1. gnu/screen
    2. vnc, skype or something like that. I have not tried tox yet.

Skype is nonfree software.  It's not a solution, it's a problem.
I don't know what VNC is; is it free software?  How does it
solve this problem?

I have some idea what Tox does.
How would Tox enable people to edit a document together?
I do not see how it relates.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as WM

[Eli Zaretskii]

> From: Tom <adatgyujto@gmail.com>
> Date: Tue, 19 Aug 2014 05:58:20 +0000 (UTC)
> 
> So while Office is a very sophisticated product, most users prefer
> it because of the simple point and click interface which does
> not require much learning to use.

The same can be said about Emacs.  In fact, our toolbar is much
simpler than the MS-Office's "ribbons".

So I think users prefer Office because it has capabilities that Emacs
doesn't, and not because its "point and click" interface is easier
than that of Emacs.

Re: Emacs as WM

[Tom]

Eli Zaretskii <eliz <at> gnu.org> writes:

> 
> So I think users prefer Office because it has capabilities that Emacs
> doesn't, and not because its "point and click" interface is easier
> than that of Emacs.
> 

On Windows people prefer office also because it looks and behaves as
any other application. So they prefer familiarity too and being
familiar is also a big part of simplicity and ease of use.

Emacs looks completely alien on Windows and its behavior is also 
alien.

The most obvious example is copy/paste which is Ctrl-C/V on windows
while emacs uses something else.

There was a discussion about making Ctrl-C/V the default a while
ago, but it was rejected because it goes against emacs standards.
It does, but most users won't relearn basic keys just to use emacs
which has no obvious advantages for them which would be worth it.

WYSIWYG alone won't gain many new users while emacs stays so
different in other UI points.

Re: Emacs as WM

[Eli Zaretskii]

> From: Tom <adatgyujto@gmail.com>
> Date: Tue, 19 Aug 2014 15:21:56 +0000 (UTC)
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 
> > So I think users prefer Office because it has capabilities that Emacs
> > doesn't, and not because its "point and click" interface is easier
> > than that of Emacs.
> > 
> 
> On Windows people prefer office also because it looks and behaves as
> any other application. So they prefer familiarity too and being
> familiar is also a big part of simplicity and ease of use.
> 
> Emacs looks completely alien on Windows and its behavior is also 
> alien.

I disagree.

> The most obvious example is copy/paste which is Ctrl-C/V on windows
> while emacs uses something else.

That's the only example.

> WYSIWYG alone won't gain many new users while emacs stays so
> different in other UI points.

We won't know unless and until we try.

Re: Emacs as WM

[David Kastrup]

Tom <adatgyujto@gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> 
>> So I think users prefer Office because it has capabilities that Emacs
>> doesn't, and not because its "point and click" interface is easier
>> than that of Emacs.
>> 
>
> On Windows people prefer office also because it looks and behaves as
> any other application. So they prefer familiarity too and being
> familiar is also a big part of simplicity and ease of use.
>
> Emacs looks completely alien on Windows and its behavior is also 
> alien.
>
> The most obvious example is copy/paste which is Ctrl-C/V on windows
> while emacs uses something else.
>
> There was a discussion about making Ctrl-C/V the default a while
> ago, but it was rejected because it goes against emacs standards.
> It does, but most users won't relearn basic keys just to use emacs
> which has no obvious advantages for them which would be worth it.
>
> WYSIWYG alone won't gain many new users while emacs stays so
> different in other UI points.

Emacs will always remain a worse NotePad than NotePad.  Most users won't
use Emacs even when it tries masking itself as NotePad.

Convincingly reinventing Emacs and its keybindings into a world of
NotePads is nothing you can solve with enough handwaving.

It's sort of like "can't we genetically engineer a womb into horseshoe
crabs in order to have them more competitive with mammals?".

-- 
David Kastrup

Re: Emacs as WM

[Alexis]

Richard Stallman writes:

> Skype is nonfree software.  It's not a solution, it's a problem.

Agreed. i feel that the most promising practical[1] alternative to Skype
at this point is Jitsi, which is licensed under the LGPL 2.1:

http://www.jitsi.org/

but it seems to me that the project needs a significant influx of
contributors willing and able to fix bugs, implement features / feature
requests, etc.


Alexis.

[1] "Practical" in the sense of, in my experience, being basically
usable by non-technically-oriented users. Which is, unfortunately for
alternatives to Skype, an area in which Skype excels.

Re: Emacs as WM

[andres.ramirez]

At Tue, 19 Aug 2014 09:09:24 -0400,
Richard Stallman wrote:
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     Just when You want to share smth with somebody remotely, right now options:
>     1. gnu/screen
>     2. vnc, skype or something like that. I have not tried tox yet.
> 
> Skype is nonfree software.  It's not a solution, it's a problem.
> I don't know what VNC is; is it free software?  How does it
> solve this problem?

Sure, It is not free software.
> 
> I have some idea what Tox does.
> How would Tox enable people to edit a document together?
> I do not see how it relates.
tox, lets You share your graphical desktop, among other things,
It is alternative to the non free sofware app.
VNC  let You share your graphical desktop without using remote
servers. It is GPL

Rudel lets You share buffer(s). Emacs users could use Emacs+Rudel on
places where tox or VNC were used before realizing about Rudel. On
my opinion the main problem Rudel solves it's sharing a buffer.

Before this thread a lot of people including me did not know about
rudel existence and usability.
> 
> -- 
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
> 

Re: Emacs as WM

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    > I have some idea what Tox does.
    > How would Tox enable people to edit a document together?
    > I do not see how it relates.
    tox, lets You share your graphical desktop, among other things,

I am not sure what "share your graphical desktop" looks like,
in practice.  Does it mean that all the users are apparently
typing at the same Emacs process?  That would be rather a pain.
Not as good as sharing a buffer.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Emacs as WM

[andres.ramirez]

Hi Richard.

At Wed, 20 Aug 2014 22:41:55 -0400,
Richard Stallman wrote:
> 
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
>     > I have some idea what Tox does.
>     > How would Tox enable people to edit a document together?
>     > I do not see how it relates.
>     tox, lets You share your graphical desktop, among other things,
> 
> I am not sure what "share your graphical desktop" looks like,
> in practice.  Does it mean that all the users are apparently
> typing at the same Emacs process?  That would be rather a pain.
> Not as good as sharing a buffer.

"share your graphical desktop"  does not enable "collaborating editing", just one person edit or
works with the desktop, and the other ones are just viewing It.

Sharing a buffer is awesome. +1

Best Regards
> 
> -- 
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>   Use Ekiga or an ordinary phone call.
> 

Re: Emacs as WM

[Matthew Plant]

It'd certainly be nice to have some way to share edits across emacs clients - one that functions as a minor mode on top of all major modes. That would be amazing! You could have an additional comments buffer that maps to lines that would be saved to everyone's disk. Code reviews could be made on the fly. I don't think there's a single programming environment that provides that.

-M

> On Aug 20, 2014, at 8:59 PM, "andres.ramirez"  <andres.ramirez@kipuamutay.com> wrote:
> 
> Hi Richard.
> 
> At Wed, 20 Aug 2014 22:41:55 -0400,
> Richard Stallman wrote:
>> 
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>> 
>>> I have some idea what Tox does.
>>> How would Tox enable people to edit a document together?
>>> I do not see how it relates.
>>    tox, lets You share your graphical desktop, among other things,
>> 
>> I am not sure what "share your graphical desktop" looks like,
>> in practice.  Does it mean that all the users are apparently
>> typing at the same Emacs process?  That would be rather a pain.
>> Not as good as sharing a buffer.
> 
> "share your graphical desktop"  does not enable "collaborating editing", just one person edit or
> works with the desktop, and the other ones are just viewing It.
> 
> Sharing a buffer is awesome. +1
> 
> Best Regards
>> 
>> -- 
>> Dr Richard Stallman
>> President, Free Software Foundation
>> 51 Franklin St
>> Boston MA 02110
>> USA
>> www.fsf.org  www.gnu.org
>> Skype: No way! That's nonfree (freedom-denying) software.
>>  Use Ekiga or an ordinary phone call.
>> 

Re: Emacs as WM

[Josh]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

On Wed, Aug 20, 2014 at 7:59 PM, andres.ramirez <
andres.ramirez@kipuamutay.com> wrote:

> At Wed, 20 Aug 2014 22:41:55 -0400,
> Richard Stallman wrote:
> >     > I have some idea what Tox does.
> >     > How would Tox enable people to edit a document together?
> >     > I do not see how it relates.
> >     tox, lets You share your graphical desktop, among other things,
> >
> > I am not sure what "share your graphical desktop" looks like,
> > in practice.  Does it mean that all the users are apparently
> > typing at the same Emacs process?  That would be rather a pain.
> > Not as good as sharing a buffer.
>
> "share your graphical desktop"  does not enable "collaborating editing",
> just one person edit or
> works with the desktop, and the other ones are just viewing It.
>
> Sharing a buffer is awesome. +1


Nic put together something along these lines last year that might
be of interest: https://github.com/nicferrier/emacs-swarmhacker

[-- Attachment #2: Type: text/html, Size: 1620 bytes --]

Re: Emacs as WM

[Garreau, Alexandre]

On 2014-08-21 at 08:15, Matthew Plant wrote:
> It'd certainly be nice to have some way to share edits across emacs
> clients - one that functions as a minor mode on top of all major
> modes. That would be amazing! You could have an additional comments
> buffer that maps to lines that would be saved to everyone's disk. Code
> reviews could be made on the fly. I don't think there's a single
> programming environment that provides that.

Even more to have it use P2P and something with cryptography and DHTs,
just like Tox… for the short term… then using GNUnet \o/ (and at this
point not only collaborating editing using GNUnet, but also asynchronous
communication with some new Gnus backend, some synchronous communication
with some yet other Emacs IM client (after the semi-dozen of IRC clients
and the XMPP client)).