The Issue
As of right now, Cura has the option to enable fill in walls everywhere or nowhere. The problem stems from when you set this setting to nowhere and you get gaps in the walls that would be like 80-99% of a full wall, but you don't want Cura to start filling in very small sections around the rest of the print.

Fill Gap Minimum Thickness
I believe that having a Fill Gap Minimum Thickness as a percentage of the wall thickness would increase the print quality of parts, as Cura will fill parts of the wall that will benefit and not increase print time or reduce quality for parts of the wall that are very thin.
Compensate Inner Wall Thickness
Another solution to this problem could be to selectively increase the flow for inner walls to fill in the wall. This will both be more efficient to print than filling gaps in walls, as well as providing a better surface quality as Fill Gaps does not always produce a continuous line.


Describe alternatives you've considered
At the moment, changing the infill wall thickness works for removing gaps in certain areas, but allows gaps in other locations to exist where the inner wall would have fit before.

Affected users and/or printers
Everyone with an FDM printer should be able to benefit from such changes, especially those that print with 0.6mm or higher diameter nozzles where the possible gap to be filled gets larger.
My understanding is that this is a WiP situation with a feature called Arachne. I don't actually know _when_ libArachne is going to be incorporated, nor exactly how it works, but it's something they're working on and it's supposed to better handle such situations. If nothing else, CuraEngine has at least two pull requests to implement it.
Whether it makes it to 4.7, and when is 4.7 expected to release? Yeah, no idea.
In the meantime, Smartavionics has some "master" builds which use a different method of calculation that seems closer to what you're looking for (among a slew of other changes/fixes). You can find them here: https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0
I can guarantee that it won't be in 4.7. LibArachne is a fundamentally different way to handle situations like this and it should resolve this situation.
This issue is killing me also. On a large cup-like shape with walls only 4 lines thick, filling gaps everywhere resulted in so many travels and micro-extrusions that when the next layer starts the 1st couple cm of printing under-extrudes horribly. Extra prime etc did not help. But with fill gaps turned off, on some layers (probably due to curvatures and mesh variations) I get large voids between walls, in some cases rendering prints unusable.
I end up tweaking the line width and watching how it gets sliced to minimize these issues, but of course there may not be one width that works for all layers.
At a minimum it would be great to see a point release that supported "minimum gap width" setting, that should be quick and easy. It sounds like the new optimized solution is a long way off from being ready for general use.
At a minimum it would be great to see a point release that supported "minimum gap width" setting, that should be quick and easy. It sounds like the new optimized solution is a long way off from being ready for general use.
We expect it to be ready for the release after the 4.7 (so that should be ~2-3 months). So that isn't so far from now to warrant having an entirely new setting to provide a band-aid solution, sorry.
I would happily settle for a reasonable hard-coded threshold:( I've only recently come to realize how many problems this setting was responsible for. I think you under-estimate the improvements in print quality and time that such a simple change could make.
While I would love to have a smart variable line-width slicer, it seem likely to be experimental for some time. Are there any test builds to try?
Thanks
Tim
Folks, my Cura builds feature a thin wall and gap filling implementation that is quite different to the UM Cura builds. IMHO, it works a lot better than the UM builds. Hopefully, when it arrives, the Arachne based solution will work even better. Anyway, if you want to try my builds you can find them at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0. Please read the README.md file before installing/using.
Oh, I just noticed that I got a mention above, thanks @Asterchades.
I would happily settle for a reasonable hard-coded threshold
There is a hard-coded threshold associated with the Filter Out Tiny Gaps setting. A gap is considered "tiny" if it has less than 2 * (Outer Wall Line Width)虏 area. In other words, create a square with the same width as the outer wall line width, and two of those squares.
While I would love to have a smart variable line-width slicer, it seem likely to be experimental for some time. Are there any test builds to try?
Our automated build system is not yet able to create builds since we have a new dependency. I can give a build of CuraEngine for Linux but it'd also need the new settings for 4.7. Anyway, it's really not ready for a release yet. Here is a screenshot, but it's hard to see a difference here:

@smartavionics I do hope I didn't overstep any bounds by providing the link. Not sure what proper Git etiquette is on such things, especially when they're hosted externally.
We expect it to be ready for the release after the 4.7 (so that should be ~2-3 months).
Nice! I mean, maybe not so nice if you miss that window (there will always be people who mistake estimates for certainties), but I've been wondering for a while what the internal timeline for both 4.7 and Arachne might be.
@smartavionics I do hope I didn't overstep any bounds by providing the link. Not sure what proper Git etiquette is on such things, especially when they're hosted externally.
No problem, that's absolutely fine.
Most helpful comment
My understanding is that this is a WiP situation with a feature called Arachne. I don't actually know _when_ libArachne is going to be incorporated, nor exactly how it works, but it's something they're working on and it's supposed to better handle such situations. If nothing else, CuraEngine has at least two pull requests to implement it.
Whether it makes it to 4.7, and when is 4.7 expected to release? Yeah, no idea.
In the meantime, Smartavionics has some "master" builds which use a different method of calculation that seems closer to what you're looking for (among a slew of other changes/fixes). You can find them here: https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0