Markdown-Discuss Digest, Vol 125, Issue 8

[Paul Wilson]

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>