I recall that this was one of the more confusing parts of EFL when I started out, but at this point the API has been shipped in enough releases that we definitely cannot change it.
Overall, I think it would be nice to have text conversion facilities at a lower level such as eina (not just iconv-based) so that the text API can have a stronger foundation. Additionally it would probably be good if, in the course of the interfaces/2.0 review process, we can look towards standardizing text APIs to deal with encoding and markup in a clearer and more intuitive way like Cedric suggested? For now, it seems like the only thing we can do with the legacy API is to improve the documentation to make it more clear what the user's expectations should be regarding formatting. On Mon, Jun 19, 2017 at 5:04 AM Andrew Williams <a...@andywilliams.me> wrote: > Hi, > > 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... > > Andrew > > 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>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 > > > > -- > http://andywilliams.me > http://ajwillia.ms > > ------------------------------------------------------------------------------ > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
