Whenever I open a link with <local-leader>vf, an error message is printed in Vim

The link is opened correctly, but a message like the one below is printed on Vim:

Git From The Bottom Up: (htt[14771:14808:0131/151208.459978:ERROR:browser_gpu_channel_host_factory.cc(121)] Failed to launch GPU process.ous (http://bit.ly/lenough) ✓
39 How Linux Works (394p) Created new window in existing browser session.

The message disappears from the terminal if I resize the window (it happened both Terminator and XFCE Terminal). The error message does not disappear from Guake when I hide/unhide.

It happens both with VikiMode and VikiMinorMode. I'm using MX-Linux 17 and Vim 8.0

|Git From The Bottom Up: (htt[14771:14808:0131/151208.459978:ERROR:browser_gpu_channel_host_factory.cc(121)] Failed to launch GPU process.ous (http://bit.ly/lenough) ✓ 39 How Linux Works (394p) Created new window in existing browser session. | The message disappears from the terminal

I assume the value for `g:vikiOpenUrlWith_ANY` is wrong for your setup. Since the correct value is highly specific to your environment, I think you'll have to try some values and probably set the correct one in your vimrc file.

Thanks! And in what viki file should I make the change?

It's a user configuration. Usually this would go into `~/.vimrc`. also... what are the values at my disposal? I don't know the environment you're using. By default, viki covers win32, mac, xdg, gnome, kde. All of these assume some sort of desktop environment. What's the current value of `vikiOpenUrlWith_ANY` -- try `:echo vikiOpenUrlWith_ANY`. Is it set?

It would also be interesting to know if the sames messages are printed when you run the command, which vikiOpenUrlWith_ANY is set to, from the command line. I think the messages come from chrome/chromium, am I right. In this case you either accept the messages or create a wrapper script/alias that redirects (presumably) the stderr channel to /dev/null.

Sorry for not being clear. g:vikiOpenUrlWith_ANY is a variable in vim. Start vim and then type :echo g:vikiOpenUrlWith_ANY vf in vim works fine but chrome displays some error/debug messages you don't get to see when starting it from gvim. Try run chrome from the terminal. Since this isn't really a problem (with vim, viki etc.) and the phenomenon is highly specific to your setup, I can't help you with that. Am February 2, 2018 12:24:26 AM UTC schrieb Davi Ramos <notifications@github.com>:

…

I'm running Viki on **MX-Linux 17**, a **Debian Stable derivative** with the **Xfce environment**. I'm using **Vim 8** on **Terminator** or **Xfce Terminal**. Does Viki work only with **gVim**? Because I just checked and <loicalder>vf **worked fine with gVim / Chrome**. **It also worked fine with Terminatror / Firefox**. Terminator quickly flashes a few lines of text when I hit <localleader>vf, but it goes out right away and it's impossible to read. Vim shows no register of it when I hit <u>. I still need a solution, though, because a had to change system-wide settings to make Firefox default, and I have no intention of switching from Chrome, and I much prefer the terminal version o Vim. I tried running `vikiOpenUrlWith_ANY -- try :echo` both on bash and Vim, but: @~$ vikiOpenUrlWith_ANY -- try :echo bash: vikiOpenUrlWith_ANY: command not found and on Vim this happens: :vikiOpenUrlWith_ANY --try :echo E492: Not an editor command: vikiOpenUrlWith_ANY --try :echo Also: is there a way to "linkify" text without having http:// ? I will try changing the config file later. Thanks! -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #19 (comment)

Navigation Menu

Repository navigation

Whenever I open a link with <local-leader>vf, an error message is printed in Vim #19

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Whenever I open a link with <local-leader>vf, an error message is printed in Vim #19

Description

Activity

tomtom commented on Jan 31, 2018

tomtom commented on Jan 31, 2018

tomtom commented on Feb 1, 2018

tomtom commented on Feb 2, 2018

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions