Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for remote URIs #16

Open
irrationalistic opened this issue Mar 11, 2016 · 4 comments
Open

Support for remote URIs #16

irrationalistic opened this issue Mar 11, 2016 · 4 comments

Comments

@irrationalistic
Copy link

It is possible for the files loaded into atom to be from remote locations (such as in nuclide: http://nuclide.io/docs/features/remote/). This breaks the validation logic since there is no way to use fs to check for file existence!
https://github.com/t9md/atom-cursor-history/blob/master/lib/entry.coffee#L41 will always return false for file URIs that look like something://url-to-file.ext. Could you add some logic to support remote urls? Thanks!

@t9md
Copy link
Owner

t9md commented Mar 12, 2016

I unserstand the background of request.
I want to know how I can implement it.
Bypassing validation is easy, but what if remote file is not exist, shoud I use try catch clause or @editor.getPath() return local path that can validate existence of file?
I'm currently not usjng remote edit, so detailed information what happen when you open remote file is helpful.

@irrationalistic
Copy link
Author

That's a good question, I'll investigate further and let you know!

@irrationalistic
Copy link
Author

Another part to this question would be, what about unsaved buffers? Can those be supported at all? They don't have a file URI, but the buffer does have an ID...

I looked at how atom handles trying to load a non-existent file and it fails if you try to load a file that doesn't exist either locally or remotely based on the given URI. atom.workspace.open is a promise, so it's possible that instead of checking if a file exists when you save the position, you could check when atom tries to open the uri. In this case, if the editor fails to open it, you silently capture the error with .catch and skip ahead to the next history entry. Then you don't have to manually check where the file is when the history item is saved, but rather when trying to access it.

A further measure you could try would be that if a history entry is loaded but the file fails, you could quickly run through the rest of the history and pull out all the entries that match the same file.

@irrationalistic
Copy link
Author

There's probably a flaw in that logic. Seems that atom.workspace.open will actually create the file if it doesn't exist, which is why you did the checking in the first place. Maybe it's a combination of the two approaches where, if the pattern of the URI looks remote, you skip the file validation and use the on-open validation. If the file looks local, you retain the fs check.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants