URLs with underscores

[Jonathan Barrett]

Interestingly, whenever I've explained Markdown-like syntax to a  
layperson, they don't understand why _this_ is italicised and not  
underlined.

Maybe the real issue here is that _ is simply the wrong character to  
use...

-J


On 6 Jul 2005, at 20:56, Aaron VonderHaar wrote:


> Correct me if I'm wrong, but as I recall the only _real_ user complain

> (as opposed to theoretical ones) is the case of the user expecting

> literal underscores in the word but unexpectedly getting emphasis.

>

> The only hypothetical case that has been cited of users _wanting_

> mid-word emphasis is "un_fucking_believable," which, if that word were

> to become as popular as it is argued, would likely end up being

> shortened to "unfuckingbelievable" by the average user, thus

> circumventing the problem.

>

> What I'm getting at is that it would be useful to see a much larger

> set of real-world examples that require mid-word emphasis.  Unless

> such a list can be produced, I suggest that whatever new syntax is

> decided on, it should give priority to the literal underscore case.

>

> Then again, this comment is coming from a programmer, not a novelist

> (but I suppose any novelist using markdown would also be familiar with

> URLs having underscores).

>

> --Aaron VonderHaar

>

> On 06/07/05, John Gruber <gruber at fedora.net> wrote:

>

>> Alastair Rankine <arsptr at optusnet.com.au> wrote on 07/06/05 at  

>> 8:41 pm:

>>

>>

>>> John, I like your ideas but I have one of my own for you to  

>>> ponder. What

>>> if we were to disable mid-word emphasis (ie pass underscores through

>>> unchanged) if any _other_ punctuation was encountered in the word?

>>>

>>> http://foo_bar_baz.com      =>  http://foo_bar_baz.com

>>> foo_bar_baz.cpp             =>  foo_bar_baz.cpp

>>> foo_bar_baz()               =>  foo_bar_baz()

>>> path/foo_bar_baz            =>  path/foo_bar_baz

>>> un_fucking_believable       =>  un<em>fucking</em>believable

>>> _freeway_                   =>  <em>freeway</em>

>>> _three_way                  =>  <em>three</em>way

>>>

>>

>> That's not a bad idea at all.

>>

>> But I suspect it might not be enough -- that there might be people

>> who refer to file names that don't have dot-extensions, or who refer

>> to subroutines without the parens (`foo_bar_baz` instead of

>> `foo_bar_baz()`), so I'm not sure this has any advantages over the

>> previous two ideas.

>>

>> Another question is whether we should have different rules for `_`

>> and `*`. Meaning, if we change the rules to say that either or both

>> of the `_` emphasis markers must occur at a word break, should we

>> change the rules for `*` to match?

>>

>> On the one hand, it certainly would simplify the rules /

>> documentation to just say that the rules for `_` and `*` are exactly

>> the same, period.

>>

>> On the other hand, the only people who are complaining about this in

>> the current implementation are doing so because of `_`, not `*`. I

>> think this is because `_` occurs commonly in variable and function

>> names, but `*` does not.

>>

>> -J.G.

>> _______________________________________________

>> Markdown-Discuss mailing list

>> Markdown-Discuss at six.pairlist.net

>> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>>

>>

> _______________________________________________

> Markdown-Discuss mailing list

> Markdown-Discuss at six.pairlist.net

> http://six.pairlist.net/mailman/listinfo/markdown-discuss

>

>