fix(colformat_md): follow internal change of flextable data structure

[atusy]

fixes #100

[atusy]

@davidgohel The issue #100 seems to be happened because of the change in the internal data structure. Am I right? (I have not yet reviewed the git log)

[davidgohel]

Yes the internal data structure has been simplified. Sorry I ran revdepcheck and did not catch that issue

[atusy]

I will drop support for flextable < 0.9.5 by specifying required version in DESCRIPTION

[cloudflare-workers-and-pages]

Deploying ftextra with    Cloudflare Pages

Latest commit:	236f205
Status:	✅  Deploy successful!
Preview URL:	https://8b2c1ab3.ftextra.pages.dev
Branch Preview URL:	https://support-flextable-0-9-5.ftextra.pages.dev

View logs

[davidgohel]

@atusy is it possible to use exported functions (I. E. as_paragraph or append_chunk) instead of using internal structures?

That would help having more robust code for both of us, see for example https://github.com/davidgohel/flextable/blob/2784247f5b500eca8fe4f9983326bf17c3897d12/R/01_fpstruct.R#L313

[atusy]

@davidgohel

Thanks. I understand robust code should avoid relying on the internal data structure.
However, I find no exported functions suits my use cases...

1. To convert texts in selected columns, I need access to the internal data to retrieve target markdown texts...
2. colformat_md's j argument supports the tidy-selection. This also requires access to the internal data structure... I like the experience of the tidy-selection, but I regret the inconsistency with the other colformat functions in the original flextable package.

To solve both, I need flextable to export a function that provides access to the internal data structure. However, but I do not think this is a good idea because flextable may face a difficulty to change the internal data structure in the future.

To solve the first one, I have a suggestion. flextable::compose()'s value argument can be enhanced to accept a callback that receives a paragraph selected by x, i, and j arguments, and returns the modified paragraph.
This also enables users to modify the content programmatically.

Anyway, I would be happy to know if there is a way for ftExtra to avoid the dependency on the internal data.
Thanks again.

[davidgohel]

Thanks for the suggestion 😊
I don't have a computer right now to try your suggestion but I will have a try later this week and iterate on the subject in this thread

[atusy]

My pleasure!

I would like to release a fix as soon as possible, so let me continue relying on the internal data structure for now.

Maybe I can do better in the near future 😄