# Multihead terminal-based text editors ?



## Spartrekus (Feb 6, 2019)

Hello,

_vim_ or _emacs_ are "single" oriented monitor. Eventually one can use _screen_ but the text editor works on a single monitor anyhow.

Do you know a possible multihead terminal-based text editor?

Concept would be that each monitor can open a file and they works alltogether (copy/cut,...) in a single terminal based application.

Feel free...









It would be possible to use sockets for instance and to display on any distant or local machine the buffers of the editor. A multihead editor could be made in just 2000 lines, largest maximum.
It could maybe just take 1 or maybe 2 hours to realize such an application. Surprising that an editor server like early vi-clone over telnet (buffers, hjkl, ...) is not yet existing.

```
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>  
#include <arpa/inet.h>   
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <sys/time.h>
```


----------



## Phishfry (Feb 6, 2019)

/sysutils/tmux and a whole lot of monitors.
For multihead the Nvidia NVS cards have a DMS59 breakout cord to 4 outputs(HDMI or DisplayPort or VGA/DVI).
I use those for Low Profile or 2U.
Many daytraders I used to deal with use ATI cards with quad outputs. So I could see a video wall of 9 monitors a doable thing.


----------



## Spartrekus (Feb 6, 2019)

Phishfry said:


> /sysutils/tmux and a whole lot of monitors.
> For multihead the Nvidia NVS cards have a DMS59 breakout cord to 4 outputs(HDMI or DisplayPort or VGA/DVI).
> I use those for Low Profile or 2U.
> Many daytraders I used to deal with use ATI cards with quad outputs. So I could see a video wall of 9 monitors a doable thing.




tmux, screen,... aren't editors.


> _vim_ or _emacs_ are "single" oriented monitor. Eventually one can use _screen_ but it works on a single monitor anyhow.


----------



## Phishfry (Feb 6, 2019)

Each screen you could assign a different ttyv number to. Each ttyv* acts interdependently.
So 8 virtual terminals right there.


----------



## Spartrekus (Feb 6, 2019)

> _vim_ or _emacs_ are "single" oriented monitor. Eventually one can use _screen_ but it works on a single monitor anyhow.


tmux and screen aren't editors and they will act with tty*, and let's say a single _vim_ will not connect to them.
One can start several _vim_ on each of tty*, but they are disconnected.



Phishfry said:


> Each screen you could assign a different ttyv number to. Each ttyv* acts interdependently.
> So 7 virtual terminal right there.



_The non-famous networking tcp Hermes terminal editor_ maybe it helps,... so that it is possible to  bring the same editor on each of your tty_. _It can have then the same clipboard, and it can display any kind of buffer (files, ...) on any tty


----------



## Phishfry (Feb 6, 2019)

File locking makes that tough.
Sounds like you need groupware.

How about emacs?
https://www.emacswiki.org/emacs/CollaborativeEditing


----------



## Spartrekus (Feb 6, 2019)

Phishfry said:


> File locking makes that tough.
> Sounds like you need groupware.
> 
> How about emacs?
> https://www.emacswiki.org/emacs/CollaborativeEditing



Emacs collab, there are not an unique clipboard for all running tty*


----------



## Deleted member 9563 (Feb 6, 2019)

I use multiple screens and open terminals everywhere. Cut paste works between them all. That's just basic KDE functionality. However, I suppose I didn't really understand the question since the answer is simple to me.


----------



## Spartrekus (Feb 6, 2019)

Eventually with server and client(s), over network, allowing to use it over any tty*. emacs collaborative is a good example.


----------



## SirDice (Feb 6, 2019)

Spartrekus said:


> Do you know a possible multihead terminal-based text editor?


Terminals aren't multihead. So applications that use the terminal can't be either.


----------



## olli@ (Feb 6, 2019)

The question is: What do you actually want to achieve? What _exactly_ do you want to do that requires running the same editor process in multiple terminal windows?


----------



## Spartrekus (Feb 7, 2019)

SirDice said:


> Terminals aren't multihead. So applications that use the terminal can't be either.




for instance. Let's start an editor as server, and read it from any desired clients.
It could be easy without encryption.


----------



## xtaz (Feb 8, 2019)

Isn't this exactly what sysutils/screen and sysutils/tmux are for? Or am I missing something. Both of them have a mode where you can attach to an existing terminal from another one and control it from either one. Here is a page that explains both: https://www.howtoforge.com/sharing-terminal-sessions-with-tmux-and-screen ?

It sounds like you are actually asking if this functionality is present in any editors, but that isn't really the unix way is it. You just use the right tool for the job and layer multiple tools on top of each other to get the desired effect.


----------



## Spartrekus (Feb 8, 2019)

xtaz said:


> Isn't this exactly what sysutils/screen and sysutils/tmux are for? Or am I missing something. Both of them have a mode where you can attach to an existing terminal from another one and control it from either one. Here is a page that explains both: https://www.howtoforge.com/sharing-terminal-sessions-with-tmux-and-screen ?
> 
> It sounds like you are actually asking if this functionality is present in any editors, but that isn't really the unix way is it. You just use the right tool for the job and layer multiple tools on top of each other to get the desired effect.



a terminal and text editor aren't same. 

If you know _vim_, maybe you will understand better.

Start _screen_:
c-a c :    start _vim_  (type vim)
c-a c :    start _vim_ 

both _vim_ haven't same buffers. two disconnected  vim's.  
how do you work on your buffers then?

Your answer:
- You can't, just use screen or tmux.   
hmmm how ???


----------



## xtaz (Feb 8, 2019)

OK, Yes, I see what you are trying to do. But I have no idea how that would be possible. I personally don't use buffers. I would just cut and paste from one terminal to another using my desktop clipboard.


----------



## SirDice (Feb 8, 2019)

Spartrekus said:


> a terminal and text editor aren't same.


An editor is an application that uses the terminal for its input/output. Terminals aren't multi-head, dual-screen, or whatever you want to call it. A terminal has ONE screen and ONE screen only. It doesn't matter _how_ you use the editor, it's still an application that's limited by the terminal's capabilities. A terminal simply does not have the capability to have more than one screen.


----------



## Spartrekus (Feb 8, 2019)

SirDice said:


> An editor is an application that uses the terminal for its input/output. Terminals aren't multi-head, dual-screen, or whatever you want to call it. A terminal has ONE screen and ONE screen only. It doesn't matter _how_ you use the editor, it's still an application that's limited by the terminal's capabilities. A terminal simply does not have the capability to have more than one screen.


a program is allowed to communicate. Simplex example: https://en.wikipedia.org/wiki/Telnet


----------



## SirDice (Feb 8, 2019)

Telnet opens a terminal session and is therefor also limited to one screen.


----------



## Spartrekus (Feb 8, 2019)

SirDice said:


> Telnet opens a terminal session and is therefor also limited to one screen.


Thank you for trying to help.
Server / and multi clients is readily possible, for using let it called _buffers_

It is just an example:




__





						How to Code a Server and Client in C with Sockets on Linux - Code Examples - BinaryTides
					

In a previous example we learnt about the . In this example we shall build a basic ECHO client and server. The server/client shown here use TCP sockets or SOCK_STREAM. Tcp sockets are connection oriented, means that they have a concept of independent connection on a certain port which one...



					www.binarytides.com
				











						GitHub - emceelam/Multi-Chat-C: A socket-based multi-client chat written with C code
					

A socket-based multi-client chat written with C code - GitHub - emceelam/Multi-Chat-C: A socket-based multi-client chat written with C code




					github.com
				







__





						Amazon.com: Pocket Guide to TCP/IP Socket Programming in C (The Morgan Kaufmann Practical Guides Series): 9781558606869: Donahoo, Michael J., Calvert, Kenneth L.: Books
					

Amazon.com: Pocket Guide to TCP/IP Socket Programming in C (The Morgan Kaufmann Practical Guides Series): 9781558606869: Donahoo, Michael J., Calvert, Kenneth L.: Books



					www.amazon.com


----------



## SirDice (Feb 8, 2019)

It has nothing to do with client/server sockets, or anything else network related. It has to do with the capabilities of a TTY.









						Teleprinter - Wikipedia
					






					en.wikipedia.org


----------



## Spartrekus (Feb 8, 2019)

SirDice said:


> It has nothing to do with client/server sockets, or anything else network related. It has to do with the capabilities of a TTY.
> 
> 
> 
> ...


amazing pictures...
On any opened/new/created... tty, we can use any client. The very first post mentioned collab emacs, which was good first approach and idea or possibility. Welcome for more ideas...

Another example:
Open a new tty, type:   multivim -x
and it would work on file buffers, ...  like you would do in regular vim.
This is some kind of idea of a collab editor.


----------



## SirDice (Feb 8, 2019)

Applications might use 'tricks' to split up the display and give the impression there's more than one screen. But it's simply a single screen that's split up by the application. Which is not the same as having two or more independent screens.


----------



## Spartrekus (Feb 8, 2019)

SirDice said:


> Applications might use 'tricks' to split up the display and give the impression there's more than one screen. But it's simply a single screen that's split up by the application. Which is not the same as having two or more independent screens.



If tricks work to have multiheads, why not...


----------



## SirDice (Feb 8, 2019)

Because it's not "multihead". It's a single display that's split in two.


----------



## Spartrekus (Feb 8, 2019)

SirDice said:


> Because it's not "multihead". It's a single display that's split in two.



OK, fine.


----------



## client (Feb 8, 2019)

vim has server mode

google search returns this:









						GitHub - bortigel/vim-multihead: Vim support for multiple frames / heads
					

Vim support for multiple frames / heads. Contribute to bortigel/vim-multihead development by creating an account on GitHub.




					github.com


----------



## Spartrekus (Mar 10, 2019)

Hello,

It is actually very simple to make an editor that is multihead and that works over the telnet protocol. About 30 years that vim exists, ... It would be possible to take for instance kilo editor and add a protocol (socket,..) for telnet. Decades ago, terminal programming was popular.    

Display it anywhere with telnet myip 8888 or  telnet localhost 8888...

It is really so simple to make.


----------



## Spartrekus (Mar 10, 2019)

client said:


> vim has server mode
> 
> google search returns this:
> 
> ...



This is an awful junk of bloat, we do not need heavy application, but it could require only a C compiler (see first post, example of lib).


----------



## Spartrekus (Apr 14, 2019)

SirDice said:


> Because it's not "multihead". It's a single display that's split in two.




It is very useful to collaborate with colleagues on a single file.
If you don't understand then let's continue to use the famous git. 
Or test gobby.
(btw, git is owned by Microsoft).

it is actually simple to do.
You open a server listening (basic sockets), that will be your file editor (on a  machine, acting as a server).

run : telnet ip port
and then you can distant edit a file as you would do with nano (or vim if it is programmed).

Each client can display the same edited file and allow editing in a collaborative way.
That means that you have a collaborative editor over telnet.

Here an example to run sockets.








						GitHub - spartrekus/mpicserv: Socket server for vim (over telnet com) to display a pdf or a png file on a distant running X11.
					

Socket server for vim (over telnet com) to display a pdf or a png file on a distant running X11.  - GitHub - spartrekus/mpicserv: Socket server for vim (over telnet com) to display a pdf or a png f...




					github.com


----------



## Hiroo Ono (Apr 14, 2019)

I still do not understand well your requirements, but...
If you want two or more GUI windows and share editor buffers between them, running emacs in GUI mode (not `emacs -nw` in a terminal) may suffice. It can make new 'frame' (as I mentioned 'GUI window') by `C-x 5 2` (see https://www.gnu.org/software/emacs/manual/html_node/emacs/Creating-Frames.html).
If what you want to do is that running an editor and later logging in from remote and running another editor that shares the buffers with the previous one, emacs-server and emacsclient might help you (see https://www.gnu.org/software/emacs/...nvoking-emacsclient.html#Invoking-emacsclient).
Off course the former can be achieved with two or more terminal windows, emacs-server and emacsclient.


----------



## Hiroo Ono (Apr 14, 2019)

Spartrekus said:


> It is very useful to collaborate with colleagues on a single file.



Do you want a multi-user solution? Like editing documents on Google docs?


----------



## D-FENS (Apr 14, 2019)

Your problem is in fact you need a clipboard that works across terminal sessions. Because the text editors are per se quite simple. They take whatever terminal window you start them in.

Regarding the root question: it depends if you're using X or not. I use in all my consoles (inside X) the standard Xorg clipboard and the program xclip, which pipes input and output to and from the clipboard. I do selection and I use Shift-Ctrl-C for copy and Shift-Ctrl-V for paste.

If you want to use a clipboard in text mode without X - I have not done it and I don't know how to do it. For me it is a non-issue, because I always edit in an X. If I administer a machine that has no X, I just login from my graphical console remotely and do whatever I want.
If I really have to go on a textual terminal, I edit what I edit, then I pipe the text to a file and this can be read from any other console. But this is definitely not my preferred mode of work.

For multihead - I LOVE monitors. The more, the better. I personally use 4 screens, but I would gladly have 2 more above them if it were easy. It's just nice to have, so I have not done it.



Spartrekus said:


> Hello,
> 
> _vim_ or _emacs_ are "single" oriented monitor. Eventually one can use _screen_ but the text editor works on a single monitor anyhow.
> 
> ...


----------



## Spartrekus (Apr 14, 2019)

Hiroo Ono said:


> I still do not understand well your requirements, but...
> If you want two or more GUI windows and share editor buffers between them, running emacs in GUI mode (not `emacs -nw` in a terminal) may suffice. It can make new 'frame' (as I mentioned 'GUI window') by `C-x 5 2` (see https://www.gnu.org/software/emacs/manual/html_node/emacs/Creating-Frames.html).
> If what you want to do is that running an editor and later logging in from remote and running another editor that shares the buffers with the previous one, emacs-server and emacsclient might help you (see https://www.gnu.org/software/emacs/...nvoking-emacsclient.html#Invoking-emacsclient).
> Off course the former can be achieved with two or more terminal windows, emacs-server and emacsclient.



thank you very much !!
it looks really very great to use the buffers.

However, there are not working things, as follows:

the problem is that I do want to share the same machine or either the same login session.

The best is to run the unsecured, no password, access that it is easily done over telnet, because then I do not need to create a new user.
+ the colleague can run windows if he wants (to testament himself.
The issue is that they are many files with clear passwords in the getenv( "HOME" ) / home user dir.


----------



## Spartrekus (Apr 14, 2019)

roccobaroccoSC said:


> Your problem is in fact you need a clipboard that works across terminal sessions. Because the text editors are per se quite simple. They take whatever terminal window you start them in.
> 
> Regarding the root question: it depends if you're using X or not. I use in all my consoles (inside X) the standard Xorg clipboard and the program xclip, which pipes input and output to and from the clipboard. I do selection and I use Shift-Ctrl-C for copy and Shift-Ctrl-V for paste.
> 
> ...


Our project pics are located on a distant (tunnel) over SSHFS.


how do you "see" the PNG file of a latex doc if you have six FreeBSD console?

I do not know any "FBI" or "feh for framebuffer"  running into vim ?


----------



## Spartrekus (Apr 14, 2019)

Hiroo Ono said:


> Do you want a multi-user solution? Like editing documents on Google docs?


this is an insane solution on an Unix forum!


----------



## hukadan (Apr 14, 2019)

Spartrekus said:


> The best is to run the unsecured, no password, access





Spartrekus said:


> this is an insane solution


----------



## Spartrekus (Apr 14, 2019)

who cares?

there is at least 6 to 10 firewalls to pass, and lot of admins to protect  
No one can hack and bypass to get access "in"


----------



## Hiroo Ono (Apr 14, 2019)

I found CoVim https://github.com/FredKSchott/CoVim. I did not use it myself.


----------



## Spartrekus (Apr 14, 2019)

Hiroo Ono said:


> I found CoVim https://github.com/FredKSchott/CoVim. I did not use it myself.


it is not lightweight.


----------



## xtremae (Apr 14, 2019)

Spartrekus said:


> (btw, git is owned by Microsoft).


The open source program git is owned by msft?


----------



## Spartrekus (Apr 14, 2019)

xtremae said:


> The open source program git is owned by msft?



"GitHub is one of the largest code hosts in the world with over 100 million* projects. Private, public, or open source, all repositories are equipped with tools to help you host, version, and release code."
Opensource hosted by a Microsoft Service.

It is a bit like a Linux conference where servers are powered by Microsoft servers. It is not congruent that much. What kind of other choice besides? There aren't much.


----------



## hukadan (Apr 14, 2019)

You do realize that git and Github are two different things, right ?


----------



## MarcoB (Apr 14, 2019)

xtremae said:


> The open source program git is owned by msft?


Afaik Github is, but git is written by Linus Torvalds.


----------



## Spartrekus (Apr 14, 2019)

MarcoB said:


> Afaik Github is, but git is written by Linus Torvalds.


it is a loop.

Go for Google is written by an Unix hero.


----------



## Spartrekus (Apr 14, 2019)

roccobaroccoSC said:


> Your problem is in fact you need a clipboard that works across terminal sessions. Because the text editors are per se quite simple. They take whatever terminal window you start them in.
> 
> Regarding the root question: it depends if you're using X or not. I use in all my consoles (inside X) the standard Xorg clipboard and the program xclip, which pipes input and output to and from the clipboard. I do selection and I use Shift-Ctrl-C for copy and Shift-Ctrl-V for paste.
> 
> ...




how do you do from vim (editing tex document) to another console (another distant machine) and display the PNG of current line using cacaview ?


----------



## D-FENS (Apr 14, 2019)

Spartrekus said:


> how do you do from vim (editing tex document) to another console (another distant machine) and display the PNG of current line using cacaview ?


I don't know vim at all. I just know to press 'dd' for deleting current line and ':wq' to exit. I started learning emacs and found it quite neat but it takes a lot of time and this is what I don't have at the moment.


----------



## D-FENS (Apr 14, 2019)

Spartrekus said:


> Our project pics are located on a distant (tunnel) over SSHFS.
> how do you "see" the PNG file of a latex doc if you have six FreeBSD console?
> I do not know any "FBI" or "feh for framebuffer"  running into vim ?


I must rephrase what I wrote. I love multihead and I use 4 displays at the moment (no 6, which would be nice to have).
I definitely use Xorg and graphical consoles. So I bind them with the Xorg buffer when copying and pasting. I think KDE has an applet that offers multiple buffers but I have not used it so far.
How to join your 6 consoles to display for example one single PNG via cacaview? That's an interesting question and I have no answer for this. If using Xorg it should be possible to create a terminal window spanning over all displays and then you could display it in a single console on multiple displays. I don't know how to split the image on many consoles.


----------



## Spartrekus (Apr 14, 2019)

roccobaroccoSC said:


> I must rephrase what I wrote. I love multihead and I use 4 displays at the moment (no 6, which would be nice to have).
> I definitely use Xorg and graphical consoles. So I bind them with the Xorg buffer when copying and pasting. I think KDE has an applet that offers multiple buffers but I have not used it so far.
> How to join your 6 consoles to display for example one single PNG via cacaview? That's an interesting question and I have no answer for this. If using Xorg it should be possible to create a terminal window spanning over all displays and then you could display it in a single console on multiple displays. I don't know how to split the image on many consoles.


Several monitors is actually good. I use to have consoles, for just C. 

With colleagues, we perform some tex document and code writing using svn. Collaborative would work too well actually better sometimes to work directly together in real time (on an highly secured small intranet behing router, explaining no security issue).


----------



## D-FENS (Apr 14, 2019)

Spartrekus said:


> Several monitors is actually good. I use to have consoles, for just C.
> 
> With colleagues, we perform some tex document and code writing using svn. Collaborative would work too well actually better sometimes to work directly together in real time (on an highly secured small intranet behing router, explaining no security issue).


I use VNC in such scenarios. But I must admit, I have not been involved in distributed development with >1 colleague at a time in my Unix work.
I used telcos quite a while back on my old job, but we telcoed via MS Lync and it's a totally different beast.


----------



## tommiie (Apr 15, 2019)

Hiroo Ono said:


> I still do not understand well your requirements


He has no requirements. He is just throlling. Look at all the other threads he started.


----------



## Spartrekus (Apr 15, 2019)

tommiie said:


> He has no requirements. He is just throlling. Look at all the other threads he started.



It is a solid consideration for using terminal editor. 
Some might understand the needs, if more interested in terminal and console (no gui) use.


----------



## Spartrekus (Apr 19, 2019)

*GOALS:*


> One of challenges when you are working in team is to collaborate in an efficient way. Moreover, working from distance with a team is a nightmare especially when you are creating a report or you are brainstorming ideas. From this perspective, the idea of creating a real-time collaborative text editor was born. The collaborative text editor permits multiple users to work on a single document simultaneously via the network.
> 
> This idea should work on the Unix console of NetBSD (likely best Unix ever *ads*).
> 
> ...



*REQUIREMENTS:*
The C language only  +  a compiler clang only + nothing else !!!
No library involved !!
clang  tcpedit-server -o server
clang  tcpedit-client  -o client

*RESULTS [DONE]:*
To make it work, it is needed to disable enter for instance on the client side.


```
void disable_waiting_for_enter(void)
{
    struct termios newt;

    /* Make terminal read 1 char at a time */
    tcgetattr(0, &oldt);  /* Save terminal settings */
    newt = oldt;  /* Init new settings */
    newt.c_lflag &= ~(ICANON | ECHO);  /* Change settings */
    tcsetattr(0, TCSANOW, &newt);  /* Apply settings */
    atexit(restore_terminal_settings); /* Make sure settings will be restored when program ends  */
}
```

disable_waiting_for_enter();
ch = getchar();

And, then on the server,  "write" to send back the drawn screen.

Once a key is pressed on the client, the server send back the full screen (row / cols limited).

Note that you need to test the row/cols before.
       printf("Env TERM ROW:  %d\n", w.ws_row );
       printf("Env TERM COL:  %d\n", w.ws_col );

I have just made a basic editor over tcp/ sort of telnet 
That's fun.

The server is the editor on port 8888  ( ./tcpedit-server ).
On the intranet, anyone doing    tcpedit-client  192.168.1.100 8888 will edit the file and have a sort of collaborative edition over telnet of a single file.
I have tried with 5 clients over this socket usage on the same server. It works pretty fast.
It still needs a sort of independant viewing, because each client see exactly the same of the other ones 
Sure, the editor does "draw" the same view (write/send the current line / cursor position and printed content over tcp).

The advantage is that it is very minimal, takes no cpu, takes no memory usage and it does well.

Does someone need it?


----------

