Gists: Bring back the (editable) title (and descriptions)

[mhulse]

TL;DR:

Allow for gist titles and descriptions, like the old gist system, that are editable and independent from the gist itself.

---

Long version:

I don't know about others, but I REALLY miss the old gist naming system.

In the old version, you could give your gist a title. You could also edit this title (independently from the gist) at any time.

These days, the "title" is the name of the first file in a gist. For an example, look at anyone's gist landing page. Here's mine:

https://gist.github.com/mhulse

Maybe it's just me, but I really don't like seeing the file name as the main title. It's not very helpful when scanning with eyes.

Additionally, what happens when your gist has several different files? Not all gists are one file gists. The title is created from the first file in the the gist, yet that file may not be the important one out of the group (IIRC, gist files are automatically sorted by file name A-Z).

Some workarounds:

1. Name the file something like This is my example of doing X for Y language.xml.
2. When there are multiple files to a gist, do the same as above, and add numbers to the start of each file name: 01. This is my example of doing X for Y language.xml, 02. Here's and example of PHP doing X with language.xml.php.

While I love the improvements from the old gist system in general, I really miss being able to give my gists titles.

Side note: Descriptions are now a part of the gist. This means that you have to edit the whole gist to modify description. Doing so creates a new revision. I'd personally prefer the description to be separated from the gist as to avoid revisions if I'm just tweaking description info. UPDATE: I was wrong. While the description is a part of the gist, editing just the description does NOT create a new revision.

GitHub support reply:

Thanks for your feedback! We're always working to improve GitHub and we consider every suggestion we receive. I've added your idea about the editable Gist titles to the Feature Request List™ for the team to see.

IIRC, I sent them the TL;DR version of my request. 👍

[patcon]

One suggestion: Perhaps the title and description could be derived from the first part of a README.md file.

README.md

# This is the gist title

This is the description that will show up in the UI. It allows gist to be a lightweight resurface of git repos.

This is some other stuff that won't make it into the description. That's because it's not in the first paragraph.

The gist UI could write it automatically from a title/description. Might be able format it similarly to any other gist file, so that people would know that they're stubbing out a README, and also keep people from trying to add a title/description and then add a README as well.

[mhulse]

@patcon, I really like that idea!

That would be a good compromise to allowing editable titles/descriptions. 😄

---

Examples in the wild:

Optimally, I'd prefer something like this (editable repo description):

… Or this (editable issue titles):

---

To clarify the issue:

Really, I'd be open to anything that solves this problem (Photoshoped for brevity's sake):

Personally, I don't find the file name helpful for when it comes to quickly scanning my gists, especially when looking for a gist I posted from several months ago.

Sure, the search box is helpful (esp. if #189 gets fixed) but you need to know what you're looking for. There are times when I don't remember what the name of the first file and/or description of the gist was … so, I have to manually scan (or search for "possible" keywords).

Look at this gist:

• 1. functions.php

That's 6 files. None of those file names would I choose to be the title of gist.

I'd simply like the ability to have full control over the Gist title and description. Like in the old system, IMHO, having the ability to quickly edit those two fields would be very helpful and much better than the current system.

[mhulse]

I said:

Side note: Descriptions are now a part of the gist. This means that you have to edit the whole gist to modify description. Doing so creates a new revision. I'd personally prefer the description to be separated from the gist as to avoid revisions if I'm just tweaking description info.

I was wrong about revisions. While you do have to edit the whole gist to get at the description, just editing the description does not create a new revision. Good to know!

[asantos3]

So... Any update from this?

[simonc]

When using a multi-file gist having it named after the first file is really annoying. A gist name Gemfile doesn't really make sense :)

[Winsto]

plus one for this. I also really like @patcon's readme.md idea.

As I'm here adding this in Aug 2015 then I'd like to echo @asantos comment; any update?

[mechanoid]

recently added license files to my gists, which i feel is a good idea, but the current title naming compromises the list overview totally :/ So please consider this issue a look, thx

[danijar]

+1 I wonder what the rationale behind displaying the name of the first file is. Maybe I just look at it the wrong way. Right now, it doesn't make any sense to me.

Seems this is still an issue. My current remedy is to basically have a "README" type file that just follows the format "a_set_of_files_for_accompishing_X" which then becomes the title since "a_" is almost always alphabetically before any of the other files included. At the very least, the option to choose which file would be the title instead of just the first would be a step in the right direction.

[lsloan]

Similar to @Fincher's suggestion, in gists with multiple files I've created filenames with leading special characters (e.g., space, underscore, etc.). That would make them appear first in the list and appear as the name of the gist. It's not ideal, but it works well enough for the moment.

Update: I'd hoped that I could use emoji as the first character of a filename to make it appear first in the list and be used as the gist title. That may have had the added benefit of indicating the status or topic of the gist depending on the emoji used. However, I've learned that emoji may not necessarily appear before alphanumeric or punctuation characters in a sorted list, so that won't help.

[system-addict]

I found this thread by way of looking for 'the ultimate character' to use. I'm using an underscore as I do in my windows folder directories for _assets. I imagine it would also generate less trouble if the need ever comes to parse the gists.

Glad to know others are thinking the same and yes, proposed solutions should maybe be bumped as README.md would seem to fit nicely in community standards.

If you're playing around with the idea of what character notation etc - I use gistbox and imagine it emulates github's rules fairly well.

[JohnL4]

Now my gist is named "App.config". Great. >:(

[cben]

Gists currently have an editable description / subtitle, right?
And it appears (in smaller font) in https://gist.github.com/USERNAME list.
Is this simply about the fact the bolder file name as "title" is distracting?

[mhulse]

@cben you raise a good point. Maybe the title of this issue could be better. I am open to suggestions. :)

Some things that bother me:

1. The gist is named after the first file in the gist.
2. When editing a title of a gist, it creates a new version in the revision history (though, it says "no changes").
3. Skimming gists, on the user index page, is hard and not a good experience.

If you had used the old system I think you would understand better where I am coming from.