On Wed, Apr 12, 2017 at 12:56 PM, vitalije <[email protected]> wrote:
I think it would be useful to have some list of such changes in default >> settings with the commits they were introduced and short description of the >> reason why the change happened. >> > Such changes are rare. In fact, the change to @bool check_for_changed_external_files is the only one I can think of. There are obvious reasons not to change defaults. I'm dithering about @bool check_for_changed_external_files. On the one hand, it seems unreasonable not to enable it by default. It's the expected behavior for most editors and IDE's. Otoh, there are rare performance problems with network drives. Earlier, I said it was a mistake to change the default, and it might be a bigger mistake to change it back. Now I'm not so sure. It seems bad not to enable checks by default. For those with problems with network files, setting @bool check_for_changed_external_files to False should be good enough. > When researching why some function of Leo got broken, it should be the >> first thing to check. That's at least what I have learned from dealing with >> this bug. >> > In my experience, documentation almost never helps, and is almost never up to date. > Well, as I write this I am realizing that it would be possible to just use >> git blame on leoSettings.leo to see when some settings were >> introduced/changed. Maybe we can formulate a procedure for hunting bugs >> where this check could be one of the first steps >> > We *never *want to change the defaults of settings. Ever. Imo, this is the take-away message from this experience. I have just tried to see the blame of leoSettings.leo in browser on >> github.com and it is too hard work for browser. I think that the >> @settings tree should be kept in some external file under git control. That >> way blame function of github.com would produce much smaller page. >> > An interesting idea. It's one example of the difficulty of diffing .leo (xml) files. I wasn't very familiar with git bisect functionality and it took me some >> time to find my way through. At the end I think it is not overly >> complicated. Should anyone else try to do it, here are some tips. First I >> have cloned my Leo folder to /tmp/leo-trunk (* could be any temporary >> folder). Then I made script (leo2) for launching Leo from that temporary >> location. After that I ran ```git checkout c235ff4```. That was the second >> last release (5.4.1). Then I ran leo2 and created a Leo file in >> /tmp/bug.leo with one @clean node in it. Then I made script that changes >> the content of the external @clean file. And I have tested that commit >> c235ff4 doesn't contain bug. Then I have issued following command: ```git >> bisect start``` and ```git bisect good```. After that ```git checkout >> <latest commit>``` and then again ```leo2 /tmp/bug.leo```, followed by >> executing the script to change @clean file. Leo didn't notice that file was >> changed. That is why I issued ```git bisect bad```. After that git has >> computed expected number of steps to find the problematic commit and >> automatically checked out some commit in the middle. The following steps >> were quite easy to perform: >> 1. leo2 /tmp/bug.leo #opens leo >> 2. run script to change @clean file >> 3. if Leo noticed that file was changed >> 3.1 git bisect good >> if Leo didn't notice that file was changed >> 3.2 git bisect bad >> 4. close Leo >> > I would have done something similar. But you don't have to use a temp folder. You can do the git bisect "in place", in your normal leo-editor folder. When you are done, git will leave your folder just as it was. 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.
