GNOME Bugzilla – Bug 108711
Encoding might be part of the profile
Last modified: 2014-04-03 17:10:52 UTC
I think it would be nice if a profile would also record the encoding to be used. I usually work both in UTF8 and latin-1, and it's a bit annoying to have to set the encoding each time, since I do use different profiles (different bg colors, so I can tell them apart) If this does not seem right, then adding the /Terminal/Character Encoding menu item to the right button context menu would be nice, since right now to change the encoding I have to show the menu bar, do the change, and hide the menubar again. Cheers, -- m
A good idea I think, may be a duplicate bug. A workaround in short-term is to set $LANG when you run the terminal (you have to use --disable-factory to do this so each terminal is its own process). The terminal defaults to the encoding from there. so e.g. LANG=es.UTF-8 etc.
A patch follows which will add the encoding to profiles (the comment on top of terminal-profile.c is very pertinent!) It does add a field on the `General' page of the profile editor. This introduces an interaction with the menu "/Terminal/Character encoding": If a profile wants encoding A, and you open a screen with that profile, then change the encoding to B manually, and then edit the profile so that it calls for encoding C, your screen will have its encoding set to C; probably not what the user would have in mind. This might be solved by adding an encoding_follows_profile flag on screens, which is set to false when the encoding is changed manually (and probably a "Use encoding from profile" (probably with better wording) option in the "/Terminal/Character encoding" submenu, so that a screen can be made to start following the profile after a manual profile change)
Created attachment 15779 [details] [review] Patch to add encoding to profiles
Bug 103275 should be marked as a dup of this.
*** Bug 103275 has been marked as a duplicate of this bug. ***
Applied patch and looked at it more now - I don't think there's really room on the General tab; what I've been saying for most preference addition bugs is that we need to mark all such bugs with the "pref" keyword, then list requested and current prefs in priority order, then draw a line and only include those above the line; we have limited space available. I'm fairly sure encoding would be above the line, so I'm willing to cut corners on doing the full big-picture analysis, but it still doesn't fit on the general tab. The Compatibility tab may well be right. All non-Unicode encodings are basically deprecated and broken for terminals, and only UTF-8 is really used on UNIX variants, so UTF-8 is pretty much the only right thing to use except for back compat. On another UI note, I think a button Add or Remove... as in the Character Coding submenu is necessary in the profile dialog as well, or it will be too confusing when people see only "Use locale" available. This also means dynamically updating the option menu in the profile dialog when profiles are added/removed. I would also say "Current Locale" instead of "Use Locale" (to match the wording of the character coding menu)
Created attachment 15883 [details] [review] Patch synced to HEAD (glade patch didn't apply)
Is this pending an updated patch from the reporter?
Yes, I reviewed this yesterday
*** Bug 116946 has been marked as a duplicate of this bug. ***
*** Bug 111309 has been marked as a duplicate of this bug. ***
*** Bug 131756 has been marked as a duplicate of this bug. ***
*** Bug 128040 has been marked as a duplicate of this bug. ***
128040, which I just marked as a dup of this, is really a patch to add an --encoding option to the command line, but close enough.
*** Bug 146422 has been marked as a duplicate of this bug. ***
*** Bug 157276 has been marked as a duplicate of this bug. ***
*** Bug 165973 has been marked as a duplicate of this bug. ***
*** Bug 303453 has been marked as a duplicate of this bug. ***
I noticed that this long-standing thing still is not in gnome-terminal 2.10, but Havoc states above that the patch has been applied. What has actually happened? It would be very nice to have the char encoding in the prefs, but if it cannot be done then the fallback option of providing a command-line switch for it to save a lot of microstress in having to select it manually all the time would be very nice. Perhaps this issue isn't so annoying to anglo-saxons and people that must use UTF-8 anyway, but to us Europeans using the high space of ISO 8859-1 on many, many legacy systems it is really, really annoying. Thanks for your time!
The patch was not applied. He applied it locally and then gave some suggestions for improvements.
*** Bug 167571 has been marked as a duplicate of this bug. ***
*** Bug 309486 has been marked as a duplicate of this bug. ***
*** Bug 173049 has been marked as a duplicate of this bug. ***
I'm just wondering, what's the primary use case in mind for having encoding in profiles. If it is "I need it because I ssh/telnet to servers that use different encodings than what I use locally", some thought should be given to bug 313480 (that lets one set this on a per server basis). Basically, I wonder if this really belongs in the profiles at all if that patch is applied. Never mind this comment if it's decided that 313480 is a WONTFIX (though I most certainly hope it's not ;) or if some other use case is in mind (it's a small operation to remove the encoding combo box from the server editor dialog).
For example, bug 313650 explicitly asks for this to be added because of some servers running with different encoding. It's also why I personally added Encoding as a per server setting. Having to change this _every_ time you connect is _very_ annoying. Also, having this in profiles would make it less obvious how to set a different encoding for a server. Sadly, UTF-8 hasn't achieved world domination quite yet. :)
I actually use different encodings locally. I do a lot of work on files in various encodings over network filesystems (afs, nfs,...) and it would make my life a lot easier if the encoding was part of the profile instead of per server. IMHO it is more obvious to put the encoding in the profile and select a profile with the correct encoding in the server edit dialog, instead of selecting both a profile and an encoding.
Selecting a different encoding from "Terminal->Select Character Encoding" isn't harder than selecting a different profile in "Terminal->Profile" with a different encoding. In fact, it's even more work since you have to create and maintain a separate profile for every single encoding you want to use. But yes, having encoding specific profiles in "File->Open Terminal" and "File->Open Tab" gives you a faster way to open a new terminal with a specific encoding. It's still extra work to create and maintain the different encodings though. Perhaps entries named "<Profile> <Encoding>" can be created automatically for every encoding you've added to the Encoding menu that's not the current locale? (Just an idea, but I don't think I like it.) On the other hand... * Why should encoding be different from any other preference? * Older encodings are being deprecated in favor of UTF-8, so maybe having it in profiles and adding some extra maintenance work for people persisting on using them ain't that big of a deal.
I can't specify an encoding when starting a terminal from command-line or by putting an application launcher on the desktop or in the panel, but I can specify a profil. f I want a different encoding than the default I _have_ to switch it manually using the menu for every terminal/tab. As you say why should the encoding be different from other preferences? And as Havoc suggests the right place to put it is probably in the Compability tab.
Btw, I think --encoding is a good idea irrespective of whether encoding is added to profiles or not.
*** Bug 313650 has been marked as a duplicate of this bug. ***
In response to comment #28, yes you can. It's a bit awkward but can be done, just as outlined in Havoc's first comment here. Create a script like e.g. this: #!/bin/sh export LANG=sv_SE gnome-terminal --disable-factory --command="ssh foo@bar.com" --title=Foo Then call that script (full path!) from your launcher. It will work. However an --encoding switch wouldn't hurt so let's fix it.
*** Bug 321996 has been marked as a duplicate of this bug. ***
*** Bug 331387 has been marked as a duplicate of this bug. ***
Bug 331387, which has just been marked as a duplicate, has a nice patch and all. When we have room for this, it is probably worth taking a look at.
Ubuntu bug about that with a patch: https://launchpad.net/distros/ubuntu/+source/gnome-terminal/+bug/3923 "I know utf-8 is great and all, but for the moment I want to run ISO-8859-1(5). I need to manually change this every time I start the application, which is kind of annoying since it should be possible to set it by default." comment from "Balint Kozman": "http://librarian.launchpad.net/1650379/default_encoding-2.13.91.diff Hi there, i had the same problem for quite long, and i didn't even want to change my locale setting just to make gnome terminal use a different encoding. This small patch adds the "--encoding=" command line option, which makes it possible to set default encoding from command line (and possibly use an alias to avoid manual setting every time the terminal starts off). It doesn't touch any part of the terminal profile and soever. Patch works against 2.13.91-ubuntu1. Cheers, Balint"
*** Bug 339008 has been marked as a duplicate of this bug. ***
*** Bug 328879 has been marked as a duplicate of this bug. ***
*** Bug 342264 has been marked as a duplicate of this bug. ***
Could you review the patch of 331387? I expect we can switch the locales with .desktop launcher. e.g. Command=env LANG=ja_JP.eucJP gnome-terminal --window-with-profile=ja_JP.eucJP
Takao, you can't do that unless there is no running instance of gnome-terminal. You could use: Command=env LANG=ja_JP.eucJP gnome-terminal --disable-factory --window-with-profile=ja_JP.eucJP but that will get you many instances.
Yes, I forgot to note the --disable-factory. People want to prepare three icons for gnome-terminal, i.e. Shift_JIS, EUC-JP and UTF-8 and just want to click one time per icon.
I have a profile that opens an ssh connection. The server I connect to uses another encoding that I do, so I'd like to set the encoding in the profiles setting.
It is still not fixed.
I make a lot of use of gnome-terminal, and need to switch between two encodings regularly. I used the trick mentioned above to set up a launcher with the other encoding. I think that an --encoding switch would be far more elegant - and a proposed patch was on the web, and above in comment # 35. It would be nice if new tabs would "copy" the current encoding from the active tab or if the profile could set the encoding. This would make it easier to work with tabs with different active encodings. Nathan Wallach Launcher application is now: env LC_CTYPE=he_IL.iso88598 gnome-terminal --disable-factory Launcher would be something like: gnome-terminal --encoding=he_IL.iso88598
In gnome-terminal 2.22.1, the encoding is still not part of the profiles. This would really be a nice feature to have (either by using the profile manager or using a --encoding command line option).
Please, enable this feature both as commandline switch and profile setting. Commandline --encoding IMHO must supersede environment LANG and profile setting.
I would also like to add that having the possibility of using the profile to set encoding or the command line is very useful when you have access to multiple different terminals. This bug is open since 2003 and a search in Google for "gnome-terminal bug" show this bug as first, that's sad.
*** Bug 577877 has been marked as a duplicate of this bug. ***
*** Bug 574552 has been marked as a duplicate of this bug. ***
For what it is worth, terminal on OS X has this features and I use it quite often, because I need to connect on old servers without utf8. And the way we can set the encoding requires to have the menu being show, which can be disabled by some people ( like me ) so changing encoding can be quite annoying.
After seven years of this bug, still no possibility for character encoding specification on command line and/or in profile (like as e.g. in Konsole) ?
I'll code this if we agree on what should happen... Ideally, with a cmdline option --encoding and also in profiles. What I cannot see is: what is the sensible way to pick an encoding when a conflicting subset of more than one of LANG, --encoding and encoding-from-the-profile is provided? My guess is --encoding trumps encoding-from-the-profile trumps LANG.
Personally I'm not really convinced, but I won't stand in your way if you want to add this feature. I'd put the order to --encoding > $LANG (not the factory's LANG of course, but the one from the cmd line opening the new terminal) > profile. Also, please hold off a few days since I'm in the process of porting g-t to gsettings which would make any patch totally obsolete :)
This was fixed with http://git.gnome.org/browse/gnome-terminal/commit/?h=gnome-3-4&id=ea2bf3a3209917a It adds a gconf setting but no other UI.