VMP Sneak Peek: Slash Commands (Part 3)
13Sometimes, before we roll out new site features, we try them out on our guinea pi- er, VMP friends first.
Y’all went crazy with the /giphy
command in part 1 of VMP Sneak Peek: Slash Commands. Then we added the /shrug
command and editor auto-completion in part 2.
For part 3, I wanted to see what it would be like in a forum to add a Unix-style command line application complete with a full argv
parser.
Cowsay is a program which generates ASCII pictures of a cow with a message. It was written in the late 90s as a joke within the hacker culture. It’s silly, but it’s a good way to test out how slash commands could work with a bunch of different arguments.
- 58 comments, 64 replies
- This topic was locked by shawn
/giphy what
¯\_(ツ)_/¯
/cowsay --help
The forums are going to become VERY interesting now. (As if they weren’t until now )
@FroodyFrog /giphy VERY interesting
/giphy VERY interesting
@medz I guess nobody does. I didn’t follow the example gif closely.
@medz
Let it be known that the Moose ascii that I requested didn’t have udders or testicles or whatever that w is.
@Moose
/cowsay -l
@medz
@cinoclav
Cow dare you say that??? (Nope, not a typo.)
I’m not seeing the /commands popup thingy, as per this pt. 2 post. Not seeing them in the editor for comments or replies. Chrome 51.0.2704.63 m; Win 7 SP1 64-bit.
Hah, it failed at parsing!
@MrGlass My first thought was… ‘/cowsay --help, not /man cowsay!!!’
Nice job breaking the parser
@shawn Should I file an issue on the mehdown project for this?
@MrGlass
@shawn After this code review meeting
@MrGlass even better, just fix the bug yourself and submit a PR
@shawn
@MrGlass I’ve looked into this and it looks like special characters are “helpfully” getting parsed as bash shell commands.
I think the best workaround is for us to simply ignore the bash shell commands when building the speech balloons and encouraging usage of putting text with special characters inside double quotes.
I’ve pushed this change to Mehdown v2.2.2 and updated the autocomplete text and help documentation to encourage
"text"
instead of justtext
.@shawn
@conandlibrarian wanted to say it without the “entire” and “so”, but the spacing was off.
¯\_(ツ)_/¯
@conandlibrarian
@conandlibrarian
/giphy udderly ridiculous
/giphy /cowsay
/giphy frown
/giphy hmmm
@awk
/giphy cogito cogito ergo cogito sum
just as long as you don’t add
sl
This brings me back to my IRC days.
@awk
/giphy Thats so meta
also @shawn thank you for /shrug, you have done a great service in preventing many accidental amputations
(۲ಥ_ಥ)
@awk my favorite so far
@jjohns71
/giphy little bobby tables
Need to be landscape on mobile to see the bigger ASCII art
Well, this may not require as much bandwidth as /giphy
@shawn @katylava @harrison
Just a suggestion from a styling point of view. I don’t really see any reason to have the code box around the ASCII art, what would you guys think of dropping the <code> tags for the /cowsays as well as adding a class to <pre> to differentiate it from the regular code-use <pre>?
I know, this request is self serving and wouldn’t be a change that really benefits your core styling so I expect nothing but I do feel like the <code> tag is unnecessary for ASCII art as it defines code and ASCII art isn’t code and adding a class to differentiate now while you’re fresh on the code could prevent a headache down the road if you later want to differentiate the two because the class is already in place.
@jbartus Visually, not sure how much it matters, but for the sake of semantics (and thus, theoretically at least, accessibility), I would have to agree with you. Seems to work as-is if the content is just dropped into
<pre>
instead of<pre><code>
, though the nesting shrinks it a bit more.@jbartus I think the exact opposite actually. I view these slash commands in the Mehdown rendering pipeline as Markdown pre-processor steps that are light weight because they piggyback on the rest of the Markdown rendering. In terms of “preventing future headaches” it’s always better to keep these types of things loosely coupled.
That said, I don’t want to shoot down a good idea if someone has a different train of thought. Code it up and we could take a look at how it turns out.
@brhfl the size difference is a result of styling, not so much the nesting.
@shawn to me, the use of the code box for any pre-formatted text kind of kills the utility of pre-formatted text to me. Call me OCD (I probably am) but to me having the box around it breaks up the flow of the entire post. It’s one thing to do that when you’re calling out code in a tutorial or a stack overflow post or something because it exists as a reference for the conversation, not part of the conversation itself. Doing it for ASCII art just feels wrong, I get why we’re using <pre> tags (nobody wants the whole site in monospace I’m sure) for the ASCII art but having the shaded box feels weird.
That said, I do see your point and agree that KISS for the mehdown parser makes sense. The <code> tag doesn’t really hurt anything except maybe accessibility (which ASCII isn’t really accessible anyhow, you kinda gotta be able to see it) but at least if the <pre> got a class assigned to it the styling of the contents could be altered accordingly if desired. I’ll poke around the mehdown code and see what it would take to add a class for the code section of things, should be easy enough to pass as a variable.
@jbartus Yes, I know how CSS works. Since
.e-content
pre
andcode
both use a relative definitiontext-size: 85%
, it is a direct result of being nested.More on topic, however, I maintain that ASCII art is not code, and use of said tag is semantically improper.
@shawn Okay maybe I’m dumb but I’m not seeing where in mehdown you’re even creating your code tags, I even downloaded the github repo and ran GREP on the directory looking for
<pre>
tags, no dice. Am I missing something? I found some manually created messages for help and the like for /cowsay but nothing relating to the normal code/pre tags.@brhfl semantically maybe but since ASCII art can only be really understood visually it’s not accessible content anyhow so I’m not sure it’s much of an issue, especially since
<code>
is generally speaking a phase tag like <em> or <strong> not a separate element unto itself.@jbartus Markdown mandates code blocks go inside
<pre><code>
; presumably that’s coming out of markdown-it which they use as the actual markdown parser.@brhfl good point. I also just noticed that cowsay is a separate repo entirely.
@jbartus
…cowfile?
(edit - & I realize not everyone worries about strict semantics, just throwing in my 2c. Makes sense in pre, not in code, but that isn’t tidy in md.)
@brhfl
/giphy popcorn
@jbartus Yep, the cow designs live in cowfiles, just like w/ real cowsay. Hence the addition of the goat. Entertains me that it’s as extensible as it is.
@shawn
@brhfl yeah I saw. Did you notice that the goat previously had a tongue that was removed for unknown reasons?
@jbartus
@brhfl More importantly, what does the fox say?
/giphy Tiny Tub Mummy
¯\_(ツ)_/¯
@KDemo
/cowsay -f tiny tub mummy
@Thumperchick
/cowsay -f tiny tub mummy
There’s no cowfile named
tiny
@shawn that makes sense.
Maybe @starblind is up for making a TTM cowfile… eh… eh…?
@brhfl I was coming back to this to ask for just that!
/giphy this is too complicated
@hems79
@hems79
/giphy RIP Avril
¯\_(ツ)_/¯
/giphy shrug
@shawn: Can we get the image to appear without the command (/giphy shrug) displaying?
@tomvarela No! If you wanted that, you’d just post the actual gif (which is just as easy, except for the whole “finding it” part).
@dashcloud and except for the whole “randomness” part.
@tomvarela
https://meh.com/forum/topics/vmp-sneak-peek-slash-commands#574d14548821bf8c06c75e9d
@Ignorant to be fair, that’s @shawn’s preference, I think @shawn has demonstrated that he is quite open to other people’s ideas and if enough people expressed the same sentiment would consider changing it.
Personally I would kind of prefer it to lose the command as well and maybe use the input text as the alt-text / mouseover for the image.
@jbartus I prefer the text, mouseover doesn’t really work for those on mobile.
@Ignorant yeah but is it really essential information?
@jbartus for any sort of context, yes. The gifs are so random that it would make no sense at all without it.
@Ignorant Context, yes. Also secondary humor in the randomness, seeing what the author requested and the arbitrary result.
/me wonders if /me was easier to do than /cowsay
@thismyusername I would implement /me and make a pull request, but I honestly don’t know what the presentation would/should be. Best I can think of is italics, but we have those.
¯\_(ツ)_/¯
/giphy TMI
/giphy suck it
@barney i guess tags don’t get picked up, but that’s probs obvs to you smart peeps
@DMlivezey I love purple! (You are so wrong; I am not a smart peep.)
Hmm. Pre Y2K. Somebody must have remediated & tested it since, from the above evidence, it appears to work!
I must have missed an embellishment - cool darker shaded highlighting at the the left edge of the quote box. Nice touch @shawn.
@thismyusername No, this is obviously MechWarrior or BattleTech for Apple, not Titanfall. The pictured mech is a Mad Cat/Timber Wolf (depending on your Inner Sphere/clan affiliation). Not all giant robots are the same, but at least you didn’t call it a Gundam. </nerd rage>
I do like the shot at Apple though.
/giphy udder disaster
¯\_(ツ)_/¯
If you don’t like what /giphy finds, click edit and save it again. It will show something different.
/giphy something different
/giphy rotten apple
strangely, it chops off the
5
if i put a space before itLocking this topic so we can continue in VMP Sneak Peek: Slash Commands (Part 4)