search

t9md / atom-cursor-history

Cursor position history manager
https://atom.io/packages/cursor-history
MIT License
59 stars 7 forks source link

Support for remote URIs #16

Open irrationalistic opened 8 years ago

irrationalistic commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

irrationalistic commented 8 years ago

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 commented 8 years ago

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.