ProjectPlainTextFileTypeManager.getFiles() is deprecated, replacement PersistentFileSetManager.getFiles() is package private

I asked the devs. Sometimes with so many moving parts in the IntelliJ Platform, it's just human oversight.

Patrick,

I had no doubt that this was the cause. I have sympathy for the developers and support teams because I can see the pressure the rapid release schedule has created with tons of products and bundled plugins to support. It is a real problem and I hope it will eventually be addressed in a sane way.

From a user perspective, the releases are too fast, too much code churn without sufficient time for stabilization. Getting exceptions in the IDE is like the old Windows blue screen of death, nicknamed UAE - Usual Application Exit.

The rapid evolution of the IDEs also puts a strain on addressing bugs and feature requests, which directly affect the user experience and perception of the IDEs. I hope it is not a surprise that JetBrains is not known for their responsiveness in that department. It may not be fair since there is a lot of development in the products, keeping developers very busy, but a lot of these changes do not translate into improved user experience beyond the thrill you get when reading a marketing glossy.

Personally, I walked away for a couple of years when I felt the API was churning too much and I spent 80% of my plugin development time "chasing the API". I came back hoping to find that the API and IDEs have stabilized. Here is my view from two miles up:

The UI is snazzy and real eye candy, but these are IDEs, not photo-album apps. Stability and performance is crucial. The move to dynamic everything seems like it should have improved the user experience but my experience does not support this expectation.

Previous versions (2018, 2019) used to take time to come up and do all the indexing and plugin loading, but after that startup delay, everything was much faster. Now the IDE comes up fast but then you get slow downs as the dynamic loading of various features is invoked. Dynamic plugin unloading sounds good but in practice it is rarely used, when it works, and mostly when initially setting up the IDE for a project.

However, it has made the implementation and threading much more complex/error prone. It is business as usual to get exceptions for EDT thread violations, UI freezes and index corruption. And this is from JetBrains bundled plugins. You have to appreciate the complexity it adds to third party plugin maintenance and development.

Looking at the products and development as user of a black box, I get the feeling that products/development have to meet some abstract, idealistic metric(s), which do not always translate meaningfully into real world user experience. There is such a thing as going too fast with too many moving parts. 

I was born in the Soviet Union and my family emigrated when I was nine. I still have command of my Russian language and love the humour. There was a joke about a question posed to a radio station about why there was a shortage of meat in the USSR. The response was that citizens of USSR are marching towards communism so fast that the cattle can't keep up.

In the above joke, you can substitute communism with "perfect implementation", citizens with "products" and your pick of: "plugin developers", "bug fixes", "user feature requests", and/or "stability" for cattle. The joke would work as well as the original. In both cases the cause is idealistic goals and metrics, not translating to real life experience.

I love the IDEs and have sympathy for the JetBrains team. I hope someone gets to re-evaluate what and how it is being done to reduce the stress for everyone involved.

Hello Vladimir Schneider

What do you want to do ?

Hi Alexey,

What do you mean? Why do I need 

OverrideFileTypeManager.getFiles()

I need a list of plain text files in my plugin to resolve links to these files.

>I need a list of plain text files in my plugin to resolve links to these files.

You need to mark some files as plain text from your plugin? Why?

Every file with unknown extension is considered plain text, so there's no need to mark something "plain text" explicitly.

The implementation code on my end is sufficiently old but the comment reads:

// add plain text marked files, these do not show up as original extension or as plain text indexed

Unless this has changed, files marked as plain text do not show up under their extension file type so using FileTypeIndex.processFiles(type... does not process them, and they also do not show up if type is PlainTextFileType.INSTANCE.

Hence, I need to check for these files in 

OverrideFileTypeManager.getFiles()

You mean your issue is that `FileTypeIndex.processFiles(PlainTextFileType.INSTANCE)` doesn't process some files with unknown extensions, but you want it to?

Alexey,

No, not unknown extensions but files with known extensions, which have been overridden with either:

Or in the new IDEs, with OverrideFileTypeManager:

I don't have an issue with any implementation, as long as I can find a workaround. My current issue is that files marked as Plain Text do not show up in FileTypeIndex.processFiles under their associated extension file type. For example, take a .java file and override file type in current versions or make it Plain Text in older versions.

The file will not be processed for Java file type in FileTypeIndex.processFiles, nor will it be processed if Plain Text file type is passed to the method. Effectively, the only way to get those files was through ProjectPlainTextFileTypeManager.getFiles().

If the current behaviour is to have the files with overridden file type show up under FileTypeIndex.processFiles() with the overridden file type, then all is good and I can remove the old code for new IDEs. 

On the other hand if the current implementation does what the previous versions did, then I have no choice but to use OverrideFileTypeManager.getFiles() to get these overridden files, which is package private and inaccessible.

Oh, I see, the issue is https://youtrack.jetbrains.com/issue/IDEA-320027/FileTypeIndex.processFilesPlainTextFileType.INSTANCE-doesnt-process-files-marked-with-Mark-as-plain-text-or-Override-file-type

I notified the developer, you can track the progress in YouTrack by visiting the url above

An issue on YouTrack that will require making significant code changes to FileTypeIndex.processFiles, which I agree, would be the ideal solution, but realistically it will take a lot longer to be implemented (if ever) than just allowing public access to the replacement for the deprecated public ProjectPlainTextFileTypeManager.getFiles().

Thanks.