Eli Zaretskii writes: > I'm talking here about something I don't understand well enough, but > did you try computing column width using vertical-motion? No, I haven't yet tried anything in that direction. Stefan Monnier writes: >>> If you're interested in this line, I think there are two avenues to >>> improve the behavior further: >>> - align lazily via jit-lock (this way the time is determined by the >>> amount of text displayed rather than the total file size). >> Wouldn't that still depend on knowing the column widths? > > Of the whole file? No: instead you'd only use the max of the columns that > you've seen so far. When it increases (thus invalidating > alignment-overlays already created), you just "flush" those overlays and > rebuild them. Wouldn't then the columns appear to jump about whenever a new max width is discovered? I also guess you'd lose the ability to do e.g. C-u 1000 C-n and stay in the same column? > Maybe we could get yet more speedup by making it possible to pass to > `current-column` (or a new C function) a start position along with its > column, so we'd avoid re-traversing the part of the line that we've > already processed. I think that sounds like a good idea; then my ugly "fast-current-column" patch from last time won't be needed. I have no prior experience with Emacs' C internals, but an initial naive attempt is attached. I've only tested it on some basic cases where it seems to behave correctly and gives a speedup factor of around 4,5x–5x. Could this track be something worth exploring further?