Problems with Definition search

[shusterboris]

I need search results by definition to show not only function definitions, but also their declarations in h-files(prototypes) for C language. It worked in old versions, but for OpenGrok 1.8 by default this feature is off. Vladak quite rightly told me that these are the ctags settings. I found a bad way to solve this problem :-). I replaced line 171 in Ctags.java from command.add("--kinds-c=+l"); to command.add("--kinds-c=+lpx");
Maybe someone can suggest how to achieve the same result using the options file for ctags.
And, the second, search results after changing the code not only corrects. As you can see, second line in results defines as prototype

But it is definition.

There are another discrepancies when call of function defines as declaration (prototype)
Would appreciate any advise

[shusterboris]

Is it correct? I can create options file something like:
--regex-asm=/^[ \t]*(ENTRY_NP|ENTRY|RTENTRY)+(([a-zA-Z0-9_]+))/\2/f,function/
--regex- is the language for, next part is regular expression, last group is keyword: function, variable, prototype, etc
\1 & \2 ????
Do the syntax documented somewhere.
I think this this option file can solve my question

[vladak]

These are Universal ctags options so any documentation would have to be located there.

[shusterboris]

Another issue related to this thread. Ok, when the options for tags are set in source code or by universal tag option, the web application shows the characteristics of the string: function, prototype, and so on (in the old version, in the Search object it was called TAG) But the API request http://domain/pai/v1/search? does not return the tag field in json result regardless of setting. Do you plan to add? It would be helpful

[shusterboris]

Thank you. But how can I do it? Add to ideas?

[vladak]

This is an area of OpenGrok I am not too familiar with. The tags are displayed via ContextFormatter used in UnifiedHighlighter. Specifically, they are acquired from respective Lucene Document here:

opengrok/opengrok-indexer/src/main/java/org/opengrok/indexer/search/context/Context.java

Lines 151 to 153 in ab58547

	IndexableField tagsField = doc.getField(QueryBuilder.TAGS);
	if (tagsField != null) {
	tags = Definitions.deserialize(tagsField.binaryValue().bytes);

and then ContextFormatter writes them to the page in

opengrok/opengrok-indexer/src/main/java/org/opengrok/indexer/search/context/ContextFormatter.java

Lines 343 to 349 in ab58547

	List<Tag> linetags = defs.getTags(lineOffset + 1);
	if (linetags != null) {
	Tag pickedTag = findTagForMark(linetags, marks);
	if (pickedTag != null) {
	dest.append(" <i>");
	Util.htmlize(pickedTag.type, dest);
	dest.append("</i>");

The marks list used to do the matching is built while constructing the highlighting in ContextFormatter#format() so another way has to be devised to make this work in SearchEngine used in SearchController to drive the search RESTful API. A crude way might be to parse the results for the <b> HTML tag and extract the symbols and then perform the tag matching. That method will be obliterated if #2612 is implemented, though.

[vladak]

Actually, looking at the results in SearchController#search(), the tags field is filled, so this is just a matter of remapping it here:

opengrok/opengrok-web/src/main/java/org/opengrok/web/api/v1/controller/SearchController.java

Lines 91 to 94 in ab58547

	Map<String, List<SearchHit>> hits = engine.search(req, projects, startDocIndex, maxResults)
	.stream()
	.collect(Collectors.groupingBy(Hit::getPath,
	Collectors.mapping(h -> new SearchHit(h.getLine(), h.getLineno()), Collectors.toList())));

[vladak]

PR #4391 contains the changes.

[shusterboris]

Incredible! I'm amazed at the speed of the reaction