One file in Defs list not using new Functions only setting.

[ted]

The first time I opened SE 18 the file that came up in the edit window had everything (#define(), #if(), const(), etc) displayed in the Defs window. I right clicked and went to Quick filters and selected Functions only. The file in the edit window still showed everything in the defs window. When any other file in the defs window is expanded only the functions are listed. I closed the first file. Then closed and opened SE. Then dragged the first file name from windows explorer back into SE. The file still has everything displayed in the Defs window. All other files are fine and only show the functions. It is only the first file that SE displayed in the edit window when SE was started for the first time. The new Functions only setting is not being used for this file.

Ted

[Dennis]

Make sure the file came up in the correct document mode.  If it is an extensionless file, maybe it was recognized as something that it was not.

Also, do you have statement tagging turned on for that file?

[ted]

It is a .c file like the others I use. The file works fine in SE 17. After looking at this some more I noticed a few things. The code is from a third party and does some things differently than I normally do. I will experiment around and see if I can come up with a simple example file that shows some of the things I am seeing.

[ted]

Dennis,
Attached is an example file that shows the problem. Has something to do with inline function. Delete the inline function from the file and file looks good in defs window.

Ted

[Dennis]

The problem seems to be on account of the embedded assembly language.

If you associate the ".s" extension with "Plain Text" instead of "IBM HLASM" (Tools > Options... > Languages > File Extension Manager), the tagging issue goes away.  It looks like the IBM HLASM parser is misbehaving when it is asked to parse embedded code sections.

Thanks for the very good example.

[Dennis]

I only suggested "Plain Text" as a workaround, it would be better to associate ".s" with "Unix Assembly"

[ted]

I associated .s with Unix Assembly and that fixed it. I did not realize when SE sees the asm keyword it would then use the .s rules. It does make sense to do that.

Thanks,
Ted

[Dennis]

It uses assembly language rules to parse for symbols (and color code) the embedded assembly only.  It looks like there is a bug in the IBM HL/ASM parser, which caused it to overstep the embedded boundaries.