I'm fine with adding a new attribute to start/end_keyword that specifies is the keyword a user keyword or library keyword. Are you interested to create a pull request? If yes, let's first agree on what the attribute should be called.

@pekkaklarck
In 2.4 of user guide it is called library keyword so it might be called:
"library_keyword" if True then it is library keyword else , user custom keyword

I am interested in pull request however it might not be so fast. Can you direct me about the place of this code piece ?

1. The type can actually be library keyword, user keyword, for loop or error. The last one occurs, for example, when a keyword that is used doesn't exist. The attribute name should thus be something more generic and the value specify the actual type. We cannot use type because it is currently used to specify is the keyword setup, teardown, for loop or normal keyword.
2. The place where to add new information to listeners is StartKeywordArguments class in robot.output.listenerarguments module. I'm not sure what is the easiest way to detect the underlying type there, though.

Are you @serhatbolsu still interested about this?

I am interested however still hard to find the time. I will try to get back to it, or you can close until a pull request comes.

Up to you

On 01 Jun 2016, at 12:42, Pekka Klärck notifications@github.com wrote:

Are you @serhatbolsu https://github.com/serhatbolsu still interested about this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #2297 (comment), or mute the thread https://github.com/notifications/unsubscribe/AHjN-i8Yy2NLS63VKuGgssYDGYUc7jGKks5qHVQPgaJpZM4HGLD6.

Making it easier to separate user and library keywords would be a good idea and it would probably be best to do it on the model object level, not only in the listener API. We could just add separate library and resource (or library_name and resource_name) attributes to keyword objects and pass that information directly to the listener. The current libname that can contain either library or resource name should probably be deprecated.

With this information added it would be enough to check does the library attribute have value or not to see is a keyword from a library or not. The resource attribute would not be set both when a keyword is from a library and when a keyword is from a test case file directly.

This kind of API changes are best done in a major release. Targeting this initially to 3.1 scope.

RF 3.1 is so long overdue that this issue has a big risk of being descoped. Comment here if you'd really like to see this in RF 3.1 and also if you'd be interested to help.

The listener v2 API still doesn't seem to separate library keywords and user keywords, but the listener v3 API has separate start/end_user_keyword and start/end_library_keyword methods since RF 7.0 (#3296). The v3 API is much more powerful and easier to use in general, so this ought to be enough.