ID:2159186
 
BYOND Version:510
Operating System:Windows 10 Pro
Web Browser:Chrome 53.0.2785.143
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
I've into a problem where the \a macro followed by an href was causing variables to be inappropriately moved around/replaced. The text ref which started the href link was replaced with just the [src] giving the name. And another variable entirely within the href text was replaced with the \ref[src] text ref.

It's possible other text macros also have collisions with hrefs, but I couldn't tell you as I only tested this specific instance.

Numbered Steps to Reproduce Problem:
1. Have the \a text ref macro before an href
2. Have the src=\ref[src]
3. Have some other variable following within the text of the href

Code Snippet (if applicable) to Reproduce Problem:
Essentially this code
to_chat(U, "<span class='name'>[U]</span> holds \a <a href='byond://?src=\ref[src];showpicture=\ref[W]'>[thename] up</a> to one of your cameras ...")


Was being compiled as this code
to_chat(U, "<span class='name'>[U]</span> holds \a <a href='byond://?src=[src];showpicture=\ref[W]'>\ref[src] up</a> to one of your cameras ...")


The \a macro caused the text ref macro on the src to be replaced with just src (making the href link just show the name of the object), and caused the variable within the href text [thename] to be entirely replaced by \ref[src]

Expected Results:
I expected to get this in my chat

Admin holds a Monitor Decryption Key up to one of your cameras ...
(href link when hovered over)
byond://?src=[0x6008bcb];showpicture=[0x2004f63]

Actual Results:
I received something like this instead

Admin holds a [0x6008bcb] up to one of your cameras ...
(href link when hovered over)
byond://?src=security camera;showpicture=[0x2004f63]

When does the problem NOT occur?
It doesn't occur when I place another variable between the \a and the href link.

Workarounds:
Put other variables before the href link and after the \a, I suppose. Perhaps even an empty [] would suffice, though it would certainly look odd, not to mention it would invalidate the point of using \a in the first place.
I don't think this is actually a bug, as such; the \a macro expects to be followed by a value, but you're not following it with a value; you're following it with another macro. DM doesn't expect macros and their values to "nest" like this.
I can see where you're coming from, but if I wanted to do \a [thing], then I would never have the choice of have [thing] being a clickable href link by itself while still interacting with \a because \a would instead always break the href.

It's also a concern that this relatively unknowable behavior may be causing issues in other portions of code, similar to the ones I experienced. After all, I spent 4 hours trying to make a small 15 minute fix just to discover this in the first place, and even then I didn't find it myself until I explained my problem to several other people, the last of which pointed it out to me.
Indeed; I don't see a viable workaround handy.

Still, altering this behavior (if feasible) would not fix the problem across the board right away. Chances are this fix would apply mostly client-side, and as such it would take a while to disseminate.
we need a way to do these kinds of macros on something that isn't itself printed.

like \self\a[thing] would just print a/an without the thing.