On Mon, 19 Jun 2017 09:01:50 +0000 Andrew Williams <a...@andywilliams.me> said:
> 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. select text that has formatting like the bold: SELECTION: markup <b>like this</> for stylin SELECTION PLAIN UTF8: markup like this for stylin after you hit "sel" button below. first entry test (Entry). selection contains markup. the plain utf8 conversion does not. the converter (to/from markup) knows some basic tags like <br> for example to mean newline... and some others. the rest are stripped entirely as they cannot be mapped to/from plain utf8 text. > 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. you can - wit the conversion helpers. > 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. it's not transformed. it is literally kept as markup tags (not as a whole string through but broken up). test_Set always sets markupe. get gets markup. it's symmetrical. it very clearly states the tags supported and that it uses tags and markup for the text... > 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. you have the helpers to do just that - convert plain text to/from markup. i didn't see the point of adding more functions to set/get text when the converters will do just fine. > 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... they ASSUME its utf8 (or compatible - eg ascii) text in and out (plain or markup). all our strings are assumed to be utf8 at the api level as an encoding. always. eina has conversion api's for anything else to be able to convert to/from utf8 :) > 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 -- ------------- 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
