Re: [qutebrowser] Per-domain editor.command, or equivalent
Excerpts from Florian Bruhin's message of January 6, 2019 4:18 pm: > I'm not sure actually. Is there other use-cases you can think of apart > from setting the file type? I personally can't. But then, it's not something I've devoted a lot of thought to. It does seem to me there is more customisation possible with this setting compared to per-domain setting of the file extension. I cannot say, though, whether that translates into any real world applications. > If it's only for that, I'd strongly prefer a (per-domain) setting to set > the filename extension for the file getting opened: > https://github.com/qutebrowser/qutebrowser/issues/2727 > > Because then that'd work for any editor, not just vim. This would also completely address my use case. I vote for whichever is more likely to be implemented first :) -David
Re: [qutebrowser] Per-domain editor.command, or equivalent
On Sun, Jan 06, 2019 at 01:36:21PM +0930, David Nebauer wrote: > Excerpts from Jay Kamat's message of January 6, 2019 8:20 am: > > > > I already said this in the issue you posted, but I think the cleanest > > solution for this is to add url pattern support to editor.command directly. > > I wholeheartedly agree. As I posted in the issue, I have been able to > come up with a workaround bound to another key, but it is an unholy > kludge. I understand that per-domain editor commands may not be a common > need, but surely I'm not the only one with a legitimate use case for it. I'm not sure actually. Is there other use-cases you can think of apart from setting the file type? If it's only for that, I'd strongly prefer a (per-domain) setting to set the filename extension for the file getting opened: https://github.com/qutebrowser/qutebrowser/issues/2727 Because then that'd work for any editor, not just vim. Florian -- https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc I love long mails! | https://email.is-not-s.ms/ signature.asc Description: PGP signature
Re: [qutebrowser] Per-domain editor.command, or equivalent
Excerpts from Jay Kamat's message of January 6, 2019 8:20 am: > > I already said this in the issue you posted, but I think the cleanest > solution for this is to add url pattern support to editor.command directly. I wholeheartedly agree. As I posted in the issue, I have been able to come up with a workaround bound to another key, but it is an unholy kludge. I understand that per-domain editor commands may not be a common need, but surely I'm not the only one with a legitimate use case for it. Thanks for your advice on this. -David
Re: [qutebrowser] Per-domain editor.command, or equivalent
David Nebauer writes: > When I attempted to set a per-domain editor.command in config.py and > source it, I received an error that editor.command does not support URL > patterns. I already said this in the issue you posted, but I think the cleanest solution for this is to add url pattern support to editor.command directly. The change should be fairly trivial, with the hardest part getting the URL to match against. Here's a similar PR: https://github.com/qutebrowser/qutebrowser/pull/4046/files The place where the editor is spawned is here: https://github.com/qutebrowser/qutebrowser/blob/0cf92862bbf583b661d9b04e6671bc3c6183f5ef/qutebrowser/misc/editor.py#L181 In order to get the URL to match against, one way you could pass it in is through the top level command, like this line: https://github.com/qutebrowser/qutebrowser/blob/0cf92862bbf583b661d9b04e6671bc3c6183f5ef/qutebrowser/browser/commands.py#L635 -Jay
