Wishlist: make the list of format fields (TIMESTAMP, NAME, THREAD, LEVEL) extensible

hlafarge commented 7 years ago

it would be a great feature i believe if it was possible to extend the list of fields recognized in the 'format' specification for a submode definition.

This would be especially useful in conjunction to other field related functionality such as filtering or my requested feature for allowing dynamic selection of fields to display for each log line.

I have no idea how difficult this would be to implement, but i think it would come as a nice enhancement to that already feature-rich module!

To illustrate what i'm talking about here, my current logfiles look something like:

and i'm currently using the following specification to parse them:

What i'd like to be able to do instead is to replace 'IGNORED' in the various places i'm using it with tailored field names that i would provide the needed information for, so that logview knows how to handle them properly.

doublep commented 7 years ago

logview knows how to handle them properly

That's the problem. Currently everything is hardwired to using specific fields. E.g. command bound to key 'a' always uses field NAME. Filter 'm+ ' searches field MESSAGE. Fields on their own are as good as IGNORED until you make something work with these specific fields. I presume you'd add a set of commands that additionally ask the field (by name) to work with, but would that be convenient enough?

hlafarge commented 7 years ago

That would be one aspect yes, but i think some existing commands could also be enhanced by supporting using a different field (if provided) than the one they're acting upon by default. A searching command for example could be applied to any field if specified, rather than just a specific one.

Am i making any sense here ? Of course not all existing commands would support being extended to use that work-on-any-field feature. But maybe it would be useful for some.

doublep commented 7 years ago

When you write "existing commands could also be enhanced" that falls on deaf ears, because for me the commands already work fine. If you want some features, describe what exactly you want, new commands or changes to existing commands etc. Like "I want to press button '...' and ... and ... to happen as a result". I will not necessarily implement it, or implement the way you asked, but without that it is a pointless request.

Keep in mind that existing features should not become more complicated to use, because the existing fields are exactly what I need, and what Log4j files contain by default and in 98% of cases. Requiring a prefix or maybe adding a new command is fine, making an existing command ask you for field name each time is not.

hlafarge commented 7 years ago

Fair enough. What i meant anyway was not to make any existing command more complicated than it currently is. I was thinking more something along the line: add a prefix to existing command if it has none already if one wants to specify some field other than the default one for the command, ie:

Ctrl-U

would be used when one wants to specify a different field than the default one.

But, you're right, i should come up with specific examples for what i think would be useful. And anyway, i wouldn't really mind adding new commands rather than augmenting existing ones, if you feel that's how things should be done.

I'll try to elaborate a bit with more specific examples. Thanks for you kindness and patience.

doublep / logview

Wishlist: make the list of format fields (TIMESTAMP, NAME, THREAD, LEVEL) extensible #18