Page MenuHomePhabricator

efl.text_markup
Open, TODOPublic

Description

|interface Efl.Text_Markup @beta
|├ (P) markup
bu5hm4n created this task.May 3 2019, 11:14 AM
bu5hm4n triaged this task as TODO priority.
zmike moved this task from Backlog to Trivial on the efl: api board.Jun 12 2019, 7:38 AM

Same as efl.text, seems okay?

What kind of markup do we actually use? Is this documented anywhere?

Maybe we can add a markup_type property which is an enum to support multiple types?
Although that means we need to keep the original markup around in case the property is changed later and we need to re-interpret the markup string.
Probably a better approach is a set_markup method with a type parameter besides the actual markup text, instead of a plain markup property.
If the type parameter has a default value then we do not add any complexity for the user (for languages supporting default parameters).

Dunno how to read that

What kind of markup do we actually use? Is this documented anywhere?

@segfaultxavi
I think that tags (=formats) which can be used with EFL markup text are listed up in evas_textblock_legacy.h.
(I'm not sure whether this is something you want to know)

Maybe we can add a markup_type property which is an enum to support multiple types?
Although that means we need to keep the original markup around in case the property is changed later and we need to re-interpret the markup string.
Probably a better approach is a set_markup method with a type parameter besides the actual markup text, instead of a plain markup property.
If the type parameter has a default value then we do not add any complexity for the user (for languages supporting default parameters).

I'm wonderting what you mean with "markup_type". I don't know whether there can be multiple types for this feature.
What I only know is that there are only utf8 and markup which need to be covered by efl.canvas.text.
(Please let me know if I'm wrong)

I was thinking that maybe we could future-proof the API by specifying the type of markup the user is providing (EFL markup, Markdown, Flavored Markdown, Github Markdown... there¡'s hundreds of types!).
Right now this type would be an enum with only one possible value (EFL Markup), but in the future it could be extended.

Anyway, this does not seem urgent right now, and there's other ways to allow other types in the future, so just ignore my comment (for the record, here are some ideas: Add another property like github_markdown, or allow a special EFL-markup code at the beginning of the string indicating the type, something like <markdown_type=github>).

Thanks for the link to evas_textblock_legacy.h, that will be helpful!

zmike added a comment.Aug 29 2019, 7:09 AM

Is this good or what

Isn't this being completely revamped by @tasn ?

zmike added a comment.Sep 25 2019, 7:37 AM

Will this interface with the same property still exist at that point? If so, this can become stable now.

tasn added a comment.Sep 25 2019, 12:47 PM

No it won't. Not this name and not sure about the same property.

zmike moved this task from Trivial to Needs experts on the efl: api board.