Properly handle local file URLs #48
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
+ Expand environment variables (eg. $HOME, $TEMPDIR, ~) + Respect documentation for w3m-local-find-file-regexps + Don't hide newly created buffer after find-file
+ The permutations were the combination of cases for default keybindings 'G', 'g', 'C-u g', C-u G' for urls of scheme "file://" that either pass or fail the conditions of variable w3m-local-find-file-regexps.
Contributor
Could you let me know the recipe? I tried find-file a local non-html file using |
Contributor
Author
|
I don't remember the exact case that caused commit 3a9b473, and
it seems that it un-does a fix of the prior commit in that PR. What I'm
trying now is creating two identical local files with content:
<html><body><center>hello</center></body></html>
One I name aa.html and another named aa.aa. Then I perform
w3m-goto-url-new-session on each.
I've reverted that commit on that branch, so it should no longer be part
of PR.
…--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
|
Contributor
Author
|
It looks like I now need to revert my reversion, and that I had things
correct originally. The issue that commit 3a9b473 solves is when
one has more than one emacs window open and one performs C-u M-x
w3m-goto-url-new-session. That is supposed to open the new buffer in the
background, so the pop-to-buffer call should not happen. However, my
judgement was that if what was being opened was not a w3m buffer but
another type of emacs buffer, eg. the case for my sample file below
aa.aa, then in such cases the buffer should be displayed, so the user
will know immediately that his request ended up not being an emacs-w3m
buffer and won't appear in the w3m buffer listings etc.
I'm going to perform this operation as a git rebase since its the most
recent item and is clear-cut and leaving a back-and-forth set of revert
commits can get confusing - especially if more testing adds some
unforeseen twists.
…On 2019-07-03 08:09, Boruch Baum wrote:
I don't remember the exact case that caused commit 3a9b473, and
it seems that it un-does a fix of the prior commit in that PR. What I'm
trying now is creating two identical local files with content:
<html><body><center>hello</center></body></html>
One I name aa.html and another named aa.aa. Then I perform
w3m-goto-url-new-session on each.
I've reverted that commit on that branch, so it should no longer be part
of PR.
--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
|
e38fea2 to
3a9b473
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes several bugs in the handling of local file URLS:
Expands environment variables (eg. $HOME, $TEMPDIR, ~)
Respects documentation for w3m-local-find-file-regexps, in terms of
what the included and excluded regexes do.
Doesn't hide a new find-file buffer when creating it using function
w3m-goto-url-new-session.