EHN: add ability to format index and col names to Styler
- [ ] closes #48936 and closes  #47489
- [ ] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [ ] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [ ] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

xref #57362

Stage one. Part of an multi-stages effort: https://github.com/pandas-dev/pandas/pull/57880#issuecomment-2003636401

Adding a method to Styler and ensuring it works for the default HTML cases with tests in the appropriate pages.
Hi thanks for this PR.

A `Styler.format_names` or `Styler.format_index_names` method has been on the requested agenda for a while now.
This PR mixes three concepts, however. 

- One is adding a method to `Styler` and ensuring it works for the default HTML cases with tests in the appropriate pages.
- Two is extending it to the `Styler.to_latex` implementation and adding specific to_latex tests.
- Three is ensuring that the legacy `DataFrame.to_latex` implementation is capable of using it (in its limited form).

- (Four would be about checking if `Styler.to_string` and `Styler.to_excel` will function accordingly)
- (Five is ensuring documentation and examples exist in `Styler.format_names` )

Since a method addition is quite a significant undertaking. I would ask that you split this PR into multiple stages.
The first stage I would look to review is part One. Adding the method just to `Styler` and adding tests in generic places, including testing the default implementation for HTML output.

From what I can see you have followed the template of previous code and that is a great start.



  Hi @attack68,

I've updated my code. It's now my attempt at the first point in your list.
Please help me take a look. I think we should probably call this method `format_index_names`. Even though its longer I think it is more obvious what it does.

I think we also need greater test coverage to cover lines.
Take a look at https://github.com/pandas-dev/pandas/blob/main/pandas/tests/io/formats/style/test_format.py

You should probably look to replicate the tests for the specific case :

- test_format_index_level
- test_format_clear
- test_format_callable
- test_format_dict
- test_display_format_index Since your code also involves cases where things are hidden you should also include a test to show that, say if a multi-index has a level hidden, the format function still works correctly on the levels that are still shown.  @attack68 added a bunch of new tests.

don't immediately see the point of `test_display_format_index` for this case so i didnt adapt it. Are you familiar with `coverage` ? The idea was that that collection of tests should pretty much cover all your code branches. Some of the re-used material like `_maybe_wrap_formatter` is already well covered. > Are you familiar with `coverage` ? The idea was that that collection of tests should pretty much cover all your code branches. Some of the re-used material like `_maybe_wrap_formatter` is already well covered.

Yeah. I ran coverage and see my new method is well covered. Mostly because i reuse a lot of things, as you have pointed out.

So i don't really understand what your suggestion is. Can you elaborate? Or maybe most of the material is reuse so you suggest we could achieve the same coverage without so much test? I hope not. My point is you need to cover your code with your tests. Aim for 100%. It seems you have achieved that. Do you agree? Thought so too.

If there is nothing major, I think i would fix up whats left and wrap this up. Then ill start to work on the next point in a new PR.

In case if things go stale, this PR can still be merged as an enhancement on its own. (ofc versionadded and whatsnew have to be filled before merge).

Does that sound good to you? Indeed, is what I would suggest. Thanks for the good work here and following the structure. Hopefully the other reviewers will recognise this as quite a tidy addition and be fairly quick approve also. I'll look to add my approval when all the bits in and tests pass.

There is one additional file you have to add to: doc/source/reference/style.rst Do you know the target version? Or should we wait for an active member? > Could you add a whatsnew note in `v3.0.0.rst` under `Other Enhancements`?

Added Thanks @quangngd  @quangngd are you interested to work on stage 2 of this. I think it would be good to get in so that there is no disconnect for users between these functions and the LaTeX output.

To my knowledge there are currently no undocumented issues between the styler and the LaTeX output so good for me to keep an eye on. @attack68 
Sure! Been a bit busy at work lately but I'll find some time to do it in the upcoming weekends.