Wishlist: do not ALWAYS behave as if format string ends with whitespace.

hlafarge commented 7 years ago

Hi!

First let me provide you with the usual praise for your wonderful 'logview' package, I've been long wishing for something similar, and was more than delighted when discovering it actually existed!

Now for the complaining part :-) Well, it's not really a complaint, but a question rather.

I'm using logview to parse logback generated files but with a slightly specific/unusual format, in that log lines are using '|' as a field separator rather than space characters.

Here is an example:

I've been able to make it work almost using the following customized definition for logview-additional-submodes:

my only remaining problem using that definition seems to come from the following lines in logview.el:

;; Always behave as if format string ends with whitespace. (unless (string-match "[ \t]$" format) (push "[ \t]+" parts))

when commenting out those two lines, i get logview to recognize my log files content allright.

Not sure if there is another way to achieve my goal, or if maybe you could make a change to allow for not 'always' behaving as if format string ends with whitespace.

Kudos again for the fantastic module!

doublep commented 7 years ago

I guess a possible solution is to add MESSAGE placeholder. If it is not present, it is added automatically with whitespace in front (i.e. as now). But you can also specify it explicitly if you need control over separator in front of it. However, MESSAGE would always need to be at the very end in the format string.

I don't want to make backward-incompatible changes, because your usecase sounds more like an exception than the norm.

That should achieve what you need, right?

hlafarge commented 7 years ago

I'm not sure i understand what you mean here.

I tried using the following:

with the untempered version of source code for logview.el, but that did not work. Is that what you meant, or did i misunderstand you.

I could not see any obvious trace in the sources of that special MESSAGE placeholder you're referring to, so i guess i'm missing something here.

Could you please enlighten me ?

doublep commented 7 years ago

It's not implemented yet. I just meant "a possible solution" would be to implemented this MESSAGE placeholder.

hlafarge commented 7 years ago

Ah sorry, i did not understand you properly. But i do now.

For sure that would be a perfectly valid solution as far as i'm concerned.

I only suggested lifting that 'always assume spaces' assumption because i did not understand the reason for it, but i guess there must be one of course.

doublep commented 7 years ago

The reason is that it is valid in most cases, but it is very easy to forget adding a space at the end of format string, not to mention that you don't even see if it's there or not.

hlafarge commented 7 years ago

makes perfect sense. As long as there is some way to 'undo' that helping assumption if needed, it's all just fine by me. And for sure, finding one that does not backward breaks things is best.

hlafarge commented 7 years ago

Just wanted to let you know that your enhancement just did the job for me.

Mucho thanks for it!

doublep / logview

Wishlist: do not ALWAYS behave as if format string ends with whitespace. #16