edwood icon indicating copy to clipboard operation
edwood copied to clipboard

External autocomplete

Open rjkroege opened this issue 6 years ago • 10 comments

Acme has a built-in simple autocomplete system that Edwood has inherited. The inclusion of this functionality isn't necessarily compatible with the Acme "IDE built of UNIX commands" model. We should consider implementing a scheme where an external command (perhaps configurable per Window) would be responsible for autocompletion functionality.

rjkroege avatar Apr 19 '18 15:04 rjkroege

Conceivably #47 should be folded into this?

rjkroege avatar Apr 19 '18 15:04 rjkroege

Having just discovered that Ctrl-F works in Acme. How does one pick one of the completions in in the +Errors window? Just Snarf it?

I think it would be really interesting to hook this into one of Go's auto-complete libraries.

sirnewton01 avatar Sep 05 '18 12:09 sirnewton01

Yes. Snarf the result or type more until there is only one choice.

And yes. The point of the bug would be to permit an external auto-completion system to be added with the libraries that you're thinking about or something like YCM running as a separate program.

rjkroege avatar Sep 05 '18 13:09 rjkroege

Note: bash has some kind of external autocomplete system. It might be worth when designing this feature to see if an external autocomplete engine could reuse bash autocomplete data.

rjkroege avatar Nov 01 '18 10:11 rjkroege

Language Server Protocol (LSP) has support for auto-completion. I've been working on a tool that integrates LSP with acme. Currently I can have a window in acme that shows a list of possible completions in a window and update it as I move the cursor. However, the way I'm implementing it is very inefficient because it reads the whole body when I move the cursor (or type something).

I think what's needed for an external auto-completion (and other LSP features) is a log file for each window, similar to the global log file, but it'd allow clients to passively monitor each window. In theory this should already be possible with the event file, but somehow writing back events to the event file doesn't always update the tag correctly. So, perhaps the event file needs to be fixed instead.

Something else to think about: can we expand the file server enough, so that it's possible to separate the acme file server part from the GUI part? This would make something like sam -r possible with acme.

fhs avatar Dec 05 '18 04:12 fhs

Several comments:

  • LSP sounds cool. It would really cool for your tool to connect Edwood to LSP. I'll have to try out your tool.
  • Feel free to share your ideas on what the UI should be for picking auto-completions.
  • Per-Window log files seem comparatively easy as a feature enhancement
  • Can you expand on what the event file issue? In particular, do you have a simple replica case that shows the problem?
  • Splitting the acme file server from the GUI is major surgery. I think that I'll eventually make it easier to contemplate with what I'm doing with #97 but at least at present, model updates and view updates are tightly intertwined.

rjkroege avatar Dec 26 '18 14:12 rjkroege

My LSP tool should already work with Edwood, since the file server is currently compatible with acme. I've been using it for a while instead of A and acmego for Go programming. It doesn't use the official Go lsp server yet, but it will when that's ready.

The problem with event file is that if you run a simple program (see below) that just writes back the events, "Put" and "Undo" doesn't automatically show up when you modify the text in the window. The window is marked as dirty but somehow the tag isn't updated so that the user can Save/Undo the file.

I'm not too concerned with picking auto-completion just yet. I'd be happy just to get a list of completions that's computed fast.

package main

import (
	"log"
	"os"
	"strconv"

	"9fans.net/go/acme"
)

func main() {
	n, err := strconv.Atoi(os.Getenv("winid"))
	if err != nil {
		panic(err)
	}
	w, err := acme.Open(n, nil)
	if err != nil {
		panic(err)
	}
	for {
		e, err := w.ReadEvent()
		if err != nil {
			break
		}
		if err := w.WriteEvent(e); err != nil {
			log.Printf("WriteEvent: %v\n", err)
		}
	}
}

fhs avatar Dec 26 '18 15:12 fhs

Out of curiosity, as I am currently trying to make it work:

My LSP tool should already work with Edwood

How do I use acme-lsp with Edwood on Windows where plumb is not a native command?

dertuxmalwieder avatar Aug 26 '19 14:08 dertuxmalwieder

How do I use acme-lsp with Edwood on Windows where plumb is not a native command?

You can't unfortunately. I've opened https://github.com/fhs/acme-lsp/issues/14.

fhs avatar Aug 26 '19 15:08 fhs

Thank you.

dertuxmalwieder avatar Aug 26 '19 16:08 dertuxmalwieder