Looking at the tests you point me at - selection (and the past) is a plain
text copy with the markup stripped - exactly what I would expect for
text_get - but the current content transformed with the helper will not get
you there - there is no built in interpretation of formatting - just
rendered understands it.

Overall the implementation feels wrong - supporting markup is great but
returning it inline in text_get feels like we are imposing internal choices
on other devs.

I note that the code considers format but only when interacting with files
- so I can have plain text files but not plain text input.

Lastly the documentation clearly discussed markup capability but it *never*
discusses encoding and there is no explicit mention that your text will be
transformed after text_set. If it were then it should be symmetrically
transformed back on text_get - path of least surprise.

I don't quite understand why we would build formatting in as mandatory,
functionality is great but it should be possible to turn it off.

I agree that people complain when markup is not supported in a widget but
that is the expectation we have set - consistency is very important indeed
and I think we don't have it in this regard.

Additionally I think the markup_to_utf8 methods are peculiarly named - they
do no character encoding so the usage of utf8 is probably incorrect...


On Sun, 18 Jun 2017 at 23:58, Carsten Haitzler <ras...@rasterman.com> wrote:

> On Sun, 18 Jun 2017 20:18:33 +0000 Andrew Williams <a...@andywilliams.me>
> said:
> > Hi team,
> >
> > Netstar pointed out something to me today that I had completely missed
> for
> > ages - elm_entry assumes you are typing markup. Type "a>b" and text_get
> > will return "a&gt;b" - what is the reason for this? It seems completely
> > crazy default behaviour.
> > Is there any reason we can't turn this off by default but provide the
> > markup filter in a way where it can be switched on as needed?
> 1. can't change because this would break many apps that rely on it.
> 2. it's documented - labels and entries use textblock parts in edje. these
> use
> markup by default to be able to do styling.
> 3. the very first entry test shows use of markup - consider the elm tests
> documentation. they are intended as such. select some text in it hit "sel"
> that
> displays the text of the selection... boom. markup.
> 4. the fact that there is a markup to utf8 function does imply markup can
> be
> involved.
> 5. if you changed you'd break 11 of the current entry tests and have to
> change
> code (a very sure sign you broke a feature).
> 6. labels work like entries and do markup too - all the multi-line capable
> things in elm do this... it's a pattern.
> so ... not going to change.
> --
> ------------- Codito, ergo sum - "I code, therefore I am" --------------
> The Rasterman (Carsten Haitzler)    ras...@rasterman.com
> --
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
enlightenment-devel mailing list

Reply via email to