.fstreeviewignore doesn't work as expected

[Curculigo]

The filter does not apply to files generated by an external process (such as a compiler). You need to manually run Refresh View....

This was reported by one of the ghost accounts on the Issues page, but it was dismissed.

I can confirm this issue on both Windows 11 and Windows 8.1, with the compiler being clang, invoked indirectly via objfw-compile.

[SpartanJ]

I couldn't reproduce it myself and debug it and behaved correctly. I need a complete example that explains how to reproduce it, at the very least provide your current .fstreeviewignore so at least I can verify that it's correct with the intention.

[Curculigo]

The first time you add filters to .fstreeviewignore and save, they are applied immediately. However, if new files are added or old files are regenerated, they reappear in the Side Panel. You’ll need to manually use Refresh View... to have ecode reapply the filters from .fstreeviewignore. I think it’s a code issue. The filters from .fstreeviewignore aren’t applied to newly updated files.

In your screencast, you didn’t modify the source code. You removed the obj directory instead. Please try a much simpler setup: a very simple project where both the source code and output are in the root directory. You need to actually modify the code rather than just deleting the object file or the executable. Finally, test it on Windows 11. I won’t ask you to test on Windows 8.1, but the behavior should be the same there as well.

Please try invoking the compiler directly without using any build systems. This will more closely match the behavior of the objfw-compile script. By the way, here’s the script I’m referring to:

https://github.com/ObjFW/ObjFW/blob/main/utils/objfw-compile

[Curculigo]

The setup I'm referring to is only meant to serve as the minimal reproduction. I have experienced the same issue in subdirectories as well, so I don't think it needs to be in the root directory to reproduce the issue. Additional details that I don’t think are very important: I don’t use compile_commands.json but a .clangd file, and I always run as Administrator (so my shell prompt is # instead of $).

Note: Each subdirectory has its own .clangd file. I know this is redundant since the .clangd in the root directory is used for the whole project, but I keep them nevertheless because each subdirectory is its own project.

[Curculigo]

If you have gone that far to set up MSYS2, would you mind installing https://packages.msys2.org/base/mingw-w64-objfw to test this as well?

This is a minimal ObjFW program you can try:

#import <ObjFW/ObjFW.h>

OF_ASSUME_NONNULL_BEGIN

@interface test: OFObject <OFApplicationDelegate>
@end

OF_ASSUME_NONNULL_END

OF_APPLICATION_DELEGATE(test)

@implementation test
- (void)applicationDidFinishLaunching: (OFNotification *)notification
{
	[OFStdOut writeLine: @"Hello World!"];	
	[OFApplication terminate];
}
@end

Compile it with objfw-compile -o test test.m --arc. To avoid having to deal with the color codes (as described in #778), run this in a terminal tab or the status bar terminal.

[SpartanJ]

With the latest comment I was able to reproduce it!
The secret was that the objfw-compile -o test test.m --arc does not overwrites the .o file to generate a modified event, it actually creates a test.o.tmp and then generates a move event from test.o.tmp to test.o. It should be fixed here.

[Curculigo]

To simulate the most extreme case, you can write a script to delete the *.o and *.exe files and let the compiler generate them again. To be even more certain, run the script from an external terminal emulator.

p/s: I have never tested this, though.