On 23 Apr 2009, at 00:48, Marius Vollmer wrote:
Yes. I suspect there is still some quadratic algorithm hidden
somewhere.
I agree that Magit's slow to work with when the changesets get big,
but I'm not sure the key problem is the latency of rendering the
status buffer, and the simplicity of the current model has its
advantages. In my experience, the perceived slowness happens when one
wants to, say, unstage 2 of 100 changed files, which causes the entire
magit status buffer to be re-rendered twice. So if there were a way
to mark multiple files/chunks and then operate on them together, that
would already improve matters greatly.
As a later and separate optimisation, one could think about updating
parts of the status buffer incrementally, which would then presumably
also allow diffs to be lazily inserted into the status buffer rather
than being automatically inserted and folded away.
Yes, that sounds like a good approach. Is the "folding" thing even
useful? What about showing the diff in another buffer instead of
folding it out? It works great for small changes, in my experience,
but
I think I would prefer the SPC / DEL paging behavior for bigger
changes.
The folding feature is pretty essential in my view. It would be
*very* much more awkward to work with additional diff buffers. Plus,
it would preclude any possibility of marking hunks across several
files and operating on them together, as I've suggested above.
However, it would really be nice to have commands for collapsing and
expanding all chunks in the magit buffer at once, since (unless I'm
missing something) there's no easy way to go from having a bunch of
expanded chunks back to just the file list. Heaven (for me at least)
would be having the same folding commands/bindings as org-mode.
-Steve
