Ticket #126 (closed enhancement: wontfix)

Opened 4 years ago

Last modified 3 months ago

multi-line emphasis not working

Reported by: waern Owned by:
Priority: minor Milestone:
Version: Keywords:
Cc: dhelta.diaz@…

Description

I discovered that there is a test for multi-line emphasis that currently passes but the text is not emphasized. Needs to be investigated.

Change History

  Changed 4 years ago by waern

  • priority changed from major to minor

follow-up: ↓ 3   Changed 9 months ago by Fūzetsu

Is this still desired? Have there been requests for this? Can we close this if not?

in reply to: ↑ 2   Changed 8 months ago by DanielDiaz

  • type changed from defect to enhancement

Replying to Fūzetsu:

Is this still desired? Have there been requests for this? Can we close this if not?

It would certainly be good, but not necessary nor important. Sometimes, it is a bit annoying, but it is not a priority.

In the other hand, I see that this has been reported now at least twice. In any case, I think "enhancement" is a better type for this issue. After all, the implementation is not supposed to work in this way.

follow-up: ↓ 6   Changed 8 months ago by Fūzetsu

I have considered it for a while and even put the functionality in to test it. In the end I think that multi-line markup would be used far less than the individual markup tokens on their own lines and you'd end up escaping tokens everywhere far more than actually getting use out of this functionality.

Something that I haven't considered before however was use of a rarer string sequence. For example, instead of having

-- | /Multi
-- line
-- string/

and having to escape ‘/’ in all documentation comments where we have pairs of the same token, we could do something like

-- | ///Multi
-- line
-- string///

I have not discussed this with anyone yet though and I'd have to give it further thought.

Do you actually end up wanting to use multi-line markup often? This issue has been around for years but no one seemed to express their interest in it until recently so I can't imagine it's of very high priority and I'd rather avoid annoying the larger part of the userbase for the sake of convenience of few people.

In any case, I think "enhancement" is a better type for this issue. After all, the implementation is not supposed to work in this way.

I agree, well changed.

  Changed 8 months ago by Fūzetsu

  • version 2.5.0 deleted

in reply to: ↑ 4   Changed 8 months ago by DanielDiaz

  • cc dhelta.diaz@… added

Replying to Fūzetsu:

I have considered it for a while and even put the functionality in to test it. In the end I think that multi-line markup would be used far less than the individual markup tokens on their own lines and you'd end up escaping tokens everywhere far more than actually getting use out of this functionality. Something that I haven't considered before however was use of a rarer string sequence. For example, instead of having {{{ -- | /Multi -- line -- string/ }}} and having to escape ‘/’ in all documentation comments where we have pairs of the same token, we could do something like {{{ -- | ///Multi -- line -- string/// }}} I have not discussed this with anyone yet though and I'd have to give it further thought. Do you actually end up wanting to use multi-line markup often? This issue has been around for years but no one seemed to express their interest in it until recently so I can't imagine it's of very high priority and I'd rather avoid annoying the larger part of the userbase for the sake of convenience of few people.

Well, I am becoming more and more a guy who likes to write extensively in the API docs. Sometimes I add a "warning" or "note to the developer" or something similar, which consist in a paragraph, normally fully italicized to be easily differentiated from the rest of the text. Anyway, as I said above, this is not of high priority. And, of course, I am not bothered by the current behavior. I just pointed this out in my original e-mail as a wish. It is up to the developer to decide which changes should go in, as it is up to the user to report bugs and formulate wishes. :)

  Changed 3 months ago by Fūzetsu

  • status changed from new to closed
  • resolution set to wontfix

I think in the end we decided against this. It is certainly possible to implement but the complexity of parsing makes it not worth the minimal amount of effort it would save few users. It would also confuse all the documentation relying on the fact that one doesn't have to escape things if there's no match on the same line.

Note: See TracTickets for help on using tickets.