On Tue, Dec 27, 2016 at 10:01 PM, ne1uno <[email protected]> wrote: > I had opportunity to use the mercurial shelf in TortoiseHG today. > say you want to revert the working tip but don't want to commit. > you have a patch for a file or a few files and shelve them > revert update then un-shelve the patches and back in business. > Git stash works much the same way. I often "stash" code away in Leo. This usage of Leo is more flexible and easier to use than git stash. I see clamoring for multiple body's in Leo > A recent Aha, which I haven't gotten around to writing up, is that comparing body text in separate windows is usually more convenient. As a result, I have even less use for multiple body panes than before. Imo, one can make a (strong?) case for removing all that ugly code completely. what about multiple outlines? or is that already being done? > It was done many years ago, in the C++ version of Leo. The feature was called "cloned windows". It was inspired by a similar feature in (iirc) Apple's Yellow Box dev system. It was cool, but totally useless. I removed it (don't remember when) and have never ever regretted it. obviously lots of work comparing two revisions and then somehow applying > > the patches. > I have just re-read the original diff thread <https://groups.google.com/forum/#!topic/leo-editor/ZKP-X2kCc9s>. The real Aha, which came after the first post, is that @auto does work that no other diff program does, namely to *consistently* split the to-be-compared files into nodes. This is a big deal, and we should keep it in mind. Having said that, I have been having my doubts that Leoinistas would actually benefit as much as I first thought. The short form of the argument is that programmers use diffs only as reminders (when creating git checkin logs) or in emergencies (say after git bisect has found a worthy bug). Most other times, we don't think in terms of diff, or use diff. Instead, we use higher-level mental representations. > even for the one file I was working on with 3 minor changes > > I managed to lose 2 of the edits by the time I got to apply the patch. > > you can get the diffs but files can radically change as you go back in > time. > Yeah. Patches are reliable only temporarily. Ditto (I think) for git merge requests. > maybe if such a tool existed you would find ways to use it? > Maybe, but I have to be more convinced *before* I start coding. is code coverage checking a done deal in python? any language? > Yes. Googling "python coverage" yields this page. <https://coverage.readthedocs.io/en/coverage-4.3.1/> It is interesting code. In the past I've studied it, and modified it, in detail. a test outline on the left and source outline on the right > uncovered code highlighted. maybe more tests generated. > https://wiki.python.org/moin/CodeCoverage > The gui representation of diffs/coverage, is important. coverage.py generates html(!) don't forget the substantial non programmer Leo user population! > there might be a use for test driven writing? > Intriguing thought. > create an outline > then analyze the nodes, do they make sense. > going the other way, take a bunch of text and generate > headlines. is a free form text importer > > possible? useful? > Once again, we have only begun to explore what is possible with Leo ;-) Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
