Limit to N most recent entries (like the `tail` command)

[Ryan J Ollos]

Thank you for creating this plugin. I was actually thinking about this over the weekend while reviewing some log files over WebDAV. When the log file gets large, it take many seconds for it to refresh. I can go on the server and delete or move and recreate it of course, but it would be a nice feature for the plugin if it could display just the N most recent lines, so that a refresh would be quick, even for a large file. This would be analogous to using the tail command in the shell.

[anonymous]

Thank you for your request. I'll consider restricting to N lines, as you requested - but head would be easier to achieve ;) For now, you can limit the output by e.g. entering the required date (using the appropriate format) in the filter input - so it displays only entries containing the specified date.

[izzy]

OK - all done at r7042. Enjoy!

[Ryan J Ollos]

Thanks! I look forward to trying it out. It looks very good.

Although I haven't tried it out yet, based on my experience viewing log files over webdav, I wonder if it would be useful to have a default for N, such as 1000. That way, one navigates to the Log Viewer page, even with a very large log file, it will load quickly.

Just a thought ... I'll have better feedback once I test it out ;)

[Ryan J Ollos]

Replying to rjollos:

Although I haven't tried it out yet, based on my experience viewing log files over webdav, I wonder if it would be useful to have a default for N, such as 1000. That way, one navigates to the Log Viewer page, even with a very large log file, it will load quickly.

I see now that the log file is not displayed until one hits Display / Refresh, so I guess my comment does not apply. I was assuming auto-loading.

[izzy]

Personally, I don't like the whole thing to autoload. In either case, whether restricted via tail or not, the entire file has to be read (unless somebody tells me how to read it bottom-up) - so the only thing sped up is page rendering (plus you don't have too many useless lines there you are not interested in). The other reason is: If I want to apply filters, I had to wait for the autoload to finish first.

But if you like and want that, feel free to open a new ticket: a compromise would be to introduce some options to be placed in trac.ini, such as autoload = 1000 (for your example). I'd suggest, in that case, also to add options for filtering, e.g. default_level = warning and wind_up = true (i.e. include higher prios). This way, everybody is free to decide whether to use autoload or not. As for the search term, I'm not sure if an option would make sense :-)

As said: if you like to request that, please open a new ticket for that issue.