"Internal" Editor

[lamarpavel]

Additional to the external editor feature, there might be a complementary internal editor feature for inputting text to a text-field on any given website. Specifically, this feature would make use of (neo)vim in the background. Input from text boxes in qutebrowser would be sent to an instance of vim (in server mode), which would return the text to be printed in the text-box. Essentially qutebrowser would be a gui for a vim-instance at this moment.

There is one plugin for Firefox doing exactly that, but as an addon, whereas the internal editor of qutebrowser would be a native solution.

Vim in server-mode might not be the most ideal solution, however, as there are reports of high latency and suboptimal performance. Possibly a much better solution would be to make use of neovims RPC interface, which is designed exactly for such a purpose. Related documentation:

• Neovim msgpack RPC-Interface
• Neovim Python interface
• Neovim Clipboard handling
• Neovim Remote Plugin support

Neovim has not yet reached a stable release, but the RPC interface seems to be rather stable. As this is not a core issue for qutebrowser but a potential additional feature, waiting for neovims first release might not be much of a problem.

Open questions:

1. How difficult would this be to implement and maintain?
2. How could we manage the dependancy on an external program ((neo)vim) for an optional feature?
3. How cool would qutebrowser be if it was the first vi-like browser that had vim as integrated editor for all text fields?

[teto]

There is RPC but one of the goals of neovim is also to propose it as a library.

[arp242]

Can't you just use XEmbed? This would work for $any editor for those of us who don't want to deal with the Neovim insanity.

http://www.emacswiki.org/emacs/EmacsXembed (also has link to PyQt4 and Emacs example).

[lamarpavel]

@Carpetsmoker This seems to be X11 centric, which would not be cross platform. This is the first time I've heard of it though, so I'll take some time to read more about it before writing it off.

[cwmke]

I'm not sure if this is the same but pentadactyl in Firefox has a similar feature called Text Edit Mode. They describe it as "Vim-like editing of input elements". The below link shows some of their code although I doubt it will be very transferable to qutebrowser. It would be wonderful to have implemented in qb.

You can search for TEXT_EDIT or just go to line 881. https://github.com/5digits/dactyl/blob/master/common/content/editor.js

[The-Compiler]

Quick summary of my thoughts:

Using XEmbed to display an editor in the edit field

(as suggested by @Carpetsmoker)

It seems QX11EmbedWidget does not exist in Qt5 and I didn't find an alternative with a quick search, so that might be difficult.

There are also some other issues with this approach:

• As @lamarpavel said, it works on X11 only - so this won't work for Windows/OS X users, and probably won't work anymore with Wayland either
• There's no such low-level access to the input boxes on the webpage, so that'd mean finding out the position of the box, drawing an XEmbed thing over it with the right position/size, and adjust that correctly when the window geometry or scroll position changes. This sounds painful.

Integrating something like NeoVim via RPC

(as suggested by @lamarpavel)

This clearly has the benefit of having a very capable vim implementation, but it might be difficult to implement, and it requires NeoVim as a dependency

edit: See firenvim for some inspiration

Doing our own small vim-emulation

(as suggested by @cwmke)

This is probably what Pentadactyl does, and also what I'd prefer. Probably big parts of this would need to be done in Javascript however, as there's no good input element access from the C++/Python API (especially with QtWebEngine).

This could get quite complex though, depending on what vim motions it should support.

It's unlikely I'll work on this, as I'm happy with using vim as an external editor - but of course, contributions would be very much welcome!

[ff2000]

Integrating something like NeoVim via RPC

(as suggested by @lamarpavel)

This clearly has the benefit of having a very capable vim implementation, but it might be difficult to implement, and it requires NeoVim as a dependency

There is neovim-qt which already offers a qt-editor-widget. Shouldn't it be possible to use that? You might want to use your own config for nvim, possibly adding tweaked ones in the wiki, so that people could use nvim without having to learn e.g. modal editing, etc. (Don't know if every qutebrowser-user also runs vim as their main editor)

I personally don't think it is that bad to depend on neovim for a certain feature. Most distros ship it. And it is way easier to use that instead of implementing an own widget that has to be maintained and never will be as good as (n)vim ;)

[The-Compiler]

No - you'd have to translate the things you get back from NeoVim to javascript to manipulate the text on the page.

It's also not a widget really - I just need the logic of Vim in javascript - as such, it might be better and easier to steal that from Pentadactyl (or some other vim addon).

[lamarpavel]

@The-Compiler, the problem I see with implementing things ourself is that existing (n)vim config and plugins will not be considered and the behaviour of the internal text edit might thus differ vastly from what the user expects.

I didn't initially think about how the RPC return might need to be translated, but that is a potentially complex problem alright. Something at the back of my head keeps telling me that there is an easy and generic way around it, but I'd have to read more about the RPC spec and how text fiels in qutebrowser work.

[larryhynes]

FWIW I use X11 on OSX, and setting external editor to urxvt -e vim "{}" works like it should, which means I don't even have to install OSX's gvim equivalent, mvim (MacVim). (Which I think is totally flippin' cool, BTW!) Anyway, I just wanted to make note of that here in case anyone else is searching for OSX X11 stuff.

OT: What I would really like is to get the QT Python launcher on OSX to work natively in X11, but from the small bit of digging I've done I don't think it's possible.

[amerlyq]

@The-Compiler what about Qt/FakeVim as internal editor? http://doc.qt.io/qtcreator/creator-editor-fakevim.html It was successfully used in https://github.com/hluk/CopyQ as text editor.

[lamarpavel]

@amerlyq It looks like that does not read the .vimrc and thus will not adhere to the user configuration of vim. It seems mundane but user config is pretty important for some vim users - I would rather continue using my neovim as an externally spawned editor than to use an internal editor that does not respect my .vimrc.

[amerlyq]

@lamarpavel, I understand your point, as someone who also uses neovim as external editor for many other usecases and have >100 plugins on top of that. But for each and every one of usecases I use several greatly simplified separate configs, where hardly any plugin present, if not even none. Because for me startup time is too important.

And truly speaking, do you really need all that plugins to insert some text in middle of current input box or exchange places of several words? After all we don't speak about complete replacement of external editor by internal one, in gmail/jira/etc it won't work smothly anyway. However neovim server would be of great help then.

But for now, for small episodical edits of input fields, at least temporary, I would preferred any vim-like inner editor, even if it's crippy. It's better then launching complete vim in background. Moreover whole neovim with plugins. And much better than having completely none.

Besides, in CopyQ you can specify path to vimrc for fakevim. So, do you really checked, it's not adhere?

[lamarpavel]

neovim as external editor works well enough for me, not to complain. I have about 20 plugins installed, but only one config file that I use for all neovim instances. It's plugins like CamelCaseMotion that will throw me off when not present.

I see your point, but the dominant philosophy of qutebrowser right now is: Do things right once, no half-baked solutions. That's why @The-Compiler has been working on nothing but tests for many months now, and things like per-domain-settings are on hold until after the tests and webkit replacement - even though you could implement a part of the feature now. In that light, I would also prefer to have a proper solution to the internal editor, rather than a few iterations of half-good solutions.

Just my personal opinion though. If you can provide a solution that @The-Compiler accepts, I will help test and review it.

edit: I haven't checked properly about CopyQ, just skimmed its features and based on my work with QtCreator some time ago I assumed you can't use your vim settings. I'll take a closer look now.

[teto]

Among the key objectives of neovim is to be embeddable, I don't see startup time as a showstopper since as @amerlyq mentioned, one can have several configurations. Have you tried using vim-plug/dein with lazy loading ? even without it, even if spawning a neovim server takes time, I suppose it happens only once during a qb sessions (perhaps even none if a server is already running) ?!

[The-Compiler]

So from the point of view from an user, I'd be fine with the FakeVim-like solution. It's nice to edit some text fields quickly without spawning another process, and for more sophisticated writing an external editor works well.

However, from the developer POV, FakeVim won't really help much, as HTML text fields aren't native Qt widgets essentially - and even if they were, FakeVim being C++ means qutebrowser would either need to translate it to Python, or write custom C++ bindings which comes with its own set of problems.

Something like vim.js would probably work better, but that thing is just crazy - I think it's basically a real vim + emscripten :wink:

[The-Compiler]

There's also wasavi which might be a possibility for a vi-emulation in JS.

Other interesting ones:

• vim.js
• Surfingkeys vim editor (apparently based on ace)
• vim.wasm
• Codemirror vim bindings

[moon-chilled]

+1 for wasavi.

[amacfie]

vim.js (different from the one mentioned above) is another one

CodeMirror has a Greasemonkey script.

[The-Compiler]

toplan/Vim.js seems very spartanic - from a (very quick) first try, it e.g. doesn't support b to go a back a word.

I'm mostly leaning towards CodeMirror really (without having taken a closer look, though), for various reasons:

• It seems relatively easy to integrate (i.e. it's not a browser addon already)
• Actively maintained (including its vim integration)
• Seems to have quite a lot of bindings
• Has tests, even for the vim integration
• Could potentially be used to offer other nice editing features for text fields.

[gramcracker]

Maybe consider a setting for switching from a default of codemirror/wasavi to neovim? That way there is a pretty, and usable default editor, until development of the neovim to javascript interpretation is up to par. A plugin will be needed to be configured in neovim for this to work anyways, this should be left up to the user. Btw here is a pretty active node client for neovim https://github.com/neovim/node-client.

[The-Compiler]

I'd rather not have multiple integrations in the qutebrowser core. Perhaps - at least in the long run, but maybe even initially - it'd be better to have some kind of extension API (#30) to allow doing this.

[gramcracker]

I agree. Thats a better way that avoids bloat, and avoids supporting a potentially buggy interface.

[monokrome]

Xembed would be dope on unix systems because it would work with tabbed

[The-Compiler]

@monokrome I'm confused. Why would you want to use tabbed for an editor field?

[The-Compiler]

Another idea based on #6608: In theory we could even use xterm.js or QTermWidget to display a real terminal overlayed to the webpage, with vim (or whatever other terminal editor) running in there.