Create vimdoc from readme #19
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
It doesn't make sense to adjust our layout unless we're merging, so only define these commands while merge is active. This makes it easier to find the right mergetool commands.
Allow users to define their own Mergetool commands. The best example I have is `:MergetoolDiffWithRemote` as an alias for `:MergetoolToggleLayout rlm`
Fix samoshkin#12: We were assuming users had 'hidden' set. mergetool#start ends with two steps: prefer_revision and set_layout. prefer_revision modifies the current buffer to remove conflict markers. set_layout closes all but the first window in g:mergetool_layout and then shows the other windows in order. If a user has these combination of settings, closing the merge buffer's window will trigger an error: set nohidden let g:mergetool_layout = 'rm' We modify the merge buffer (without saving it -- so the user knows we made changes) and then we try to close it (because 'm' is not the first item in mergetool_layout), which triggers an "unsaved changes" error. Prevent the error by temporarily marking the merge buffer to hide while we're modifying the layout. Uses setbufvar (introduced to vim in 7.0) to clean up so if the user doesn't include 'm' in the layout, we don't fail to clean up. And in that case, the merge buffer is already hidden, so it doesn't cause unsaved errors until it's shown again.
Fix buffer already exists error on win32. Cannot create a buffer called 'remote' if there's already one called 'REMOTE' because win32 is not case-sensitive. When we use as git-mergetool, there's always buffers called BASE, LOCAL, and REMOTE. So append a suffix to disambiguate. These buffers are derived by removing conflicts from the merge file, so I call them _derived.
Fix samoshkin#13: add g:mergetool_args_order. Add g:mergetool_args_order to renames arguments as hidden files with the same names as git (BASE, REMOTE, LOCAL). This allows mergetool to behave as if invoked by git-mergetool for any scm.
- Mostly copied verbatim. Moved some sections around to be more logical within vimdoc. - Rephrased some bits and applied the same rephrasing to readme. - Removed some sections that weren't relevant to people already using from within vim. - Lots of line wrapping and converting `` to || or other corresponding help markup. Not sure if the readme should be stripped down to avoid duplication.
If the readme is "marketing" for people looking to see if they want to install the plugin, then the vimdoc is a "manual" to help them figure out how to use it once installed. These sections duplicate what's in the vimdoc and are more relevant to someone trying to configure the plugin instead of someone checking out what it can do. Also, these sections don't have images.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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 isn't really mergeable because it's based on a bunch of my other PRs. Since they touched readme, it's not worth it to disentangle them. But if you merge them, I can clean it up for merging.
Only the last two commits are relevant.
I did this because I occasionally try to look up help for mergetool and am annoyed to find nothing and have to browse the readme (which doesn't have intra document links).
within vimdoc.
within vim.
help markup.
Second commit strips down readme to reduce (but not eliminate) duplication. Readme has lots of pictures and I didn't want to remove those.