{"push_id":1009000593,"size":4,"distinct_size":4,"ref":"refs/heads/auto-maps","head":"853b7fc3b90338c26f6330c72115bbd782a5d367","before":"d58b76e759999246ee8d94fea8b829efe83cc5b1","commits":[{"sha":"717a173d18085eeae822e5b20a9ed57e1d069652","author":{"email":"06c1af6e2bb35c651c80e1859df23a1f5d6c4f97@gmail.com","name":"Brett Stahlman"},"message":"Fixing the the previous fix, which was intended to fix a bug w.r.t.\ninsertion of virtual <eob> tok, but which added its own bug: in\nparticular, it was moving cursor pos back to phantom tail\nunconditionally: e.g., even when an actual tok had been found past the\nregion! In such cases, the found tok was found twice...","distinct":true,"url":"https://api.github.com/repos/bpstahlman/txtfmt/commits/717a173d18085eeae822e5b20a9ed57e1d069652"},{"sha":"74f7881f794562807ca5b2bca84670737fa2c8d2","author":{"email":"06c1af6e2bb35c651c80e1859df23a1f5d6c4f97@gmail.com","name":"Brett Stahlman"},"message":"Fix for bleed-through logic, which was OBE at some point...\nNote that prior to this fix, the test for capping didn't really make\nsense, and was capping in cases where it made no sense to do so:\nspecifically, it would cap even when there was no whitespace between\nsuperseded and superseding tok! While this was harmless as far as\ndisplay was concerned, it resulted in useless tokens after cleanup.\n\nBackround: Recall that the original logic was intended to handle the\ncase in which removal of a superseded tok would allow preceding\nhighlighting to \"bleed through\" onto whitespace (possibly hlable by the\npreceding highlighting - think underline or bg colors). However, that\nwas an issue only when whitespace could be considered non-hlable;\ncurrently, any non-zero buffer width prevents supersedence, so we could\nalmost just do away with the bleed-through capping altogether; however,\nI've retained for one special case: a single newline (possibly\nsurrounded by tokens) comes between superseded and superseding tok.\n\nRationale: Can't position cursor between end of one line and beginning\nof next; hence, an argument can be made that this area doesn't represent\nnzwbs. Moreover, user probably doesn't really think of this area as\nretaining any sort of highlighting. If he opens a line there, he\nprobably wouldn't be surprised to find it has no highlighting. If we\nsupersede normally, an opened line would have the bleed-through\nhighlighting. Hmm... This might not actually be surprising. Probably\ndepends upon how the superseding situation was created (which we have no\nway of knowing).\nAt any rate, for now at least, I'm going to cap bleed-through in this\nscenario. TODO: Revisit...","distinct":true,"url":"https://api.github.com/repos/bpstahlman/txtfmt/commits/74f7881f794562807ca5b2bca84670737fa2c8d2"},{"sha":"9d40388e953f2903752ba7e2e74da6aafa9b779c","author":{"email":"06c1af6e2bb35c651c80e1859df23a1f5d6c4f97@gmail.com","name":"Brett Stahlman"},"message":"Enhanced debug print routine (already done on\nselectors-exp-phantoms-everywhere branch).","distinct":true,"url":"https://api.github.com/repos/bpstahlman/txtfmt/commits/9d40388e953f2903752ba7e2e74da6aafa9b779c"},{"sha":"853b7fc3b90338c26f6330c72115bbd782a5d367","author":{"email":"06c1af6e2bb35c651c80e1859df23a1f5d6c4f97@gmail.com","name":"Brett Stahlman"},"message":"Bugfix: This one's been around for a long time. Cursor was left at\nincorrect location after inserting toks on a line containing multi-byte\nchars (including pre-existing toks).\nRoot Cause: Was calculating end of line byte pos using virtcol('$');\nshould have been col('$').\nTODO: Really need to rework a lot of this logic in post Vim 7.0 era.\nFor instance, shouldn't be communicating indirect return vals with\nstatic vars.","distinct":true,"url":"https://api.github.com/repos/bpstahlman/txtfmt/commits/853b7fc3b90338c26f6330c72115bbd782a5d367"}]}