If a comment or node description references the same post multiple times, it can make reading the post rather difficult.

I think this comment pretty well demonstrate the problem: #1875632-43: JS settings merging behavior: preserve integer keys (allow for array literals in drupalSettings), where an issue was referenced 4 times in about 6 sentences:

#39: HAH! Irony wants that this precise bug was introduced at #1812866: Rebuild the server side AJAX API and reported by me. I pointed the people who introduced that into the right direction by debugging it. Adding test coverage for this was deferred to #1848880: Test order of AJAX commands: add Ajax\FrameworkTest::testOrder(), strengthen testLazyLoad(), fix JS settings not being prepended.
Even more ironic is that effulgentsia accidentally introduced this bug in #31, and he's the one who rolled #1848880: Test order of AJAX commands: add Ajax\FrameworkTest::testOrder(), strengthen testLazyLoad(), fix JS settings not being prepended to prevent that from happening again.

I'm marking this issue as fixed again, because #1848880: Test order of AJAX commands: add Ajax\FrameworkTest::testOrder(), strengthen testLazyLoad(), fix JS settings not being prepended contains the test coverage, which I just extended significantly to prevent this regression from ever occurring again: #1848880-2: Test order of AJAX commands: add Ajax\FrameworkTest::testOrder(), strengthen testLazyLoad(), fix JS settings not being prepended.

As you can see, reading the post is difficult (especially in this quoted form with no links).

It might be nice to only show the entire node title the first time the post if the same post is referenced multiple times. Thoughts?

Comments

dww’s picture

Yeah, that's definitely an interesting thought. I tend to do that myself when I'm composing a comment. I only use [#x] the first time, and then just type #x the rest instead of using the [] again. So yeah, maybe for people who like to always do [#x] it makes some sense to do that for them.

However:

A) Sometimes you only refer to another issue a few times in a comment, perhaps early and then again in a list of follow-up issues or something. In that case, you'd definitely want the full [] behavior on both instances.

B) I think the code for the filter might get ridiculously complicated to try to enforce this behavior. Filters are almost always hairy regexp code in the first place. Trying to build this conditional logic in, too, might be really complex and fragile, and/or expensive computationally.

C) In cases where people go nuts with [] around every reference, perhaps the best solution is to edit the comment. People sometimes leave broken html tags in a comment, rendering it hard/impossible to read. I consider this somewhat similar.

So I dunno. Interesting, but I'm not sure this is a good idea. And it's definitely not a blocker for the 7.x-2.0 release so it's probably not going to happen anytime soon. ;)

But thanks for the suggestion!
-Derek

quicksketch’s picture

So I dunno. Interesting, but I'm not sure this is a good idea.

Yep, sort of my thoughts too. The include once and then using again later in a list does seem like it could happen regularly.

A different approach (again with readability as the ultimate goal) could be to simply use the "title" attribute everywhere and not expand out the links at all. Or make a new token suffix that includes the whole title, sort of like how we link to individual comments. A la [#123456-title]. I don't know... just trying to think of ideas. Github links just the text you typed exactly, which I've found both convenient and annoying at the same time. Maybe we should just make a JS-enhancement to hide subsequent titles in dreditor. :P

sun’s picture

I don't think this requires a technical solution.

Instead, it is better to train people to talk about one topic in a single paragraph. Doing so inherently means that only ~1 issue is referenced in a single paragraph, and that no other paragraph repeats the same topic or referenced issue.

Training people always takes time. But ultimately it is for the better.

Thus, instead of acting here, I'd rather encourage everyone to react like @quicksketch did in the original issue that caused this one; i.e., highlighting the linguistic/structural issue in a constructive way.

dww’s picture

Right, I suggested "edit the comment" (and I should have mentioned "train people") as the cultural solution to this, instead of a technical one.

I was also considering other modifiers to the text that the filter expands (like we have for using @ at the end to get who an issue is assigned to and other randomness) but hardly anyone knows about any of those and uses them, so that didn't seem worth it, either.

Seems like this should probably be won't fix, bu we can leave it open a bit longer if anyone else has any insights.

Thanks,
-Derek

sun’s picture

Hah, interesting. :)

but hardly anyone knows about any of those

You know, there's a simple reason for that: The filter tips don't mention it. But that's exactly what they are for. ;)

That said, I just noticed that it is mentioned on http://drupal.org/filter/tips... oh boy, I wonder when we finally get rid of that page... :(

sun’s picture

Status: Active » Closed (won't fix)

Anyway, let me change the status for you. :)

wim leers’s picture

Status: Closed (won't fix) » Active

(Sorry for reopening, I only found this issue now.)

So, the reason I was linking to the same issue many many times was because I was deep-linking to comments within that issue. So, instead of asking for the "only expand fully on first occasion" behavior, how about this: make it possible to link to comments within issues without having it also show the issue title.

So:

(Or whatever syntax would be more suitable.)

The only alternatives:

  • Not linking to comments, but just saying "#" in plain text.
  • Manually linking to comments, which involves copy/pasting links numerous times, which is very annoying/time consuming, and would then still require manual <a href="URL">comment #NUMBER</a> syntax because otherwise there's enormously long URLs inside of the text, which equally reduces legibility