andreikop / enki

A text editor for programmers
http://enki-editor.org
GNU General Public License v2.0
161 stars 38 forks source link

Open file from console in existing session (Enki istance) #279

Open vi opened 9 years ago

vi commented 9 years ago

My current workflow:

  1. In console, determine which file I need;
  2. Use readlink -f to get full path;
  3. Copy it;
  4. Switch to Enki;
  5. Press Ctrl+L;
  6. Paste the path;
  7. Press enter;

It would be nice to have something like:

enki -s mysession --remote-open /path/to/my/fil
andreikop commented 9 years ago

I like the idea. But have another ideas to implement after the release

vi commented 9 years ago

Implemented a prototype (to enable the feature for myself early):

https://github.com/vi/enki/tree/remoteopen

The code is probably not merge-worthy so far and it's probaby not Windows-friendly.

Accompanying enkopen shell script:

#!/bin/sh
if [ -z "$2" ]; then
    echo "Usage: enkopen session_name file1 [file2...]"
    exit 1
fi
S="$1"; shift;
F="$1"; shift;

FF="`readlink -f "$F"`"
printf 'open %s' "$FF" | socat - unix-connect:$HOME/.config/enki/session_"$S".socket

if [ -n "$1" ]; then
    exec "$0" "$S" "$@"
fi
andreikop commented 9 years ago

http://stackoverflow.com/questions/12712360/qtsingleapplication-for-pyside-or-pyqt will probably be more cross-platform than socket.AF_UNIX

In this implementation last started enki holds the socket. If it has been terminated, nobody holds the socket. I think common solution for this problem is to always use 1 application instance and many windows. But I wouldn't like to do it because 1 instance == 1 actively working thread due GIL.

Probably should just start new instance if nobody holds the socket.

vi commented 9 years ago

I usually follow policy "Enki with default session => short-lived, Enki with named session => sole instance". Multiple Enki instances saving the same session file is a poor mode anyway.

If needed, sockets can also include PID, so the file will be opened in random Enki instance for this session.

I think the "Single application" approach is OK, but other named session should receive other "single application" instance. This way trying to open a new Enki will just open a file in existing Enki instead of opening a new window, unless --session somesession.

andreikop commented 9 years ago

I agree about 1 application per session. But the majority of users don't use sessions. How to behave in this case?

vi commented 9 years ago

Just increment the session name (like session_2.json).

enki --new-window myfile.txt should start new Enki process. The session name is derived from "myfile" somehow. If it already exists, add or increment a counter to it;

enki --remote myfile.txt should search for active sessions named after myfile (without a counter or with minimal counter value). If there are none, search for any active session. If there are still none, start new Enki process with a session named after "myfile" (with or without a counter). Stale sockets should not stop Enki from opening the file;

enki myfile.txt should be like with --new-window or like with --remote, depending on user preferences ("Keep one Enki window by default" setting).

Obviously enki --session qqq --remote myfile.txt should omit searching for session and use the session with explicit name instead (and start a new window if none).

Active Enki session == Enki window. The term "window" may be exposed to user instead of "session" (so there be "named windows" instead of "named sessions").

There should be a way to enumerate/delete/rename sessions (espeically passive) and open new Enki window for other session; like File -> Sessions -> Qqq. There should be a session manager. There should be command-line enki --list-sessions that does nicer ls ~/.config/enki/session_*.json (with a number of opened files in sessions, in tabular form)

There should be "Clone window": copy current session name to the one with incremented counter and open it.