fix unable to parse filename with spaces #27
Conversation
editorconfig_plugin/gedit3.py
Outdated
| if file_uri.startswith('file:///'): | ||
| return self.get_properties_from_filename(file_uri[7:]) | ||
| return self.get_properties_from_filename(unquote(urlparse(file_uri).path)) |
There was a problem hiding this comment.
This seems wrong to me, because what if the file_uri is something like sftp://host.domain/path/to/some%20remote%20file.txt? At least in theory that's possible, with Gio... so it seems like the if file_uri.startswith('file:///') check is still necessary, no?
In fact, I just ran gedit sftp://my.fileserver/home/ferd/.zshrc and GEdit opened up my remote .zshrc just fine. But it'd break things, if the plugin turns that location into the path to my local .zshrc. (Which also exists, but is not the same file!)
If the file_uri does start with file:///, I agree using urlparse and unquote is a better approach to converting URLs into local pathnames.
There was a problem hiding this comment.
Alright thanks for the correction. So I guess it's better to keep the file:/// URI checking then, let me fix this soon
|
@ferdnyc sorry for the very late delay, I got occupied with my projects. I have re-enabled the URI checking for file names. Please kindly check it out. Thanks |
| if location: | ||
| file_uri = location.get_uri() | ||
| if file_uri.startswith('file:///'): | ||
| return self.get_properties_from_filename(file_uri[7:]) | ||
| if file_uri.startswith('file://'): | ||
| return self.get_properties_from_filename(unquote(urlparse(file_uri).path)) |
There was a problem hiding this comment.
Apologies, @michaelrk02, for not checking this out earlier, but I was just reading the terminal plugin source, and it turns out this plugin is using outdated APIs. This function can be written like this, and not require urllib at all:
location = document.get_file().get_location()
if location and location.has_uri_scheme('file'):
return self.get_properties_from_filename(location.get_path())(document.get_file() returns a GtkSourceFile, and its get_location() method returns a GFile with access to all of that interface's methods.)
| if file_uri and file_uri.startswith("file:///"): | ||
| return self.get_properties_from_filename(file_uri[7:]) | ||
| if file_uri and file_uri.startswith('file://'): | ||
| return self.get_properties_from_filename(unquote(urlparse(file_uri).path)) |
There was a problem hiding this comment.
I'll have to track down GEdit 2 API documentation, to figure out if this one can use similar calls. Though it's debatable whether providing a gedit2 plugin really makes any sense anymore.
There was a problem hiding this comment.
Hmm. It seems that while document.get_uri() returned a gchar string containing the URI, there was also a document.get_location() which, similar to GEdit 3, returned an ancient-history version of a GFile. (ref)
What did the GFile API look like in 2010, tho? Absolutely no idea.
There was a problem hiding this comment.
...Huh, I guess even back in 2010 GFile was provided by Gio, which means its API should be fairly similar to what it is today. GLib has evolved very little over the years. And neither has_uri_scheme() nor get_path() is shown as being a later addition to the GFile API, so they should exist just the same even in GEdit 2.
Looks like this one can be written the same as in GEdit 3, just using document.get_location() instead of document.get_file().get_location().
This is done by parsing file URI's with
urllibstandard library instead of picking a substring at a specified offsetTherefore
file:///my%20dir/my%20file.cwill be read as/my dir/my file.cinstead of/my%20dir/my%20file.cwhich results in file not found and causes plugin to not working