open files in a running editor with shell command

[Joseph Xu]

Hi:

First off, thanks for making ne. It's the only usable console editor I've found that avoids the do-everything insanity of emacs and the keystroke-minimization insanity of vim.

However, one feature I do miss from those editors is the ability to open files in a running instance of the editor using a shell command. For example, with vim, you can type "vim --remote <file>" to load the file in an already running vim session. Does ne have a similar feature?

If not, I want to try to convince you that it's a good idea because it is very useful for integrating the editor into your work environment instead of the other way around (the way of emacs, and recently vim also). For example, if you use tmux or screen and run vim side-by-side with a gdb debugging session, you can type "edit" into gdb and make the source file pop up in the vim window, centered at the line you're stopped on. You can also set up scripts to pick out things that look like file references in the output of any command, such as grep or make, and automatically load those files into your running editor. The editor gains the power of those commands without any additional features.

I hope you'll give this feature some consideration.

Joseph

[Sebastiano Vigna]

On Oct 22, 2012, at 10:01 PM, Joseph Xu wrote:

> I hope you'll give this feature some consideration.

Do you have an idea of how this is implemented in vim? That could put us on the right track. I think it's an interesting concept.

Ciao,

seba

[Joseph Xu]

Hi Seba:

Thanks for the quick response.

Do you have an idea of how this is implemented in vim? That could put us on the right track. I think it's an interesting concept.

 
I think vim uses some X11 IPC mechanism to communicate between the editor process and the loading command, which I never liked because it requires the user have an X session running. I don't know how emacs does it, but I will look into it. Two other editors that I know support this feature are the Plan 9 editors "sam" and "acme" (great editors btw). They both use the 9p file protocol, which is natively supported in modern Linux kernels and the BSDs, but I don't know if this an acceptable dependency for ne.

From my naive perspective, I think all that's needed is for the editor to listen on a BSD file socket, for example at "/tmp/ne.in". Then any other process can open a connection to that socket, write a location to it in the form of a plain text string, such as "/path/to/file:line:char", and then disconnect. Once the editor reads the string, it can open a new document and present it to the user.

The main problem is control flow. The file socket events have to be multiplexed with user events such as keystrokes, and I don't know how ne handles events. Ideally, something like select() would be used.

Joseph

[utoddl]

Well, that was nearly unreadable. Let's try that again.

I looked briefly over some vim sources. Vim appears to open an X window specifically to facilitate this sort of communication, and uses the facilities X provides. (There is special case code to make it work in Windows of course.)

Since ne makes no assumptions about the existence of X, it think it would be more appropriate to use named pipes, probably in ~/.ne/ or /tmp. We would somehow have to arbitrate between different instances of ne, and we'd need to decide how to handle the situation where ne has been backgrounded... There are other issues as well I'm sure.

It would probably end up as a secondary channel through which a use can submit an arbitrary stream of ne commands, either as
  ne --remote "cmd string"
or
  echo "cmd string" > ~/.ne/.remote.p#
   
An intriguing idea to be sure; definitely deserving more thought.
--
Todd

[Joseph Xu]

On Mon, Oct 22, 2012 at 01:57:20PM -0700, utoddl wrote:
>
> Since ne makes no assumptions about the existence of X, it think it would
> be more appropriate to use named pipes, probably in ~/.ne/ or /tmp. We

It's sometimes useful for a remote command to block until the user is finished
editing the document, such as when composing mail in mutt or commit messages in
svn. I think it would be difficult to make multiple remote commands block on a
single named pipe, since all their messages get multiplexed together, and
furthermore pipes are one-way. This can be achieved easily with a socket, if
after sending the file path the editor should open, the remote command waits
for a "done" message from the editor to indicate that the user has closed the
document.

On the other hand, named pipes are really easy to write to, whereas the BSD
socket interface is horribly arcane.

[Joseph Xu]

I had some time today and tried to write a very naive proof-of-concept implementation of this feature using named pipes. Basically, I wrote a wait_for_input() function that opened a named pipe and then, in a while(TRUE) loop, blocked on a select call with the named pipe and stdin as arguments. If select returns and indicates that the named pipe is readable, I read from the named pipe and call execute_command_line with the contents. Otherwise if select returns and indicates stdin is readable, I exit the function. I make a call to wait_for_input() right before the get_key_code() call in the main loop. This modification does read in commands from the pipe and execute them correctly, but also has the undesired side effect of always buffering one keystroke, i.e. if I type the sequence "abc", the "a" won't be inserted into the document until I press "b", and "b" won't be inserted until I press "c". I don't really understand get_key_code() so it's not surprising that this doesn't work correctly. 

I would appreciate any comments about what I'm doing wrong, or if this approach is completely inappropriate. I've attached a patch for ne.c, the only file I modified.

Thanks for the help.

Joseph