Writing to a fifo buffer

When you open a fifo using edit -fifo <fifo>, it only reads from it right?
I would like to be able to also write to it in order to use kak to communicate with a tty (serial port).

Is there already a plugin that does this?
It might be fairly easy to implement by just registering new additions at the end of the fifo buffer and sending them back to the fifo, maybe I will have a go at that later.

I feel like “talking to a serial port” would be more closely related to Kakoune’s various REPL plugins than the edit -fifo mode.

Any particular reason you’re not using a traditional tool like minicom or GNU Screen?

In Emacs interactive REPL often is a simple buffer, that follows the same rules as non-interactive buffer, while still having some set of REPL related facilities. E.g. indentation rules can be applied to text written in this buffer, and auto-completion will work if configured. If you run REPL in tmux, it will not have Kakoune features, so embedding REPL into buffer is a good idea.

@JJK96 I think you don’t really need fifo, you just need a buffer that has some functions that

  • can append results from external REPL process to buffer,
  • can send text that you’ve typed after prompt to external REPL process,
  • have set of mappings that automate this process
    • <ret> to send
    • <backspace> to delete text but not prompt
  • and maybe set hooks that ensure REPL prompt invariant

Oops for some reason I’ve seen Screwtapello’s mention of the REPL, and thought that you need a REPL. This may not be applicable to communicating with tty.

I personally think that it’s not a good idea to try to make interactive REPL buffers in Kakoune. I don’t have this completely sorted out, but my reasoning goes something like this:

  • emacs does this because it’s basically an operating system, and the user cannot rely on different ways to open windows
  • Kakoune has decided it is not a window manager, and leans on terminal emulator features to implement panes, tabs, and layout.
  • REPL programs should own their interactive features.

So every time we get close to implementing a terminal-emulator-like thing in Kakoune, we should think pretty hard about it, IMHO.

Kakoune’s send-text basically works, and this can be used to edit an expression in Kakoune and send it. One corner case is that rlwrap REPLs don’t deal with large amounts of text received quickly, but this is clearly a bug in rlwrap and it doesn’t happen in other GNU readline programs.

Many REPLs have ^X^O or ^X^E which spawns an editor to edit an expression. I have this configured in bash and rlwrap, and it is really nice.

Copying results back to the program from the REPL is a little rough and needs to be smoothed over, though. I have a Clojure (pbcopy text) function that I load into my Clojure REPLs, and I can say, (pbcopy *1) to get the last value. I feel there’s more to be done here.


REPL itself and windowing is quite separate things. REPL is just a program, that runs in some textual environment that can print and consume text, hence read eval print loop. So it’s not strictly related to creating a window in Kakoune or Emacs, but creating interactive buffer to hold what was printed, and read what was put.

Interactive buffers in Kakoune are kinda normal thing, e.g. *grep*, or *make*, where you can see the log and jump to errors/grep results. My little flygrep command is another instance of using interactive buffer in Kakoune. Tagbar and Kaktree could be external programs but I see no point, because they were made for Kakoune in the first place and use internal text editing primitives.

So my point is that we can use Kakoune as a rendering engine, just like what Emacs does with it’s buffers. I see big potential in this approach, because it leverages abilities of Kakoune to accept input and render colored text, thus makes it kinda portable. Portability is not an issue though, because of narrow scope.

REPL is something like interactive hacking environment, and I would like to keep all my editor-powers in it, such as completion, structural editing (paredit or parinfer), syntax highlighting, documentation popup:

I mean, that’s really cool to have in REPL. I do not need this for terminal, but I don’t mind having it there as well.

true, but if you’re already in the editor, why would you want this? :slight_smile:

Well we’re on the different sides here, but I think you will agree that if you can have generic repl that works with multiple languages, and has all your personal configurations from the editor you’re using, you will not want to loose it and use external repl.

You’re right, it’s more related to something that communicates bidirectional, but the difference is that a repl is a program, while a tty is a file.

I am actually using screen for most of the tty communication, but sometimes I need to copy large amounts of output, for which I have not found a way in screen, so that is where kakoune comes in, but then I need to send the input using echo