Hi, On Mon, Jun 19, 2017 at 12:01 PM, 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. > > "elm_entry_selection_get" returns the text in markup format. The test prints both types one after another (markup followed by plaintext) using "elm_entry_markup_to_utf8". It is essential for copy & paste of markup text between two entry clients, so the pasted formatting is kept. > 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. > > Right, it's a feature so you can load plain files. You specify the format you want to load (plaintext or markup). But, after the file is loaded, it's discarded. It's important to point out that because there's an actual representation (markup), it's costly to store both plaintext and markup content in the object. Asking you to convert using "markup_to_utf8" is understandable, as it what we would actually do internally if we were to add API to get the text in plaintext. It's only one function call away, and it's easier than just add more API to the widget. No need for a new function if there's a way to do this already. > 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. > > Actually, it is not transformed on "text_set". You are expected to enter a markup-compatible text. Otherwise you will have the mentioned special characters (like "<") misinterpreted as markup. You can try with "elm_object_text_set" on an entry widget. > 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... > They're correct. UTF-8 is the standard plaintext encoding. We support UTF-8, and provide converters for your convenience. You probably won't need those most of the time. Your plaintext is always "encoded", but you probably won't notice that because it's backward-compatible with US ASCII (1-byte per character). > > Andrew > > Lastly, I would like to mention "Efl.Ui.Text" - this new widget is a part of a rework of the Textblock object. It's in BETA stage. It does what you require: all text input is expected to be plaintext. There's no "markup" logic in it. Instead, you format your text by setting ranges and calling functions to apply formatting. Again, markup does not exist in this object, and can be re-added as a module in later stages. You can check its current state in "efl ui text" test in elementary_test. Feedback will be very much appreciated. Hope this answers a few of your questions. Best, -- Danny (herdsman) Hirt ------------------------------------------------------------------------------ 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
