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
