On Fri, Jul 29, 2011 at 11:20 AM, SegundoBob <[email protected]> wrote:
> Until recently, the position-visited-list was truncated by add-new- > position-to-list (method update()) to the current position (i.e., > beadPointer) whenever the "next" or "previous" buttons had been used > to navigate to a previously visited position. This truncation was > removed (using an "if 0") with the comment "This makes no sense." I'm pretty sure I did this. > While this slow, small leak is unlikely ever to be a practical problem > for anyone. A huge list is not very useful. Because of unlimited undo, *nothing* (that is, no data) is *ever* deleted while Leo is running. You could call this a *large* memory leak. > I think making the list > a 36-entry circular buffer (that overwrites the oldest entry) would be > appropriate. I suggest 36 because this would make it the same size as > the "Recent Files" list. The "Recent Files" menu has 36 entries > because it uses 0 to 9 and A to Z as shortcuts. Hmm. Why not 42? "Answer to the Ultimate Question of Life, the Universe, and Everything". http://en.wikipedia.org/wiki/42_%28number%29 Somewhat more seriously, no positive number less than 1000 would have any effect whatever on memory usage. I would prefer to leave the list "unbounded" unless it is actually causing problems. In fact, any "smallish" number is likely to be actively confusing to the user if the limit actually gets exceeded. Best to leave well enough alone for now... Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
