Windows:

GTK (note that the fonts I'm completing in guifontwide are not monospaced fonts):

Codecov Report

Merging #13264 (4ef6cd4) into master (b74ebfc) will increase coverage by 3.82%.
The diff coverage is 71.29%.

@@            Coverage Diff             @@
##           master   #13264      +/-   ##
==========================================
+ Coverage   78.33%   82.15%   +3.82%     
==========================================
  Files         150      160      +10     
  Lines      153287   196256   +42969     
  Branches    39519    43974    +4455     
==========================================
+ Hits       120076   161234   +41158     
- Misses      20932    22137    +1205     
- Partials    12279    12885     +606     

Flags with carried forward coverage won't be shown. Click here to find out more.

... and 148 files with indirect coverage changes

Code coverage is complaining a lot of lines aren't testing. Most of them are due to guards around not being able to allocate memory. I'm following the pattern that I see in other areas in Vim's codebase and making sure to check against allocation results, but I don't know if there are good ways to test such situations.

Code coverage is complaining a lot of lines aren't testing. Most of them are due to guards around not being able to allocate memory. I'm following the pattern that I see in other areas in Vim's codebase and making sure to check against allocation results, but I don't know if there are good ways to test such situations.

You can use the test_alloc_fail() function to test for allocation failures. To use this function,
you need to add an ID in alloc_id_T and use the alloc_id() function for memory allocation.

You can use the test_alloc_fail() function to test for allocation failures. To use this function,
you need to add an ID in alloc_id_T and use the alloc_id() function for memory allocation.

Hmm that seems like a lot of work though. As in, the pattern that I see (and therefore follow) usually call vim_strsave / alloc or some other generic ways to get an allocated buffer and then NULL-check to protect against memory allocation issues. Only a few are tagged with an alloc ID.

You can use the test_alloc_fail() function to test for allocation failures. To use this function,
you need to add an ID in alloc_id_T and use the alloc_id() function for memory allocation.

Hmm that seems like a lot of work though. As in, the pattern that I see (and therefore follow) usually call vim_strsave / alloc or some other generic ways to get an allocated buffer and then NULL-check to protect against memory allocation issues. Only a few are tagged with an alloc ID.

Bram initially added the basic infrastructure (in 7.4.1058 and 7.4.1073) for testing memory
allocation failures. I used this infra in the features that I developed (quickfix, signs,
and tag stack) and used this in a few other places. As you said there are still a large
number of other places where this is not used yet. But this is the only mechanism
available currently to test memory allocation failures.

Relevant patches:
Patch 7.4.1058
Patch 7.4.1073
Patch 8.1.0519
Patch 8.1.0614
Patch 8.2.4474

Right. That's useful context to know. It feels to me this is quite manual and difficult to roll out across the board as it requires exhaustively tagging all your allocation, and testing each feature against it.

FWIW I think sometimes test coverage % could be a fickle thing. I'm working on another PR to fix cmdline expansion code related to escaping commas and spaces, and there are some tests that while technically "cover" the lines in question by getting the code to visit that code path (therefore increasing the code coverage %), do not actually test that the underlying behavior (it will be fixed in my PR) works.

As an aside, if you look at the change, in GTK Linux, if you don't have a guifont set, if you do :set guifont=<Tab> it will automatically suggest the default font "Monospace 10" for the user so they can adjust it. In Windows I decided not to implement this feature because I really hate the default Fixedsys font and the default font size is tiny on a modern monitor as it's set to pixels rather than points (maybe it's time to come up with a better default?) and not sure if there's any value in auto-filling the default. It can be changed of course.

thanks!