So long as you run it correctly, it's a matter of your preference.
Aside from differences in features, what text editor you use is indeed pretty much your preference. This is true even when your text editor is a graphical program like Gedit. This isn't to say there's no good reason
vim are often recommended. Terminal-based text editors like
vim (or at least a
vi command) and
nano are available even when there's no GUI and even on most very minimal and broken systems; they have some tradition behind them (if you're partial to that sort of thing); they can be run in the same terminal in which other tasks are performed; they automatically integrate into terminal multiplexer users' workflows; and they are more likely to be available than any particular graphical text editor, even Gedit, even on Ubuntu (which has several flavors).
That's not all. If you're going to edit system files, one approach is to run your editor as root. This is not the only approach, and there are some arguments against it (see below), but it is a common one. If you take that approach and use a graphical program as your editor, then you need to take care to run it in such a way that
$HOME is root's home directory rather than your own, and this adds another layer of hassle and complexity. But you're already doing that; you're running
sudo -H gedit, which is one of the reasonable ways. Still, that complexity is another reason people tend to suggest non-graphical editors.
Graphical programs are often more complicated than non-graphical programs. Having more stuff run as root is generally bad, in that there are more ways things could go wrong, including due to possible bugs, including by accident. (Non-graphical text editors such as
vim are quite sophisticated too, though, and are often configured to run numerous external programs to perform various tasks.)
Besides running the editor as root, another general approach is to edit a file that the editor is able to modify even when running as your (non-root) user, such that changes to the file are propagated to the root-owned file you wish to change. That sounds abstract because the specifics vary considerably. Two major concrete approaches follow.
One fairly long-standing way to do this is
sudoedit (documented in the same manual page as
sudo). By default,
sudoedit uses the default text editor, which is usually not--and should not be--a graphical program. But you can tell it to use any editor through the
EDITOR environment variables, which it consults in that order. Thus you can run:
VISUAL=gedit sudoedit filename
filename with a relative or absolute path to your file.
This makes a temporary copy of the file you wish to edit. The copy is owned by you, not by root (or whoever the original owner is). It opens the text editor, and you can edit the temporary copy. When you close the text editor,
sudoedit checks if you actually made changes. If you did, it copies the modified temporary copy back to the original.
sudoedit works with graphical editors, it's also useful for terminal-based editors. In both cases, the text editor runs as you, so it has your configuration, and other actions you perform in it other than the modifications made to that file are performed by you, which affords a bit of protection against some kinds of mistakes.
You can set one of those environment variables persistently if you like.
SUDO_EDITOR is perhaps the best since it's used for fewer other things. However, if you set it to
gedit, keep in mind that commands like
sudoedit filename won't work when no GUI is available, as is often (albeit not always) the case in a virtual console or via SSH.
The GVFS admin backend
Another newer way to do this, is to open the file through its GVFS
admin:// path rather than its traditional Unix-style path. Thanks go to pomsky for teaching me about this. Just as there are GVFS paths for editing files that are, in other respects, not in a convenient place to be edited--for example because they are on a remote machine you're connected to through SSH--GVFS supports
admin:// paths for editing files you don't own.
This is conceptually similar to
sudoedit in that you run your editor as yourself and the file the editor sees is something it is allowed to edit. Attempting to open the file requires you to authenticate; this is not a magical way to circumvent usual security restrictions.
/path/to/filename must be an absolute path to the file, starting with
/. So there are three
/ characters after
Encodings and other stuff theoretically affected by editor configuration
The encoding of a file is not really affected by whether or not the editor you use is graphical. Some editors, like
vim, even can operate either graphically (the
gvim command) or non-graphically (the
vim command). The simple answer to your question about encodings is that you don't have to worry about that. That's close enough to the truth that you really don't have to read the rest of this answer.
In current (and past) Ubuntu releases, commands like
sudo nano and
sudo vim run those editors as root but have
$HOME still set to your home directory. This means the editors will, by default, use your configuration rather than root's configuration. If there's something in your configuration of those editors (or in a program they run to do some of their work, like
git) about encodings or line endings, it will be followed. With
sudo -H editor, that won't happen.
Some people use bare
sudo (i.e., without
-H) to editors because they want that. But really, you should think twice about this. Not only can you achieve that goal more cleanly with a method like
sudoedit, there are other disadvantages of commands like
sudo nano and
If your editor configuration causes something to be run, that gets run as root. For sophisticated editors like
vim, this can cause quite a bit of nontrivial code to run as root. As mentioned above, having less code run as root is generally good and this is one of the arguments against running graphical editors as root.
vim configuration has numerous plugins--for example, to perform static analysis on source code as you type it--and root's doesn't, less stuff runs as root with
sudo -H vim filename than
sudo vim filename. (Even less runs as root with
VISUAL=vim sudoedit filename, but your plugins still work!) This is separate from whether or not your editor is graphical.
If your editor configuration is broken and keeps you from editing files easily, then fixing that may be even more of a hassle, since it applies to root, too. This is merely a hassle, not a difficult problem to solve.
sudo vim have a bit of the same problem as the (ill-advised!) command
sudo gedit. If you run an editor like
vim as root but without resetting
sudo -H and
sudo -i would do), and it creates configuration files for itself, those configuration files will reside in your home directory but they will be owned by root, and your configuration may be somewhat broken when you later run the editor as yourself.
Well, this sure sounds a lot like that problem! The reason it's less of a big deal than with graphical applications is that the editor usually still starts, the error messages are usually easier to understand, you can usually figure out what specific files are affected much more easily, and the breakage is typically confined to that one program. (Graphical programs use configuration files in more places.) Furthermore, unlike with graphical editors, users who only casually use a text editor and don't deliberately change its configuration are fairly unlikely to experience this problem.
Again, you can use your own user account's editor configuration while avoiding permissions problems by using
sudoedit or, from the desktop, starting the editor normally but accessing the file through an
Finally, note that the above-mentioned behavior of
-i is passed is actually planned to change in a future release of Ubuntu (as it already has, years ago, in most Unix-like operating systems that use
sudo). The behavior has already changed in Ubuntu 19.10, which is the development release as of this writing.