Opening a network file on windows

[n8henrie]

Summary

New user, accustomed to nvim on *nix but currently using hx 23.03 on windows 10.

I can't seem to open a file from my synced network desktop.

If I right-click and "copy as path": "\1.2.3.4\UsersFiles\me\Desktop\file.txt"

Dragging the file onto an open nvim window opens it properly. Dragging onto an open helix window, I see the below on the command line and no file opens:

select:ersFiles\me\Desktop\file.txt

If I instead copy the file to a local directory and drag it in, I get the full path: :\Users\me\Downloads\file.txt but it still doesn't open.

If I run :o and then drag in the local file I can get it to open.

If I run :o and then drag in the network file it lags and freezes at :o \\... pauses for 10 seconds then gets to :o \\1 ... another 10 seconds then :o \\1.

If I right click, copy as path, confirm that I have "\\1.2.3.4\UsersFiles\me\Desktop\file.txt" on my clipboard (including the quotes), then run :o -- I am unable to paste in the path. <c-v> pasted in a literal v, <c-V> a literal V, right click the mouse doesn't do anything.

Is there any way for me to open this file?

Reproduction Steps

As per above

Helix log

~/.cache/helix/helix.log doesn't exist.

Platform

Windows 10

Terminal Emulator

Running hx.exe directly

Helix Version

23.03

[CptPotato]

Pasting the path usually works fine for me. You could open the file using it as an argument hx path/to/file.
Alternatively, type/paste the :o [...] command in helix, select it and yank it to the command register ":y. Then you can execute it using :<ret>.

[n8henrie]

Thanks for your time.

Pasting the path usually works fine for me.

What key combination do you use to paste? I can't even seem to paste in insert mode. What I'm trying (for insert mode):

• i
• <c-v>

All that happens is it seems to go into some kind of literal mode (like how on *nix one can insert a linebreak with <c-v> <c-j> or something like that) in which <c-[> doesn't exit insert mode (but Esc does). Nothing pastes.

I expect if I can get paste to work in insert mode then perhaps I can figure out how to paste into :o .

You could open the file using it as an argument hx path/to/file

I'm launch directly from hx.exe window instead of running from a shell (which is why it opens to an empty buffer in the first place).

[n8henrie]

Hmm, neither "*p or "+p pastes my system clipboard either. Seems like perhaps some issues accessing the clipboard?

[n8henrie]

I don't know if these messages from hx.exe --health are relevant:

Runtime directory does not exist: C:\Users\me\AppData/Roaming/helix\runtime
Clipboard provider: clipboard-win
System clipboard provider: clipboard-win

[n8henrie]

Here's a log from when I try to drag the network file into the window:

2023-04-17T07:42:33.733 helix_vcs [ERROR] Error {
    context: "failed to open git repo",
    source: Discover(
        NoGitRepository {
            path: "\\\\?\\UNC\\1.2.3.4\\UsersFiles\\me\\Desktop",
        },
    ),
}
2023-04-17T07:42:33.737 helix_vcs [ERROR] failed to open diff base for \\?\UNC\1.2.3.4\UsersFiles\me\Desktop\foo.txt
2023-04-17T07:42:33.751 helix_vcs [ERROR] Error {
    context: "failed to open git repo",
    source: Discover(
        NoGitRepository {
            path: "\\\\?\\UNC\\1.2.3.4\\UsersFiles\\me\\Desktop",
        },
    ),
}
2023-04-17T07:42:33.752 helix_vcs [ERROR] failed to obtain current head name for \\?\UNC\1.2.3.4\UsersFiles\me\Desktop\foo.txt

[CptPotato]

What key combination do you use to paste?

It's Space p / P to paste from the system clipboard.

If you're searching for commands I'd recommend using Space ? or looking for it in the docs.

Also, on Windows you could set up file types to always open in helix (it's requires some workaround if you want to run it in a terminal emulator, though).

[n8henrie]

It's Space p / P to paste from the system clipboard.

Ah, thanks -- I now remember learning that in the tutorial. But that's from command mode, right? I had expected <c-v> to work in insert mode, but I guess that's not the case? Also, spacep doesn't seem to work as a command (e.g. after :o ...). I assume you're using <c-v> there -- is that true?

Wow, space? is great, thank you!

[CptPotato]

It's Space p / P to paste from the system clipboard.

Ah, thanks -- I now remember learning that in the tutorial. But that's from command mode, right? I had expected <c-v> to work in insert mode, but I guess that's not the case? Also, spacep doesn't seem to work as a command (e.g. after :o ...). I assume you're using <c-v> there -- is that true?

Ctrl V works depending on the terminal emulator and configuration you're using. Some use Ctrl Shift V by default, others mouse right or middle click. (Not sure if helix does some things that interfere with this, too.).

You are saying you're using helix without an additional terminal emulator, so it's Windows' default console? In that case you could enable the option to use Ctrl Shift C/V in the console settings (right click the title bar and open Properties, this setting will be specific to the executable):

screenshot

There's also an Enable Ctrl key shortcuts setting but I don't exactly know what it does.

But be aware that this style of pasting will interpret each character separately as if typed by hand. So you can run into issues where you get additional indentations, parantheses, etc. when pasting somewhere in the buffer, so I'd recommend to stick with space-P in that case. There is a "bracketed paste" feature that could work around this but iirc it doesn't work on Windows for now.

[n8henrie]

Some use Ctrl Shift V by default, others mouse right or middle click. (Not sure if helix does some things that interfere with this, too.).

Yes, as I mentioned in OP:

I am unable to paste in the path. pasted in a literal v, a literal V, right click the mouse doesn't do anything.

(with <c-V I meant ctrlshiftv). I've also tried middle and right mouse clicks.

You are saying you're using helix without an additional terminal emulator, so it's Windows' default console?

I have no idea; nvim uses (or at least can use) Qt for its standalone GUI, I don't know how this works under the covers. From releases, the x86 Windows .zip file has a hx.exe. I double click that and this comes up:

In that case you could enable the option to use Ctrl Shift C/V in the console settings

Well that worked for enabling <c-V> to paste in insert mode, so that's a step in the right direction! Unfortunately when I paste the copied path into the command bar, I get the behavior described above, namely:

it lags and freezes at :o \... pauses for 10 seconds then gets to :o \1 ... another 10 seconds then :o \1.

I just timed it, it's actually around 13 seconds per character.

[n8henrie]

The log (while it's taking 13 seconds per character to paste) aren't very interesting:

2023-04-18T09:14:14.183 helix_vcs [ERROR] Error {
    context: "failed to open git repo",
    source: Discover(
        NoGitRepository {
            path: "\\\\?\\UNC\\1.2.3.4\\UsersFiles\\me\\Desktop",
        },
    ),
}
2023-04-18T09:14:14.187 helix_vcs [ERROR] failed to open diff base for \\?\UNC\1.2.3.4\UsersFiles\me\Desktop\todo.txt
2023-04-18T09:14:14.201 helix_vcs [ERROR] Error {
    context: "failed to open git repo",
    source: Discover(
        NoGitRepository {
            path: "\\\\?\\UNC\\1.2.3.4\\UsersFiles\\me\\Desktop",
        },
    ),
}
2023-04-18T09:14:14.202 helix_vcs [ERROR] failed to obtain current head name for \\?\UNC\1.2.3.4\UsersFiles\me\Desktop\todo.txt

Again, if I take the same approach but paste in a path to e.g. "C:\Users\me\Downloads\todo.txt" (instead of the same file hosted on \\1.2.3.4...), it takes <1s to paste the path.

It's on the clipboard as a string, I don't understand why pasting a string would take so long if the string refers to a network share.

[gabydd]

The windows console does not support bracketed paste I am pretty sure, windows terminal does those so you can use that or another terminal emulator. If are using the regular windows console you will want to use the built in paste commands, you can make a custom keybind in insert mode for it if you would like and it should work.

[n8henrie]

@gabydd Thanks for your input -- again, I'm just using hx.exe downloaded directly from the releases, I have no idea how its windowing / GUI is implemented on Windows. I am not opening a separate terminal emulator, just double clicking on hx.exe.

[n8henrie]

Also, I'm fairly curious as to why the behavior is so different for pasting a string that refers to a local file vs a string that refers to a network file.

[kirawi]

I assume this issue can be closed then?

[n8henrie]

I assume this issue can be closed then?

I don't think so -- nothing has changed, and I am still unable to open the file.

Is there anyone else running Windows with a network share available that can try to reproduce? It's a pretty simple test procedure:

• Download the official executable from Releases
• Double click to run hx.exe
• Try to open a file on a network share

[n8henrie]

Alternatively, type/paste the :o [...] command in helix, select it and yank it to the command register ":y. Then you can execute it using :

This works, but seems like a lot of effort to open a file from the GUI:

• Right click file, Copy as path
• Open hx.exe
• spacep
• IospaceEscx":d
• :Enter

In contrast, in neovim:

• Open nvim-qt.exe
• Drag file onto window
• Alternatively, :espaceCtrlr+

I don't think the latter of those can work in helix as there is no clipboard register, but either implementing the first or figuring out why pasting the path into the command bar takes several minutes to completely (seriously, ~13 seconds per character) would be really nice.

I tried to compile from source yesterday to see if I could help debug, but this device doesn't have gcc, and unfortunately I don't have admin privileges.

[n8henrie]

seriously, ~13 seconds per character

Confirming this only happens for network files:

• Enable shift-ctrl-v to copy / paste as per above (thank you again)
• Right click file and copy as path
• Type :o and then try to paste:
• "\\1.2.3.4\UsersFiles\me\Desktop\foo.txt" -> 13 second lag between pasting each character
• Modify the clipboard and try to paste:
• \\1.2.3.4\UsersFiles\me\Desktop\foo.txt -> 13 second lag between pasting each character
• 1.2.3.4\UsersFiles\me\Desktop\foo.txt -> minimal lag, pastes fine
• "1.2.3.4\UsersFiles\me\Desktop\foo.txt" -> minimal lag, pastes fine

So the quotes don't seem to be a problem, just the leading \\.

[pascalkuthe]

Ok the issue is the following:

• to paste certain characters like \ without triggering hotkeys you need bracketet paste
• "double clicking" a tui application on windows opens cmd.exe
• cmd.exe doesn't support brackeyet paste
• this works with nvim, because nvim has a GUI (nvim-qt). Helix dies not (see Gui #39)

So there is nothing we can do here. Helix is a TUI application so we are at the mercy of the terminal emulator. If you want to use bracketet paste you need to start helix from a terminal emulator that support it (for example alacrity). This is simply how TUI applications work. They are not intended to be "double clicked".

[n8henrie]

@pascalkuthe thanks for the explanation -- clearly (edit: I need) to read more about bracketed paste.

The \ character pastes just fine in several cases, as I've explained above, which doesn't seem to fit your explanation. The only problem is when it is the leading part of the path (with or without a leading double quote).

If the bracketed paste issues are truly the problem, would it make sense that they work fine on non-network share paths?

[n8henrie]

Also, to be clear, I can use shift-ctrl-v to paste "\\1.2.3.4\UsersFiles\me\Desktop\foo.txt" totally fine into the editor pane, and I can use shift-ctrl-v to paste "b\\\\\\\" into the command window without issue, it's only with a "leading" \ (other than the preceding ") and only in the command pane that the weird behavior manifests.

I see the same behavior when I launch helix from Powershell or cmd.exe -- trying to paste in "\\1.2.3.4\UsersFiles\me\Desktop\foo.txt" to the editor pane is fine, trying to paste it into the command pane glitches.

Does this still sound like a window bracketing issue?

Helix is a TUI application so we are at the mercy of the terminal emulator (edit: as opposed to its own UI). If you want to use bracketet paste you need to start helix from a terminal emulator that support it (for example alacrity). This is simply how TUI applications work. They are not intended to be "double clicked".

Sorry, I'm just not very familiar with Windows, and I didn't recognize that this was just opening up a terminal emulator. I'm a heavy Linux server user and most of my machines are headless and managed exclusively over SSH, I'm at least a little familiar with TUIs, just no idea what I'm doing on Windows.

I don't mean to pester, and I am grateful for the project and for the time spent in responding to me so far.

I'm attaching two videos of the behavior. (I'm sorry that the text is so small it's difficult to see, you may need to expand to full screen. The built-in Windows screen recording app doesn't seem very fully featured.) In both of these videos, I exclusively use shiftctrlv to paste (did not use spacep at all).

In the first, "1.2.3.4\UsersFiles\me\Desktop\foo.txt" (a string containing backslashes) pastes into the text area without trouble and subsequently pastes into the command area without trouble:

output2.mp4

In the second, you can see that "\\1.2.3.4\UsersFiles\me\Desktop\foo.txt" pastes into the text area without trouble, but at about 14 seconds in you can see it have trouble pasting into the command area; the " appears, which is when I initiated the paste (~14s in), then at about 30 seconds the \\ appears, and I ended the video here (for privacy of the filenames that the auto-suggest pops up) but the subsequent letters trickle in, ~13 seconds between each character:

output1.mp4

I'll continue to investigate, and if I find a solution I'll tag a maintainer to request re-opening. In the meantime hopefully this issue will be helpful to other windows network-share users.

[n8henrie]

This still happens on 23.10, it is cripplingly slow to try to open a file on the network share. In particular, when pasting / dragging in a file, filling in the filepath (after :o \\filepath\here) it slows to a crawl once it reaches a directory with a lot of subdirectories.

I'm still not sure that this is due to bracketed paste issues, though I could be wrong; it looks like bracketed paste was enabled for Windows Terminal 1.7: microsoft/terminal#395 -- I'm currently reproducing this same bug on WT 1.18, the behavior is the same as that shown above.

Further, in all terminals I've tried, if I intentionally typo :e and then drag in a file, the filepath appears instantly. However if I type :o and then drag in the filepath, it fills in the first few directories but then hangs as soon as it gets to the directory with lots of subdirectories (and eventually, character by character, fills in the rest). This includes Windows Terminal, which as I noted apparently has bracketed paste support.

Possibly related issues:

• Opening a file is *very* slow on slow FSes #6867
• multi-second lags while typing filenames after :o on slow filesystems. #6114
• Disable searching for git/ignore files for path completion #7715

[n8henrie]

Opening the * buffer directly and seems to work much more efficiently than what I had posted above:

1. Shift + right click file and "copy as path"
2. In helix, :o <C-r>*Enter

The resulting path looks like \\?\UNC\[ip-address]\UsersFiles\me\Desktop\the\file.txt