profile
viewpoint
Tim Pope tpope Brooklyn, NY https://tpo.pe/ Vim plugin artist

tpope/heroku-fucking-console 558

When I run heroku console, I want a fucking console, dammit

tpope/hookup 439

Automate the bundle/migration tedium of Rails with Git hooks

tpope/gem-ctags 368

Automatic ctags generation on gem install

tpope/gem-shut-the-fuck-up 364

Gem SHUT THE FUCK UP

hashrocket/dotmatrix 337

Hashrocket Dot Files

tpope/pickler 301

PIvotal traCKer Liaison to cucumbER

tpope/git-bump 242

Create Git release commits and tags with changelogs

tpope/fivemat 234

MiniTest/RSpec/Cucumber formatter that gives each test file its own line of dots

tpope/gem-browse 195

gem edit, gem open, gem clone, gem browse

tpope/heroku-binstubs 92

Create binstubs to easily dispatch the heroku command for specific apps

issue commenttpope/vim-fugitive

:Gblame mapping doesn't close split on second toggle

I'm phasing out :Gblame because I want fewer commands, not more, and I don't think I want to invent "fake" Git subcommands. I also think a toggle is better suited to a global window than a context dependent one like :Git blame, and as a consequence don't really want to implicitly endorse it by making it a first class feature. Thanks to your issue it should be pretty easy for users that want it to find this solution; I think that's good enough.

mschwager

comment created time in 19 hours

issue closedtpope/vim-dispatch

binding.pry does not work when running specs

Having added a binding.pry in the code to test and using vim-test, the pry console does not appear in the window. When running :Dispatch ./bin/rspec % directly, it does pause for a few seconds where binding.pry was placed, but modifiable is off and I cannot do anything. Not sure if there is a solution to this.

closed time in a day

ioanniswd

issue commenttpope/vim-dispatch

binding.pry does not work when running specs

The solution is to use :Spawn instead of :Dispatch. If you have a default b:dispatch configured, :0Spawn will use it automatically. I don't know if vim-test provides a mechanism for this.

ioanniswd

comment created time in a day

issue closedtpope/vim-fugitive

:Gblame mapping doesn't close split on second toggle

Here's my map:

" Map Ctrl+b to open git blame
:map <C-b> :Gblame<CR>

Hitting ctrl + b once opens :Gblame as expected. When I hit ctrl + b again it appears to quickly close the vertical split then re-open it. So it's impossible to close the window unless I switch to it and do :q. It looks like the behavior changed in v3.1 - if I use v3.0 the behavior works as expected.

Any idea what could be going wrong?

closed time in a day

mschwager

issue commenttpope/vim-fugitive

:Gblame mapping doesn't close split on second toggle

This was a deliberate change. I wanted to enable the ability to re-blame with varying options, that is, allow you to first call :Gblame and then later call :Gblame -w to see the blame with whitespace changes ignored. This was incompatible with toggling.

Here's a lightly tested map that implements the old toggling behavior:

function! s:BlameToggle() abort
  let found = 0
  for winnr in range(1, winnr('$'))
    if getbufvar(winbufnr(winnr), '&filetype') ==# 'fugitiveblame'
      exe winnr . 'close'
      let found = 1
    endif
  endfor
  if !found
    Git blame
  endif
endfunction

nmap <silent> <Leader>b :call <SID>BlameToggle()<CR>

Note that :Gblame is very softly deprecated in favor of :Git blame, so I've used the new form here.

mschwager

comment created time in a day

issue closedtpope/vim-fugitive

ftplugin interfering with Gdiff

Hi, relatively inexperienced vim user here.

Every time I try to use :Gdiff with Python files I get the following error, for example when I'm trying to open a file $PROJECT_ROOT/subdir/file.py:

UpdateLastColumn failed to find bufnr 2 in w:BufKillList
UpdateLastColumn failed to find bufnr 2 in w:BufKillList
Error detected while processing /home/mond0/.vim/after/ftplugin/python.vim:
line    6:
E484: Can't open file fugitive:///mnt/c/Users/mondo/Documents/workspace/project_root/.git//0/subdir/file.py

I know this has something to do with a small ftplugin I wrote to change the indentation settings to match my organization's settings when the python file contains my organization's name:

"~/.vim/after/ftplugin/python.vim
if match(readfile(expand("%:p")),"ORG_NAME")!=-1
    setlocal softtabstop=2
    setlocal tabstop=2
    setlocal shiftwidth=2
endif

The snippet above is the only content of python.vim, and commenting it out fixes my issue with Gdiff. However, I would like to keep the functionality it implements, and I don't understand why it's causing Gdiff to fail- it seems like it's interfering with the path Gdiff is looking for?

I can reproduce this error on both my home environment (running on WSL) and on my work environment, and I do not get the error when editing other kinds of files.

closed time in 2 days

mondO

issue commenttpope/vim-fugitive

ftplugin interfering with Gdiff

You're calling readfile() on a file that doesn't exist. It's more than just Fugitive buffers that will break this: any new Python file will as well. You probably want to use getline(), or perhaps search() with the n flag.

mondO

comment created time in 2 days

issue commenttpope/vim-fugitive

:Gstatus is super slow

Nvm should only slow things down if you've done one of the following:

  • Activated it in a non-interactive shell config file (e.g., '.zshenv') instead of an interactive one (e.g., '.zshrc') as recommended.
  • Added -i to 'shellcmdflag'. People do this so that shell aliases work on :!, but it breaks all sorts of things in the process. Turn your aliases into shell scripts instead.
sgottfried

comment created time in 3 days

push eventtpope/vim-fugitive

Tim Pope

commit sha a5c921190a4db37cd6c75898891fb9edaa653c2b

Override existing config values on :Git -c config.option=

view details

Tim Pope

commit sha 430253c302cfbb35b07b8819f32fab1f785076fd

Drop support for non-PTY :! The experience without a PTY is pretty lackluster, and if you're using a GUI or Windows, there's probably nothing stopping you from upgrading to a version of Vim with job support.

view details

Tim Pope

commit sha c452181975761f8b055b88eb1c98f736323510fd

Remove old :Git! temp buffer behavior Rip the band-aid off now so we can reclaim it for something else sooner rather than later. If you're trying to support both old and new versions of Fugitive, exists('*FugitiveConfigGetAll') will be true on versions where --paginate is supported. In a pinch you can also swap in :Gsplit!, but that's eventually going away too.

view details

push time in 3 days

push eventtpope/vim-fugitive

Tim Pope

commit sha 87f998e15fb18e71badf54df7ab13eb6c8c45057

Remove erroneous :Gedit! deprecation The ! to :Gedit has always been passed to :edit and not used for Git execution like the others.

view details

Tim Pope

commit sha 5a5a95b90a0929db37ccb30a046ca0c4fc284ef6

Tease apart bang and non-bang variants of :Gread

view details

Tim Pope

commit sha 31629d8bd18ddb5db6d9c55585d1eeb325a6bb43

Use :read for :{range}Git! --paginate

view details

push time in 4 days

push eventtpope/vim-fugitive

Tim Pope

commit sha efb1c8a29d3395dbeab85bda594b35e6c6803051

Add - map for Push header

view details

Tim Pope

commit sha 8b83d6ec6ce560ae67fb73f30972017562755e98

Use :pedit for :Git! --paginate

view details

Tim Pope

commit sha c0aad3ac7877f9310816c4cdbdaaaf3776dbcab5

Update internal uses of :Git! to :Git --paginate

view details

Tim Pope

commit sha 2acea41bef4cabf14f684604d679a0e528e1a47c

Handle custom Git executable for :Git --paginate

view details

push time in 4 days

issue closedtpope/vim-fugitive

Get errors when trying to create a commit

When I try and run cc in the fugitive buffer to create a commit with some staged files, I get a long list of the same error showing up. After quitting the buffer with :q and then returning to fugitive, the files do not show up as staged. This is the error I'm seeing:

(node:19565) Warning: The 'NO_COLOR' env is ignored due to the 'FORCE_COLOR' env being set.
(node:19565) Warning: The 'NO_COLOR' env is ignored due to the 'FORCE_COLOR' env being set.
(node:19565) Warning: The 'NO_COLOR' env is ignored due to the 'FORCE_COLOR' env being set.
... (on and on)

Has anyone seen this before and/or know a fix? Thanks in advance!

closed time in 5 days

dylanirlbeck

issue commenttpope/vim-fugitive

Get errors when trying to create a commit

This will likely need to be addressed upstream. The warning is mostly worthless: Environment variables don't have a single origin so this sort of thing is inevitable, and there's not a clear action to be taken when it does. But it's completely worthless in this case because they're both set to disable colors!

You can work around it by doing a unset NO_COLOR in your pre-commit hook.

dylanirlbeck

comment created time in 5 days

issue closedtpope/vim-fugitive

On staged files in`:Gstatus`, open the real file instead of the ` fugitive://.git//` one

Sometimes I have staged files and, before committing them, I normally do a mini code-review on it, just to double-check. Sometimes I find stuff that shouldn't be in that commit, so I press <CR> to open the file, but because it is already staged, it opens the fugitive://.git//... file, instead of the original one. I was wondering if there's a way of always opening the original file, regardless of when it is staged or not (probably via a different map).

I know that if I edit the file on fugitive://.git//..., it will automatically add that to the staged files, but because I edited it directly, it will diverge from the original file, and the original file will show as an unstaged change. I feel like a better and more natural workflow would be if I could go to the original file directly, fix the mistake, and then add the change to the staged changes, instead of fixing the staging change and then rolling back the new unstaged file (which is the original file).

What do you think?

closed time in 5 days

GabrielDuarteM

issue commenttpope/vim-fugitive

On staged files in`:Gstatus`, open the real file instead of the ` fugitive://.git//` one

It does open the work tree file if you press <CR> on the filename. It only jumps to the index version if you press <CR> on a line of the diff, because that diff is only guaranteed to be valid for the index version. If you invoke :Gedit from that index version, it will do the best it can to get you back to the same line in the work tree version. I don't think "best it can" is a good thing to promote to the default.

GabrielDuarteM

comment created time in 5 days

issue commenttpope/vim-fugitive

Get errors when trying to create a commit

Do you use lint-staged? It's caused issues before, such as #1446.

dylanirlbeck

comment created time in 5 days

issue commenttpope/vim-markdown

Markdown: fenced code blocks

Just because you were polite doesn't mean you were respectful.

cup

comment created time in 5 days

push eventtpope/vim-markdown

Tim Pope

commit sha 296eeaa8877528fae45e89a9013c5a8d317deef1

Support tilde code blocks Also ensure the end marker has the same number of delimiter characters as the start marker. Closes https://github.com/tpope/vim-markdown/issues/156

view details

push time in 6 days

issue closedtpope/vim-markdown

Markdown: fenced code blocks

Fenced code blocks are defined as:

A code fence is a sequence of at least three consecutive backtick characters (<code>`</code>) or tildes (~).

This is in the current Markdown spec (Apr 2019), and even back to the oldest spec (Oct 2014):

  • https://spec.commonmark.org/0.29#fenced-code-blocks
  • https://spec.commonmark.org/0.5#fenced-code-blocks

However Vim-MarkDown only seems to define backticks with inline code:

https://github.com/tpope/vim-markdown/blob/f35c43c535af40dc045d55dd459969b6f31d4128/syntax/markdown.vim#L107-L109

Doesnt define tilde use at all, and only recognizes the indented style of code blocks:

https://github.com/tpope/vim-markdown/blob/f35c43c535af40dc045d55dd459969b6f31d4128/syntax/markdown.vim#L73

Is this the case or am I overlooking something?

closed time in 6 days

cup

issue commenttpope/vim-markdown

Markdown: fenced code blocks

Did you miss the part where I said "patches welcome" or are you just an entitled asshole that thinks I owe you a fix?

cup

comment created time in 6 days

issue closedtpope/vim-markdown

Sublist items treated as code

Markdown defines a list like this:

M is a list marker of width W followed by 1 ≤ N ≤ 4 spaces

[...]

and indenting subsequent lines of Ls by W + N spaces

[...]

A sublist must be indented the same number of spaces a paragraph would need to be in order to be included in the list item.

https://spec.commonmark.org/0.29#list-items

Which means that if you have a list like this:

- Sun
- Mon
- Tue
- Wed

Then W + N equals 1 + 1..4 equals 2..5. It follows that subsequent lines with list marker, indented in this range should be considered sublists. Example:

- Sun
  - Day
- Mon
   - Day
- Tue
    - Day
- Wed
     - Day

The issue is that regardless of depth, with Vim Markdown any list item starting with 5 or more spaces is treated as code rather than a sublist.

closed time in 6 days

cup

issue commenttpope/vim-markdown

Sublist items treated as code

This was a compromise. Patches welcome.

cup

comment created time in 6 days

issue commenttpope/vim-markdown

Markdown: fenced code blocks

Sounds good.

cup

comment created time in 6 days

push eventtpope/vim-fugitive

Rob Pilling

commit sha 349b18d373f19b7b2c6361daaf6d5f2e2f4ebadd

Pull out s:fileignorecase()

view details

Rob Pilling

commit sha 9e4a5239ee2a91f71605a288810419ce3a603df2

Respect 'wildignorecase' when completing :Gedit

view details

push time in 6 days

PR merged tpope/vim-fugitive

Respect 'wildignorecase' when completing :Gedit

This makes completion for :Gedit respect wildignorecase and fileignorecase, when completing the path part of a fugitive-object. With this change, the :Gedit command feel more native to vim, matching the behaviour of the :e command (amongst others).

+8 -2

2 comments

1 changed file

bobrippling

pr closed time in 6 days

pull request commenttpope/vim-fugitive

Respect 'wildignorecase' when completing :Gedit

Can you rename to s:FileIgnoreCase()? I'm trying to standardize on camel case for all new functions.

bobrippling

comment created time in 6 days

issue commenttpope/vim-markdown

Markdown: fenced code blocks

There have been requests for tilde delimiters before, but they were always contextualized as being part of some non-standard extension. I didn't realize they were widely supported. We should definitely support them too.

cup

comment created time in 6 days

issue closedtpope/vim-speeddating

Day name not incremented with date

When pressing <C-A> over the day number, only the day number increments and not the day name. Same issue if incrementing the month number--day name does not update.

2020-02-20 Thu 9:04 PM => 2020-02-24 Thu 9:04 PM 2020-02-24 Thu 9:04 PM => 2020-03-24 Thu 9:04 PM

closed time in 6 days

unknownbreaker

issue commenttpope/vim-speeddating

Day name not incremented with date

2020-02-24 Thu 9:04 PM isn't a built-in format. Define it with :SpeedDatingFormat.

unknownbreaker

comment created time in 6 days

issue closedtpope/vim-dispatch

Can I see full raw command output from :Dispatch?

I can't find any way to view the full output (stdout and stderr) from a command, only the quickfix entries. Is there a way?

closed time in 7 days

dbarnett

issue commenttpope/vim-dispatch

Can I see full raw command output from :Dispatch?

:Copen!

dbarnett

comment created time in 7 days

issue commenttpope/vim-fugitive

`:Git log --oneline --decorate --graph --all` stopped showing colours on neovim.

At the highest level I would not consider this an edge case. log is one of the most important commands in Git and do hope to improve Fugitive's interface to it. I don't think --graph highlighting is in the cards, though, unless we do something barbaric like force color.ui=always and highlight the ansi escape sequences directly.

See also https://github.com/tpope/vim-fugitive/issues/1415 for a recent change that may prove helpful.

robin-snt

comment created time in 7 days

issue commenttpope/vim-fugitive

`:Git diff` with diff-highlight?

Git's --paginate is essentially "disable Git's own pagination and just use the system default", which makes it a perfect fit for forcing a temp buffer. We're the system, in a manner of speaking, and a temp buffer is how we paginate. And with that behavior in place, I've experimentally enabled :terminal for any command with a custom pager configuration. Let's see if it breaks anything for anybody.

riceissa

comment created time in 8 days

push eventtpope/vim-fugitive

Tim Pope

commit sha cb1300d7517b7110ec94ac22d1bb65e06391ab7b

Deprecate :Gsplit! family in documentation

view details

Tim Pope

commit sha a81ba999e8a48e4b86beef84714ad4ad3dd1ff84

Correctly treat config keys without values as true

view details

Tim Pope

commit sha 2e67f82b79dac66fb7eea1ed2ca4881a5f265568

Refine handling of pagination via temp buffer Use temp buffer for output of any command for which the Git configuration option of pager.<command> is true. Avoid using a temp buffer if the value is false, even for commands like "show" where we normally would. If the configuration value is present and can't be interpreted as a Boolean, punt to a :terminal where Git will invoke it directly. Generate and use custom config dictionary that includes -c values passed to :Git. This enables `:Git -c pager.status status` to correctly use a pager. Paginate "config", "branch", and "tag" for certain argument lists, matching the logic found in the Git source code as closely as possible. These 3 commands were identified as having special pagination logic by the presence of the DELAY_PAGER_CONFIG flag on their definitions in git.c. Paginate "am --show-current-patch". References https://github.com/tpope/vim-fugitive/issues/1415

view details

push time in 8 days

push eventtpope/vim-fugitive

Tim Pope

commit sha d10dc9ea93428acc11c54aa22b985c6392ff897c

Quarantine deprecated commands in documentation

view details

push time in 8 days

push eventtpope/vim-fugitive

Tim Pope

commit sha 2401f1a7da95f1185d50c2ba0bfe39d5bad3c90c

Work around minibufexpl/autochdir induced error Closes https://github.com/tpope/vim-fugitive/issues/1456

view details

push time in 8 days

issue closedtpope/vim-fugitive

Gblame in conflict with minibufexpl

I have both fugitive and minibufexpl(fholgado/minibufexpl.vim) installed. When running Gblame they two seems to run into compatibility issues and yield the follow error:

Error detected while processing function fugitive#Command[25]..<SNR>61_BlameSubcommand: line 183: E201: *ReadPre autocommands must not change current buffer

I opened vim's debug logging and the relevant log is below:

Calling shell to execute: "(git -C /root/tensorflow-upstream --literal-pathspecs --no-pager -c 'blame.coloring=none' -c 'blame.blankBoundary=false' blame --show-number --contents - -- tensorflow/core/kernels/conv_ops.cc > /tmp/verC6g6/3.fugitiveblame 2> /tmp/verC6g6/3.err) < /tmp/verC6g6/4" Executing ShellFilterPost Autocommands for "*" autocommand call fugitive#ReloadStatus(-2, 0)

[sy:git] Updating signs. [sy:git] sy#repo#get_diff() Reading viminfo file "/root/.viminfo" marks not found in 'runtimepath': "syntax/minibufexpl.vim syntax/minibufexpl/.vim" not found in 'runtimepath': "indent/minibufexpl.vim" not found in 'runtimepath': "ftplugin/minibufexpl.vim ftplugin/minibufexpl_.vim ftplugin/minibufexpl/*.vim" [sy:git] Update is already in progress. [sy:git] Update is already in progress. Error detected while processing function fugitive#Command[25]..<SNR>61_BlameSubcommand: line 183: E201: *ReadPre autocommands must not change current buffer --- Signs ---

From the log it looks like the Gblame command requires a implementation of sytax/indent/ftplugin of another (minibufexpl), therefore I'm filing as an issue here.

To reproduce, install both plugins, and run Gblame.

closed time in 8 days

jerryyin

issue commenttpope/vim-fugitive

Gblame in conflict with minibufexpl

So minibufexpl is, and I say this without exaggeration, the worst plugin in all of Vim history. It abuses autocommands in all sorts of extremely fragile ways that routinely break other plugins. Whenever I see an autocommand or window related bug report, on any plugin, I always reply with "try disabling other plugins", and minibufexpl is the reason I do so. Thank goodness it's popularity declined after Vim got tabs or I probably would have quit the industry by now. (It's possible the fork is better behaved than the original. It's certainly not worse behaved, that would be impossible.)

Meanwhile, this is from the documentation for 'autochdir':

Note: When this option is on some plugins may not work.

Knowingly or not, you've combined the world's most broken Vim plugin with the world's most broken Vim option. Fugitive never had a chance.

I'm going to try moving 'buflisted' to BufReadPost, but if that causes other problems, I will not hesitate to revert. Until proven otherwise, this is a minibufexpl bug, not a Fugitive bug.

jerryyin

comment created time in 8 days

issue commenttpope/vim-fugitive

`:Git log --oneline --decorate --graph --all` stopped showing colours on neovim.

The following relevant changes have happened since roughly the time when this issue was created.

  • :Git foo now effectively equivalent to :Gfoo when the latter exists. For example, :Git push calls :Gpush, and :Git commit calls :Gcommit. This is the "subcommand special casing" I was referring to, and for now, it remains a private interface.
  • A few chatty commands, notably :Git log, now force a temp buffer like :Git!, even if a bang wasn't given. This also falls under "subcommand special casing".
  • Commands are now global. This means you can change autocmd User Fugitive command! -buffer -bar to command! -bar.
  • I thought --paginate was a no-op for commands that already paginated, but it actually replaces Git's configurable pagination with a dumb call to PAGER. This makes it a terrible fit for a general :terminal flag, and a great fit for doing custom pagination of our own inside of Vim, so that's what it does now. It's the same behavior as :Git! and intended to ultimately replace it. I haven't decided what, if anything, should provide the old :terminal behavior.
  • All public functions are documented as inline comments in plugin/fugitive.vim. Related: :terminal on Vim 8.1 (not Neovim) takes an argument list, not a shell command, so you'll need to do something like exe 'terminal' &shellcmd &shellcmdflag fnameescape(FugitivePrepare(...)) for it to work there.
  • (This one is brand new.) :Git no longer uses :! but rather a custom job based runner. This runner is capable of handling file edits, so commands like :Gcommit - which previously needed to do all sorts of shenanigans to edit the commit message - have been reduced to simple stubs that delegate to :Git. The general purpose nature of this change mean I no longer see much of a reason for "subcommand special casing" to become a public interface.
  • (This one is coming soon.) Old wrapper commands like :Gcommit and :Gpush are now softly deprecated in favor of using the :Git equivalent.

I am 100% convinced at this point that the fundamental issue here is syntax highlighting. If you want to continue to work around it with :terminal, I won't try to stop you, but I don't really see that as a compelling justification to bake in support for it.

robin-snt

comment created time in 8 days

pull request commenttpope/vim-fugitive

Fix Trailing Characters Invalid range error for :<count>Gstatus

Good catch, thanks!

woodstok

comment created time in 8 days

push eventtpope/vim-fugitive

Appu Joseph

commit sha 81ca98d7e8498d63383f5a4ca6cee2a07dff24c7

Fix Trailing Characters, Invalid range error for :<count>Gstatus Correct the position of newly added keepalt option from 'botright <count>keepalt split' to 'botright keepalt <count>split'

view details

push time in 8 days

PR merged tpope/vim-fugitive

Fix Trailing Characters Invalid range error for :<count>Gstatus

Correct the position of newly added keepalt option from 'botright <count>keepalt split' to 'botright keepalt <count>split'

+1 -1

0 comment

1 changed file

woodstok

pr closed time in 8 days

issue commentneovim/neovim

Complete falling apart of fugitive in neovim

Restore that throw and change it to a echomsg so you can see what command is being run next time you catch it in action.

mcepl

comment created time in 9 days

issue closedtpope/vim-fugitive

Is it possible to create tags in my repository?

What command I must use? There is no Gtag or similar command.

closed time in 9 days

ont

push eventtpope/vim-fugitive

Tim Pope

commit sha 9f6901942427bb1fadc18524dbdbbeb382c61654

Partially support :Git difftool on old Git

view details

Tim Pope

commit sha 9bbbb65888293f6d6a4da55bc8b0d8907ba779d4

Add capitalized versions of non-standard commands The long term goal is to use :Gsomecommand for commands that wrap Vim built-ins (e.g., :Gedit for :edit), :Git some-command for commands that wrap Git built-ins, and :GSomeCommand for everything else. For :GRemove, :GDelete, :GMove, and :GRename, this gives us symmetry with eunuch.vim, and for :GBrowse, this gives us symmetry with a hypothetical :Browse command that I've long wanted to make a plugin for but probably never will. :GcLog and :GlLog get their names because they match Vim's :c and :l prefixes but bring their own custom suffix. This is rather unsatisfying and I may change it if something better comes along.

view details

push time in 9 days

issue commenttpope/vim-fugitive

Is it possible to create tags in my repository?

:Git tag. All Git commands can and should be called like this; wrappers like :Gcommit and :Grebase are softly deprecated. Documentation updates are forthcoming.

ont

comment created time in 9 days

push eventtpope/vim-fugitive

Tim Pope

commit sha 98f67310aa3ae324d725a3b6b68a63e5a48372f4

Parameterize subcommand Git executable

view details

push time in 11 days

issue commenttpope/vim-fugitive

Allow to diff in a new tab on diffing in :Gstatus

I want to retool maps such that the big leader keys like d and c bring up an interactive popup window, and until that happens, I'm not really interested in continuing to pile onto the existing mess. I recommend implementing such a map locally using autcocmd User FugitiveIndex.

lourenci

comment created time in 12 days

issue commenttpope/vim-fugitive

Stage visual selection (add -p)

I guess what is missing here is on the GStatus window when i open the file with enter i just enter a the fugitive diff mode and then stage the chunks from them?

You can do this in one step by pressing dd on the file.

As a current workout around just press I on the status file right?

That's less of a workaround and more of an alternative workflow, and as far as alternative workflows go, I'd sooner recommend pressing =.

gilligan

comment created time in 12 days

issue commenttpope/vim-fugitive

Can't :Gcommit because of 'invalid key'

That commit had some junk in it that was reverted. Try df3ac9d278c13e06888e0270ae7296377ec05ee7 (last good commit?) and e144a9f55986317a0c1dd78bb83748396d0a7e5e (first bad commit?).

tankorsmash

comment created time in 13 days

issue commenttpope/vim-fugitive

Can't :Gcommit because of 'invalid key'

#1433 fundamentally changed how :Git worked.

You might have luck upgrading to Vim 8.1.0902 or newer, as that allows passing in environment variables rather than needing to construct a shell command.

tankorsmash

comment created time in 13 days

issue commenttpope/vim-fugitive

Can't :Gcommit because of 'invalid key'

All of this sounds like you have 2 different UNIX environments installed and they are interacting badly.

tankorsmash

comment created time in 13 days

issue commentneovim/neovim

'env' job option overrides variables incorrectly, broken for pty jobs

Can we mark patch 8.2.0239 as included once this is resolved? Not the exact same thing but I do believe it is a proper subset.

tpope

comment created time in 13 days

issue commenttpope/vim-fugitive

Can't :Gcommit because of 'invalid key'

How did you install Git? This sort of error can happen when you do something weird like mix a Cygwin Git with cmd.exe (to name just one of many examples).

tankorsmash

comment created time in 13 days

issue commenttpope/vim-eunuch

SudoWrite not working in neovim

It works if you have $SUDO_ASKPASS set, or Path askpass configured in /etc/sudo.conf.

eskinderg

comment created time in 13 days

issue commenttpope/vim-rails

add :Rfactory command for test/factories/**/*.rb

:Efixtures opens factories now. Spread the word.

sunaku

comment created time in 13 days

issue closedtpope/vim-fugitive

Fascist tag line

'so awesome, it should be illegal'

The law is not set by man; only fascist desire to set the law. This is quite the fascist statement. Just saying.

closed time in 14 days

lifranc

issue commenttpope/vim-fugitive

Fascist tag line

Funny guy.

lifranc

comment created time in 14 days

issue commenttpope/vim-fugitive

A command for force pushing

You can also create, say, a pushf alias in your Git config and then :Git pushf or :G push will call it. (:Gpush is softly deprecated in favor of :Git push or :G push.)

mrded

comment created time in 14 days

issue commenttpope/vim-fugitive

diffing loaded json file just diffs with itself

This is the exact behavior you get if you call :Gdiffsplit on a path that belongs to a repo but lives outside of it (for example, a temp file generated by :Git --paginate). Does the file have a weird name? Are there symlinks involved in anything you are doing?

gfixler

comment created time in 15 days

issue commenttpope/vim-fugitive

diffing loaded json file just diffs with itself

Try all of the following in the JSON buffer and report back on which work:

  • :Gdiffsplit
  • :Gdiffsplit!
  • :Gdiffsplit :0
  • :Gdiffsplit! :0
  • :Gdiffsplit :0:%
  • :Gdiffsplit! :0:%
  • :Gdiffsplit HEAD
  • :Gdiffsplit! HEAD
  • :Gdiffsplit HEAD:%
  • :Gdiffsplit! HEAD:%
gfixler

comment created time in 15 days

issue commenttpope/vim-fugitive

diffing loaded json file just diffs with itself

What does "loading the same file twice" mean? Are you saying that it's the same buffer, with the same bufname('') and the same bufnr(''), or are you saying it's two different buffers with distinct bufname('') and bufnr('') values but the contents are the same?

What is "d, gh, or gv"? I'm guessing you mean dd, dh, and dv but that's meeting you more than halfway.

gfixler

comment created time in 16 days

push eventtpope/vim-dispatch

Leandro Lourenci

commit sha 3757ddad87073a6ded8c34dfabb28c325acf6c02

Make iTerm strategy to work with vimr

view details

push time in 16 days

issue commenttpope/vim-unimpaired

Add support for cabove/cbelow

If it's scoped to the current file then yeah, we probably shouldn't replace the existing mappings. Linter warnings is also my use case, but that means :labove and :lbelow, which is a bit of an odd thing for Unimpaired to express a preference on.

cbows

comment created time in 16 days

issue commenttpope/vim-unimpaired

Add support for cabove/cbelow

These are cool but I'm not sure where they would fit. It's tempting to swap them out for :cnext and :cprevious but I think it's a bit too soon for that.

cbows

comment created time in 16 days

issue commentneovim/neovim

Complete falling apart of fugitive in neovim

So it's working fine, you just didn't pull before reporting a bug.

mcepl

comment created time in 16 days

issue commenttpope/vim-fugitive

:Gstatus buffer shows binary data

gq isn't the only sanctioned way to close the buffer so this wouldn't really fix anything, just sweep it under the rug.

Does :edit in the :Gstatus buffer without :bwipeout fix it? If not, what are the first few lines of :9verbose edit? I'm expecting to see Executing BufReadCmd Autocommands for "index{,.lock}".

PhilRunninger

comment created time in 17 days

issue commentneovim/neovim

Complete falling apart of fugitive in neovim

Try with echo "GIT_EDITOR is '${GIT_EDITOR-unset}'" to see if it's unset or an empty string.

After this line, add a throw string([argv, jobopts]) and see what's in the error message.

https://github.com/tpope/vim-fugitive/blob/0e6f72b005312225ffb47290500941d59eb1f0f7/autoload/fugitive.vim#L2439

mcepl

comment created time in 17 days

issue commenttpope/vim-fugitive

error: cannot apply binary patch to '...' without full index

Is the issue happening for hunks in both .vim/spell/en.utf-8.add and .vim/vimrc? I'm trying to assess if the order of the files in the diff matters.

soylent

comment created time in 17 days

issue commentneovim/neovim

Complete falling apart of fugitive in neovim

@teto I don't think much has changed that would affect :Gdiffsplit but if you can't figure it out open an issue.

mcepl

comment created time in 17 days

issue commentneovim/neovim

Complete falling apart of fugitive in neovim

Create the following .git/hooks/pre-commit

#!/bin/sh

echo "GIT_EDITOR is '$GIT_EDITOR'"
exit 1

What does :Git commit display?

mcepl

comment created time in 17 days

issue commenttpope/vim-fugitive

error: cannot apply binary patch to '...' without full index

The exact command we run is git diff --color=never --no-ext-diff --no-prefix; what does that look like?

soylent

comment created time in 18 days

issue commenttpope/vim-fugitive

error: cannot apply binary patch to '...' without full index

What does the git diff for this binary file look like?

soylent

comment created time in 18 days

Pull request review commenttpope/vim-dispatch

Use v:echospace to avoid hit-Enter prompts

 function! s:postfix(request) abort   return '(' . a:request.handler.'/'.(!empty(pid) ? pid : '?') . ')' endfunction +function! s:echo_without_hitenter(msg, suffix) abort+  if exists('v:echospace')+    if strwidth(a:msg.' '.a:suffix) > v:echospace+      let msg = printf('%.*S...', v:echospace - 3 - len(a:suffix), a:msg)+    else+      let msg = a:msg+    endif+    echom msg.' '.a:suffix+    return+  endif++  redraw+  let suffix_len = len(substitute(a:suffix, '.', '.', 'g'))+  let max_cmd_len = (&cmdheight * &columns) - 2 - suffix_len - 2++  if has('cmdline_info')+    let last_has_status = (&laststatus == 2 || (&laststatus == 1 && winnr('$') != 1))++    if &ruler && !last_has_status+      if empty(&rulerformat)+        " Default ruler is 17 chars wide.+        let max_cmd_len -= 17+      elseif exists('g:rulerwidth')+        " User specified width of custom ruler.+        let max_cmd_len -= g:rulerwidth+      else+        " Don't know width of custom ruler, make a conservative guess.+        let max_cmd_len -= &columns / 2+      endif+      let max_cmd_len -= 1+    endif+    if &showcmd+      let max_cmd_len -= 10+      if !&ruler || last_has_status+        let max_cmd_len -= 1+      endif+    endif+  endif++  let msg_len = len(substitute(a:msg, '.', '.', 'g'))+  if msg_len > max_cmd_len

Character length rather than byte length.

blueyed

comment created time in 18 days

pull request commenttpope/vim-dispatch

Use v:echospace to avoid hit-Enter prompts

If I was going to do it myself I would have done it myself rather than explicitly requesting changes.

blueyed

comment created time in 18 days

PR closed tpope/vim-fugitive

add rk and rx keymap into rebase maps of help

https://github.com/tpope/vim-fugitive/blob/0e6f72b005312225ffb47290500941d59eb1f0f7/autoload/fugitive.vim#L5879-L5881

+2 -1

1 comment

1 changed file

hitsuji-no-shippo

pr closed time in 19 days

pull request commenttpope/vim-fugitive

add rk and rx keymap into rebase maps of help

These aren't official and are deliberately undocumented.

hitsuji-no-shippo

comment created time in 19 days

issue commenttpope/vim-rails

:Rake on test file with binding.pry debug can not work in Neovim

This isn't vim-test.

lingceng

comment created time in 19 days

issue commenttpope/vim-rails

:Rake on test file with binding.pry debug can not work in Neovim

With dispatch.vim and vim-dispatch-neovim, you can use :0Spawn to run the current file's test in a terminal, or :.Spawn to run the test under the cursor.

lingceng

comment created time in 19 days

issue commentneovim/neovim

Complete falling apart of fugitive in neovim

$GIT_EDITOR (which Fugitive sets) should take precedence over $EDITOR but you should definitely double check that isn't a contributing factor.

mcepl

comment created time in 19 days

issue commentneovim/neovim

Complete falling apart of fugitive in neovim

Verify you can reproduce with no other plugins installed and a default nvim config and open a Fugitive issue if so.

mcepl

comment created time in 19 days

issue commentneovim/neovim

Complete falling apart of fugitive in neovim

You're saying :echo $GIT_EDITOR is blank?

mcepl

comment created time in 19 days

issue commentneovim/neovim

Complete falling apart of fugitive in neovim

This screams #11751 plus $GIT_EDITOR. There's no good reason to set $GIT_EDITOR, stop doing it.

mcepl

comment created time in 19 days

issue closedtpope/vim-fugitive

precommit hook show terminal escape characters in output

I'm using some npm packages for precommit linting (husky and lint-staged).

lint-staged attempts to rewrite characters in place in the terminal by using escape characters, is there anyway i can get the fugitive window that precommit output shows in to either support or drop these escape characters?

image

closed time in 20 days

NickyTope

issue commenttpope/vim-fugitive

precommit hook show terminal escape characters in output

Dupe of #1446. Fixed in https://github.com/okonet/lint-staged/issues/781.

NickyTope

comment created time in 20 days

PR closed tpope/vim-liquid

Create README.md
+13 -0

3 comments

1 changed file

andyk

pr closed time in 20 days

pull request commenttpope/vim-liquid

Create README.md

  1. That line is wrong, yes.
  2. This isn't a "vim-pathogen plugin", it's a Vim plugin, full stop.
  3. It's not really even a plugin, it's a collection of runtime files.
  4. These runtime files are included with Vim; the README should note that and advise users that installation generally isn't necessary.
  5. This doesn't match the style and tone of my other READMEs.

If someone really cares about adding a README, https://github.com/tpope/vim-haml is as good of starting point as any.

andyk

comment created time in 20 days

issue commenttpope/vim-fugitive

Gblame in conflict with minibufexpl

Do you have any configuration options set for minibufexpl? How are you opening its window, if at all?

jerryyin

comment created time in 20 days

IssuesEvent

issue commenttpope/vim-fugitive

Gblame in conflict with minibufexpl

I still need a way to reproduce this. Does this happen with only Fugitive and minibufexpl installed? Your debug log suggests you had other plugins installed.

jerryyin

comment created time in 20 days

pull request commenttpope/vim-fugitive

Fix typo --include-index to --keep-index in help

Thanks!

hitsuji-no-shippo

comment created time in 21 days

push eventtpope/vim-fugitive

hitsuji no shippo

commit sha 460664018a8eaecd89fb2b095fad59c0e16f5f06

Fix typo --include-index to --keep-index in help

view details

push time in 21 days

PR merged tpope/vim-fugitive

Fix typo --include-index to --keep-index in help

https://github.com/tpope/vim-fugitive/blob/0e6f72b005312225ffb47290500941d59eb1f0f7/autoload/fugitive.vim#L5858

+1 -1

0 comment

1 changed file

hitsuji-no-shippo

pr closed time in 21 days

push eventtpope/vim-fugitive

Tim Pope

commit sha e144a9f55986317a0c1dd78bb83748396d0a7e5e

Extract helper for setting job environment

view details

Tim Pope

commit sha 0e6f72b005312225ffb47290500941d59eb1f0f7

Allow custom subcommands outside of Git repository

view details

push time in 21 days

push eventtpope/vim-fugitive

Tim Pope

commit sha a95972cefc8c6bc4ea5f7798f1462dda3d1f4709

Don't clobber alternate buffer on :Gstatus

view details

Tim Pope

commit sha 3c45ed0d138f57ff5bfa590520f354191be5f51a

Fix false positive on deprecated :.Glog usage

view details

Tim Pope

commit sha df3ac9d278c13e06888e0270ae7296377ec05ee7

Enable opening arbitrary URLs with :Gbrowse This is still doing a lot of unnecessary processing looking for a remote, but it doesn't seem to hurt anything.

view details

push time in 21 days

issue closedtpope/vim-fugitive

[neovim] Warning messages are sometimes flushed to commit message buffer

I'm using neovim v0.4.3.

In :GStatus, I pressed C (which is deprecated now) and this happened:

image

It's not deterministically reproducible, but it looks like the default content for that buffer and the warning message are mixed up.

I know that C is deprecated, but the message still shouldn't be there.

closed time in 21 days

jaekyeom

push eventtpope/vim-fugitive

Tim Pope

commit sha 18582f4986eb3c43f259b3f05ba2e1300833305c

Remove deprecated C map to fix broken warning https://github.com/tpope/vim-fugitive/issues/1458

view details

push time in 21 days

issue commenttpope/vim-fugitive

[neovim] Warning messages are sometimes flushed to commit message buffer

Seems like this is incompatible with the new :Git. Luckily there's an easy fix.

jaekyeom

comment created time in 21 days

issue closedtpope/vim-fugitive

fugitive makes vim start very slowly

When the vim fugitive package is installed on a Linux system with autofs-mounted home directories, vim starts slooooowly. Running strace on the process shows that it is calling lstat() on paths like "/home/HEAD" and "/home/.git". These directories don't exist, there are no users named "HEAD" or ".git", but it takes a while for the automounter and NFS system to figure that out, and error out the lstat() call. It adds up to ... a ... frustrating ... experience ... every ... time.

Searching around it seems like similar problems have been reported in other environments, and someone has figured out that fugitive is walking the directory tree upwards looking for the metadata of a git repository. One suggestion I found somewhere was to hack the plugin to get it to stop a the user's home directory.

Besides being frustrating, I'm concerned that this a security problem. What would fugitive do if it found a /home/HEAD or /home/.git directory? What could a trickster with control of the home directory server make fugitive plugins do if they put directories in place with those names and crafted their own special contents for them?

With regard to git itself, "git status" runs very quickly, even in paths that are not inside git projects. The error message is

$ git status fatal: not a git repository (or any parent up to mount point /home) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

so that would seem to explain the algorithm it's using: don't cross file system boundaries unless that variable is set.

closed time in 22 days

cannon-zz
more