gi/gI: Add cursor filename at line [count]

[ptosi]

The way fugitive_gi/fugitive_gI have been implemented implies the following 2 choices:

• choose the target file betwen .gitignore and .git/info/exclude
• choose between simply opening the file and also adding the filename under the cursor to it

To do so, the following 2 degrees of freedom were used:

• gi-gI distinguishes between "open" and "open+write"
• {count}gi-gi and {count}gI-gI distinguish between .gitignore and .git/info/exclude

which reduces [count] to a boolean flag (through its existence, not value).

Instead, I feel (possibly wrongly) that it would be more intuitive [2] to "invert" the DoFs and use:

• gi for one file, gI for the other [1];
• gi/gI for opening the file, {count}gi/{count}gI for also adding the filename under the cursor

which has the added benefit that [count] can now be used, for example, as the target line to receive the filename (remotely resembling {address}, as used by :copy).

Would it be possible to implement such mappings? Now, I understand that changing a user-facing interface like this might not be desired, in order to avoid unnecessarily confusing existing users. If this is the case and if the proposal above is sensible, would a flag toggling the behaviour of gi/gI be a considerable option?

---

• [1]: the choice between

  • gi=.gitignore & gI=.git/info/exclude and
  • gi=.git/info/exclude & gI=.gitignore

  is somewhat arbitrary but I would probably pick the former as ".gitignore" is "smaller" (as in shorter) than .git/info/exclude, just like i is "smaller" than I and gi reminds me of .{g}it{i}gnore while gI could be for .{g}it{/i}nfo/exclude.

• [2]:

  • the "target" (i or I) is symmetrically present in both commands
  • the resemblance between i and I (as opposed to {count} and ) makes it clear that those "targets" are of the same class
  • passing [count] requires "more work", just like what the mapping does and, conceptually, {count}gi/{count}gI could be seen as always adding the filename to the file at line [count] with gi/gI (no count) being the special case using the "null line" (similarly to /dev/null and "_).

[tpope]

The way fugitive_gi/fugitive_gI have been implemented implies the following 2 choices:

• choose the target file betwen .gitignore and .git/info/exclude
• choose between simply opening the file and also adding the filename under the cursor to it

To do so, the following 2 degrees of freedom were used:

• gi-gI distinguishes between "open" and "open+write"
• {count}gi-gi and {count}gI-gI distinguish between .gitignore and .git/info/exclude

which reduces [count] to a boolean flag (through its existence, not value).

The idea was that this could be extended so that 1gi added to the root .gitignore, 2gi to dir/.gitignore, 3gi to dir/subdir/.gitignore, etc. This is not a common use case so I haven't bothered implementing.

Instead, I feel (possibly wrongly) that it would be more intuitive [2] to "invert" the DoFs and use:

• gi for one file, gI for the other [1];
• gi/gI for opening the file, {count}gi/{count}gI for also adding the filename under the cursor

which has the added benefit that [count] can now be used, for example, as the target line to receive the filename (remotely resembling {address}, as used by :copy).

This isn't a bad idea, but it's a bit awkward, as you would need to input gi, return focus to the status buffer, and then input {count}gi. This assumes #1516 is implemented.

Would it be possible to implement such mappings? Now, I understand that changing a user-facing interface like this might not be desired, in order to avoid unnecessarily confusing existing users. If this is the case and if the proposal above is sensible, would a flag toggling the behaviour of gi/gI be a considerable option?

A flag is absolutely off the table. More work for me, more confusion for users. It's like if cars had an option to swap the gas and break pedals, albeit with lower stakes. Either it's good enough to justify the growing pains of replacing it or it isn't.

• [1]: the choice between

  • gi=.gitignore & gI=.git/info/exclude and
  • gi=.git/info/exclude & gI=.gitignore

  is somewhat arbitrary but I would probably pick the former as ".gitignore" is "smaller" (as in shorter) than .git/info/exclude, just like i is "smaller" than I and gi reminds me of .{g}it{i}gnore while gI could be for .{g}it{/i}nfo/exclude.

• [2]:

  • the "target" (i or I) is symmetrically present in both commands
  • the resemblance between i and I (as opposed to {count} and ) makes it clear that those "targets" are of the same class
  • passing [count] requires "more work", just like what the mapping does and, conceptually, {count}gi/{count}gI could be seen as always adding the filename to the file at line [count] with gi/gI (no count) being the special case using the "null line" (similarly to /dev/null and "_).

I made .git/info/exclude the default partially because it slotted there nicely with the count making more sense for nested .gitignore files, but also because blindly appending to the end of .git/info/exclude is perfectly acceptable as you're the only one that's going to see it, but for .gitignore, generally you want to manually organize it, so compared to that typing an extra digit isn't a big deal.

There is some good food for thought here, and perhaps it will inspire future functionality, but for now, I don't think it justifies breaking changes.