Just to add a couple of cents-worth of comment to the excellent and
detailed discussion.
I use a mix of Windows, Mac and Linux platforms regularly and require that
files be easily transferrable between all three. As some bits of Linux are
less comfortable with spaces in filenames, I tend to replace them with
underscores. If and when I mention file names in documents, which happens
fairly regularly, I would not want anything trying to italicise them.
To extend bowerbird's comment about URLs, the (often incorrectly named)
protocols that I use fairly often cover a lot of options in addition to
"http", and the implied "https". I find myself using mail,
ftp/ftps, rdp,
sip and a number of others. This emphasises the risks in assuming that an
underscore will always imply a need for italics.
Perhaps a command line flag? A metadata command in the source (although I
dislike this approach for source material that will be read in it's native
state)? Allowing users to option for embedding italics in words is a
partial solution. Partial because it would work on the entire document, and
that may not always be appropriate.
But that's people for you :)
Regards,
Paul Wilson
On Mon, Jul 8, 2013 at 1:35 PM,
<markdown-discuss-request at six.pairlist.net>wrote:
> Send Markdown-Discuss mailing list submissions to
> markdown-discuss at six.pairlist.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
> or, via email, send a message with subject or body 'help' to
> markdown-discuss-request at six.pairlist.net
>
> You can reach the person managing the list at
> markdown-discuss-owner at six.pairlist.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Markdown-Discuss digest..."
>
>
> Today's Topics:
>
> 1. Re: what this has to do with markdown (David Chambers)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 7 Jul 2013 22:35:31 -0700
> From: David Chambers <dc at davidchambers.me>
> Subject: Re: what this has to do with markdown
> To: "Discussion related to Markdown."
> <markdown-discuss at six.pairlist.net>
> Message-ID:
> <CAAEv1nq2-xqQ> wWrHAeGiB0a++L98MW4BheXJt3sT4zGgPv-qg at
mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> thank you for taking the time to share these thoughts, bowerbird. much
> food for thought.
>
>
> On 7 July 2013 20:00, Sherwood Botsford <sgbotsford at gmail.com>
wrote:
>
> > Bowerbird, after this epistle, I promise to read you more thoroughly.
> > Nicely put.
> >
> >
> >
> > Respectfully,
> >
> > Sherwood of Sherwood's Forests
> >
> > Sherwood Botsford
> > Sherwood's Forests -- http://Sherwoods-Forests.com
> > 780-848-2548
> > 50042 Range Rd 31
> > Warburg, Alberta T0C 2T0
> >
> >
> >
> > On 7 July 2013 20:21, bowerbird <bowerbird at aol.com> wrote:
> >
> >> first, i'm sorry for the expletive in your in-box. really.
> >>
> >> i also apologize for the smell from those dead skunks.
> >>
> >> ***
> >>
> >> as to "what this has to do with markdown", it's
simple.
> >>
> >> if i remember correctly -- i might not, but who cares? --
> >> "fan_f*ck*ng_tastic" was the word gruber used to justify
> >> his choice that his version of markdown would recognize
> >> intraword italics. so that's why _i_ used that one as well.
> >>
> >> now, the reason i followed it up with my reference to the
> >> dead-skunk problem is because it's almost perfect as a
> >> demonstration of the full range of problems these days...
> >>
> >> a person comes in and says, "hey, i noticed this
glitch".
> >>
> >> somebody else says "here's a workaround you can
use."
> >>
> >> which -- first -- ignores the fact that it's after-the-fact.
> >>
> >> but, in this particular case, the suggestion was actually
> >> better than most. to remind you, the workaround was to
> >> surround filename_withanunderbar.txt with `backticks`,
> >> which marks it as `code`, and thus short-circuits italics.
> >>
> >> because, as the suggester pointed out, it is the case that
> >> you probably _want_ filenames to be marked as `code`,
> >> so they will display in a different typeface, and stand out.
> >>
> >> the problem with that tactic, however, is that it does not
> >> address the situation where you would want the word to
> >> be rendered with the same typeface as surrounding text.
> >> you wouldn't want "fan_f*ck*ng_tastic" marked as
code.
> >>
> >> so... sticking with the problem in regard to filenames...
> >>
> >> another workaround would be to backslash/escape the
> >> underbar in the filename, which will also nix the italics,
> >> but that presents a different problem, which is that now
> >> we've gummed up the plain-text version of the filename
> >> with an unwanted backslash, with unknown side-effects.
> >> (since you just know somebody is going to end up using
> >> that now-improper filename, and they will suffer for it.)
> >>
> >> that same type of problem would likely manifest with the
> >> "just use raw .html" workaround, even if you can find
the
> >> way to concoct that. (it hurts my brain to think about it;
> >> i'm using light-markup so i'm not forced to do raw html.)
> >>
> >> the fact is, we really want to leave a filename untouched.
> >> but we also don't want its underbars to be italic triggers.
> >>
> >> and remember that when an underbar is misrecognized
> >> as an italic-trigger, it's dropped from .html output, so
> >> we now have _another_ wrong version of that filename,
> >> in addition to the difficult problem of the runaway italics.
> >>
> >> and, just to remind y'all that this is even _more_ thorny,
> >> this underbar problem also happens regularly with urls.
> >>
> >> (there are other instances too, but i do not intend to
> >> share all of the results from my hard-fought research;
> >> since url's have the problem, it is significant enough.)
> >>
> >> this is not a thing we can casually sweep under the rug.
> >>
> >> which is why some markdown script-writers have just
> >> decided that they will _disallow_ intraword underbars.
> >>
> >> and, in defense of that decision, it is the absolute truth
> >> that browsers make a sad tragedy with intraword italics.
> >> go look at some, take a hard look, and you _will_ see it:
> >> the italic characters either slant into the upright ones, or
> >> lean far too far away from them. either side, it's _awful_.
> >>
> >> so yes, many markdown scripters do an outright ban...
> >>
> >> which is fine if you are god, and you make the decisions.
> >>
> >> but if you are beholden to users, it might not be so good.
> >>
> >> and if you consider yourself to be a _servant_of_writers_,
> >> then you really need to do a bit of research (or lots of it)
> >> to discern if writers actually do ever use intraword italics.
> >>
> >> that was what i did, as i was developing my light-markup.
> >>
> >> so i can tell you that, yes, indeed, writers _do_ use them.
> >>
> >> not a lot, of course, but they're not that infrequent either,
> >> and it is a sizable percentage of writers that do use them.
> >>
> >> so that's probably why about _half_ of the implementations
> >> ban 'em, and half _allow_ them. it's split down the
middle.
> >>
> >> so if you really want to know if it's acceptable to ban them,
> >> my advice would be "no".
> >>
> >> ***
> >>
> >> now, let's go back and look what the original poster said.
> >>
> >> > Why not to ignore all "_"
> >> > which are not followed or preceded
> >> > either by a whitespace or by a newline?
> >>
> >> just for the record, a newline _is_ whitespace, so we can
> >> strike the "or by a newline" phrase; just use
"whitespace".
> >>
> >> as a first pass in thinking about that issue, that's not bad.
> >> i'd say it's the "solution" most people would
come up with.
> >>
> >> i wouldn't even be surprised if some implementations do
> >> indeed use exactly that rule to govern their conversions...
> >>
> >> but if you actually go look at where italics markup is used,
> >> you'll find many people put italics _inside_ any punctuation.
> >> (most typically, you can find this with double-quote marks,
> >> but any terminal-punctuation will present the same issue.)
> >>
> >> now i wouldn't recommend that, because -- as i just said --
> >> browsers do a lousy job when italics are next to un-italics,
> >> and that's true for punctuation as much as other characters.
> >>
> >> but the fact remains that a lot of people use italics like that,
> >> so if you use "whitespace" as the rule, you'll screw
them up.
> >>
> >> (of course, by putting your underbars _outside_ quotemarks,
> >> you can screw up some conversion routines for curly-quotes,
> >> because _they_ are using whitespace to make their decisions;
> >> but that's why you need to decide things in a systematic way.)
> >>
> >> again, back to the original poster:
> >>
> >> > It would be nice to make
> >> > a part of the official Markdown definition
> >> > then all implementation will display this in the same way.
> >>
> >> as gruber put it, years ago and very recently, people _say_
> >> they wanna have an "official" version of markdown -- but
> >> what they _mean_ is that they want _their_ pet desires to
> >> receive his stamp of approval as "the official
markdown".
> >>
> >> but if gruber _were_ to make an "official version", he
says
> >> that it would make those people very unhappy, because he
> >> will instantiate _his_ pet desires as the canonical standard.
> >>
> >> so, let me say to the original poster, gruber _did_ make the
> >> closest thing to an official version, and it specifically _allows_
> >> intraword italics. so you wouldn't get what you want anyway.
> >>
> >> which is not to say that other implementations, which do it
> >> _differently_ are "wrong", because gruber likes it
"flexible".
> >>
> >> in other words, he doesn't _want_ all implementations to
> >> "display in the same way". which could be well and
good,
> >> if not for all these dead skunks in the middle of the road.
> >>
> >> you can call it "flexiblity", or you can call it
"inconsistencies".
> >>
> >> whether you, or i, or anyone else for that matter, considers
> >> all this to be "right" or "wrong" is entirely
beside the point...
> >>
> >> since gruber ain't gonna change his ways, and neither are
> >> the many developers, whose stubborn insistence has also
> >> been equally-well documented, there is no resolution here.
> >>
> >> which is why most people have stopped thinking long ago.
> >>
> >> ***
> >>
> >> and _that_, my friends, is another one of the problems here.
> >>
> >> because that refusal to do any more thinking on the matters
> >> -- the disinclination to remove dead skunks from the road --
> >> means that the situation really has become totally hopeless.
> >>
> >> as fletcher put it, in his reply to the original poster:
> >>
> >> > Stick around. You'll learn. ;)
> >>
> >> hey, at least he put a winkey-smiley after it... ;+)
> >>
> >> ***
> >>
> >> so, just to do a follow-through as a for-example for you,
> >> let me run you through the thinking that i did when i was
> >> working about the aspects of this intraword italics issue.
> >>
> >> one part, which i mentioned above, was to survey books
> >> -- as my system focuses on books -- to see if authors
> >> actually use intraword italics. and they occasionally do.
> >>
> >> on the other hand, more research revealed quite readily
> >> that there was a problem with both filenames and urls,
> >> as they often contain underbars. (and, so i note it, yes,
> >> a url _is_ a filename, but sometimes it's a symbolic one
> >> -- in the sense that the "file" does not actually exist
--
> >> so both for purposes of clarity and to remind us of the
> >> full range of the problem, i mention them specifically.)
> >>
> >> so, both use-cases do exist. we have intraword italics,
> >> and intraword underbars that must be taken as literals.
> >>
> >> thus, we need a way to differentiate them.
> >>
> >> the key here, to which i have already given one big hint,
> >> is that the literal-underbars occur in specific situations,
> >> namely for filenames and urls. intraword italics, on the
> >> other hand, occur (by definition) in the middle of words.
> >>
> >> so when my system encounters an underbar in a string,
> >> it decides whether the string is a filename/url or a word.
> >> in the former, the underbar is seen as a literal character;
> >> in the latter, the underbar is considered an italic trigger.
> >>
> >> it's relatively simple to determine if something is a url;
> >> e.g., an "http" or a "www" or a
".com" is a dead giveway.
> >> and an internal period is a good indicator of a filename,
> >> especially if it's followed by a known filename extension.
> >>
> >> likewise, it's relatively easy to tell if something is a word,
> >> or is not, once you have removed the underbars inside it.
> >> if it's in the dictionary, or if it's repeated (sans
underbars)
> >> elsewhere in the document, odds are that the underbars
> >> in this version of the string are intended as italic triggers.
> >>
> >> so, in my testing, this decision-rule has been pretty solid.
> >>
> >> it's not something that i would recommend for markdown,
> >> because of factors i will discuss later, but it works for me.
> >>
> >> and, more to the point i'm trying to make here, it's what
> >> can happen if you really try hard to resolve a discrepancy,
> >> rather than simply just throwing your hands up in the air.
> >> (like you just don't care. hu-hum, hu-hum, baby-cakes.)
> >>
> >> i mean, i understand the paralysis that _will_ result when
> >> you're mired in a standoff situation, like this has become,
> >> but i think you markdown developers need to fight that.
> >> instead, you've all let yourself become complacent about
> >> the edge-cases and inconsistencies that dog the format.
> >>
> >> a little elbow-grease might go a long way, is what i say.
> >>
> >> but you're going to have to apply it. i had to work a lot
> >> to come to the easy understanding of intraword italics
> >> that i have just imparted to you. you need to work too.
> >>
> >> and, for me, the italics situation was actually less sticky
> >> than the asterisk problem, because asterisk-overload is
> >> much, much worse. asterisks -- which i use for *bold*
> >> (and i didn't take the easy way out and require two) --
> >> _also_ represent bullets in unordered lists, _and_ occur
> >> in equations where they are the sign for multiplication.
> >> writing the routines to sort through all that was a pain.
> >>
> >> further, curly-quote conversion isn't as easy as it seems.
> >> a single round of thinking (like microsoft did) will create
> >> a converter that makes some very embarassing mistakes.
> >>
> >> even a couple more rounds of thinking might not give
> >> you a routine that correctly gives straight-quotes in the
> >> cases where the marks are referring to feet and inches,
> >> or the minutes-and-seconds part of lattitude/longitude.
> >>
> >> again, this is the kind of intense thinking you have to do
> >> if you wanna sort through these types of difficulties, but
> >> nobody here that i can see is doing much thinking at all.
> >> and for sure you don't share any thinking you are doing,
> >> or bounce ideas off of each other in a collaborative way.
> >>
> >> and that's really sad.
> >>
> >> ***
> >>
> >> so, anyway, this is what i'd recommend for markdown,
> >> as your general solution to the underbar/italic problem.
> >>
> >> (and, yes, i am chuckling as i write this, because i know
> >> darn well that nobody even wants "a general solution",
> >> and even though some implementations already do it,
> >> the rest -- including gruber -- will never, ever, follow,
> >> so any such proposal is an exercise in mere folly, but...)
> >>
> >> anyway, here it is:
> >>
> >> ban intraword italics, outright, with full notice, _but_
> >> make it clear that the workaround is to use raw .html
> >> to obtain the necessary italics for any intraword needs.
> >>
> >> (and if you're curious why i don't use this in my system,
> >> the reason is because i do not permit raw .html at all.)
> >>
> >> ***
> >>
> >> and, finally, hey, let's put this all into perspective, ok?
> >>
> >> the kind of standoff we have here is relatively minor.
> >> and the problems we see border on the most trivial...
> >>
> >> we see the same type of stubborness at a larger level
> >> as the big corporations continue lobbying for d.r.m.,
> >> and the big tech companies up their lock-in tactics.
> >>
> >> and unlike here, in little old markdown land, where
> >> there is no money to be made one way or the other,
> >> the dollars from d.r.m. and lock-in could be _huge_.
> >> so those companies are gonna be firm, intransigent,
> >> and persistent in their stubbornness and their greed.
> >>
> >> and, on a bigger level still, look at global warming,
> >> and the way that we are rapidly polluting our planet.
> >>
> >> again, the standoff there is so much more dangerous,
> >> as the money is _staggering_, so don't even bother to
> >> wonder if any of the big corporations will ever change.
> >>
> >> and once humans go extinct, it will not really matter if,
> >> once upon a time, somewhere along the line, someone
> >> had their italics messed up because of a stray underbar.
> >>
> >> so, just so you know, if it was _just_ markdown that this
> >> was relevant to, i probably wouldn't care nearly so much.
> >>
> >> but the problem of stubborn standoffs is much bigger,
> >> and applies to arenas far larger than this little molehill,
> >> causing problems worse than the smell of dead skunks,
> >> and _that_ is why i care, and why i choose to speak up...
> >>
> >> now i will ask you: why do you sit and suffer in silence?
> >>
> >> -bowerbird
> >>
> >> _______________________________________________
> >> 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
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
>
http://six.pairlist.net/pipermail/markdown-discuss/attachments/20130707/56283d21/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> Markdown-Discuss mailing list
> Markdown-Discuss at six.pairlist.net
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>
>
> End of Markdown-Discuss Digest, Vol 125, Issue 8
> ************************************************
>
--
"Software - secure, cheap, quick - choose any two"
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://six.pairlist.net/pipermail/markdown-discuss/attachments/20130708/22dc5dd1/attachment.htm>