Flog v2

[rbong]

Requests for changes in v2 and feedback on planned changes welcome.

Major changes:

• Rewrite in vim9script, subsequent speed improvements
• Rewrite performance-sensitive portions of Flog in Lua
• Flog will draw the commit graph itself
• Flog will be able to position the cursor directly on the commit
• Better commit graph highlighting
• Better default format commit content highlighting
• API will be restructured
• "Command" wording will be changed to avoid naming confusion with "Vim commands"
  • "Command windows" will be renamed "side windows"
  • The "run_command()" function will be renamed "exec()"

Deprecations:

• AnsiEsc plugin is no longer required and will be removed
• Custom branch program is no longer required and will be removed
• Most of the now "public" API will be made private (still accessible, just no deprecation warnings)

Progress:

• [X] Restructure API
• [x] Implement parts in Lua
• [x] Branch drawing
• [X] Highlighting
• [x] Graph buffer commands
• [x] Exec format
• [x] Exec commands
• [x] Graph buffer settings
• [x] Side window buffer settings
• [x] Graph buffer syntax highlighting
• [x] Misc. fixes
• [x] PR for fugitive completion
• [x] Documentation
• [X] Neovim support added
• [x] Tests
  • [X] Framework
  • [x] Tests

Prerequisites for finalizing:

• [X] Vim9script finalized
• [X] Neovim vim9script support determined (not supported)

[rbong]

This is how the branch drawing currently looks. It's similar to git-forest, with straight lines prioritized over compactness, but it uses round edges and cleaner "jumps" over branches.

Let me know how this looks.

Here is a sample in text form so you can paste it into gvim/your terminal and tell me if you have any trouble with your fonts. I expect some issues, since many fonts will fall back on default fonts for these box drawing characters. I am using the Hack font with Alacritty.

╭
├─╮
│ ├
│ ├
├ │
├─◠─╮
│ │ ├
│ │ ├
├ │ │
├─◠─◠─╮
│ │ │ ├
│ │ │ ├
├ │ │ │
├─◠─◠─◠─╮
│ │ │ │ ├
│ │ │ │ ├
│ ├─◠─◠─╯
├ │ │ │
├─◠─◠─◠─╮
│ │ │ │ ├
│ │ │ │ ├
├ │ │ │ │
├─◠─◠─◠─◠─╮
│ │ │ │ │ ├

[ThomasFeher]

Looking good with font Iosevka in Alacritty.

[TamaMcGlinn]

Looks good with Ubuntu 20.04 default terminal and font.

[rbong]

I'm working on the way I draw merges with more than one target, or octopus merges.

The way git log --graph draws these is not very nice and I don't think we can get many good ideas here.

*   main
|\
| * d
| *
| |
|  \
*-. \   c Merge a and b
|\ \ \
| | |/
| |/|
| | * b
| | *
| * | a
| * |
| |/
* |
* |
|/
*
*

git-forest does a bit better job, but it leaves a fake hanging branch that doesn't go away until the commit is reached. Note that a splits into two branches, one of which is needed only for the merge. Imagine how much space would be wasted if we merged more than two branches, or if one branch was merged multiple times.

┌ main
├─┐
│ ├ d
│ ├
├ │ c Merge a and b
├─≡─┬─┐
│ │ │ ├ b
│ │ │ ├
│ ├─┘ │
│ ├   │ a
│ ├   │
├ │   │
├ │   │
├─┴───┘
├
└

We can partially solve this by drawing the merge over two lines and visually merging the fake split branch right away. It leaves an empty space, which still makes the graph unnecessarily wide, but at least that space can be filled later. I've come up with a good algorithm for filling empty spots but it still will push commits too far right too soon.

┌ main
├─┐
│ ├ d
│ ├
├ │ c Merge a and b
├─≡─┬─┐
│ ├─┘ │
│ │   ├ b
│ │   ├
│ ├   │ a
│ ├   │
├ │   │
├ │   │
├─┴───┘
├
└

Since we're using more box drawing characters, however, we don't need to leave a space.

╭ main
├─╮
│ ├ d
│ ├
├ │ c Merge a and b
├┬◠─╮
│╰┤ │
│ │ ├ b
│ │ ├
│ ├ │ a
│ ├ │
│ ├─╯
├ │
├ │
├─╯
├
╰

Here's a wider merge:

╭
│ ╭
│ │ ╭
│ │ │ ╭
├ │ │ │
├┬◠┬◠┬◠─╮
│╰┤╰┤╰┤ │
│ │ │ │ ╰
│ │ │ ╰
│ │ ╰
│ ╰
╰

Let me know what you think of this octopus merging style, if it's too compact or if you just don't like the way it looks.

Also... I am still thinking about providing an ASCII-only version, which makes this harder to draw legibly. Maybe something like this could work:

* main
|-.
| * d
| *
* | c Merge a and b
|-=-.
|\| |
| | * b
| | *
| * | a
| * |
| |-'
* |
* |
|-'
*
*

Here's a wider merge using ASCII characters, which is definitely harder to read:

*
| *
| | *
| | | *
* | | |
|-=-=-=-.
|\|\|\| |
| | | | *
| | | *
| | *
| *
*

[TamaMcGlinn]

Looks good and whatever character-drawing algo you choose in the end, I would push forward without worrying about the ASCII-only version; I don't really see the use case for that as people already have regular git log --graph.

It seems to me though that when you draw the a branch going into the merge, it is connected with a ◠ and then also with a regular connection, which seems superfluous to me. Isn't using 0x253c ┼ simpler?

╭ main
├─╮
│ ├ d
│ ├
├ │ c Merge a and b
├─┼─╮
│ │ │
│ │ ├ b
│ │ ├
│ ├ │ a
│ ├ │
│ ├─╯
├ │
├ │
├─╯
├
╰

The more common case, I would expect, is that both a and b's branches end after they are merged:

╭ main
├ d
│
│ 
├ c Merge a and b
├─┬─╮
│ │ │
│ │ ├ b
│ │ ├
│ ├ │ a
│ ├ │
│ ├─╯
├ │
├ │
├─╯
├
╰

[TamaMcGlinn]

When I was in GitExtensions, I would be looking at a commit, and it would have a list of hyperlinks for 'parents' and a list of hyperlinks for 'children'. The link itself was just the commit hash, but mouse-over would give the commit message. I realise flog's UI will be quite different but being able to meaningfully choose between the parents/children to navigate to next is what I'll be looking for in graph navigation.

[rbong]

┼ is not enough to represent every merge. In this example, d is a child of a, b, and c, but e is only a child of b.

╭ main
├─╮
│ ├ e
├ │ d Merge b and c
├┬◠─╮
│╰┤ │
│ │ ├ c
│ ├ │ b
│ ├─╯
├─╯
├ a

If we draw an ideal graph where a and c are also parents of e, we can see that if we used ┼ in the first case it would make the parents of e ambiguous.

╭ main
├─╮
│ ├ e Merge a and c
├ │ d Merge b and c
├─┼─╮
│ │ │
│ │ ├ c
│ ├ │ b
│ ├─╯
├─╯
├ a

This is not a problem specific to Flog, as I showed above both git-forest and git log --graph seek to distinguish between which branches are in the middle of the merge but continue on afterwards. Refer to the real examples at the start of my last comment.

[rbong]

Speed is becoming a bit of a concern. Parsing output is much faster in v2 than v1, but I can't hope to match the graph drawing speed of git log --graph (however it's currently always faster than git-forest, which I'm not using for comparison).

So currently at about 5000 commits with the Linux repo, v2 is marginally faster than v1 because of the parsing improvements. But at about 10,000 commits, it becomes slower because of graph drawing.

I still have to implement graph movement, which means recording more info about each commit, which means that it will get slower still. If I do implement visual graph movement, it will get much worse.

If I claim v2 is faster, I would preferably like people to have the option of displaying more than the current practical 1k-3k commit cap before it becomes slower.

Vim recommends complex plugins should be external programs that communicate with vim. Using, say, C or C++ to draw the graph would certainly make things faster, and make the nvim version easier to implement if they decide not to merge vim9script, but I know in the past people have been opposed to the idea of Flog being bundled with a new program, and this would be quite a change on top of already switching to vim9script. However, for both graph drawing and parsing speed improvements, both changes would be necessary.

The reason this would be faster than just going back to git log --graph is I could format each commit like this:

<hash>
<refs>
<visual parents>
<number of lines of output>
<output>

Whereas using any other branch viewer program, distinguishing between the graph and the commit data and then rebuilding the output takes a large amount of string processing.

Let me ask: how important is speed optimization for you? How many commits would you like to be able to see in a buffer? Are you opposed to Flog coming bundled with a program?

[TamaMcGlinn]

Neovim plugins are recommended to be built in lua because it is an order of magnitude faster. However, that would leave Vim users low and wet (being from the Netherlands, I am unable to consider 'high and dry' a bad thing).

I am not at all opposed to bundling a separate program with Flog - that's exactly how I bundled git-forest in flog-forest.

I feel that being able to navigate to parents/children at least an order of magnitude faster than flog-navigate's jk bindings would be a really significant improvement. (currently that plugin does a bunch of string processing and of course it is very slow, but I still use it)

[rbong]

Now that I think about it, Lua might be the ideal language to implement any external program in rather than, say, something like C++/Go/Rust like I was thinking.

• LuaJIT is fast
• Would be able to use any Lua functions directly in neovim if they don't merge vim9script
• Would be very fast in neovim (don't need to externally call the program and parse output)

Seems obvious now.

I have a very optimized graph drawing algorithm now though.

Current speed stats (Linux repo, max count 10,000):

Command	Time (s)
git log --graph > /dev/null	0.244
git log --graph (GPU accelerated)	0.306
git-forest > /dev/null	1.308
git-forest (GPU accelerated)	1.527
vim -c 'qa' (base time)	2.074
vim -c 'exec "Flog" \| qa' (v1 minus base time)	2.016
vim -c 'exec "Flog" \| qa' (v2 minus base time)	1.08

The fact that it's twice as fast and doing exponentially more work than v1 is great. Graph drawing is also inherently slower than git log --graph's algorithm since it prioritizes straight lines and fills empty space dynamically, not to mention we have to record more information about each commit and we are using a slower language, so I consider only being 5x slower a success, and I especially consider being faster than git-forest despite using a similar algorithm a success.

The problem is that recording any visual information makes it at least 2x as slow. Now that I have the graph drawing algorithm, though, I want to just focus on getting v2 done rather than messing around with new features and languages.

I'm thinking this might be the roadmap right now:

• Complete vim9script rewrite
• Initial release (new branch)
• Neovim support/Lua
• Visual graph navigation (should not take long)

[rbong]

Better ASCII octopus merges using L (still focusing on Unicode):

*
|-.-.
| * |
| | *
* | |
|-=-=-.
|L|L| |
| * | |
| | * |
| | | *
| |-'-'
* |
|-'
*

[rbong]

Another thing I wanted to ask about - does anyone have any issues with running git commit-graph write --reachable by default if it doesn't already exist? (It will be possible to turn this off and to turn off --reachable).

[TamaMcGlinn]

Did you know that git repositories can contain multiple root-commits, and may also contain completely separate trees? These both show up when you do a git subtree split & merge. Just something to keep in mind for your drawing algorithm.

[rbong]

There's a problem with syntax highlighting, and that's how commits either look odd when they're colored differently from the branch. If we make them the same color as the branch, they're harder to make out. This isn't a problem for git-forest because it doesn't try to highlight branches.

I would like to switch to 🞄 (U1F784, black slightly small circle) for commits.

This makes it impossible to distinguish connected commits in some cases:

 🞄 
─◠─
 🞄

So for jumps I would like to switch to ┊ (U250A, light quadruple dash vertical).

 🞄 
─┊─
 🞄

This also fixes other problems with the half circle character that was used previously.

Sample:

🞄
├─╮
│ 🞄
🞄 │
├─┊─┬─╮
│ │ │ 🞄
│ ├─┊─╯
│ │ 🞄
│ ├─╯
🞄 │
├─╯
🞄

Screenshot:

[rbong]

I realized ASCII has the same issue and now looks visually inconsistent so we can use : for jumps:

*
|-.
| *
* |
|-:---.
|L| | *
| |-:-'
| | *
| |-'
* |
|-'
*

[rbong]

Preview of branch highlighting. Just like before, it's only visually highlighting columns, since that's all vim can really do, but since we control branch drawing and straight lines have been prioritized (a branch will usually not move left/right), colors actually align to branches.

Honestly it's a bit weird seeing branches colored like this, but it is exponentially easier to track branches vertically with your eyes than git-forest, especially while scrolling.

[TamaMcGlinn]

Is there any reason the dots cannot also be colored the same as the branch? Or did you choose not to?

[rbong]

That's a choice - it makes commits more visually distinct and git log --graph does the same thing

[rbong]

Preview of commit highlighting:

Of course other date formats are still supported:

Or removing items:

The difference now is that, there won't be as many false positives. For instance, if hash, refs, or author are seen more than once, they're not highlighted:

The downside is that you can no longer put format items at the end of the line. That might change, I'm not sure yet.

There are still some false positives. Some common ones could be that if you put valid ref names at the start of a commit without refs, or if you put a valid date at the start of your commit:

However, if you put non-valid refs, or put items later on in the commit message, they won't show up:

In addition, for multiline formats, since we have more control over graph drawing, everything will only be highlighted on the first line:

[rbong]

Diff syntax now works:

You can now do diffs with -no-graph, which I believe was not possible before:

Also I have a new test system in place using shell scripts. I don't want to deal with vim9script/vim-flavor, and this will work even if some of the tests use Lua.

I consider this the "proof of concept" milestone, I now know what new features will and won't work, and I'm happy that the plan right now is solid, save if I discover some performance issue when re-implementing navigation.

[rbong]

For navigating parent and child commits, how about bindings that load parents into the quickfix/location list, and another one for children?

[rbong]

Argument parsing and log command building are done, and with that it's possible to use a very rudimentary :Flog command. I've pushed it up on the dev branch if you want to try things out. Don't expect anything to work, and expect me to rewrite git history on this branch.

Major changes to arg parsing and log command building:

• All boolean args now have both -<option> args and -no-<option> args. This lets you override your defaults for boolean options.
• Option names for bools no longer have no_ prefixes.
• g:flog_default_arguments renamed to g:flog_default_opts
• g:flog_permanent_default_arguments renamed to g:flog_permanent_default_opts
• Special characters should work better for various arguments

[rbong]

:Flog completion is done.

Changes:

• Can now use g:flog_get_authors_args to control author completion
• Format completion simplified
• Open command combinations available for completion
• Various minor completion bugs fixed

[rbong]

Finished implementing :Flogsetargs, -no-graph, and buffer name. Added automatic commit graph writing.

Other changes:

• max_count now 5000 by default

[rbong]

Added support for more date formats, supported list is now:

• human
• local
• relative
• short
• iso
• iso-strict
• rfc

[rbong]

You can now use % with -limit, ex.:

:Flog -limit=1,5:%

[rbong]

Another major milestone, finished porting the internal API for the :Flog command and the floggraph file type to vim9script. No changes to report.

[rbong]

Finished exec formatting (previously command formatting), fixed a bug with mutating the path option if it has special characters and improved support for special characters in converted items.

[rbong]

Finished :Floggit. Special characters should work better. Also, argument completion now relies more on Fugitive's own internal argument completion. If something that's useful is missing, I'll make a PR there.

[rbong]

Finished mappings.

Changes:

• Fixed typo in co<Space> mapping
• cot now col
• ' commit mark is now set only if the commit changed

With that, v2 is now fully featured.

I discovered an issue with branch drawing though. With git log --graph, if commits are filtered, parent branches that don't match will not show up.

Ex. git log --graph --grep=x86 --format="%h - %p" e8ffcd3ab0e5 -- in the Linux repo:

* e8ffcd3ab0e5 - 2afa90bd1c75 57690554abe1
* 57690554abe1 - 2f5b3514c33f
* 2f5b3514c33f - fbe618399854
* fbe618399854 - 58e138d62476
* 58e138d62476 - 2585cf9dfaad
* dcce50e6cc4d - cb8747b7d2a9

Note the last two lines - the parent of 58e138d62476 is 2585cf9dfaad, however the next commit that shows up is dcce50e6cc4d.

I don't like the way git log --graph shows this, ideally it should show that the branch has a hidden parent, something like this:

🞄 e8ffcd3ab0e5 - 2afa90bd1c75 57690554abe1
🞄 57690554abe1 - 2f5b3514c33f
🞄 2f5b3514c33f - fbe618399854
🞄 fbe618399854 - 58e138d62476
🞄 58e138d62476 - 2585cf9dfaad
┆

🞄 dcce50e6cc4d - cb8747b7d2a9

There are a couple problems with this:

• git log --graph doesn't just look at the lines in the range of --max-count, we have to look at all of the commits, which is extremely expensive the way things are now
• Even if we only go by --max-count, looking for missing parents is expensive
• The way I want to show the branch tapering off is also expensive right now

The problem with leaving it the way it is now is that the graph quickly starts filling up with branches, since the ultimate parent branches of filtered commits are never encountered.

This is going to require another round of graph drawing changes and optimizations. I haven't decided if it's time to port the graph drawing algorithm to lua yet, but it might be.

[rbong]

For now I'm not going to handle removing filtered parents from the graph.

I'm going to have to revisit this in Lua and see if I can handle it fast enough. v2 is not going to get released until the graph is drawn in Lua because of this issue.

I've been thinking about how to handle simplifying complex graphs when they get too wide in general.

I've added the gct binding to set the current rev to the commit under the cursor and clear the skip option (mnemonic: "go commit top" like "zt").

I'v also added the gcc binding to clear the current rev.

[rbong]

I implemented the graph drawing algorithm in Lua with all the changes I wanted and more optimizations. It's now comparable to the performance of git log --graph, in some cases it even outperforms it.

All tests done in the Linux repo.

Command	Time (s)
git log --graph --oneline --max-count=10000	0.242
test.lua --max-count=10000	0.304
git log --graph --oneline --max-count=100000	1.382
test.lua --max-count=100000	2.257
git log --graph --oneline --grep=x86	7.693
test.lua --grep=x86	7.384

Flog has to parse this output, but it has to do 0 string processing, so it may be even faster than gv.vim in some cases. In neovim, we don't need to even do any parsing.

[rbong]

I pushed up Lua support on the dev branch.

This relies on LuaJIT 2.1 being installed on your system.

Vim9script is still being used so it requires Vim 8 and doesn't support Neovim.

Apologies for the new prerequisites, this is just the state of the Vim plugin ecosystem.

It's quite fast, haven't found any case that's as fast as gv.vim as I had hoped but it's orders of magnitudes faster than even the last round of optimizations, to say nothing for how fast it should be in Neovim with integrated LuaJIT 2.1 support.

[rbong]

Documentation is now complete and the v2 branch has been added. I will no longer be rewriting commit history, so you can safely use this branch. This means you can now viably use v2 if you want, though it's still in alpha.

I have written a v2 Migration Guide if you which to switch now.

See also :help flog.

[rbong]

I should be done with optimizations for now. Here is an updated speed comparison.

All speed comparisons done with the Linux repo on commit fc74e0a40e4f with max count 10,000.

Vim startup time has been removed from Vim commands.

Command	Time (s)
git log --graph	0.244
vim -c GV	0.292
vim -c Flog (v1)	0.865
vim -c Flog (v2)	0.388

[rbong]

v2 is now as complete feature-wise as it's going to be until vim9script is complete or merged into neovim.

[rbong]

v2 API has changed because vim9script has changed how autoload functions are defined.

ex. flog#exec_tmp is now flog#ExecTmp. All functions have been similarly renamed.

You need the latest version of vim to use the latest version of v2.

[kevinhwang91]

v2 is now as complete feature-wise as it's going to be until vim9script is complete or merged into neovim.

Do you mean there will never be a Lua version? If yes, I feel sad, I still hope that someone can port it to a Lua version.

[rbong]

Do you mean there will never be a Lua version?

Select parts of Flog have been ported to Lua as required for speed.

There are a few reasons that it is not a pure Lua plugin.

1) There is not much advantage, in terms of making Flog easier to read and modify, by making Flog 100% Lua. The changes to vim9script make it a much better language in that regard. 2) Vim's focus is now on vim9script and job channels, not intefaces to other languages. Bram has floated around the idea of dropping some of these interfaces since they are unpopular, and I don't want to build my plugin on a low-priority system that could be dropped. 3) Flog v2's speed comes from working with LuaJIT, not with Lua. I can rely on LuaJIT in Neovim, but in Vim I can't rely on every Vim user to recompile using the flag --with-luajit. So as an alternative, v2 supports either embedded LuaJIT or LuaJIT installed on the system. This is practical to support with select parts of Flog implemented in Lua, but not the entire plugin. Were using the system-installed LuaJIT significantly slower, I would drop this idea and focus on Lua, but practically it's the same speed.

Were Vim to make LuaJIT a priority like Neovim, that would be another reason to adopt it fully. But at the moment it is not.

If you are considering porting Flog v2 to Lua, I suggest that you wait. vim9script is not even done, and Flog v2 is likely going to be restructured again once classes are implemented. Porting it now will make it more difficult to receive future changes. In addition, based on Neovim's response to vim9script, I may do it myself.

If you are using Neovim and waiting to use Flog v2, I am sorry. I hope too that this situation gets resolved soon, as I want to switch to Neovim myself once tree sitter is finalized.

If you just love Lua, I am sorry that the Vim plugin ecosystem is like this currently. Writing a pure Lua plugin for speed is just not practical currently without throwing Vim users under the bus.

[kevinhwang91]

Thanks for your sincere explanation. In fact, these two communities are dividing, but you are never biased on a community, still explain to me technically, which is hard to get.

Yes, I know Vimscript9 is unstable for now, and no plan to port Flog v2 to Lua. I am just greedy for v2 higher performance and let other Neovim users know what you thinking about Lua and Neovim here. I am neither biased on Lua nor Vimscript, I only expect the v1 is under-maintained until the communities are divided.

Finally, thanks for your contribution to the plugin. I use it almost every day.

[TamaMcGlinn]

Same here; just waiting for the speed upgrade to reach Neovim users. Thank you for vim-flog, I use it every day, for just about every git interaction I do, despite having to wait a few seconds for the flog buffer to show up - a small price to pay for such a quick and easy interface.

[rbong]

I have checked periodically on what Neovim's decision will be and I just saw they added this to their charter:

Non-goals

• Vim9script (or anything later than Vimscript v1)

This leaves us with a few different options: 1) Abandon vim9script for almost every function (parsing the output of system-installed Lua through a pipe still needs vim9script-level performance, and is Vim-only anyways). 2) Maintain one vim9script version and one Lua version. One of the reasons that vim9script is so much cleaner is to make it easier to do these kinds of transformations. 3) Go for Lua only since we practically need Lua for at least some of the speed improvements. Vim users will have to compile with --with-luajit.

The idealist in me wants to go for option 2 or 3, but practically I am leaning towards option 1. The downside here is that instead of a mostly clean vim9script or Lua plugin, Flog will be a mess of vimscript v1, Lua, and a bit of vim9script.

I consider using a compatibility layer, ie vim9jit, a non-option right now. It's a very cool project but too early to tell whether it will pan out.

If anyone has any ideas, feel free to chime in.

[kevinhwang91]

Why don't just use Lua5.1/jit to refactor? Here're the references I have seen:

https://github.com/brammool/vim9 https://github.com/henriquehbr/lua-vs-vimscript

I haven't explored the perf of vim9, but it seemly has no significant advantage compared with Lua (without jit). Lua/jit in Neovim is very stable for now, but I don't know whether Lua in Vim is as stable as Neovim. I think v2 should use Lua to refactor and the users can experience the perf improvement. If vim9 is stable and promising enough, building a vim9 layer is not late.

[rbong]

The problem with writing the entire plugin in LuaJIT is that I have to have Vim users recompile using --with-luajit, which is an unrealistic expectation. Not even I want to recompile Vim before I can use Flog on every platform.

Even if I were to make the decision to force Vim users to recompile, integrated languages in Vim have become lower-priority to vim9script and Bram has floated the idea of dropping them. I don't want to build my plugin on a system that is low priority and could be dropped.

The workaround that I am using right now is to only write speed-sensitive areas in Lua 5.1, and allowing users to use the system-installed LuaJIT.

Building a vim9script layer to Lua for the entire plugin would not be nice. The best way to build this layer is to build a server in Lua, and zero-dependency servers are not simple in Lua. So the best way I have found is to communicate with the process via pipes. Implementing the whole plugin so that it can communicate either with Neovim or with Vim through pipes would be messy, hard to debug, difficult to contribute to, and defeat the point of keeping the whole plugin to a single, nice language.

Bram has indicated that he wants to add better ways to communicate with external programs using job channels, and that could solve the problem, but that's future work. He hasn't said how that will work yet.

(Note that this is my first Lua project, so if I'm missing a better way to do a bridge between Vim and Lua let me know.)

All of this is why I am considering having both a Vim 9 version and a Lua version, rather that switching entirely to Lua and throwing Vim users under the bus. As much as I do like Lua, cutting off most of the users just so I can write the plugin in a nice language is not something I would like to do.

[kevinhwang91]

I haven't explored flog's code, why must Luajit? Lua also works fine with N/Vim. RPC also need an extra dependence, like https://github.com/RRethy/vim-hexokinase

[rbong]

LuaJIT is significantly faster than Lua, and Flog is speed-sensitive. In addition, to use an integrated version of Lua instead of LuaJIT, Vim users will be forced to recompile with Lua 5.1, which is the version of the language used by LuaJIT and by extension Neovim.

Installing dependencies with Vim plugins is possible, yes. (That is not really a third-party dependency in the case of vim-hexokinase though, it is the underlying program used by the plugin itself.)

There's another point though, which is that if I'm already going to have certain system requirements and have extra steps to install and manage dependencies, I would rather revisit the language choice than try and do something with Lua that it's not very well suited for (running a server).

[rbong]

Neovim is now supported by Flog v2.

Although it pains me to say, most of Flog v2 has been changed to legacy Vimscript to support Neovim, except speed sensitive code. This speed sensitive code is only required in Vim, so it's available in legacy Vimscript for Neovim. The idea of having a Lua version and a Vim9script version of Flog v2 was nice, but it's just not worth the maintenance cost.

Now, I will use the updated plugin for a while, and allow Neovim users to give feedback. After a while I'll release Flog v2.

[kevinhwang91]

<Plug>(FlogVDiffSplitRight) is slow in Neovim under v2 branch if the target commit is far away from the head.

[rbong]

@kevinhwang91 Trying with Linux repo on a semi-recent HEAD against the old commit 287d00d4131e.

Using dd on commit 287d00d4131e isn't slower than Git diff HEAD 287d00d4131e, or slower than git --no-pager diff HEAD 287d00d4131e > /dev/null (piping output to /dev/null because terminal output is slow), or slower than doing the same thing in vim.

Running git diff HEAD 287d00d4131e seems faster without --no-pager because the output is streamed. With vim/neovim/--no-pager the command has to finish first.

Do you have a repo/commit you can reproduce on that's slower in Flog than it is with :Git?

[rbong]

As I think about it, this actually opens up some questions with the Flog API though.

Normally you can run Git! to run commands in the background. This solves the problem because it essentially acts as a pager for vim.

But Floggit! does something different than Git!. This is a problem because Floggit is now possible to run in every buffer, not just Flog buffers. It should act the same. There should instead be a flag to update Flog, and while we're at it to run in a temp window.

Second, there is no customizing default behaviour of commands using Exec("Git ..."). Really they should use Exec("Floggit..."), in case we want to add global customization (I don't think we do yet).

Third, if Exec() bindings use Floggit, I don't think Exec() itself needs commands to update Flog and open temporary windows. There's the possibility of third-party Git commands, but I don't know of any that are a problem.