Hi! > I personaly never use the repertoire editor because I find > PGN more universal to keep track of one's repertoire. That > you prefer to use vi to edit it, confirms to me that the > repertoire editor is not the best tool.
Well you're right, in the sense that it keeps the lines and variations. I just find the repertoir files a convenient way to display the variations. But of course I admit that the editor itself is not that nice as it should be. An ugly "feature" is that it tends to delete my comments. Also adding branches to a tree should be easier (e.g. if it would be able to "calculate" where to hook in this particular branch in the current tree). Anyway if you want to search new games for certain lines the sor-files are an easy way to keep track of the necessary searches in a concise manner and if you have a good tree there it is really a valuable help. (Admitting that it took me quite some time to get anything usable out of the repertoir editor plus the point that I have to write the sor-files with vi instead of the editor.) > But the "index all" makes sense, and should not be too > complicated to implement ... That would be nice :) > Maybe a more general way to do this would be to have a > list of "standard lines" defined in tree.tcl that covers > more openings and with more plies (currently it includes > about 100 lines, with an average of 3 moves), and it is > what is used when "fill the cache" is triggered. IMHO one main point of the repertoir files is, that I could define this tree to my needs and also the depth to my needs and outside the scid source. That's why I'd suggest to implement it there. Of course for you hacking into the tcl/tk isn't the issue, but the "normal user" (aka me ;) would rather prefer a config file (call it repertoir file or whatever) that I could keep outside the "scid binary". One point could be that one is currently interested in only a small set of openings to study and just wants to add these lines to the index of existing db's quickly but to some extensive depth. > So we could use a PGN-ified version of Scid.eco or > something like that and asks Scid to generate the cache > from it (even if the computing time will increase > somewhat). This is a good starting point, still I think it would be woth to have also a "userdefined input file" somewhere which could be used as input to add lines to the cache. IMHO the sor-files are in a way the natural source. One could also use some pgn of course and have a function like "fill cache with lines from pgn". > I will look at it. TIA :) -- Kind regards, Alexander Wagner Universitaetsbibliothek Ilmenau Langewiesener Str. 37 98693 Ilmenau Tel.: 03677/69-4521 , Fax.: 03677/69-4617 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Scid-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/scid-users
