GNOME Bugzilla – Bug 733624
Apply shell syntax highlighting for ~/.bashrc etc
Last modified: 2014-08-13 23:18:43 UTC
Gedit's looking really awesome these days, good work! So, this is just a small nit that would be a nice enhancement were it easy to implement. Not sure but anyway be nice if gedit were to recognise and prettify the following with bashy formatting instead of being plain old text by default like any other invisible file. ~/.bashrc ~/.profile and ~/.bash_profile possible? My gedit version is 3.12.2 in case that's useful.
It would be useful, indeed.
Should be just a matter of adding those to the sh.lang globs
(In reply to comment #2) > Should be just a matter of adding those to the sh.lang globs Not familiar with the way gedit files and directories set up sorry but off hand I could'nt find what you were referring to in the git repo, sorry if this seems obvious but could you explain where's that is done, more precisely?
See https://git.gnome.org/browse/gtksourceview/tree/data/language-specs/sh.lang#n28 It's a semicolon separated list of shell like globs to which file names are matched. You should be able to add .bashrc .profile and .bash_profile to the list.
(In reply to comment #4) > See > https://git.gnome.org/browse/gtksourceview/tree/data/language-specs/sh.lang#n28 > > It's a semicolon separated list of shell like globs to which file names are > matched. You should be able to add .bashrc .profile and .bash_profile to the > list. Awesome, thanks. I'll have a craic!
Created attachment 281837 [details] [review] add *bashrc *profile and *bash_profile globs
Created attachment 281838 [details] [review] sh.lang: add globs *bashrc *profile and *bash_profile
Review of attachment 281838 [details] [review]: Thank you for the patch. Please squash the two commits with 'git rebase -i'. ::: data/language-specs/sh.lang @@ +26,3 @@ <metadata> <property name="mimetypes">text/x-shellscript;application/x-shellscript;text/x-sh</property> + <property name="globs">*.sh;*bashrc;*bash_profile;*profile</property> for *bashrc and *bash_profile, I think it's ok. But for *profile, does it work with ".profile"? Because if a user has a simple text file ending with "profile", it'll be highlighted as a shell script…
(In reply to comment #8) > Review of attachment 281838 [details] [review]: > > Thank you for the patch. > Please squash the two commits with 'git rebase -i'. What is the problem you refer to here? I am not following... > > ::: data/language-specs/sh.lang > @@ +26,3 @@ > <metadata> > <property > name="mimetypes">text/x-shellscript;application/x-shellscript;text/x-sh</property> > + <property name="globs">*.sh;*bashrc;*bash_profile;*profile</property> > > for *bashrc and *bash_profile, I think it's ok. > But for *profile, does it work with ".profile"? Because if a user has a simple > text file ending with "profile", it'll be highlighted as a shell script… I can't see where that might happen but I can take profile out or have it as $HOME/.profile if you prefer to be careful? If you decide you want to keep it in there's a good point though *bash_profile is already dealt with in *profile so that can probably go out in the case *profile stays, anyway.
Created attachment 282957 [details] [review] sh.lang: add globs for *bashrc and *profile files
Created attachment 282958 [details] [review] sh.lang: add globs for *bashrc and *profile files
Why not just match the actual filename? i.e. ".profile" instead of "*profile"? Like said before *profile is to general and will cause normal files ending on profile to be misclassified as shell scripts.
(In reply to comment #12) > Why not just match the actual filename? i.e. ".profile" instead of "*profile"? > Like said before *profile is to general and will cause normal files ending on > profile to be misclassified as shell scripts. Ah, ok I see what you mean now. If you only put .profile then you miss out /etc/profile and etc/bashrc and for a plain text file profile.txt it would still format plain text since it's only going to format as a shell script the file ends in *profile with no .txt at the end anyways. That seems unlikely to me so the patch is personally how I'd have it, for my own purposes, anyway. That said I wouldn't have a problem changing to .profile and .bashrc just that it is worth noting that this won't cover the root profile and bash files so in that case it might be worth putting something explicit in for these files too otherwise they'll not get the benefit of shell formatting.
You can have text files without the .txt extension. (.txt comes from Windows)
(In reply to comment #14) > You can have text files without the .txt extension. (.txt comes from Windows) ??? A riddle: a) A plain text file ending in profile b) A shell script with the file ending profile c) A solution to 733624 One of these is very unlikely to exist, another is almost certain to exist (at least once) and the other is not ever going to happen at this rate.
On my system I already have 91 files ending on profile, I don't think it's _very_ uncommon, and it would not be very future proof. Also, I don't know how many people try to open /etc/profile with sudo in gedit, but I can take an educated guess that it does not happen very often. If you do, it's a matter of selecting the highlighting once and saving the file. The highlighting mode will be saved in metadata.
Created attachment 283277 [details] [review] explicit .bashrc et al (In reply to comment #16) > On my system I already have 91 files ending on profile, I don't think it's > _very_ uncommon, and it would not be very future proof. Also, I don't know how > many people try to open /etc/profile with sudo in gedit, but I can take an > educated guess that it does not happen very often. If you do, it's a matter of > selecting the highlighting once and saving the file. The highlighting mode will > be saved in metadata. I said "files" in a) and b) with no adjective there, right? What do you think the probability of anyone making a decision is according to the CLT of pointless arguments about non-issues that nobody cares about in c) of this riddle, then? It really is this simple: (In reply to comment #13) > (In reply to comment #12) > > Why not just match the actual filename? i.e. ".profile" instead of "*profile"? > I wouldn't have a problem changing to .profile and .bashrc So i.e, I am not going to agree, but I do not care enough to argue because ultimately, you say tomato, I say it properly ;-) and ultimately none of us have any way of determining whether our intuition is right because that's not how statistics and probability work. So, it's up to the maintainers to be clear about what they want. Failing that, here is a second alternative patch so there is a choice to make.
I've modified a little the latest patch and pushed it: https://git.gnome.org/browse/gtksourceview/commit/?id=4a774bd8dd1a362fa03c75000dc173efdc273188 We were talking about "*profile", not "*bashrc". As I said above, I think "*bashrc" is fine.
(In reply to comment #18) > I've modified a little the latest patch and pushed it: > https://git.gnome.org/browse/gtksourceview/commit/?id=4a774bd8dd1a362fa03c75000dc173efdc273188 > > We were talking about "*profile", not "*bashrc". As I said above, I think > "*bashrc" is fine. Totally, but I genuinely cannot see the the logical difference between the treatments for bashrc or profile nor can I understand why nobody's bothered about poor old bash_profile's fate. In any case though, thank you for deciding on one of the patches. That's awesome! It was great to get the opportunity to contribute to gtksourceview and bring this cool little enhancement to gedit... \o/ Thanks for the help everyone :-)