Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

Hi,

Whilst more API may seem counterintuitive I am a proponent of each method
does 1 thing well.
Therefore if we want to handle markup and handle plain text then a 2* API
count actually makes sense.

Andy

On Mon, 17 Jul 2017 at 08:33 Carsten Haitzler  wrote:

> On Wed, 5 Jul 2017 09:14:02 +0300 Daniel Hirt  said:
>
> > Hello all,
> >
> >
> > On 07/05/2017 08:48 AM, Carsten Haitzler (The Rasterman) wrote:
> > > On Wed, 05 Jul 2017 03:26:09 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > >> Hi,
> > >>
> > >> Unfortunately I don't have time to reply to all of these thoughts
> right now
> > >> but I wanted to reply to the first one before any more replies
> arrive. I am
> > >> not (and nether is anyone else) suggesting that we remove markup
> support.
> > >> Please stop implying that.
> > > i have clearly listed options on how to do it as an api. ONE of those
> > > options is no markup in text_set etc. and HELPERS indstead that would
> > > convert from makrup to plain text PLUS call the metadata api's to set
> > > metadata correctly. you double up on your api's and the markup ones are
> > > built on top of the plain text + metadata ones. i have been VERY clear
> on
> > > that. i have been EXPLICITLY discussing the problems with this path.
> > >
> > > you could implement both WITHOUT the markup being wrappers (and now
> have to
> > > support both as native internal paths). from an api view it loosk the
> same,
> > > internally it look different.
> >
> > There are benefits when going for the "wrappers" approach:
> >
> > 1. You offload the parsing logic to another source (as it should, it has
> > little to do with the current implementation of formats/annotations).
> >
> > 2. You don't repeat your logic - less to maintain. By making things use
> > "annotation" API, whether you want to use a markup or just the
> > annotation API, you maintain only the annotation code (in most cases, as
> > markup logic is only a wrapper).
> >
> > > an options was dave's "set a mode (markup or plain)"" method which
> cuts down
> > > our api's again to something nice BUT means we always have to switch
> to a
> > > specific mode then back to where it was each time.
> >
> > I would rather not do that. Setting "modes" is kind of unpleasant.
> >
> > > other methods were provide text format as a parameter with the string,
> > > provide it as special chars at the start of the string as a format
> header,
> > > and you propose having special string objects vaguely (i havent gotten
> > > something clear on it yet), and i think this is probably worse as you
> have
> > > to create string object from markup string, then set/provide string
> object
> > > to label/entry object, and the reverse (to get text, get string obj,
> then
> > > get string from string obj etc.). this double-object thing IMHO would
> make
> > > the api even worse to use than any of the other options.
> > >
> > > imho the simplest option is pick one encoding only and provide
> converters
> > > like:
> > >
> > >obj.text_set(to_markup("Hello\nWorld"));
> > >text = to_plain(obj.text_get());
> > >
> > > ALL you need to know is it's markup by default. this means all the
> string
> > > query and manipulation funcs only need a single markup version at the
> api
> > > since you lose no information.
> >
> > Not all usages of text require markup. SOME (even a lot) want it, but
> > not all.
> > The question is: can we allow having two different interpretations for
> > "Efl.Text.text" property?
> > My answer is "no". We should stick to it being a plain text.
> >
> > >> Also my email was about api and not about internal storage. If you
> want to
> > >> handle everything internally in some encoded form fine - just don't
> push
> > >> that choice on users of what looks like a text api. Supporting both
> plain
> > >> text and markuped text models does not mean lowest common denominator
> > >> internally.
> > > i am not talking about internal encoding at all. ONLY talking about
> api. i
> > > was saying that IF the "native model" for api is not markup (all data
> > > inline in the blob of text) and has to be dealt with by various api's
> > > defining content then defining format ranges (char 13 to 67 is "bold",
> at
> > > char 16 insert image item "bob.jpg", etc. for example). then the markup
> > > api's will be build AROUND this and that makes them complex
> internally. you
> > > also double up on your api's - having markup versions for every plain
> text
> > > version. this is not a great thing.
> > >
> > > this morning i just personally spoke to 2 developers in the office and
> the
> > > BOTH were: "markup is great. we like it. everyone i know of liked it
> and
> > > had no issues with elm_entry being markup by default - they liked it".
> these
> > > people have interacted with dozens of developers using these api's...
> their
> > > experience is the polar opposite of yours. they had zero issues in
> dealing
> > 

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Wed, 5 Jul 2017 09:14:02 +0300 Daniel Hirt  said:

> Hello all,
> 
> 
> On 07/05/2017 08:48 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 05 Jul 2017 03:26:09 + Andrew Williams 
> > said:
> >
> >> Hi,
> >>
> >> Unfortunately I don't have time to reply to all of these thoughts right now
> >> but I wanted to reply to the first one before any more replies arrive. I am
> >> not (and nether is anyone else) suggesting that we remove markup support.
> >> Please stop implying that.
> > i have clearly listed options on how to do it as an api. ONE of those
> > options is no markup in text_set etc. and HELPERS indstead that would
> > convert from makrup to plain text PLUS call the metadata api's to set
> > metadata correctly. you double up on your api's and the markup ones are
> > built on top of the plain text + metadata ones. i have been VERY clear on
> > that. i have been EXPLICITLY discussing the problems with this path.
> >
> > you could implement both WITHOUT the markup being wrappers (and now have to
> > support both as native internal paths). from an api view it loosk the same,
> > internally it look different.
> 
> There are benefits when going for the "wrappers" approach:
> 
> 1. You offload the parsing logic to another source (as it should, it has 
> little to do with the current implementation of formats/annotations).
> 
> 2. You don't repeat your logic - less to maintain. By making things use 
> "annotation" API, whether you want to use a markup or just the 
> annotation API, you maintain only the annotation code (in most cases, as 
> markup logic is only a wrapper).
> 
> > an options was dave's "set a mode (markup or plain)"" method which cuts down
> > our api's again to something nice BUT means we always have to switch to a
> > specific mode then back to where it was each time.
> 
> I would rather not do that. Setting "modes" is kind of unpleasant.
> 
> > other methods were provide text format as a parameter with the string,
> > provide it as special chars at the start of the string as a format header,
> > and you propose having special string objects vaguely (i havent gotten
> > something clear on it yet), and i think this is probably worse as you have
> > to create string object from markup string, then set/provide string object
> > to label/entry object, and the reverse (to get text, get string obj, then
> > get string from string obj etc.). this double-object thing IMHO would make
> > the api even worse to use than any of the other options.
> >
> > imho the simplest option is pick one encoding only and provide converters
> > like:
> >
> >obj.text_set(to_markup("Hello\nWorld"));
> >text = to_plain(obj.text_get());
> >
> > ALL you need to know is it's markup by default. this means all the string
> > query and manipulation funcs only need a single markup version at the api
> > since you lose no information.
> 
> Not all usages of text require markup. SOME (even a lot) want it, but 
> not all.
> The question is: can we allow having two different interpretations for 
> "Efl.Text.text" property?
> My answer is "no". We should stick to it being a plain text.
> 
> >> Also my email was about api and not about internal storage. If you want to
> >> handle everything internally in some encoded form fine - just don't push
> >> that choice on users of what looks like a text api. Supporting both plain
> >> text and markuped text models does not mean lowest common denominator
> >> internally.
> > i am not talking about internal encoding at all. ONLY talking about api. i
> > was saying that IF the "native model" for api is not markup (all data
> > inline in the blob of text) and has to be dealt with by various api's
> > defining content then defining format ranges (char 13 to 67 is "bold", at
> > char 16 insert image item "bob.jpg", etc. for example). then the markup
> > api's will be build AROUND this and that makes them complex internally. you
> > also double up on your api's - having markup versions for every plain text
> > version. this is not a great thing.
> >
> > this morning i just personally spoke to 2 developers in the office and the
> > BOTH were: "markup is great. we like it. everyone i know of liked it and
> > had no issues with elm_entry being markup by default - they liked it". these
> > people have interacted with dozens of developers using these api's... their
> > experience is the polar opposite of yours. they had zero issues in dealing
> > with markup by default. i'm warning - change defaults and a silent happy
> > large group become noisy and unhappy.
> 
> Markup is staying. The developer will just need to use 
> "efl_text_markup_set/insert", instead.
> Using a different name shouldn't upset anyone, unless I am missing 
> something?

that was my point way way way up in the thread. if you want to do this way you
need plain text AND markup versions of every api that deals with text on a
window.

text_get()

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

Hi,

That sounds excellent. I like the idea of markup handling being separate
but just as convenient as before. The more we can split out the logo from
widgets the more testable our apis will be as well.

Thanks,
Andy
On Wed, 5 Jul 2017 at 07:13, Daniel Hirt  wrote:

> Hello all,
>
>
> On 07/05/2017 08:48 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 05 Jul 2017 03:26:09 + Andrew Williams 
> said:
> >
> >> Hi,
> >>
> >> Unfortunately I don't have time to reply to all of these thoughts right
> now
> >> but I wanted to reply to the first one before any more replies arrive.
> I am
> >> not (and nether is anyone else) suggesting that we remove markup
> support.
> >> Please stop implying that.
> > i have clearly listed options on how to do it as an api. ONE of those
> options
> > is no markup in text_set etc. and HELPERS indstead that would convert
> from
> > makrup to plain text PLUS call the metadata api's to set metadata
> correctly.
> > you double up on your api's and the markup ones are built on top of the
> plain
> > text + metadata ones. i have been VERY clear on that. i have been
> EXPLICITLY
> > discussing the problems with this path.
> >
> > you could implement both WITHOUT the markup being wrappers (and now have
> to
> > support both as native internal paths). from an api view it loosk the
> same,
> > internally it look different.
>
> There are benefits when going for the "wrappers" approach:
>
> 1. You offload the parsing logic to another source (as it should, it has
> little to do with the current implementation of formats/annotations).
>
> 2. You don't repeat your logic - less to maintain. By making things use
> "annotation" API, whether you want to use a markup or just the
> annotation API, you maintain only the annotation code (in most cases, as
> markup logic is only a wrapper).
>
> > an options was dave's "set a mode (markup or plain)"" method which cuts
> down
> > our api's again to something nice BUT means we always have to switch to a
> > specific mode then back to where it was each time.
>
> I would rather not do that. Setting "modes" is kind of unpleasant.
>
> > other methods were provide text format as a parameter with the string,
> provide
> > it as special chars at the start of the string as a format header, and
> you
> > propose having special string objects vaguely (i havent gotten something
> clear
> > on it yet), and i think this is probably worse as you have to create
> string
> > object from markup string, then set/provide string object to label/entry
> > object, and the reverse (to get text, get string obj, then get string
> from
> > string obj etc.). this double-object thing IMHO would make the api even
> worse
> > to use than any of the other options.
> >
> > imho the simplest option is pick one encoding only and provide
> converters like:
> >
> >obj.text_set(to_markup("Hello\nWorld"));
> >text = to_plain(obj.text_get());
> >
> > ALL you need to know is it's markup by default. this means all the
> string query
> > and manipulation funcs only need a single markup version at the api
> since you
> > lose no information.
>
> Not all usages of text require markup. SOME (even a lot) want it, but
> not all.
> The question is: can we allow having two different interpretations for
> "Efl.Text.text" property?
> My answer is "no". We should stick to it being a plain text.
>
> >> Also my email was about api and not about internal storage. If you want
> to
> >> handle everything internally in some encoded form fine - just don't push
> >> that choice on users of what looks like a text api. Supporting both
> plain
> >> text and markuped text models does not mean lowest common denominator
> >> internally.
> > i am not talking about internal encoding at all. ONLY talking about api.
> i was
> > saying that IF the "native model" for api is not markup (all data inline
> in the
> > blob of text) and has to be dealt with by various api's defining content
> then
> > defining format ranges (char 13 to 67 is "bold", at char 16 insert image
> item
> > "bob.jpg", etc. for example). then the markup api's will be build AROUND
> this
> > and that makes them complex internally. you also double up on your api's
> -
> > having markup versions for every plain text version. this is not a great
> thing.
> >
> > this morning i just personally spoke to 2 developers in the office and
> the BOTH
> > were: "markup is great. we like it. everyone i know of liked it and had
> no
> > issues with elm_entry being markup by default - they liked it". these
> > people have interacted with dozens of developers using these api's...
> their
> > experience is the polar opposite of yours. they had zero issues in
> dealing with
> > markup by default. i'm warning - change defaults and a silent happy
> large group
> > become noisy and unhappy.
>
> Markup is staying. The developer will just need to use
> "efl_text_markup_set/insert", instead.
> Using a different name 

Re: [E-devel] Elm_Entry assuming markup input???

[Daniel Hirt]

Hello all,


On 07/05/2017 08:48 AM, Carsten Haitzler (The Rasterman) wrote:

On Wed, 05 Jul 2017 03:26:09 + Andrew Williams  said:


Hi,

Unfortunately I don't have time to reply to all of these thoughts right now
but I wanted to reply to the first one before any more replies arrive. I am
not (and nether is anyone else) suggesting that we remove markup support.
Please stop implying that.

i have clearly listed options on how to do it as an api. ONE of those options
is no markup in text_set etc. and HELPERS indstead that would convert from
makrup to plain text PLUS call the metadata api's to set metadata correctly.
you double up on your api's and the markup ones are built on top of the plain
text + metadata ones. i have been VERY clear on that. i have been EXPLICITLY
discussing the problems with this path.

you could implement both WITHOUT the markup being wrappers (and now have to
support both as native internal paths). from an api view it loosk the same,
internally it look different.


There are benefits when going for the "wrappers" approach:

1. You offload the parsing logic to another source (as it should, it has 
little to do with the current implementation of formats/annotations).


2. You don't repeat your logic - less to maintain. By making things use 
"annotation" API, whether you want to use a markup or just the 
annotation API, you maintain only the annotation code (in most cases, as 
markup logic is only a wrapper).



an options was dave's "set a mode (markup or plain)"" method which cuts down
our api's again to something nice BUT means we always have to switch to a
specific mode then back to where it was each time.


I would rather not do that. Setting "modes" is kind of unpleasant.


other methods were provide text format as a parameter with the string, provide
it as special chars at the start of the string as a format header, and you
propose having special string objects vaguely (i havent gotten something clear
on it yet), and i think this is probably worse as you have to create string
object from markup string, then set/provide string object to label/entry
object, and the reverse (to get text, get string obj, then get string from
string obj etc.). this double-object thing IMHO would make the api even worse
to use than any of the other options.

imho the simplest option is pick one encoding only and provide converters like:

   obj.text_set(to_markup("Hello\nWorld"));
   text = to_plain(obj.text_get());

ALL you need to know is it's markup by default. this means all the string query
and manipulation funcs only need a single markup version at the api since you
lose no information.


Not all usages of text require markup. SOME (even a lot) want it, but 
not all.
The question is: can we allow having two different interpretations for 
"Efl.Text.text" property?

My answer is "no". We should stick to it being a plain text.


Also my email was about api and not about internal storage. If you want to
handle everything internally in some encoded form fine - just don't push
that choice on users of what looks like a text api. Supporting both plain
text and markuped text models does not mean lowest common denominator
internally.

i am not talking about internal encoding at all. ONLY talking about api. i was
saying that IF the "native model" for api is not markup (all data inline in the
blob of text) and has to be dealt with by various api's defining content then
defining format ranges (char 13 to 67 is "bold", at char 16 insert image item
"bob.jpg", etc. for example). then the markup api's will be build AROUND this
and that makes them complex internally. you also double up on your api's -
having markup versions for every plain text version. this is not a great thing.

this morning i just personally spoke to 2 developers in the office and the BOTH
were: "markup is great. we like it. everyone i know of liked it and had no
issues with elm_entry being markup by default - they liked it". these
people have interacted with dozens of developers using these api's... their
experience is the polar opposite of yours. they had zero issues in dealing with
markup by default. i'm warning - change defaults and a silent happy large group
become noisy and unhappy.


Markup is staying. The developer will just need to use 
"efl_text_markup_set/insert", instead.
Using a different name shouldn't upset anyone, unless I am missing 
something?


Also, I am writing the "Efl.Markup" mixin, that will use the annotation 
API, right now.

Just letting you know.

-- herdsman.


before jumping into "the decision is made, but we have no numbers on what is
popular" ... get some data on that first. i suspect you may be surprised at how
many people find markup simple, obvious and easy to deal with. it keeps our api
implementation simpler and api size smaller.


I'll get to the rest later, apologies for the partial reply)
Andy
On Tue, 4 Jul 2017 at 20:29, Carsten Haitzler  wrote:


On Tue, 

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Wed, 05 Jul 2017 03:26:09 + Andrew Williams  said:

> Hi,
> 
> Unfortunately I don't have time to reply to all of these thoughts right now
> but I wanted to reply to the first one before any more replies arrive. I am
> not (and nether is anyone else) suggesting that we remove markup support.
> Please stop implying that.

i have clearly listed options on how to do it as an api. ONE of those options
is no markup in text_set etc. and HELPERS indstead that would convert from
makrup to plain text PLUS call the metadata api's to set metadata correctly.
you double up on your api's and the markup ones are built on top of the plain
text + metadata ones. i have been VERY clear on that. i have been EXPLICITLY
discussing the problems with this path.

you could implement both WITHOUT the markup being wrappers (and now have to
support both as native internal paths). from an api view it loosk the same,
internally it look different.

an options was dave's "set a mode (markup or plain)"" method which cuts down
our api's again to something nice BUT means we always have to switch to a
specific mode then back to where it was each time.

other methods were provide text format as a parameter with the string, provide
it as special chars at the start of the string as a format header, and you
propose having special string objects vaguely (i havent gotten something clear
on it yet), and i think this is probably worse as you have to create string
object from markup string, then set/provide string object to label/entry
object, and the reverse (to get text, get string obj, then get string from
string obj etc.). this double-object thing IMHO would make the api even worse
to use than any of the other options.

imho the simplest option is pick one encoding only and provide converters like:

  obj.text_set(to_markup("Hello\nWorld"));
  text = to_plain(obj.text_get());

ALL you need to know is it's markup by default. this means all the string query
and manipulation funcs only need a single markup version at the api since you
lose no information.

> Also my email was about api and not about internal storage. If you want to
> handle everything internally in some encoded form fine - just don't push
> that choice on users of what looks like a text api. Supporting both plain
> text and markuped text models does not mean lowest common denominator
> internally.

i am not talking about internal encoding at all. ONLY talking about api. i was
saying that IF the "native model" for api is not markup (all data inline in the
blob of text) and has to be dealt with by various api's defining content then
defining format ranges (char 13 to 67 is "bold", at char 16 insert image item
"bob.jpg", etc. for example). then the markup api's will be build AROUND this
and that makes them complex internally. you also double up on your api's -
having markup versions for every plain text version. this is not a great thing.

this morning i just personally spoke to 2 developers in the office and the BOTH
were: "markup is great. we like it. everyone i know of liked it and had no
issues with elm_entry being markup by default - they liked it". these
people have interacted with dozens of developers using these api's... their
experience is the polar opposite of yours. they had zero issues in dealing with
markup by default. i'm warning - change defaults and a silent happy large group
become noisy and unhappy.

before jumping into "the decision is made, but we have no numbers on what is
popular" ... get some data on that first. i suspect you may be surprised at how
many people find markup simple, obvious and easy to deal with. it keeps our api
implementation simpler and api size smaller.

> I'll get to the rest later, apologies for the partial reply)
> Andy
> On Tue, 4 Jul 2017 at 20:29, Carsten Haitzler  wrote:
> 
> > On Tue, 04 Jul 2017 18:50:34 + Andrew Williams 
> > said:
> >
> > > Hi,
> > >
> > > Apologies I did not realise it was a question that needed answering. As I
> > > moved in to discuss if we are worrying about text manipulation in our
> > > widgets then we probably have bigger issues around separation of
> > concerns.
> > > Our text handling apis should worry about that - and the widget have a
> > > simple way to bind to a text model or have the resulting text set.
> >
> > it's part of the concerns. if you want to drop markup entirely then you're
> > going to REALLY annoy a lot of people used to inlining their metadata.
> > dave is
> > the counter example i am pointing at (and i bet you there are many more
> > like
> > him).
> >
> > i remember at e dev day we specifically skipped popularity with "we have no
> > info on what people prefer and are not doing some popularity poll here" or
> > words to that effect. so the jury is still out on what people actually
> > prefer.
> > i know what you prefer. i have heard what some others prefer. if its 55v45
> > in
> > favour of plain text + api's 

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

Hi,

Unfortunately I don't have time to reply to all of these thoughts right now
but I wanted to reply to the first one before any more replies arrive. I am
not (and nether is anyone else) suggesting that we remove markup support.
Please stop implying that.

Also my email was about api and not about internal storage. If you want to
handle everything internally in some encoded form fine - just don't push
that choice on users of what looks like a text api. Supporting both plain
text and markuped text models does not mean lowest common denominator
internally.

I'll get to the rest later, apologies for the partial reply)
Andy
On Tue, 4 Jul 2017 at 20:29, Carsten Haitzler  wrote:

> On Tue, 04 Jul 2017 18:50:34 + Andrew Williams 
> said:
>
> > Hi,
> >
> > Apologies I did not realise it was a question that needed answering. As I
> > moved in to discuss if we are worrying about text manipulation in our
> > widgets then we probably have bigger issues around separation of
> concerns.
> > Our text handling apis should worry about that - and the widget have a
> > simple way to bind to a text model or have the resulting text set.
>
> it's part of the concerns. if you want to drop markup entirely then you're
> going to REALLY annoy a lot of people used to inlining their metadata.
> dave is
> the counter example i am pointing at (and i bet you there are many more
> like
> him).
>
> i remember at e dev day we specifically skipped popularity with "we have no
> info on what people prefer and are not doing some popularity poll here" or
> words to that effect. so the jury is still out on what people actually
> prefer.
> i know what you prefer. i have heard what some others prefer. if its 55v45
> in
> favour of plain text + api's to define format regions/nodes i still say
> "stick
> to markup as it will make a transition easier". if it's 80v20 in favour of
> plain then move, but you need some way to provide inlined format handling
> to
> express a string of text WITH formatting embedded (ie markup). what you are
> presenting is a fait accompli that has clearly said "ignoring the data
> - making this decision anyway".
>
> and to do that then you would need to provide api's that set/get (and
> otherwise
> manipulate and query) that do both markup versions AND plain text versions
> given your design. the way we do it now is when going from markup (all data
> there) to plain - we just drop all the markup on the floor and convert a
> very
> tags ( for example) and vice-versa.
>
> when your metadata is out-of-band like proposed you have to now have markup
> versions of every plain text api version on anything because dealing with
> formatting requires more calls to go query the formatting info separately
> to
> the text and it can't just be done in a "simple wrapper that converts a
> string" because you are not just stripping out data from a full data set,
> but
> having to do multiple api's to query and rebuild it and vice-versa. the
> proposal for strings is to make them very very very dumb (plain text) by
> default and that is highly problematic from a technical point of view.
> popularity is totally unknown at this point, so just assuming its 50v50,
> choosing the path with far more technical issues at the api level is a bad
> choice, and plain text is just that.
>
> you can't separate out the choice of markup or not from designing the api.
> doing markup by default is "we choose to lose NO information by default and
> have all of it there and provide you with helpers to drop info not needed
> or
> used". choosing plain text by default is "we already lost all the info -
> you
> have to add it back with more api's by querying or providing it". if you
> provide markup versions of every text api then this would be dealt with
> BUT it
> leads to doubling up of every text api that manipulates or queries a
> string and
> that is not exactly wonderful. unlike markup by default, you can't just
> provide
> a simple "degrade it to plain text" helper (or promote to markup) like we
> do
> now. you have to have the full set doubled up.
>
> > I appreciate that people have not had issues with the way it is, but I
> > don't think that is reason enough to dismiss the issues that are reported
> > or the confusion created... (I reference back to user enters 2>3 but
> > text_get returns 23)
>
> and removing markup by default creates other problems which i am pointing
> out
> because it downgrades the information passed in and out BY DEFAULT (plain
> text
> is downgraded vs markup). you will have issues EITHER way. plain text is
> not
> magically so much better than markup. it switches a different base
> assumption
> on the text encoding (text is always encoded. UTF-8 plain text where \n
> means
> go down 1 line and move cursor to left (or right) edge, char values > 127
> e.g.
> even for latin-1 are encoded with multiple byte sequences ala UTF-8 ...
> it's
> ALWAYS encoded). markup is just an 

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Tue, 04 Jul 2017 18:50:34 + Andrew Williams  said:

> Hi,
> 
> Apologies I did not realise it was a question that needed answering. As I
> moved in to discuss if we are worrying about text manipulation in our
> widgets then we probably have bigger issues around separation of concerns.
> Our text handling apis should worry about that - and the widget have a
> simple way to bind to a text model or have the resulting text set.

it's part of the concerns. if you want to drop markup entirely then you're
going to REALLY annoy a lot of people used to inlining their metadata. dave is
the counter example i am pointing at (and i bet you there are many more like
him).

i remember at e dev day we specifically skipped popularity with "we have no
info on what people prefer and are not doing some popularity poll here" or
words to that effect. so the jury is still out on what people actually prefer.
i know what you prefer. i have heard what some others prefer. if its 55v45 in
favour of plain text + api's to define format regions/nodes i still say "stick
to markup as it will make a transition easier". if it's 80v20 in favour of
plain then move, but you need some way to provide inlined format handling to
express a string of text WITH formatting embedded (ie markup). what you are
presenting is a fait accompli that has clearly said "ignoring the data
- making this decision anyway".

and to do that then you would need to provide api's that set/get (and otherwise
manipulate and query) that do both markup versions AND plain text versions
given your design. the way we do it now is when going from markup (all data
there) to plain - we just drop all the markup on the floor and convert a very
tags ( for example) and vice-versa.

when your metadata is out-of-band like proposed you have to now have markup
versions of every plain text api version on anything because dealing with
formatting requires more calls to go query the formatting info separately to
the text and it can't just be done in a "simple wrapper that converts a
string" because you are not just stripping out data from a full data set, but
having to do multiple api's to query and rebuild it and vice-versa. the
proposal for strings is to make them very very very dumb (plain text) by
default and that is highly problematic from a technical point of view.
popularity is totally unknown at this point, so just assuming its 50v50,
choosing the path with far more technical issues at the api level is a bad
choice, and plain text is just that.

you can't separate out the choice of markup or not from designing the api.
doing markup by default is "we choose to lose NO information by default and
have all of it there and provide you with helpers to drop info not needed or
used". choosing plain text by default is "we already lost all the info - you
have to add it back with more api's by querying or providing it". if you
provide markup versions of every text api then this would be dealt with BUT it
leads to doubling up of every text api that manipulates or queries a string and
that is not exactly wonderful. unlike markup by default, you can't just provide
a simple "degrade it to plain text" helper (or promote to markup) like we do
now. you have to have the full set doubled up.

> I appreciate that people have not had issues with the way it is, but I
> don't think that is reason enough to dismiss the issues that are reported
> or the confusion created... (I reference back to user enters 2>3 but
> text_get returns 23)

and removing markup by default creates other problems which i am pointing out
because it downgrades the information passed in and out BY DEFAULT (plain text
is downgraded vs markup). you will have issues EITHER way. plain text is not
magically so much better than markup. it switches a different base assumption
on the text encoding (text is always encoded. UTF-8 plain text where \n means
go down 1 line and move cursor to left (or right) edge, char values > 127 e.g.
even for latin-1 are encoded with multiple byte sequences ala UTF-8 ... it's
ALWAYS encoded). markup is just an extended form of encoding on top of this.
and functions/helpers were provided to do this conversion. it's not being
dismissed. far from it - it was already envisaged and addressed. maybe the
helpers could now use eina_slstr to avoid needing to free strings afterwards...

but my point is that if the DEFAULT api were to be lossy (plain text) then you
create a huge amount of problems. if it were markup then you'd have far fewer
problems and just need the kind of convert funcs as we already have. that or
having to provide markup duplicates api's for every string get/set/insert/fetch
substring etc. and from api size/complexity duplicating is generally a bad path
to go down.

and ALL of this discussion at the technical api level hasn't even got the info
on what people prefer to be the default. to get a good feel for this... you
NEED to give them some options on what to choose and thus 

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

Hi,

Apologies I did not realise it was a question that needed answering. As I
moved in to discuss if we are worrying about text manipulation in our
widgets then we probably have bigger issues around separation of concerns.
Our text handling apis should worry about that - and the widget have a
simple way to bind to a text model or have the resulting text set.

I appreciate that people have not had issues with the way it is, but I
don't think that is reason enough to dismiss the issues that are reported
or the confusion created... (I reference back to user enters 2>3 but
text_get returns 23)
Encoding of text is not something that a widget should have to deal with
and decoding is not something that a cost char* text_get api implies.

Andy
On Tue, 4 Jul 2017 at 13:23, Davide Andreoli  wrote:

> 2017-07-04 14:22 GMT+02:00 Andrew Williams :
>
> > Hi,
> >
> > I jumped back to this email I sent a week ago and realised that we have
> > just spent a bunch of time revisiting a discussion that had clearly
> wrapped
> > up at the EDD in Malta. One reason I wanted to post our conclusion to the
> > list was for visibility and a chance to comment for anyone who was not
> able
> > to attend. Unfortunately instead we have had a lot of the same points
> > brought forward that were already discussed at the event which has led to
> > confusion and time wasting.
> >
> > There is a question in here about general API design that I will start
> in a
> > new thread but i want to wrap up this discussion. Is there anyone on this
> > list (except raster as Tizen developer proxy) who disagrees with the
> > approach as was laid out in my email of the 29th?
> >
>
> you still did not reply to the first raster's question:
> do we will have a markup variant for every text operation? (text_set,
> text_append, text_insert...etc).
>
> To be honest I never had any issue with the current always-markup model,
> so for now I vote for keeping the legacy behavior also on the new EO api.
>
>
>
> >
> > I understand that this could be conceived as a massive change but my
> > understanding was that the Eo API was a chance to fix things up to be
> > better going forward and not to be shackled by our choices of the past.
> If
> > that is not true then we will really struggle to make quality bindings to
> > higher level languages (in this context the difference between plain text
> > and markedup/parameterised text and also the tight coupling of text
> > handling and the rendering).
> >
> > Thanks
> > Andy
> >
> > On Thu, 29 Jun 2017 at 07:13, Andrew Williams 
> > wrote:
> >
> > > Hi,
> > >
> > > Just to wrap this thread up following EDD:
> > >
> > > * no-one is proposing that we remove the ability to mark up text
> through
> > > the markup format mechanism, it is a great feature
> > > * we cannot make changes to this legacy API as apps depend on it or
> have
> > > adapted to it
> > >
> > > * the new textblock API, which is currently plain text only is being
> > > extended with a solid markup API
> > > * The existing markup format will be supported through _markup_text_set
> > or
> > > similar API leaving text_set/get to be plain text only
> > >
> > > It was beileved that this would satisfy all requirements whilst
> removing
> > > any confusion about the nature of text encoding when using plain text.
> > > This allows us to take a path-of-least-surprise approach for the new Eo
> > > based text APIs
> > >
> > > Thanks everyone for the discussion :)
> > > Andy
> > >
> > > On Sat, 24 Jun 2017 at 05:39 Carsten Haitzler 
> > > wrote:
> > >
> > >> On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli <
> > >> d...@gurumeditation.it>
> > >> said:
> > >>
> > >> > 2017-06-19 13:36 GMT+02:00 Daniel Hirt :
> > >> > > 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
> > >> > 

Re: [E-devel] Elm_Entry assuming markup input???

[Davide Andreoli]

2017-07-04 14:22 GMT+02:00 Andrew Williams :

> Hi,
>
> I jumped back to this email I sent a week ago and realised that we have
> just spent a bunch of time revisiting a discussion that had clearly wrapped
> up at the EDD in Malta. One reason I wanted to post our conclusion to the
> list was for visibility and a chance to comment for anyone who was not able
> to attend. Unfortunately instead we have had a lot of the same points
> brought forward that were already discussed at the event which has led to
> confusion and time wasting.
>
> There is a question in here about general API design that I will start in a
> new thread but i want to wrap up this discussion. Is there anyone on this
> list (except raster as Tizen developer proxy) who disagrees with the
> approach as was laid out in my email of the 29th?
>

you still did not reply to the first raster's question:
do we will have a markup variant for every text operation? (text_set,
text_append, text_insert...etc).

To be honest I never had any issue with the current always-markup model,
so for now I vote for keeping the legacy behavior also on the new EO api.



>
> I understand that this could be conceived as a massive change but my
> understanding was that the Eo API was a chance to fix things up to be
> better going forward and not to be shackled by our choices of the past. If
> that is not true then we will really struggle to make quality bindings to
> higher level languages (in this context the difference between plain text
> and markedup/parameterised text and also the tight coupling of text
> handling and the rendering).
>
> Thanks
> Andy
>
> On Thu, 29 Jun 2017 at 07:13, Andrew Williams 
> wrote:
>
> > Hi,
> >
> > Just to wrap this thread up following EDD:
> >
> > * no-one is proposing that we remove the ability to mark up text through
> > the markup format mechanism, it is a great feature
> > * we cannot make changes to this legacy API as apps depend on it or have
> > adapted to it
> >
> > * the new textblock API, which is currently plain text only is being
> > extended with a solid markup API
> > * The existing markup format will be supported through _markup_text_set
> or
> > similar API leaving text_set/get to be plain text only
> >
> > It was beileved that this would satisfy all requirements whilst removing
> > any confusion about the nature of text encoding when using plain text.
> > This allows us to take a path-of-least-surprise approach for the new Eo
> > based text APIs
> >
> > Thanks everyone for the discussion :)
> > Andy
> >
> > On Sat, 24 Jun 2017 at 05:39 Carsten Haitzler 
> > wrote:
> >
> >> On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli <
> >> d...@gurumeditation.it>
> >> said:
> >>
> >> > 2017-06-19 13:36 GMT+02:00 Daniel Hirt :
> >> > > 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 

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

Hi,

I jumped back to this email I sent a week ago and realised that we have
just spent a bunch of time revisiting a discussion that had clearly wrapped
up at the EDD in Malta. One reason I wanted to post our conclusion to the
list was for visibility and a chance to comment for anyone who was not able
to attend. Unfortunately instead we have had a lot of the same points
brought forward that were already discussed at the event which has led to
confusion and time wasting.

There is a question in here about general API design that I will start in a
new thread but i want to wrap up this discussion. Is there anyone on this
list (except raster as Tizen developer proxy) who disagrees with the
approach as was laid out in my email of the 29th?

I understand that this could be conceived as a massive change but my
understanding was that the Eo API was a chance to fix things up to be
better going forward and not to be shackled by our choices of the past. If
that is not true then we will really struggle to make quality bindings to
higher level languages (in this context the difference between plain text
and markedup/parameterised text and also the tight coupling of text
handling and the rendering).

Thanks
Andy

On Thu, 29 Jun 2017 at 07:13, Andrew Williams  wrote:

> Hi,
>
> Just to wrap this thread up following EDD:
>
> * no-one is proposing that we remove the ability to mark up text through
> the markup format mechanism, it is a great feature
> * we cannot make changes to this legacy API as apps depend on it or have
> adapted to it
>
> * the new textblock API, which is currently plain text only is being
> extended with a solid markup API
> * The existing markup format will be supported through _markup_text_set or
> similar API leaving text_set/get to be plain text only
>
> It was beileved that this would satisfy all requirements whilst removing
> any confusion about the nature of text encoding when using plain text.
> This allows us to take a path-of-least-surprise approach for the new Eo
> based text APIs
>
> Thanks everyone for the discussion :)
> Andy
>
> On Sat, 24 Jun 2017 at 05:39 Carsten Haitzler 
> wrote:
>
>> On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli <
>> d...@gurumeditation.it>
>> said:
>>
>> > 2017-06-19 13:36 GMT+02:00 Daniel Hirt :
>> > > 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 

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Sun, 02 Jul 2017 21:42:01 + Andrew Williams  said:

> As I'm on the move I have no decent email app so I can't interleave with
> your replies so it's all up-top:
> 
> First time: Maybe not on ML but this has been discussed before on IRC, but
> that does not exactly make angood source of documentation for issues or api
> confusion.

i've never seen it before... :)

> UTF8: we are in agreement here, I think you misread my comment - I was
> saying this complication is introduced by unicode so the markup does not
> add that complexity.

oh sorry. my bad, i misread your mail. we agree. markup or not - you don't have
a simple mapping from char string bytes or even unicode codepoints to visible
chars. throwing markup in or not doesn't change anything here in principal.

> Tizen: maybe this is the crux of the issue. I do not see Tizen developers
> coming to the efl community to feed back on any of this so we don't have
> good visibility. Are you therefore the champion for everything going on
> over there that we need to take on? It's  kind of tricky to be spending
> lots of time building apps on our apis and yet find that invisible users of
> the api carry substantially more influence.

correct. it's a pain. but this is the reality of things. the vast majority are
disinterested in open source and are just doing their jobs. there is little to
zero encouragement to push them to upstream too. tizen has also significantly
altered efl... so it is very hard to help in many ways. but markup is not one
of them.

> The thing I get most from your email is that, as we decided to do markup by
> default in current apis, it is unwise to ever change it. If we will always

it's unwise to change without REALLY GOOD data. right now we have poor data.
have data on what people think. is it just a "oh... that's ... interesting"
moment when first discovered? is it a "crap crap. i hate this" or "wow. well i
expected a kind of markup anyway".

some people respond one way, others another way. those that may be perfectly
happy and silent now may become a complaining group later. i want people to
consider this. if there is no clear winner, then i would say "stay with what
you have as it causes less upsets and problems moving to it from existing efl
code". if there is clear data of happy vs "neutral - that's fine" vs
"unhappy" ... then i think a decision can be made to change if the data
supports it.

> be constrained by historical apis then why not just make an edict that the
> eo api must be a direct mirror of the legacy for compatibility reasons?...
> 
> Andy
> 
> On Sun, 2 Jul 2017 at 10:53, Carsten Haitzler  wrote:
> 
> > On Sat, 01 Jul 2017 06:37:03 + Andrew Williams 
> > said:
> >
> > > Hi,
> > >
> > > This is not the first time this has come up (just search phab for "HTML"
> > or
> > > "encoding") and given that we agreed we don't have many app developers it
> > > seems dismissive to state it's not a problem as we've had no complains
> > from
> > > app developers...
> >
> > first time it has come up on mailing lists or irc (as a
> > question/disatisfaction).
> >
> > there are are probably several times more developers using it in tizen...
> > and i
> > have never heard a complaint out of them about it.\
> >
> > i have seen many spreadsheets with complaints on efl from tizen base devs.
> > never was markup one of them.
> >
> > it's not dismissive. it's me saying that you lack a perspective i do. you
> > think
> > this move would be an improvement yet you have never seen what i have ...
> > and
> > i have a deep worry that what goes from no complaints suddenly becomes
> > "what i
> > used to be able to use markup.. now i can't? how do i make my text bold
> > now?"
> > "oh you have to sue the markup versions of all the text interfaces" "what?
> > i
> > didn't see that. why did you not make it default like before?". ... i
> > think YOU
> > are begin dismissive of this scenario. we go from no complaints there to
> > lots
> > of them.
> >
> > > Markup vs text does not introduce cursor problems that otherwise are
> > simple
> > > - just supporting UTF8 means you can't make assumptions about cursor vs
> > > text offset. Additionally that should only be a concern for entry which
> > is
> > > a very small subset of the text engine responsibilities.
> >
> > you can't make it WITH utf-8/unicode. read up the unicode standards and
> > check
> > with composite characters (ô == o + ^ unicode chars beside eachother for
> > example... there's far more complex ones for various languages - i'm not
> > talking input here... text strings). it's impossible to make an assumption
> > that
> > 1 utf8 char or even 1 unicdoe codepoint == 1 visible on screen character.
> > it's
> > impossible. if you go forward with this assumption you'll be bitterly
> > disappointed. it's an issue that has to be handled anyway.
> >
> > > In terms of complexity or api confusion I return to the path of 

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

As I'm on the move I have no decent email app so I can't interleave with
your replies so it's all up-top:

First time: Maybe not on ML but this has been discussed before on IRC, but
that does not exactly make angood source of documentation for issues or api
confusion.

UTF8: we are in agreement here, I think you misread my comment - I was
saying this complication is introduced by unicode so the markup does not
add that complexity.

Tizen: maybe this is the crux of the issue. I do not see Tizen developers
coming to the efl community to feed back on any of this so we don't have
good visibility. Are you therefore the champion for everything going on
over there that we need to take on? It's  kind of tricky to be spending
lots of time building apps on our apis and yet find that invisible users of
the api carry substantially more influence.

The thing I get most from your email is that, as we decided to do markup by
default in current apis, it is unwise to ever change it. If we will always
be constrained by historical apis then why not just make an edict that the
eo api must be a direct mirror of the legacy for compatibility reasons?...

Andy

On Sun, 2 Jul 2017 at 10:53, Carsten Haitzler  wrote:

> On Sat, 01 Jul 2017 06:37:03 + Andrew Williams 
> said:
>
> > Hi,
> >
> > This is not the first time this has come up (just search phab for "HTML"
> or
> > "encoding") and given that we agreed we don't have many app developers it
> > seems dismissive to state it's not a problem as we've had no complains
> from
> > app developers...
>
> first time it has come up on mailing lists or irc (as a
> question/disatisfaction).
>
> there are are probably several times more developers using it in tizen...
> and i
> have never heard a complaint out of them about it.\
>
> i have seen many spreadsheets with complaints on efl from tizen base devs.
> never was markup one of them.
>
> it's not dismissive. it's me saying that you lack a perspective i do. you
> think
> this move would be an improvement yet you have never seen what i have ...
> and
> i have a deep worry that what goes from no complaints suddenly becomes
> "what i
> used to be able to use markup.. now i can't? how do i make my text bold
> now?"
> "oh you have to sue the markup versions of all the text interfaces" "what?
> i
> didn't see that. why did you not make it default like before?". ... i
> think YOU
> are begin dismissive of this scenario. we go from no complaints there to
> lots
> of them.
>
> > Markup vs text does not introduce cursor problems that otherwise are
> simple
> > - just supporting UTF8 means you can't make assumptions about cursor vs
> > text offset. Additionally that should only be a concern for entry which
> is
> > a very small subset of the text engine responsibilities.
>
> you can't make it WITH utf-8/unicode. read up the unicode standards and
> check
> with composite characters (ô == o + ^ unicode chars beside eachother for
> example... there's far more complex ones for various languages - i'm not
> talking input here... text strings). it's impossible to make an assumption
> that
> 1 utf8 char or even 1 unicdoe codepoint == 1 visible on screen character.
> it's
> impossible. if you go forward with this assumption you'll be bitterly
> disappointed. it's an issue that has to be handled anyway.
>
> > In terms of complexity or api confusion I return to the path of least
> > surprise. Text apis should not unexpectedly encode content such that
> input
> > != output. Splitting the data from the metadata or making the setting of
>
> see above.
>
> > marked up text explicit avoids this confusion. For inspiration I point
> you
>
> it does not.
>
> > to the iOS APIs where they have "attributedString" (get/set etc) which is
> > different to the plain text methods. Additionally they avoid the
> > insert/replace issues by pushing those features into the string handling
> > rather than the widget which makes a lot of sense now I think about it.
> >
> > Thanks,
> > Andy
> > On Sat, 1 Jul 2017 at 03:33, Carsten Haitzler 
> wrote:
> >
> > > On Fri, 30 Jun 2017 16:22:03 +0200 Davide Andreoli <
> d...@gurumeditation.it
> > > >
> > > said:
> > >
> > > > 2017-06-30 1:37 GMT+02:00 Carsten Haitzler :
> > > >
> > > > > On Thu, 29 Jun 2017 11:13:51 + Andrew Williams <
> > > a...@andywilliams.me>
> > > > > said:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Just to wrap this thread up following EDD:
> > > > > >
> > > > > > * no-one is proposing that we remove the ability to mark up text
> > > through
> > > > > > the markup format mechanism, it is a great feature
> > > > > > * we cannot make changes to this legacy API as apps depend on it
> or
> > > have
> > > > > > adapted to it
> > > > > >
> > > > > > * the new textblock API, which is currently plain text only is
> being
> > > > > > extended with a solid markup API
> > > > > > * The existing markup format will be 

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Sat, 01 Jul 2017 06:37:03 + Andrew Williams  said:

> Hi,
> 
> This is not the first time this has come up (just search phab for "HTML" or
> "encoding") and given that we agreed we don't have many app developers it
> seems dismissive to state it's not a problem as we've had no complains from
> app developers...

first time it has come up on mailing lists or irc (as a
question/disatisfaction).

there are are probably several times more developers using it in tizen... and i
have never heard a complaint out of them about it.\

i have seen many spreadsheets with complaints on efl from tizen base devs.
never was markup one of them.

it's not dismissive. it's me saying that you lack a perspective i do. you think
this move would be an improvement yet you have never seen what i have ... and
i have a deep worry that what goes from no complaints suddenly becomes "what i
used to be able to use markup.. now i can't? how do i make my text bold now?"
"oh you have to sue the markup versions of all the text interfaces" "what? i
didn't see that. why did you not make it default like before?". ... i think YOU
are begin dismissive of this scenario. we go from no complaints there to lots
of them.

> Markup vs text does not introduce cursor problems that otherwise are simple
> - just supporting UTF8 means you can't make assumptions about cursor vs
> text offset. Additionally that should only be a concern for entry which is
> a very small subset of the text engine responsibilities.

you can't make it WITH utf-8/unicode. read up the unicode standards and check
with composite characters (ô == o + ^ unicode chars beside eachother for
example... there's far more complex ones for various languages - i'm not
talking input here... text strings). it's impossible to make an assumption that
1 utf8 char or even 1 unicdoe codepoint == 1 visible on screen character. it's
impossible. if you go forward with this assumption you'll be bitterly
disappointed. it's an issue that has to be handled anyway.

> In terms of complexity or api confusion I return to the path of least
> surprise. Text apis should not unexpectedly encode content such that input
> != output. Splitting the data from the metadata or making the setting of

see above.

> marked up text explicit avoids this confusion. For inspiration I point you

it does not.

> to the iOS APIs where they have "attributedString" (get/set etc) which is
> different to the plain text methods. Additionally they avoid the
> insert/replace issues by pushing those features into the string handling
> rather than the widget which makes a lot of sense now I think about it.
> 
> Thanks,
> Andy
> On Sat, 1 Jul 2017 at 03:33, Carsten Haitzler  wrote:
> 
> > On Fri, 30 Jun 2017 16:22:03 +0200 Davide Andreoli  > >
> > said:
> >
> > > 2017-06-30 1:37 GMT+02:00 Carsten Haitzler :
> > >
> > > > On Thu, 29 Jun 2017 11:13:51 + Andrew Williams <
> > a...@andywilliams.me>
> > > > said:
> > > >
> > > > > Hi,
> > > > >
> > > > > Just to wrap this thread up following EDD:
> > > > >
> > > > > * no-one is proposing that we remove the ability to mark up text
> > through
> > > > > the markup format mechanism, it is a great feature
> > > > > * we cannot make changes to this legacy API as apps depend on it or
> > have
> > > > > adapted to it
> > > > >
> > > > > * the new textblock API, which is currently plain text only is being
> > > > > extended with a solid markup API
> > > > > * The existing markup format will be supported through
> > _markup_text_set
> > > > or
> > > > > similar API leaving text_set/get to be plain text only
> > > > >
> > > > > It was beileved that this would satisfy all requirements whilst
> > removing
> > > > > any confusion about the nature of text encoding when using plain
> > text.
> > > > > This allows us to take a path-of-least-surprise approach for the new
> > Eo
> > > > > based text APIs
> > > >
> > > > you have to have a markup version of everything. set, append, prepend,
> > > > insert,
> > > > replace etc.
> > > >
> > >
> > > or something like "markup_mode_enabled" that you can set on the widget to
> > > enable/disable markup insert of text.
> >
> > actually this would be worse. any code calling an api to get or manipulate
> > text
> > needs to also always query mode first (maybe change it, then change it
> > back)...
> > so now instead of
> >
> >   text_set(obj, "Blah");
> >
> > you have
> >
> >   prev_mode = text_mode_get(obj);
> >   text_mode_set(obj, PLAIN);
> >   text_set(obj, "Blah");
> >   text_mode_set(obj, prev_mode);
> >
> > we could make it a push and pop... just to cut this down so it goes from 4
> > ro 3
> > lines... but still./.. not great (and the implementation actually needs to
> > keep
> > a real stack then not a counter).
> >
> > not knowing how your text is interpreted at all is very bad. you need to
> > know.
> > if there is only one way then there is no problem. if we 

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Sat, 1 Jul 2017 09:07:27 +0200 Davide Andreoli  said:

> 2017-07-01 4:28 GMT+02:00 Carsten Haitzler :
> 
> > On Fri, 30 Jun 2017 16:22:03 +0200 Davide Andreoli  > >
> > said:
> >
> > > 2017-06-30 1:37 GMT+02:00 Carsten Haitzler :
> > >
> > > > On Thu, 29 Jun 2017 11:13:51 + Andrew Williams <
> > a...@andywilliams.me>
> > > > said:
> > > >
> > > > > Hi,
> > > > >
> > > > > Just to wrap this thread up following EDD:
> > > > >
> > > > > * no-one is proposing that we remove the ability to mark up text
> > through
> > > > > the markup format mechanism, it is a great feature
> > > > > * we cannot make changes to this legacy API as apps depend on it or
> > have
> > > > > adapted to it
> > > > >
> > > > > * the new textblock API, which is currently plain text only is being
> > > > > extended with a solid markup API
> > > > > * The existing markup format will be supported through
> > _markup_text_set
> > > > or
> > > > > similar API leaving text_set/get to be plain text only
> > > > >
> > > > > It was beileved that this would satisfy all requirements whilst
> > removing
> > > > > any confusion about the nature of text encoding when using plain
> > text.
> > > > > This allows us to take a path-of-least-surprise approach for the new
> > Eo
> > > > > based text APIs
> > > >
> > > > you have to have a markup version of everything. set, append, prepend,
> > > > insert,
> > > > replace etc.
> > > >
> > >
> > > or something like "markup_mode_enabled" that you can set on the widget to
> > > enable/disable markup insert of text.
> >
> > actually this would be worse. any code calling an api to get or manipulate
> > text
> > needs to also always query mode first (maybe change it, then change it
> > back)...
> > so now instead of
> >
> >   text_set(obj, "Blah");
> >
> > you have
> >
> >   prev_mode = text_mode_get(obj);
> >   text_mode_set(obj, PLAIN);
> >   text_set(obj, "Blah");
> >   text_mode_set(obj, prev_mode);
> >
> > we could make it a push and pop... just to cut this down so it goes from 4
> > ro 3
> > lines... but still./.. not great (and the implementation actually needs to
> > keep
> > a real stack then not a counter).
> >
> 
> I was supposing the developer to set the mode right after object creation
> and then
> stay with that, ex:

you could do that but the above would still be needed because let's say you use
a helper api... or some other part of efl has to... do copy & paste and insert
text. what mode is it in? every api needs to handle all possible modes OR
always force the mode it wants then go back to where it was. the developer who
created the widget in their code is not always the only piece of code messing
with the text content.

> lb = elm_label_add(...)
> elm_text_mode_set(lb, MARKUP)
> 
> and then always use markup in your code for that widget,
> Isn't this the 99% of the usage case?
> 
> 
> >
> > not knowing how your text is interpreted at all is very bad. you need to
> > know.
> > if there is only one way then there is no problem. if we were going to have
> > lots of text modes (plain, markup, full html, rtf, ...) then maybe we'd
> > have to
> > live with the above mode thing as the api's would multiply like crazy...
> > the
> > alternative is we must pass format every time WITH the text
> >
> >   text_set(obj, PLAIN, "Blah");
> >
> > everyone is probably going to hate this too. we could make use of
> > "non-visible"
> > ascii chars as format markers like magic numbers for file formats...
> >
> >   #define PLAIN ""
> >   #define MARKUP "\001\001"
> >   #define HTML "\001\002"
> >   #define RTF "\001\003"
> >
> > etc. and we literally require you decode the header... (many values of the
> > first 32 ascii values other than \000 could be used for this as they can
> > never
> > be visibly displayed or mapped to a glyph and make zero sense to use so we
> > can
> > use them as control chars like \n, \t and \r (\012, \011 \015) are format
> > control chars and not directly mappable to a visible glyph on their own).
> > so
> > now you do:
> >
> >   text_set(obj, "Blah");
> >   text_set(obj, MARKUP"Blah");
> >
> > etc. but people will probably dislike this too... no matter how you slice
> > or
> > dice this, people will hate something. so make take is, you either do plain
> > text and give up on markup entirely other than having to use a whole bunch
> > of
> > metadata api's to apply it (that's going to be **FUN** on inserts ... -
> > not),
> > make wrappers that parse markup for you then do these (which means markup
> > versions of every query, set, insert, append etc.) and the implementation
> > is
> > going to be "fun" (what is a cursor pos? a char pos #, a utf8 byte value
> > offset? enjoy the figuring out of this as its likely going to be a visible
> > glyph/char pos) ...
> >
> > or you just bite the bullet and say "it's all markup. DEAL WITH IT" (and
> > provide some converters). only people i have 

Re: [E-devel] Elm_Entry assuming markup input???

[Davide Andreoli]

2017-07-01 4:28 GMT+02:00 Carsten Haitzler :

> On Fri, 30 Jun 2017 16:22:03 +0200 Davide Andreoli  >
> said:
>
> > 2017-06-30 1:37 GMT+02:00 Carsten Haitzler :
> >
> > > On Thu, 29 Jun 2017 11:13:51 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > Just to wrap this thread up following EDD:
> > > >
> > > > * no-one is proposing that we remove the ability to mark up text
> through
> > > > the markup format mechanism, it is a great feature
> > > > * we cannot make changes to this legacy API as apps depend on it or
> have
> > > > adapted to it
> > > >
> > > > * the new textblock API, which is currently plain text only is being
> > > > extended with a solid markup API
> > > > * The existing markup format will be supported through
> _markup_text_set
> > > or
> > > > similar API leaving text_set/get to be plain text only
> > > >
> > > > It was beileved that this would satisfy all requirements whilst
> removing
> > > > any confusion about the nature of text encoding when using plain
> text.
> > > > This allows us to take a path-of-least-surprise approach for the new
> Eo
> > > > based text APIs
> > >
> > > you have to have a markup version of everything. set, append, prepend,
> > > insert,
> > > replace etc.
> > >
> >
> > or something like "markup_mode_enabled" that you can set on the widget to
> > enable/disable markup insert of text.
>
> actually this would be worse. any code calling an api to get or manipulate
> text
> needs to also always query mode first (maybe change it, then change it
> back)...
> so now instead of
>
>   text_set(obj, "Blah");
>
> you have
>
>   prev_mode = text_mode_get(obj);
>   text_mode_set(obj, PLAIN);
>   text_set(obj, "Blah");
>   text_mode_set(obj, prev_mode);
>
> we could make it a push and pop... just to cut this down so it goes from 4
> ro 3
> lines... but still./.. not great (and the implementation actually needs to
> keep
> a real stack then not a counter).
>

I was supposing the developer to set the mode right after object creation
and then
stay with that, ex:

lb = elm_label_add(...)
elm_text_mode_set(lb, MARKUP)

and then always use markup in your code for that widget,
Isn't this the 99% of the usage case?


>
> not knowing how your text is interpreted at all is very bad. you need to
> know.
> if there is only one way then there is no problem. if we were going to have
> lots of text modes (plain, markup, full html, rtf, ...) then maybe we'd
> have to
> live with the above mode thing as the api's would multiply like crazy...
> the
> alternative is we must pass format every time WITH the text
>
>   text_set(obj, PLAIN, "Blah");
>
> everyone is probably going to hate this too. we could make use of
> "non-visible"
> ascii chars as format markers like magic numbers for file formats...
>
>   #define PLAIN ""
>   #define MARKUP "\001\001"
>   #define HTML "\001\002"
>   #define RTF "\001\003"
>
> etc. and we literally require you decode the header... (many values of the
> first 32 ascii values other than \000 could be used for this as they can
> never
> be visibly displayed or mapped to a glyph and make zero sense to use so we
> can
> use them as control chars like \n, \t and \r (\012, \011 \015) are format
> control chars and not directly mappable to a visible glyph on their own).
> so
> now you do:
>
>   text_set(obj, "Blah");
>   text_set(obj, MARKUP"Blah");
>
> etc. but people will probably dislike this too... no matter how you slice
> or
> dice this, people will hate something. so make take is, you either do plain
> text and give up on markup entirely other than having to use a whole bunch
> of
> metadata api's to apply it (that's going to be **FUN** on inserts ... -
> not),
> make wrappers that parse markup for you then do these (which means markup
> versions of every query, set, insert, append etc.) and the implementation
> is
> going to be "fun" (what is a cursor pos? a char pos #, a utf8 byte value
> offset? enjoy the figuring out of this as its likely going to be a visible
> glyph/char pos) ...
>
> or you just bite the bullet and say "it's all markup. DEAL WITH IT" (and
> provide some converters). only people i have heard complain are efl people
> and
> only now after many many many years who oddly didn't even read our own
> docs and
> find out it's markup... everyone else seems to be fine with it and expects
> markup...
>
> anecdotal statistics tells me that removing the "markup by default" is
> going to
> be a big mistake...
>
> > > > Thanks everyone for the discussion :)
> > > > Andy
> > > >
> > > > On Sat, 24 Jun 2017 at 05:39 Carsten Haitzler 
> > > wrote:
> > > >
> > > > > On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli <
> > > d...@gurumeditation.it
> > > > > >
> > > > > said:
> > > > >
> > > > > > 2017-06-19 13:36 GMT+02:00 Daniel Hirt :
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Mon, Jun 19, 2017 

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

Hi,

This is not the first time this has come up (just search phab for "HTML" or
"encoding") and given that we agreed we don't have many app developers it
seems dismissive to state it's not a problem as we've had no complains from
app developers...

Markup vs text does not introduce cursor problems that otherwise are simple
- just supporting UTF8 means you can't make assumptions about cursor vs
text offset. Additionally that should only be a concern for entry which is
a very small subset of the text engine responsibilities.

In terms of complexity or api confusion I return to the path of least
surprise. Text apis should not unexpectedly encode content such that input
!= output. Splitting the data from the metadata or making the setting of
marked up text explicit avoids this confusion. For inspiration I point you
to the iOS APIs where they have "attributedString" (get/set etc) which is
different to the plain text methods. Additionally they avoid the
insert/replace issues by pushing those features into the string handling
rather than the widget which makes a lot of sense now I think about it.

Thanks,
Andy
On Sat, 1 Jul 2017 at 03:33, Carsten Haitzler  wrote:

> On Fri, 30 Jun 2017 16:22:03 +0200 Davide Andreoli  >
> said:
>
> > 2017-06-30 1:37 GMT+02:00 Carsten Haitzler :
> >
> > > On Thu, 29 Jun 2017 11:13:51 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > Just to wrap this thread up following EDD:
> > > >
> > > > * no-one is proposing that we remove the ability to mark up text
> through
> > > > the markup format mechanism, it is a great feature
> > > > * we cannot make changes to this legacy API as apps depend on it or
> have
> > > > adapted to it
> > > >
> > > > * the new textblock API, which is currently plain text only is being
> > > > extended with a solid markup API
> > > > * The existing markup format will be supported through
> _markup_text_set
> > > or
> > > > similar API leaving text_set/get to be plain text only
> > > >
> > > > It was beileved that this would satisfy all requirements whilst
> removing
> > > > any confusion about the nature of text encoding when using plain
> text.
> > > > This allows us to take a path-of-least-surprise approach for the new
> Eo
> > > > based text APIs
> > >
> > > you have to have a markup version of everything. set, append, prepend,
> > > insert,
> > > replace etc.
> > >
> >
> > or something like "markup_mode_enabled" that you can set on the widget to
> > enable/disable markup insert of text.
>
> actually this would be worse. any code calling an api to get or manipulate
> text
> needs to also always query mode first (maybe change it, then change it
> back)...
> so now instead of
>
>   text_set(obj, "Blah");
>
> you have
>
>   prev_mode = text_mode_get(obj);
>   text_mode_set(obj, PLAIN);
>   text_set(obj, "Blah");
>   text_mode_set(obj, prev_mode);
>
> we could make it a push and pop... just to cut this down so it goes from 4
> ro 3
> lines... but still./.. not great (and the implementation actually needs to
> keep
> a real stack then not a counter).
>
> not knowing how your text is interpreted at all is very bad. you need to
> know.
> if there is only one way then there is no problem. if we were going to have
> lots of text modes (plain, markup, full html, rtf, ...) then maybe we'd
> have to
> live with the above mode thing as the api's would multiply like crazy...
> the
> alternative is we must pass format every time WITH the text
>
>   text_set(obj, PLAIN, "Blah");
>
> everyone is probably going to hate this too. we could make use of
> "non-visible"
> ascii chars as format markers like magic numbers for file formats...
>
>   #define PLAIN ""
>   #define MARKUP "\001\001"
>   #define HTML "\001\002"
>   #define RTF "\001\003"
>
> etc. and we literally require you decode the header... (many values of the
> first 32 ascii values other than \000 could be used for this as they can
> never
> be visibly displayed or mapped to a glyph and make zero sense to use so we
> can
> use them as control chars like \n, \t and \r (\012, \011 \015) are format
> control chars and not directly mappable to a visible glyph on their own).
> so
> now you do:
>
>   text_set(obj, "Blah");
>   text_set(obj, MARKUP"Blah");
>
> etc. but people will probably dislike this too... no matter how you slice
> or
> dice this, people will hate something. so make take is, you either do plain
> text and give up on markup entirely other than having to use a whole bunch
> of
> metadata api's to apply it (that's going to be **FUN** on inserts ... -
> not),
> make wrappers that parse markup for you then do these (which means markup
> versions of every query, set, insert, append etc.) and the implementation
> is
> going to be "fun" (what is a cursor pos? a char pos #, a utf8 byte value
> offset? enjoy the figuring out of this as its likely going to be a visible
> glyph/char pos) ...
>
> or 

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Fri, 30 Jun 2017 16:22:03 +0200 Davide Andreoli 
said:

> 2017-06-30 1:37 GMT+02:00 Carsten Haitzler :
> 
> > On Thu, 29 Jun 2017 11:13:51 + Andrew Williams 
> > said:
> >
> > > Hi,
> > >
> > > Just to wrap this thread up following EDD:
> > >
> > > * no-one is proposing that we remove the ability to mark up text through
> > > the markup format mechanism, it is a great feature
> > > * we cannot make changes to this legacy API as apps depend on it or have
> > > adapted to it
> > >
> > > * the new textblock API, which is currently plain text only is being
> > > extended with a solid markup API
> > > * The existing markup format will be supported through _markup_text_set
> > or
> > > similar API leaving text_set/get to be plain text only
> > >
> > > It was beileved that this would satisfy all requirements whilst removing
> > > any confusion about the nature of text encoding when using plain text.
> > > This allows us to take a path-of-least-surprise approach for the new Eo
> > > based text APIs
> >
> > you have to have a markup version of everything. set, append, prepend,
> > insert,
> > replace etc.
> >
> 
> or something like "markup_mode_enabled" that you can set on the widget to
> enable/disable markup insert of text.

actually this would be worse. any code calling an api to get or manipulate text
needs to also always query mode first (maybe change it, then change it back)...
so now instead of

  text_set(obj, "Blah");

you have

  prev_mode = text_mode_get(obj);
  text_mode_set(obj, PLAIN);
  text_set(obj, "Blah");
  text_mode_set(obj, prev_mode);

we could make it a push and pop... just to cut this down so it goes from 4 ro 3
lines... but still./.. not great (and the implementation actually needs to keep
a real stack then not a counter).

not knowing how your text is interpreted at all is very bad. you need to know.
if there is only one way then there is no problem. if we were going to have
lots of text modes (plain, markup, full html, rtf, ...) then maybe we'd have to
live with the above mode thing as the api's would multiply like crazy... the
alternative is we must pass format every time WITH the text

  text_set(obj, PLAIN, "Blah");

everyone is probably going to hate this too. we could make use of "non-visible"
ascii chars as format markers like magic numbers for file formats...

  #define PLAIN ""
  #define MARKUP "\001\001"
  #define HTML "\001\002"
  #define RTF "\001\003"

etc. and we literally require you decode the header... (many values of the
first 32 ascii values other than \000 could be used for this as they can never
be visibly displayed or mapped to a glyph and make zero sense to use so we can
use them as control chars like \n, \t and \r (\012, \011 \015) are format
control chars and not directly mappable to a visible glyph on their own). so
now you do:

  text_set(obj, "Blah");
  text_set(obj, MARKUP"Blah");

etc. but people will probably dislike this too... no matter how you slice or
dice this, people will hate something. so make take is, you either do plain
text and give up on markup entirely other than having to use a whole bunch of
metadata api's to apply it (that's going to be **FUN** on inserts ... - not),
make wrappers that parse markup for you then do these (which means markup
versions of every query, set, insert, append etc.) and the implementation is
going to be "fun" (what is a cursor pos? a char pos #, a utf8 byte value
offset? enjoy the figuring out of this as its likely going to be a visible
glyph/char pos) ...

or you just bite the bullet and say "it's all markup. DEAL WITH IT" (and
provide some converters). only people i have heard complain are efl people and
only now after many many many years who oddly didn't even read our own docs and
find out it's markup... everyone else seems to be fine with it and expects
markup...

anecdotal statistics tells me that removing the "markup by default" is going to
be a big mistake...

> > > Thanks everyone for the discussion :)
> > > Andy
> > >
> > > On Sat, 24 Jun 2017 at 05:39 Carsten Haitzler 
> > wrote:
> > >
> > > > On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli <
> > d...@gurumeditation.it
> > > > >
> > > > said:
> > > >
> > > > > 2017-06-19 13:36 GMT+02:00 Daniel Hirt :
> > > > > > 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.
> > > > > >>
> > > > > >>
> > > > > > 

Re: [E-devel] Elm_Entry assuming markup input???

[Davide Andreoli]

2017-06-30 1:37 GMT+02:00 Carsten Haitzler :

> On Thu, 29 Jun 2017 11:13:51 + Andrew Williams 
> said:
>
> > Hi,
> >
> > Just to wrap this thread up following EDD:
> >
> > * no-one is proposing that we remove the ability to mark up text through
> > the markup format mechanism, it is a great feature
> > * we cannot make changes to this legacy API as apps depend on it or have
> > adapted to it
> >
> > * the new textblock API, which is currently plain text only is being
> > extended with a solid markup API
> > * The existing markup format will be supported through _markup_text_set
> or
> > similar API leaving text_set/get to be plain text only
> >
> > It was beileved that this would satisfy all requirements whilst removing
> > any confusion about the nature of text encoding when using plain text.
> > This allows us to take a path-of-least-surprise approach for the new Eo
> > based text APIs
>
> you have to have a markup version of everything. set, append, prepend,
> insert,
> replace etc.
>

or something like "markup_mode_enabled" that you can set on the widget to
enable/disable markup insert of text.


>
> > Thanks everyone for the discussion :)
> > Andy
> >
> > On Sat, 24 Jun 2017 at 05:39 Carsten Haitzler 
> wrote:
> >
> > > On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli <
> d...@gurumeditation.it
> > > >
> > > said:
> > >
> > > > 2017-06-19 13:36 GMT+02:00 Daniel Hirt :
> > > > > 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...
> > 

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Thu, 29 Jun 2017 11:13:51 + Andrew Williams  said:

> Hi,
> 
> Just to wrap this thread up following EDD:
> 
> * no-one is proposing that we remove the ability to mark up text through
> the markup format mechanism, it is a great feature
> * we cannot make changes to this legacy API as apps depend on it or have
> adapted to it
> 
> * the new textblock API, which is currently plain text only is being
> extended with a solid markup API
> * The existing markup format will be supported through _markup_text_set or
> similar API leaving text_set/get to be plain text only
> 
> It was beileved that this would satisfy all requirements whilst removing
> any confusion about the nature of text encoding when using plain text.
> This allows us to take a path-of-least-surprise approach for the new Eo
> based text APIs

you have to have a markup version of everything. set, append, prepend, insert,
replace etc.

> Thanks everyone for the discussion :)
> Andy
> 
> On Sat, 24 Jun 2017 at 05:39 Carsten Haitzler  wrote:
> 
> > On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli  > >
> > said:
> >
> > > 2017-06-19 13:36 GMT+02:00 Daniel Hirt :
> > > > 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 

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

Hi,

Just to wrap this thread up following EDD:

* no-one is proposing that we remove the ability to mark up text through
the markup format mechanism, it is a great feature
* we cannot make changes to this legacy API as apps depend on it or have
adapted to it

* the new textblock API, which is currently plain text only is being
extended with a solid markup API
* The existing markup format will be supported through _markup_text_set or
similar API leaving text_set/get to be plain text only

It was beileved that this would satisfy all requirements whilst removing
any confusion about the nature of text encoding when using plain text.
This allows us to take a path-of-least-surprise approach for the new Eo
based text APIs

Thanks everyone for the discussion :)
Andy

On Sat, 24 Jun 2017 at 05:39 Carsten Haitzler  wrote:

> On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli  >
> said:
>
> > 2017-06-19 13:36 GMT+02:00 Daniel Hirt :
> > > 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,
> >
> > What? no more markup support? 

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Fri, 23 Jun 2017 21:55:14 +0200 Davide Andreoli 
said:

> 2017-06-19 13:36 GMT+02:00 Daniel Hirt :
> > Hi,
> >
> > On Mon, Jun 19, 2017 at 12:01 PM, Andrew Williams 
> > 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,
> 
> What? no more markup support? This is really, really sad to hear :(

i've ben trying to tell people that markup is LESS bad than no markup (or
having to do it via api calls)... but the people giving the opinions on this
aren't writing the apps. 

maybe you c an convince them.

> I'm using markup everywhere in my media center and I'm really happy with
> it's usage.

too bad. plain text for you unless you call lots of api calls to insert it tag
by tag. have fun. 

> Please think carefully at my use case:
> 
> http://www.enlightenment.org/ss/e-594d67c3ee4752.10999768.jpg
> 
> Look at the the textblock in the lower-right corner,
> the code to set the text is something like this:
> 
> text = sprintf("%s %s"
>"%s %s / %s %s"
>"%s %s / "
>"%s %s / "
>"%s %s%s",
>video.name, video.duration,
>_('user'), video.user,
>_('uploaded'), relative_date(video.created_time),
>views, ngettext('view', 'views', views),
>likes, ngettext('like', 'likes', likes),
>comments, ngettext('comment', 'comments', comments),
>video.description)
> 
> ..thats 

Re: [E-devel] Elm_Entry assuming markup input???

[Davide Andreoli]

2017-06-19 13:36 GMT+02:00 Daniel Hirt :
> Hi,
>
> On Mon, Jun 19, 2017 at 12:01 PM, Andrew Williams 
> 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,

What? no more markup support? This is really, really sad to hear :(

I'm using markup everywhere in my media center and I'm really happy with
it's usage.

Please think carefully at my use case:

http://www.enlightenment.org/ss/e-594d67c3ee4752.10999768.jpg

Look at the the textblock in the lower-right corner,
the code to set the text is something like this:

text = sprintf("%s %s"
   "%s %s / %s %s"
   "%s %s / "
   "%s %s / "
   "%s %s%s",
   video.name, video.duration,
   _('user'), video.user,
   _('uploaded'), relative_date(video.created_time),
   views, ngettext('view', 'views', views),
   likes, ngettext('like', 'likes', likes),
   comments, ngettext('comment', 'comments', comments),
   video.description)

..thats it, and I have those beautiful (theme-able!) formatted text.

Now try to think at the code needed to do the same with the "new" API !!

Another insurmountable problem of the API approach: the text in my example
comes from plugins (the vimeo plugin in this case) that are separate
processes
from the core mediacenter, plugins just fetch datas from the net and pass
them back to the core. This means that the plugins do not have access to the
textblock API.

Some more examples:
https://github.com/DaveMDS/epymc/wiki/Screenshots

I can understand the initial issue Andrew was speaking in this thread
(text_get
is difficult to use). And I agree 

Re: [E-devel] Elm_Entry assuming markup input???

[Daniel Hirt]

Hi,

On Mon, Jun 19, 2017 at 12:01 PM, Andrew Williams 
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

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Mon, 19 Jun 2017 09:01:50 + Andrew Williams  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 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  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  wrote:
> 
> > On Sun, 18 Jun 2017 20:18:33 + Andrew Williams 
> > 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 "ab" - 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

Re: [E-devel] Elm_Entry assuming markup input???

[Mike Blumenkrantz]

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 
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 
> wrote:
>
> > On Sun, 18 Jun 2017 20:18:33 + Andrew Williams  >
> > 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 "ab" - 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

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

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  wrote:

> On Sun, 18 Jun 2017 20:18:33 + Andrew Williams 
> 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 "ab" - 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

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Sun, 18 Jun 2017 16:53:34 -0700 Cedric BAIL  said:

> On Sun, Jun 18, 2017 at 4:45 PM, Carsten Haitzler 
> wrote:
> > On Sun, 18 Jun 2017 16:20:59 -0700 Cedric BAIL  said:
> >> On Sun, Jun 18, 2017 at 3:58 PM, Carsten Haitzler 
> >> wrote:
> >> > On Sun, 18 Jun 2017 15:22:04 -0700 Cedric BAIL 
> >> > said:
> >> >> On Sun, Jun 18, 2017 at 3:07 PM, Andrew Williams 
> >> >> wrote:
> >> >> > Can we be a little careful with that response? The behaviour you think
> >> >> > people are relying on is undocumented and confusing. Are people truly
> >> >> > relying on the "HTML encoding" behaviour of user input?
> >> >> > I think that something so unintuitive is better fixed rather than live
> >> >> > with it forever!
> >> >> > Simple user input such as "user" is not being returned as
> >> >> > expected and I really don't want to be the kind of framework that
> >> >> > instructs developers to use workarounds especially as we roll out a
> >> >> > shiny new API.
> >> >>
> >> >> I do agree with both of you, Kai and Andrew. My proposal to fix this
> >> >> problem is to fix it in the new API, eo based, and make sure that we
> >> >> don't repeat this problem. What do you think Daniel ?
> >> >
> >> > i disagree. we should do markup by default in most places where text is
> >> > to be displayed. not only do the back-ends already do it (textblock) it's
> >> > convenient for just adding some bold or underlined text but also allows
> >> > us to trivially extend. add another method to get/set plain utf8. markup
> >> > in general is more useful.
> >>
> >> It is obviously confusing to people and has created bugs in the past.
> >> People do expect they get text when they ask for text, not markup. If
> >> you call .text() in JS, you don't get markup, you get text. I really
> >> believe this is making our API harder to use without mistake.
> >> .text.get() and .markup.get() should be 2 differents exposed API. Them
> >> being available on every object is fine, but text should not return
> >> markup.
> >
> > yet in js's home turf (web) all text i/o for a document (the tree of
> > widgets so to speak) is markup.
> 
> Expectation in JS world seems to point toward what I just said above.
> https://www.w3schools.com/jquery/html_text.asp .

but document.write() takes html (and defines widgets and content and everyone
does widgets as divs with content these days basically).

but our docs are incredibly clear the text is markup. in this case the docs
were not read and an assumption was made. that assumption was wrong.

i suspect if we stop doing markup by default we'll have even more complaints.
so far i have never heard a complaint about our text being markup for
entries/labels ... i HAVE heard complaints that buttons, checkboxes don't
support markup (text vs textblock) and people expected/wanted markup.

i don't see enough evidence to change the default here. i have seen the reverse
(expecting and wanting markup but not getting it).

we do have inconsistency though and that needs to be fixed (support markup
everywhere).


-- 
- 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

Re: [E-devel] Elm_Entry assuming markup input???

[Cedric BAIL]

On Sun, Jun 18, 2017 at 4:45 PM, Carsten Haitzler  wrote:
> On Sun, 18 Jun 2017 16:20:59 -0700 Cedric BAIL  said:
>> On Sun, Jun 18, 2017 at 3:58 PM, Carsten Haitzler 
>> wrote:
>> > On Sun, 18 Jun 2017 15:22:04 -0700 Cedric BAIL  said:
>> >> On Sun, Jun 18, 2017 at 3:07 PM, Andrew Williams 
>> >> wrote:
>> >> > Can we be a little careful with that response? The behaviour you think
>> >> > people are relying on is undocumented and confusing. Are people truly
>> >> > relying on the "HTML encoding" behaviour of user input?
>> >> > I think that something so unintuitive is better fixed rather than live
>> >> > with it forever!
>> >> > Simple user input such as "user" is not being returned as 
>> >> > expected
>> >> > and I really don't want to be the kind of framework that instructs
>> >> > developers to use workarounds especially as we roll out a shiny new API.
>> >>
>> >> I do agree with both of you, Kai and Andrew. My proposal to fix this
>> >> problem is to fix it in the new API, eo based, and make sure that we
>> >> don't repeat this problem. What do you think Daniel ?
>> >
>> > i disagree. we should do markup by default in most places where text is to
>> > be displayed. not only do the back-ends already do it (textblock) it's
>> > convenient for just adding some bold or underlined text but also allows us
>> > to trivially extend. add another method to get/set plain utf8. markup in
>> > general is more useful.
>>
>> It is obviously confusing to people and has created bugs in the past.
>> People do expect they get text when they ask for text, not markup. If
>> you call .text() in JS, you don't get markup, you get text. I really
>> believe this is making our API harder to use without mistake.
>> .text.get() and .markup.get() should be 2 differents exposed API. Them
>> being available on every object is fine, but text should not return
>> markup.
>
> yet in js's home turf (web) all text i/o for a document (the tree of widgets 
> so
> to speak) is markup.

Expectation in JS world seems to point toward what I just said above.
https://www.w3schools.com/jquery/html_text.asp .
-- 
Cedric BAIL

--
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

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Sun, 18 Jun 2017 16:20:59 -0700 Cedric BAIL  said:

> On Sun, Jun 18, 2017 at 3:58 PM, Carsten Haitzler 
> wrote:
> > On Sun, 18 Jun 2017 15:22:04 -0700 Cedric BAIL  said:
> >> On Sun, Jun 18, 2017 at 3:07 PM, Andrew Williams 
> >> wrote:
> >> > Can we be a little careful with that response? The behaviour you think
> >> > people are relying on is undocumented and confusing. Are people truly
> >> > relying on the "HTML encoding" behaviour of user input?
> >> > I think that something so unintuitive is better fixed rather than live
> >> > with it forever!
> >> > Simple user input such as "user" is not being returned as expected
> >> > and I really don't want to be the kind of framework that instructs
> >> > developers to use workarounds especially as we roll out a shiny new API.
> >>
> >> I do agree with both of you, Kai and Andrew. My proposal to fix this
> >> problem is to fix it in the new API, eo based, and make sure that we
> >> don't repeat this problem. What do you think Daniel ?
> >
> > i disagree. we should do markup by default in most places where text is to
> > be displayed. not only do the back-ends already do it (textblock) it's
> > convenient for just adding some bold or underlined text but also allows us
> > to trivially extend. add another method to get/set plain utf8. markup in
> > general is more useful.
> 
> It is obviously confusing to people and has created bugs in the past.
> People do expect they get text when they ask for text, not markup. If
> you call .text() in JS, you don't get markup, you get text. I really
> believe this is making our API harder to use without mistake.
> .text.get() and .markup.get() should be 2 differents exposed API. Them
> being available on every object is fine, but text should not return
> markup.

yet in js's home turf (web) all text i/o for a document (the tree of widgets so
to speak) is markup.


-- 
- 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

Re: [E-devel] Elm_Entry assuming markup input???

[Cedric BAIL]

On Sun, Jun 18, 2017 at 3:58 PM, Carsten Haitzler  wrote:
> On Sun, 18 Jun 2017 15:22:04 -0700 Cedric BAIL  said:
>> On Sun, Jun 18, 2017 at 3:07 PM, Andrew Williams  
>> wrote:
>> > Can we be a little careful with that response? The behaviour you think
>> > people are relying on is undocumented and confusing. Are people truly
>> > relying on the "HTML encoding" behaviour of user input?
>> > I think that something so unintuitive is better fixed rather than live with
>> > it forever!
>> > Simple user input such as "user" is not being returned as expected
>> > and I really don't want to be the kind of framework that instructs
>> > developers to use workarounds especially as we roll out a shiny new API.
>>
>> I do agree with both of you, Kai and Andrew. My proposal to fix this
>> problem is to fix it in the new API, eo based, and make sure that we
>> don't repeat this problem. What do you think Daniel ?
>
> i disagree. we should do markup by default in most places where text is to be
> displayed. not only do the back-ends already do it (textblock) it's convenient
> for just adding some bold or underlined text but also allows us to trivially
> extend. add another method to get/set plain utf8. markup in general is more
> useful.

It is obviously confusing to people and has created bugs in the past.
People do expect they get text when they ask for text, not markup. If
you call .text() in JS, you don't get markup, you get text. I really
believe this is making our API harder to use without mistake.
.text.get() and .markup.get() should be 2 differents exposed API. Them
being available on every object is fine, but text should not return
markup.
-- 
Cedric BAIL

--
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

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Mon, 19 Jun 2017 07:55:01 +0900 Carsten Haitzler (The Rasterman)
 said:

> On Sun, 18 Jun 2017 20:18:33 + Andrew Williams 
> 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 "ab" - 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.

7. VERY clearly documented:

https://docs.enlightenment.org/efl/current/group__Elm__Entry.html

scroll down... "formatted text".

> 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
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- 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

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Sun, 18 Jun 2017 20:18:33 + Andrew Williams  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 "ab" - 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
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Elm_Entry assuming markup input???

[The Rasterman]

On Sun, 18 Jun 2017 15:22:04 -0700 Cedric BAIL  said:

> Hi,
> 
> On Sun, Jun 18, 2017 at 3:07 PM, Andrew Williams  wrote:
> > Can we be a little careful with that response? The behaviour you think
> > people are relying on is undocumented and confusing. Are people truly
> > relying on the "HTML encoding" behaviour of user input?
> > I think that something so unintuitive is better fixed rather than live with
> > it forever!
> > Simple user input such as "user" is not being returned as expected
> > and I really don't want to be the kind of framework that instructs
> > developers to use workarounds especially as we roll out a shiny new API.
> 
> I do agree with both of you, Kai and Andrew. My proposal to fix this
> problem is to fix it in the new API, eo based, and make sure that we
> don't repeat this problem. What do you think Daniel ?

i disagree. we should do markup by default in most places where text is to be
displayed. not only do the back-ends already do it (textblock) it's convenient
for just adding some bold or underlined text but also allows us to trivially
extend. add another method to get/set plain utf8. markup in general is more
useful.

> Best,
>   Cedric
> 
> > On Sun, 18 Jun 2017 at 22:39, Kai Huuhko  wrote:
> >> 2017-06-19 0:11 GMT+03:00 Andrew Williams :
> >> > Marking up an input field is not the most common use-case - and is surely
> >> > inputted by the app rather than the user normally?
> >> >
> >> > I propose that ...text_get should return stripped markup and a new method
> >> > markup_text_get returns the current stuff. That would cater for both use
> >> > cases...
> >>
> >> This would break existing applications relying on the old behavior. I
> >> think we should not to break things more; if anything a method could
> >> be added for returning utf8 text directly. But I believe the helper
> >> functions do their job just as well.
> >>
> >> >
> >> > Thanks,
> >> > Andrew
> >> > On Sun, 18 Jun 2017 at 22:00, Daniel Hirt  wrote:
> >> >
> >> >> Hi Andrew,
> >> >>
> >> >> Markup uses tags like 

Re: [E-devel] Elm_Entry assuming markup input???

[Cedric BAIL]

Hi,

On Sun, Jun 18, 2017 at 3:07 PM, Andrew Williams  wrote:
> Can we be a little careful with that response? The behaviour you think
> people are relying on is undocumented and confusing. Are people truly
> relying on the "HTML encoding" behaviour of user input?
> I think that something so unintuitive is better fixed rather than live with
> it forever!
> Simple user input such as "user" is not being returned as expected
> and I really don't want to be the kind of framework that instructs
> developers to use workarounds especially as we roll out a shiny new API.

I do agree with both of you, Kai and Andrew. My proposal to fix this
problem is to fix it in the new API, eo based, and make sure that we
don't repeat this problem. What do you think Daniel ?

Best,
  Cedric

> On Sun, 18 Jun 2017 at 22:39, Kai Huuhko  wrote:
>> 2017-06-19 0:11 GMT+03:00 Andrew Williams :
>> > Marking up an input field is not the most common use-case - and is surely
>> > inputted by the app rather than the user normally?
>> >
>> > I propose that ...text_get should return stripped markup and a new method
>> > markup_text_get returns the current stuff. That would cater for both use
>> > cases...
>>
>> This would break existing applications relying on the old behavior. I
>> think we should not to break things more; if anything a method could
>> be added for returning utf8 text directly. But I believe the helper
>> functions do their job just as well.
>>
>> >
>> > Thanks,
>> > Andrew
>> > On Sun, 18 Jun 2017 at 22:00, Daniel Hirt  wrote:
>> >
>> >> Hi Andrew,
>> >>
>> >> Markup uses tags like 

Re: [E-devel] Elm_Entry assuming markup input???

[Rbt. Y-Lee]

It is python but this caused us (Bodhi linux) some headache with Jeffs
esudo program: https://github.com/JeffHoogland/esudo/issues/2

On Sun, Jun 18, 2017 at 4:59 PM, Daniel Hirt  wrote:

> Hi Andrew,
>
> Markup uses tags like 

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

Can we be a little careful with that response? The behaviour you think
people are relying on is undocumented and confusing. Are people truly
relying on the "HTML encoding" behaviour of user input?
I think that something so unintuitive is better fixed rather than live with
it forever!
Simple user input such as "user" is not being returned as expected
and I really don't want to be the kind of framework that instructs
developers to use workarounds especially as we roll out a shiny new API.

Andy
On Sun, 18 Jun 2017 at 22:39, Kai Huuhko  wrote:

> 2017-06-19 0:11 GMT+03:00 Andrew Williams :
> > Marking up an input field is not the most common use-case - and is surely
> > inputted by the app rather than the user normally?
> >
> > I propose that ...text_get should return stripped markup and a new method
> > markup_text_get returns the current stuff. That would cater for both use
> > cases...
>
> This would break existing applications relying on the old behavior. I
> think we should not to break things more; if anything a method could
> be added for returning utf8 text directly. But I believe the helper
> functions do their job just as well.
>
> >
> > Thanks,
> > Andrew
> > On Sun, 18 Jun 2017 at 22:00, Daniel Hirt  wrote:
> >
> >> Hi Andrew,
> >>
> >> Markup uses tags like 

Re: [E-devel] Elm_Entry assuming markup input???

[Kai Huuhko]

2017-06-19 0:11 GMT+03:00 Andrew Williams :
> Marking up an input field is not the most common use-case - and is surely
> inputted by the app rather than the user normally?
>
> I propose that ...text_get should return stripped markup and a new method
> markup_text_get returns the current stuff. That would cater for both use
> cases...

This would break existing applications relying on the old behavior. I
think we should not to break things more; if anything a method could
be added for returning utf8 text directly. But I believe the helper
functions do their job just as well.

>
> Thanks,
> Andrew
> On Sun, 18 Jun 2017 at 22:00, Daniel Hirt  wrote:
>
>> Hi Andrew,
>>
>> Markup uses tags like 

Re: [E-devel] Elm_Entry assuming markup input???

[Al Poole]

It's certainly a bit of a surprising feature. An additional method would
save loads of code duplication? Also documenting the behaviour?

On Sun, Jun 18, 2017 at 10:11 PM, Andrew Williams 
wrote:

> Marking up an input field is not the most common use-case - and is surely
> inputted by the app rather than the user normally?
>
> I propose that ...text_get should return stripped markup and a new method
> markup_text_get returns the current stuff. That would cater for both use
> cases...
>
> Thanks,
> Andrew
> On Sun, 18 Jun 2017 at 22:00, Daniel Hirt  wrote:
>
> > Hi Andrew,
> >
> > Markup uses tags like 

Re: [E-devel] Elm_Entry assuming markup input???

[Andrew Williams]

Marking up an input field is not the most common use-case - and is surely
inputted by the app rather than the user normally?

I propose that ...text_get should return stripped markup and a new method
markup_text_get returns the current stuff. That would cater for both use
cases...

Thanks,
Andrew
On Sun, 18 Jun 2017 at 22:00, Daniel Hirt  wrote:

> Hi Andrew,
>
> Markup uses tags like 

Re: [E-devel] Elm_Entry assuming markup input???

[Daniel Hirt]

Hi Andrew,

Markup uses tags like