@herdsman ping :) Could you update your idea on this task ?

I am in favor of limiting Edje regarding text theming.
In fact, I remember that at some point we considered removing most of Edje's functionality (text included) and move the calculations to the widgets.
That was the main motivation behind the Efl.Ui.Text widget, that actually skips the text size calculation logic of Edje. It is accomplished by querying its current state (line-wrap, scrollable, multiline).

2. Allows to change elm.text part's properties.
   • line wrap
   • ellipsis

How should this be prioritized over the style set by the theme?
If a developer has a text widget with a theme:

text { 
    style: "style_with_ellpsis_and_nowrap"; //" ellipsis=1.0 wrap=none"
}

Efl.Text properties are implemented in Canvas.Text to have lower priority over set styles.
That is, a call such as efl_text_wrap_set(efl_part(obj, "ui_text"), WORD_WRAP);, if simply forwarded to efl_text_wrap_set(text_real_obj, WORD_WRAP); will not change the word wrap, as the style has set NONE for linewrap.
Canvas.Text is meant to work this way so that styles can be overlaid.

Possible solutions for this:

1. Move styles out of Canvas.Text API and handle them in Edje via usage of properties (map wrap=none to efl_text_wrap_set(obj, WRAP_NONE). This will allow us to override the set properties of the default style.
2. OR we populate a "user-style" for the text part on efl_text_wrap and efl_text_ellipsis calls, and apply it on the text real part object.

Note that option (2) implies we may need to have a user style for each real object (though, we could share those user style strings with additional handling).

• size calculation rule (ex. description.text.min, description.text.max) for satisfying the above two things.

This is not part of Efl.Text. What API should we introduce here? Efl.Canvas.Layout.Part_Text.text_min/max_hint?

3. Allows to control size calculation rule by developer explicitly. Currently, the following things are only controllable by modifying/customizing its theme. It's an annoying work.
   • Horizontally/Vertically expandable.
   • Horizontally/Vertically not expandable with ellipsis or scroll.
   • Horizontally/Vertically expandable till reach to the given max limits.

Is this not the same as the description.text.min/max? If so, so yes let's where this API should be introduced (namespace).

4. Allows the interface for satisfying above requirements to other widgets which have text parts.

I am especially concerned about adding user calls to set description.text.min/max. Edje is designed (unless I am mistaken and you are welcome to correct me) to work from the theme for most (if not all) of the calculation logic. This feels like bad practice for users.
Not sure if this is the correct approach.
@raster, @jpeg, @cedric?