File language not saved back to github after editing in ST2 #57

Open
minimaldesign opened this Issue Nov 18, 2012 · 45 comments

Comments

Projects
None yet

I open a Textile formatted gist, modify it, then save it.

When I look at the gist back on github, everything's fine beside for its language now set to Text instead of Textile. Is there any way to preserve the formatting?

I should mention it opens as a Textile file within ST2 just fine. It's just the saving that seems to go wrong.

Thanks!

I noticed this issue just now. Up until now I've been saving plaintext Gists, but I wanted to change it to Markdown for one so I changed it on the website, then made and edit and updated it, only to find it had reverted the Gist back to Plaintext :( I can imagine it isn't a hard fix to implement?

Contributor

deiga commented Feb 15, 2013

I can't replicate this. Can you link a gist with which this happens?

@deiga For me it happens with every gist.. Here's a screencast showing my issue: http://www.screencast.com/users/brandonb927/folders/Snagit/media/eca22434-27d7-45f0-b68d-ebfbc8991ef7

Contributor

deiga commented Feb 16, 2013

Okay, thank you for that. Was able to reproduce the steps.

You can avoid that by naming the file with the correct type in sublime.
But I will investigate this now :)

Contributor

deiga commented Feb 16, 2013

After some investigation it seems that the problem is in the Gist API. Files just aren't renamed over the API.

Thats a shame :( Thanks for looking into it!

Owner

condemil commented Aug 11, 2013

@brandonb927 Can you try again? I can't reproduce it now, maybe GitHud fixed this issue with API?

👍 I seem to be having the same issue with a CoffeeScript file.
Disregard user error.

Hmm seems to be working fine again. Thanks for checking in on this! (sorry for the late response btw)

Owner

condemil commented Aug 27, 2013

Great!

condemil closed this Aug 27, 2013

I am seeing this same problem on a private gist. It's a block of HTML and I can't change it from Text to HTML. It seems to work, but after saving it's back to text.

Ok, I think this is because it's preferring the filename to the user's selection. If I set the filename to end in html, it works. Should probably trust the user...

The bug still exists in private gists.

I just added the ".md" to the end of the file name when I uploaded (the original in sublime doesn't even need to be saved as such) and it uploads fine, even in private gists.

condemil reopened this Dec 6, 2013

Can't change language in my public gist: https://gist.github.com/andrejsc/b2db1b18433e5cc1543a
It was saved as HTML (but switched back to text), and now it won't update either.

yoaquim commented May 20, 2014

Was having same issue with javascript, just added the js extension and it worked. Try renaming it bootstrap_center_div.html.

@yoaquim: thanks, changing title from Bootstrap center div to bootstrap-center-div.html helped. Now html is properly highlighted.

blowsie commented May 27, 2014

I ran into this today, IIS web.config is actually XML, but it wont let me change it in gist.
https://gist.github.com/blowsie/04c183c62a432f6450c9

@yoaquim thanks. extensions worked

cfxd commented Jul 13, 2014

@deiga's and @yoaquim's suggestions worked perfectly. Just need to add the appropriate extension in the filename.

mmv-ru commented Aug 11, 2014

Not alvays is good to add extension to perl or shell scripts in linux.

@condemil condemil added Bug and removed Bug labels Aug 23, 2014

JVimes commented Sep 1, 2014

I think the expected behavior is that the language setting works regardless of file name/extension.

I don't think this is a bug with this plugin. When creating Gist manually, if I don't specify an extension github reverts back to text, no matter what language I specify.

JVimes commented Sep 11, 2014

Oops, I'm not where I thought I was. My issue is with Gist, itself.

Same issue as described by others. Gist's always end up as Text for format.
Chrome v37.0.2062.122

deekej commented Oct 22, 2014

Still not working. Using Opera 12.16 and Opera Developer 26 @ Linux Mint 17. Please, fix this. Thanks!

There is definitely still a language selection issue. My gist (https://gist.github.com/gabe19/f6d0590d77909f28fd3b) keeps some of the files as "Smalltalk" even though I never selected this and the files have the .cs extension. The language will be correctly auto-selected to C# when I edit the file but it doesn't hold.

I've had the same issue with some ObjC gists I've been creating, added the .m and it worked but I've got older gists with no file extension that saved fine

[Using Safari Version 8.0.2 (10600.2.5)]

risyasin commented Mar 7, 2015

Two problems still exist for Chrome latest (public gists).

  • Unable to use custom extension.
    When i change file name to a xxx.conf, A javascript sets language option to Apacheconf, even if i have changed it to Nginx. then it ignores completes. syntax highlighting also
  • Language option can not be saved when we edit the gist.
    When in editing gists. whichever option you change the language. it just ignores & saves as "text".

@risyasin I can confirm the second problem is also the case in Safari 8.0.4 , Mac OS X Yosemite 10.10.2.

viion commented Apr 24, 2015

I also am noticing the second issue @risyasin pointed out, it doesn't save the language anymore.

Confirming the second issue as well. Mac OS X Yosemite 10.10.4 / Chrome 42.0.2311.90

bazzilic commented May 5, 2015

Same issue, setting gist to C#, reverts back to Text.
This gist: https://gist.github.com/bazzilic/8c63050c818868f98f1d
The problem appears to be solved if I add an extension .cs to the file name.

cajuuh commented May 12, 2015

it seems like @bazzilic solved my problem, adding file extension makes gist recognize my code.

thank you.

I believe this is still an issue; surely we don't need the file extension as the language can be chosen manually?

deekej commented May 18, 2015

I agree with @Code-Toolbox - this is just a workaround and is not the FIX itself. The issue here has been fixed before, I don't see a reason why it shouldn't be fixed again. IMHO, it should be prioritized a little bit more, since it's very annyoing.

cajuuh commented May 18, 2015

well, like i said it worked for me, i agree the issue still there for a long time and sure should have more priorization, for sure this workaround won't work again in another project nor another gist.

deekej commented May 19, 2015

Well that's the point exactly - I'm not entirely sure, if this workaround will work for other file types and for how long... This makes the gist kind of unattractive for me to use at the moment. And I will soon need something for code snippets.

Is there any way how to raise this issue more directly to the devel team? I don't think fix should be so problematic that somebody could not look into it.

viion commented May 19, 2015

I contacted GitHub and they said it is currently working as expected (but have passed this issue on as feedback!), so here is the behavior:

  • New Gist + No Filename + Language Set = Saved with language
  • New Gist + Filename (no extension) + Language Set = Defaults to "Text"
  • New Gist + Filename (with extension) + Language Set = Saved with language (based on extension)

I believe my initial thought was because I normally don't create a file name, only a title. I've never really noticed it. Then one day I decided to put in a file name so my gists were named correctly and I started noticing it not saving the language and this caused me some confusion.

To save language, currently you must either not enter a filename or enter one with the extension.

deekej commented May 20, 2015

Well, but that's just really confusing concept, IMHO, because I do want to make files with only names (without the filename extension) and assign the programming language to it.

It's because I can sometimes share smalls scripts, which can be copied to /usr/bin/, /usr/share/bin/, etc. on Linux and I don't want anybody to need to rename it additionally.

I would vote for this functionality to be changed...

Agreed. If there's a language select, then I extensions.
More so, we don't want amateur programmers just randomly including snippets just
by file name into their own code by an easy search result.
GitHub, Use one or the other, not both

Sent using CloudMagic [https://cloudmagic.com/k/d/mailapp?ct=pi&cv=6.3.16&pv=8.1]
On Wed, May 20, 2015 at 10:10 AM, condemil/Gist
reply@reply.github.com
wrote:
Well, but that's just really confusing concept, IMHO, because I do want to make
files with only names (without the filename extension) and assign the
programming language to it.

It's because I can sometimes shares smalls scripts, which can be copied to
/usr/bin/, /usr/share/bin/, etc. on Linux and I don't want anybody to need to
rename it additionally.

I would vote for this functionality to be changed...


Reply to this email directly or view it on GitHub
[https://github.com/condemil/Gist/issues/57#issuecomment-103921348] .[https://github.com/notifications/beacon/ABkODP-E2GgARcRIbzrS6McACVWqMY1Bks5oLJtggaJpZM4AQlpE.gif]

frob commented May 21, 2015

I do Drupal development. Drupal uses custom file extensions for .module and .info and .install

Github thinks that these files are just text files no matter how many times I change this in the ui. The UI setting should override whatever Github thinks based on the file extension. Not every system/framework/engine uses standard file extensions.

geosmart commented Jun 8, 2015

thanks BlakeJenningsJohnson ,just add the sufffix of the format,everything is ok

frob commented Jun 8, 2015

@geosmart The issue is now that a file extension shouldn't be required and if the user selects the language github should use that extension regardless of what the file extension is.

Is this ever going to be fixed?
I actually keep my custom git hooks in a Gist, and they require specific filenames, which can be in several languages, and the files don't have file extensions. I can't add extensions, as this would break the hooks when I pull the files.

So my Gist currently doesn't have any highlighting, despite me saving the Gist with a specific language from the dropdown.

Seriously, this isn't a difficult problem. BTW, I'm an enterprise customer - so I'm paying for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment