17:53Coming from red/bugs. @Oldes noted this old behavior:
For tags, the brackets are included, except for
How you get around that today is not great:
Of course, the current
We could *almost* get tricky and say
It *may* be as simple as adding a check for tags [here](https://github.com/red/red/blob/master/runtime/datatypes/string.reds#L2273) to change this, and then you would need to use
Thoughts?
>> append <a> <b> == <a<b>>
Append/Insert/Change behavior is tricky. It tripped people up in R2, but may lead to other questions. I hope @meijeru is watching, because he is really good at thinking about big picture consistency. Consider these:>> append "a" <b>
== "a<b>"
>> append "a" "b"
== "ab"
>> append "a" mold "b"
== {a"b"}
>> head change <a> <b>
== <b>
>> head insert <a> <b>
== <<b>a>For tags, the brackets are included, except for
change. To get them for normal strings, you need to use mold. I think consistency would be better there. But why does it happen? Because of how form works for tags. This was clearly done for Rebol compatibility, and if we change it, we break old code. I don't know how much relies on it, but I will guess not much.>> form <b> == "<b>" >> head insert <a> form <b> == <<b>a>
How you get around that today is not great:
>> head insert <a> as string! <b> == <ba>
Of course, the current
form behavior makes sense. The user-friendly version of a tag is still a tag.Append doesn't say it forms the value if the series is a string, but we all learn that pretty quick. There is no rule to say it *has to* do strictly that though. There are conflicting consistencies at play.We could *almost* get tricky and say
/only with strings includes quotes/brackets, but it's no shorter than mold, and is then inconsistent with mold/only on blocks which *excludes* the brackets.It *may* be as simple as adding a check for tags [here](https://github.com/red/red/blob/master/runtime/datatypes/string.reds#L2273) to change this, and then you would need to use
mold, as with strings, to get the brackets. Thoughts?
17:59I can't remember using tags even once, can't say about including or not decorations. But
change should work as remove/part + insert, not be an outlier, else it's an ill design IMO.18:11I haven't used tags much historically, having been lucky enough not to need to generate markup too often. Of course, people can always use "<fake tag>" formats when doing that, but it would be nicer not too. And a lot of people will use tags, if the world at large is any indication.
18:16Since I don't use markup much, I have to rely on memory of people expecting things like this to work:
>> append <img > <src="red.png"> == <img <src="red.png">>
18:16And I don't remember ever using
build-tag in R2, so someone else will have to comment on how well it worked and for what use cases.18:22Could be something one would expect with tags (on question of form-ing):
>> rejoin ["" <a> 'text </a>] == "<a>text</a>"
18:25Indeed, which may be the reason for the original design, as that's a common idiom.
19:12I don't think that
![]()
>19:12I don't think that there is anybody using tags for something else than parsing, because current tags are quite not clever enough.
19:16Imho... it would be more practical to have:
"" = append 19:18Sounds like we need to write up a tag design RFC.
19:18And main reason, why tags are not used.
19:20On the other side, I can imagine, that someone may want to build a tag using:
>> append <a> { href=http://}
== <a href=http://>19:21But maybe it would be more practical not to need the space:
>> append <a> {href=http://}
== <a href=http://>19:23With automatic space you won't be able to remove it easily when you *don't* need it ☻
19:24Exactly.. so I don't know :-/ hard to decide.. but making tags, which are not a tags is a nonsense.
19:29Although building a markup without input sanitation is a nonsense too:)
19:31Maybe there should just be a scanner on the second value and if it would contain
< or > chars, there should be an error when first value is a tag.19:33What if it's
append { text=""}?19:38> Maybe there should just be a scanner on the second value and if it would contain
That's outside the scope of data manipulation at this level.
< or > chars, there should be an error when first value is a tag.That's outside the scope of data manipulation at this level.
19:48Here's my intitial thought: tags are a special kind of "string" in that the delimiters are somehow part of the value. I would not find it inconsistent therefore, nor overly inconvenient, to have
> = append change. For consistency, I would expect change to yield <>.21:45For series actions like
append/insert/change if both arguments types are tag! returning an error looks better to me. Because that action is meaningless.