I have been using gedit as a programming text editor for a while...
I would like to increase the number of recently opened files from 5 to 10...
I checked the gedit preferences and the gconf-editor gedit options but there was nothing there related to the recently opened file list.
Where can I change this setting?
The configuration setting is in /schemas/apps/gedit-2/preferences/ui/recents/max_recents according to http://people.gnome.org/~bmsmith/gconf-docs/C/gedit.html.
According to OP the setting can successfully be changed by issuing the command gconftool-2 --type int --set /apps/gedit-2/preferences/ui/recents/max_recents 10 (Notice: /schemas is removed!)
I tried the accepted answer with Ubuntu 14.04 and as pevik ran into the problem that adding that did not do anything.
Instead, I had to change the already existing key in dconf:
$ dconf write /org/gnome/gedit/preferences/ui/max-recents '20'
EDIT: Since after a restart gEdit's number of most recently used items was reduced to 5 again, I did some investigation and found bug #1024168 on Launchpad and it seems that the solution is not using dconf at all, but instead gsettings:
$ dconf read /org/gnome/gedit/preferences/ui/max-recents
20
$ gsettings get org.gnome.gedit.preferences.ui max-recents
uint32 5
$ gsettings set org.gnome.gedit.preferences.ui max-recents 25
$ dconf read /org/gnome/gedit/preferences/ui/max-recents
25
$ gsettings get org.gnome.gedit.preferences.ui max-recents
uint32 25
So, it seems that the information flow dconf -> gsettings does not work properly, while gsettings -> dconf works as expected. On a side-note: dconf claims the key to be a signed int32, while gsettings states that it is an unsigned int32...
Related
Trying to use p4.exe command line to manipulate perforce. Because the server uses unicode so at first I changed the P4CHARSET value to utf16le-bom(p4 set P4CHARSET=utf16le-bom). Later I try the command 'p4 login' the console returned 'p4 can't support a wide charset unless P4COMMANDCHARSET is set to another charset.'. After reading the guidance from the page ftp://ftp.perforce.com/perforce/r08.2/doc/user/i18nnotes.txt I know when the P4CHARSET is set to utf16 or 32 the P4COMMANDCHARSET has to be set to something else so it can read the command line command. But every time I used the command 'p4 set P4COMMANDCHARSET=winansi' it still return the same error info said that it can't support the wide charset. Now even the 'p4 help' command is not working, can anyone help me with this? thanks
Try forcing the command charset:
p4 -Q winansi login
If that works it just means that you haven't set P4COMMANDCHARSET correctly in your environment. Try running p4 set and see where it's reading environment data from.
And see this page for more info: http://answers.perforce.com/articles/KB_Article/Internationalization-and-Localization#i18n
I've found in the gnome-terminal help documentation a really cool list of things you can configure in a file but absolutely no documentation of what the variables in the conf file are. I've googled a bunch for this and haven't found anything useful. Can someone point me to something or even list the actual commands. Or maybe come out and sit here at my desk and pair on it. My google-fu has failed me this morning.
thanks
Also, gconf-editor stores it's configurations for gnome-terminal in ~/.gconf/apps/gnome-terminal
You're not just talking about using gconf-editor (from the System menu usually) are you?
Actually, gconf-editor needs to be started from a terminal on my Ubuntu system here, but there are a bunch of settings under gnome-terminal there.
GNOME Terminal has since changed how it stores its configuration; it now uses dconf, at least as of gnome-terminal 3.28.2.
You can query the dconf database for the UUIDs of available Profiles using:
gsettings get org.gnome.Terminal.ProfilesList list
Example output:
['b1dcc9dd-5262-4d8d-a863-c897e6d979b9']
You can view all per-Profile configurable settings (called "keys" in dconf) and their current values using:
gsettings list-recursively "org.gnome.Terminal.Legacy.Profile:/org/gnome/terminal/legacy/profiles:/:b1dcc9dd-5262-4d8d-a863-c897e6d979b9/"
Example output:
org.gnome.Terminal.Legacy.Profile audible-bell false
org.gnome.Terminal.Legacy.Profile cursor-shape 'block'
org.gnome.Terminal.Legacy.Profile cursor-colors-set true
org.gnome.Terminal.Legacy.Profile scroll-on-keystroke true
org.gnome.Terminal.Legacy.Profile cjk-utf8-ambiguous-width 'narrow'
org.gnome.Terminal.Legacy.Profile default-size-rows 24
org.gnome.Terminal.Legacy.Profile encoding 'UTF-8'
org.gnome.Terminal.Legacy.Profile use-theme-colors false
org.gnome.Terminal.Legacy.Profile custom-command ''
org.gnome.Terminal.Legacy.Profile visible-name 'Unnamed'
org.gnome.Terminal.Legacy.Profile text-blink-mode 'always'
... lots more ...
(tip: you can sort alphabetically by key if you pipe to sort, so modify your command to gsettings list-recursively "org.gnome......" | sort -k2)
To set a key (e.g. audible-bell), use:
gsettings set \
"org.gnome.Terminal.Legacy.Profile:/org/gnome/terminal/legacy/profiles:/:b1dcc9dd-5262-4d8d-a863-c897e6d979b9/" \
"audible-bell" \
false
Check out this script in my GitHub dotfiles repo for a practical example. In that script, I create a Profile of my own (if it does not already exist), set that Profile as the default, then configure the keys for that Profile as well as some keys for GNOME Terminal as a whole.
I've set up my ~/.hgrc as per https://www.mercurial-scm.org/wiki/MergingWithVim to use vimdiff.
[ui]
merge = vimdiff
[merge-tools]
vimdiff.executable = vim
vimdiff.args = -d $base $local $output $other +close +close
However, when I try to run the actual merge, it just fails out not very helpfully with the following:
bash-3.2$ hg --debug merge
searching for copies back to rev 7
resolving manifests
overwrite None partial False
ancestor 88aaf3a2e10f local 311bb03b96cd+ remote 29bec6ac5dd3
junk: versions differ -> m
preserving junk for resolve of junk
updating: junk 1/1 files (100.00%)
picked tool 'vimdiff' for junk (binary False symlink False)
abort: Operation not supported: /Accounts/rainest/mtest/junk.orig
Any idea why it's doing this?
I've figured it out.
It turns out there's a very specific bug in Python2.6's shutil library that occurs if you're working with NFS mounts on a BSD-like system. More information, and the fix, can be found at http://bugs.python.org/issue7512.
Depending on how you installed it Mercurial usually comes with vimdiff pre-configured for merging. On my machine that's in /etc/mercurial/hgrc.d/mergetools.rc but I imagine it's different in your OSX box.
You might want to check to see if it doesn't already use vimdiff for merging if you remove all of that from your .hgrc.
You can use the command hg showconfig --debug to see all the per-user, per-repo, and system-wide configuration items that are in effect. If you see vimdiff in there after the lines you've added are removed then you might be good to go.
the -w and -W options of vim have theoretically the following effect:
-w {scriptout} All the characters that you type are recorded in the file
"scriptout", until you exit Vim.
This is useful if you want to create
a script file to be used with "vim -s"
or ":source!". When the "scriptout"
file already exists, new characters
are appended. See also
|complex-repeat|. {scriptout} cannot
start with a digit. {not in Vi}
-W {scriptout} Like -w, but do not append, overwrite an existing file.
{not in Vi}
But when I do this, the {scriptout} file will always begin with a hexadecimal sequence like 80 fd 60 (sometimes it is 80 fd 62).
I am using gvimportable.exe 7.3 from portableapps.com. With the -u NONE switch, it does the same.
What is this “magic number” for? Under Windows with gvim.exe I cannot replay my scriptout until I have removed those three leading bytes…
It seems that this feature, which could be very useful, is poorly documented.
Thank you for your answers.
(This answer is probably fragmented significantly, it took me a while playing around - I wanted to find a solution too because it intrigued me - not just the bounty of 200 :P. It more or less shows my train of thought and experimentation.)
I can now reproduce it with gvim on Linux, which is /usr/bin/vim.gnome -g; running as vim -g does just the same.
Delving into the code: (futile in this case, but fun to do and to learn how to do)
I've looked through the source code and I can now explain it somewhat (but not usefully!); it gets the outfile FILE (src/globals.h:1004) set (src/main.h:2275); this is then written to in src/getchar.h:1501, in the updatescript method which is used by gotchars (line 1215) which is used by vgetorpeek, which is used by vgetc and vpeekc... (no, I don't know where this is going!) then these are used in a number of places.
Anyway, I suppose the key is somewhere in src/gui.c, but I don't know where at the moment! It's also possible that some key sequence is being "sent" (physically or virtually, I don't know), but seeing as the issue is the same across platforms it would seem more likely to be a Vim issue than otherwise.
Interesting situations leading to a probable explanation:
It's also worth while noting that if you automatically quit, gvim -u NONE -w scriptout -c quit (:quit after loading) or gvim -u NONE -w scriptout -c quit (instant :quit, never shows GUI), the file scriptout is left empty.
Additionally, if you open gvim and then close it using the X button, pressing no keys:
0000000: 80fd 6280 fd63 80fd 62 ..b..c..b
If you open gvim, click away, click back and use :q:
0000000: 80fd 6280 fd63 80fd 6280 fd2c 80fd 2e3a ..b..c..b..,...:
0000010: 710d q.
So I think it's the window events are internally translated into something else. 80 fd 62 is the open sequence and 80 fd 63 80 fd 62 is the close sequence.
I've found another way of triggering 80fd as well, which leads me to thing it's some sort of "user has access to the window"; by default with GNOME in Ubuntu, Ctrl+Alt+S does something with the window (can't remember what it's called; slides it all up into the title bar, app inside loses keyboard control etc.). gvim ... (you know the arguments!), i<Ctrl+Alt+S (contracted) Ctrl+Alt+S (expanded) >Esc Z Q produces this for me:
0000000: 80fd 6269 3c80 fd63 80fd 623e 1b5a 51 ..bi<..c..b>.ZQ
Summary: so there we have what I believe is the solution; gVim catches the window messages in some form and - whether it should or shouldn't - puts them in its scriptout. If you think it shouldn't (or would like to know why they're left in or if they're even meant to be or whether you should care at all), ask on the Vim list, I think.
My best guess is that this is a bug in the GUI code of gVim.
Using gVim 7.3, if I run gvim -u NONE -W scriptout then I see the problem, but if I run vim -u NONE -W scriptout then the unwanted bytes are not present.
I also tested Vim 7.2 from the shell in Linux, the version of Vim included in Snow Leopard (7.2), and the GUI and terminal versions of MacVim 7.2 (with mvim -W and /Applications/MacVim/Contents/MacOS/Vim -W, respectively) and they all worked correctly.
Someone has done the hard work for us in the vimgolf project, in particular this well-commented file: https://github.com/igrigorik/vimgolf/blob/master/lib/vimgolf/lib/vimgolf/keylog.rb
0x80 in escape sequence for special two-byte codes. In this case they represent gvim focus events. See here:
# If you use gvim, you'll get an entry in your keylog every time the
# window gains or loses focus. These "keystrokes" should not show and
# should not be counted.
"\xfd\x60" => nil, # 7.2 Focus Gained compat
"\xfd\x61" => nil, # Focus Gained (GVIM) (>7.4.1433)
"\xfd\x62" => nil, # Focus Gained (GVIM)
"\xfd\x63" => nil, # Focus Lost (GVIM)
I am having a problem with vim 7.2 hanging (for about 10 seconds) after it parses the .vimrc file. I had a similar issue in the past with tcsh on linux, but it was resolved by setting TERM to xterm-color. The same does not resolve the issue here. Any idea what may be causing this?
$ env
USER=redacted
LOGNAME=redacted
HOME=/home/redacted
PATH=redacted
MAIL=/var/spool/mail/redacted
SHELL=/bin/tcsh
TZ=redacted
LC_COLLATE=C
SSH_CLIENT=redacted
SSH_CONNECTION=redacted
SSH_TTY=/dev/pts/11
TERM=dtterm
HOSTTYPE=sun4
VENDOR=sun
OSTYPE=solaris
MACHTYPE=sparc
SHLVL=1
PWD=/home/redacted
GROUP=redacted
HOST=redacted
REMOTEHOST=redacted
QUOTA_CHECKED=1
WHOAMI=redacted
HOSTNAME=redacted
EDITOR=vim
PRINTER=redacted
INFOPATH=/software/gnu/gcc/2.8.1/sun4os5.10/info:/software/gnu/sun4os5/info:/software/gnu/emacs/20.3.1/sun4os5/info:/software/gnuish/sun4os5/info:/usr/local/gnu/info
MANPATH=/software/gnu/gcc/2.8.1/sun4os5.10/man:/software/gnu/sun4os5/man:/software/gnu/emacs/20.3.1/sun4os5/man:/opt/rational/clearcase/doc/man:/usr/openwin/man:/usr/share/man:/usr/local/man:/usr/dt/man:/software/gnuish/sun4os5/man
H_ARCH=sun4
H_ARCHOS=sun4os5
H_ARCHOS_SUB=sun4os5.10
H_OSTYPE=SUNOS
H_OSREV=51000
T_ARCH=sun4
T_ARCHOS=sun4os5
T_ARCHOS_SUB=sun4os5.10
T_OSTYPE=SUNOS
T_OSREV=51000
X11HOME=/usr/local/x11/sun4os5
OPENWINHOME=/usr/openwin
LD_LIBRARY_PATH=/usr/dt/lib:/usr/openwin/lib
MOTIFHOME=/usr/dt
XINITRC=/usr/openwin/lib/Xinitrc
GCC_REV=281
Does a vim -X make any difference (as I suspect you're not running gvim) ?
Otherwise, a lot of plugins may cause this. Or plugins that hang on some operations.
You can try starting vim with -u NONE to disable reading .vimrc, -U NONE to disable .gvimrc, and the --noplugin option disables loading of plugins, see if this helps.