windows gvim: time to have "Save Font Settings" in the menu (saveable settings ?)
Yakov
fabulous 'viminfo' for a long time,
viminfo that saves much more state than settings.
Why not have "saveable settings" which could make save-setting easier
for the naive user ?
It would be really convenient (and maybe for unix, too).
gVIM on Windows is nice app that walked a long way toward normal
Windows users.
I'd like to talk about "saveable settings", lack of which is
explainable in unix (historically)
but difficult to explain on Windows.
To save my current vim font setting on Windows, I look for menu
item
"Save Current Font Setting". Missing. I need to accomplish 15 easy
steps below [1].
Given that vim has 'viminfo' that saves, among other things, *cursor
position*,
I have difficult to believe it's technically difficult to save font
setting persistently by
a simple menu selection.
Yakov
[1] Steps needed to save font settings for Windows user:
- seek the "Save Font Setting" hard in the gVim menu
- figure find locations and names spellings of your vimrc file(s) of
files-to-be
- figure out of which of altrnative vimrc files to put font setting to
- figure which alternative vimrc already have possible setting
- check for overriding from other 'set gf=' command
- find spelling of the correct 'set font' command (which is 'set
guifont=' or 'set gf=').
Consult google, vim help, mailing list, IRC chat.
- figure correct quoting rules for space, backspace, apostrophes,
double quote, comma, and
other non-alphanumeric characters
- seek the "Save Font Setting" hard in the gVim menu, again
- figure which part of the command are case-insensitive and which are
not (ok, I exaggerate, but not much, not much...)
- figure which 'if's need to put before and/or after
- find current font name that 'set guifont' expect
Consult google, vim help, mailing list, IRC chat.
- find out where your gVim is built with Motif, Athena or GTK (it's
neither, that's ok, just having fun).
Gene Kwiecinski
at least the colorscheme via a modeline, specific to a file?
Seems as if modelines only accept ":set" commands; everything I tried
to do the equivalent of ":colorscheme torte" (ie, an out-of-the-box
bundled colorscheme, nothing made-up after-the-fact) seems to just grex
about an error reading the modeline.
No big deal, but would be nice for specific files. Eg, something with
wiiiiiiiide lines of code, I'd like to automagically shrink the font
size 1pt or so, just to be able to stuff a little more of the line in
the visual window, and I'm already defaulting to fullscreen (maximised)
on a widescreen monitor (207x61). I already include modelines of
# vim: sm smd nu ai so=3
for code, in case anything's not set in the .vimrc, and to get scrolloff
and line-numbering turned on for code files only; any texty files I
usually leave numbering turned off, and so=1 is fine in most cases.
Again, no big deal, but would be nice to do...
Raúl Núñez
On Thu, 6 Mar 2008 07:36:56 -0800 (PST), Yakov dixit:
> Is it time for vim to acquire the "persistent settings" ? Vim has
> fabulous 'viminfo' for a long time,
> viminfo that saves much more state than settings.
> Why not have "saveable settings" which could make save-setting easier
> for the naive user ?
> It would be really convenient (and maybe for unix, too).
I don't understand: why viminfo is not enough? I mean, if you think tha
viminfo is way too much (it saves too many things), you can:
- Select *less* things to save in viminfo, using the "viminfo" option.
- Disable viminfo entirely and use .vimrc and .gvimrc to save ONLY your
settings and nothing more.
> To save my current vim font setting on Windows, I look for menu
> item
> "Save Current Font Setting". Missing. I need to accomplish 15 easy
> steps below [1].
>
> [1] Steps needed to save font settings for Windows user:
> - seek the "Save Font Setting" hard in the gVim menu
> - figure find locations and names spellings of your vimrc file(s) of
> files-to-be
For that, use ":scriptnames". You will see what scripts were loaded and
where they were found.
> - figure out of which of altrnative vimrc files to put font setting to
:help vimrc
:help initialization
> - figure which alternative vimrc already have possible setting
Alternative .vimrc? You only have three: .vimrc, .gvimrc and .exrc. The
last one is not used if .vimrc is present, and .gvimrc is used after
.vimrc for settings that only affect the GUI version. If you only use
the GUI version, you can live with .gvimrc only, IIRC.
> Consult google, vim help, mailing list, IRC chat.
Next time, if you feel that you don't know what to look for, try the
list first. Google is great, as is the vim help, but vim is a very
complex and powerful program, and sometimes finding what you need is
very difficult. The list is then the best bet, and I think you can abuse
the list as long as you don't mind being answered with oneliners like
"see :help whatever" ;)
> - figure correct quoting rules for space, backspace, apostrophes,
> double quote, comma, and other non-alphanumeric characters
Well, this may be a problem, I don't know. Probably I have not problem
with this because vim quoting have looked always natural to me. It's not
much different than the quoting in C, Perl, shell script, etc...
> - seek the "Save Font Setting" hard in the gVim menu, again
> - figure which part of the command are case-insensitive and which are
> not (ok, I exaggerate, but not much, not much...)
You're exagerating *much* ;)))
> - figure which 'if's need to put before and/or after
This can be a problem, yes. Usually you can go without any "if", but
then you may face problems (e.g., when calling "vim" as "view" or
something). For the font this shouldn't be a problem, though.
> - find current font name that 'set guifont' expect
> Consult google, vim help, mailing list, IRC chat.
And yes, this IS a problem that could be avoided by having a menu entry
to set the font, probably.
Last but not least: I can see your point. As an end user you would like
to be able to manage vim settings using a menu and dialogs (which you
can more or less do now) *and* have that settings saved, which you can
do using sessions but is not a normal way for a Windows user.
But the thing is that vim is more UNIX oriented in that aspect, using a
text RC file for configuration. This is pretty standard under UNIX, but
not under Windows, where settings are stored in that ominous registry.
I can't see any reason you cannot ask for that "feature" to be added,
though ;)
Raúl "DervishD" Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
We are waiting for 13 Feb 2009 23:31:30 +0000 ...
ThoML
> at least the colorscheme via a modeline, specific to a file?
for that (well, not exactly "that" because I don't want the font size
or the color scheme to be changed automatically).
Automatical execution of code when loading a file into a buffer
implies some potential security problems. :h modeline (scroll down)
gives a hint at how to set variables from an autocommand. A similar
approach could be used to run any command (at your risk). If you
select some idiosyncratic prefix nobody knows about, it probably isn't
a problem though.
Gene Kwiecinski
>>at least the colorscheme via a modeline, specific to a file?
>I personally use http://www.vim.org/scripts/script.php?script_id=441
>for that (well, not exactly "that" because I don't want the font size
>or the color scheme to be changed automatically).
Hmm, interesting. 'Though most of what I'd use that for would be
necessarily bouncing around from one dir to another, so w/o having to
copy the '.lvimrc' to each and every one, that probably wouldn't work.
If it got annoying enough, would just add to the .vimrc for the project
(or map it to a key and bap the key to fire off the new
commands/settings) and then just edit the .vimrc back to what it was
previously. Tnx, though.
>Automatical execution of code when loading a file into a buffer
>implies some potential security problems. :h modeline (scroll down)
>gives a hint at how to set variables from an autocommand. A similar
>approach could be used to run any command (at your risk). If you
>select some idiosyncratic prefix nobody knows about, it probably isn't
>a problem though.
Understood, but was just hoping for some weirdo punctuation prefixes to
be able to use a modeline for such things, eg,
# vim: ++colorscheme=torte
or something along those lines, vs the usual ':set' commands only.
The solution would just be to map a key, as above. Eg, one of the
function keys or something else little-used. I did that to set the
filetype to .xml, because I'd be working with lots of intermediate files
with numeric suffices, like a .i10, .i20, .i30, .i35, etc., for all .xml
files but in intermediate stages of conversion. Typing ':set ft=xml'
each and every time I'd edit a new file got *really* old *really* fast.
Gary Johnson
:help new-filetype
Example:
augroup filetypedetect
au! BufRead,BufNewFile *.i\d\+ setfiletype xml
augroup END
Or if you want that only for files in a certain directory:
augroup filetypedetect
au! BufRead,BufNewFile */xmlwork/*.i\d\+ setfiletype xml
augroup END
HTH,
Gary
Gene Kwiecinski
>>filetype to .xml, because I'd be working with lots of intermediate
files
>>with numeric suffices, like a .i10, .i20, .i30, .i35, etc., for all
.xml
>>files but in intermediate stages of conversion. Typing ':set ft=xml'
>>each and every time I'd edit a new file got *really* old *really*
fast.
> augroup filetypedetect
> au! BufRead,BufNewFile *.i\d\+ setfiletype xml
> augroup END
Aha, *this* could come in handy, tnx!
Cyril Slobin
> [1] Steps needed to save font settings for Windows user:
From my _vimrc:
" Called automagically after .viminfo and plugins are loaded, sets
" miscellaneous options from persistent global variables
function! VimEnter()
for opt in g:options
let varname = "g:OPT_" . toupper(opt)
if exists(varname)
execute "let &" . opt . " = " . varname
endif
endfor
execute "syntax" g:SYNTAX
if g:keep_position && has("gui_running") &&
\ exists("g:WINPOSX") && exists("g:WINPOSY")
execute "winpos" g:WINPOSX g:WINPOSY
endif
endfunction
" Called automagically before .viminfo is saved, saves miscellaneous
" options into persistent global variables
function! VimLeavePre()
for opt in g:options
let varname = "g:OPT_" . toupper(opt)
execute "let " . varname . " = &" . opt
endfor
let g:SYNTAX = exists("g:syntax_on") ? "on" : "off"
if has("gui_running")
let g:WINPOSX = getwinposx()
let g:WINPOSY = getwinposy()
endif
endfunction
autocmd VimEnter * call VimEnter()
autocmd VimLeavePre * call VimLeavePre()
" These options will be kept between editing sessions
let options = ["iminsert", "spell", "guifont"]
let keep_position = 1
In fact there is a bit of lie here: "guifont" is not in my actual _vimrc,
I don't like it to be saved. But before posting this I have added it and
tested whether it worked. It does.
--
Cyril Slobin <slo...@ice.ru> `When I use a word,' Humpty Dumpty said,
http://wagner.pp.ru/~slobin/ `it means just what I choose it to mean'
Tony Mechelynck
Actually modelines can only do the equivalent of ":setlocal" commands,
and not for all options (some are disabled in modelines for security
reasons); but in the case of global options, the ":setlocal" becomes a
":set".
The problem with using a modeline to set the font (which can be done in
the GUI) and/or the colorscheme (which cannot be done), is that these
are global settings, applying to all buffers and windows. If one file
(written in Chinese) sets some Chinese font by means of a modeline, and,
in another split window, another file (written in Arabic) sets an Arabic
font by _its_ modeline, then whichever is loaded last, wins, and quite
probably makes the other totally illegible.
Best regards,
Tony.
Tony Mechelynck
Some settings can be saved in the viminfo, others can be saved in a
session script (created by ":mksession" q.v.)
If, after changing your GUI font, you decide that you like the new
setting and want to use it every time, just do the following (assuming
'nocompatible' mode):
1. :set guifont=<Tab>
2. Write down what is now on your Vim command-line. It may contain extra
backslashes if and where you will need them, so include them in what you
copy.
3. Hit <Esc>
4. Add to your vimrc the line you wrote down at step 2 (you may leave
out the initial colon).
No sweat. Have fun.
Best regards,
Tony.
--
It is against the grain of modern education to teach children to
program. What fun is there in making plans, acquiring discipline in
organizing thoughts, devoting attention to detail, and learning to be
self-critical?
-- Alan Perlis
jerbear
simple config file, then vim might be a bit too advanced for you?
Jürgen Krämer
Hi,
Tony Mechelynck wrote:
>
> If, after changing your GUI font, you decide that you like the new
> setting and want to use it every time, just do the following (assuming
> 'nocompatible' mode):
>
> 1. :set guifont=<Tab>
> 2. Write down what is now on your Vim command-line. It may contain extra
> backslashes if and where you will need them, so include them in what you
> copy.
> 3. Hit <Esc>
> 4. Add to your vimrc the line you wrote down at step 2 (you may leave
> out the initial colon).
or open your vimrc, change to insert mode and enter
let &guifont='<c-r>=&guifont<cr>'
Regards,
Jürgen
--
Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us. (Calvin)
Andy Wokula
>
> Hi,
>
> Tony Mechelynck wrote:
>> If, after changing your GUI font, you decide that you like the new
>> setting and want to use it every time, just do the following (assuming
>> 'nocompatible' mode):
>>
>> 1. :set guifont=<Tab>
>> 2. Write down what is now on your Vim command-line. It may contain extra
>> backslashes if and where you will need them, so include them in what you
>> copy.
>> 3. Hit <Esc>
>> 4. Add to your vimrc the line you wrote down at step 2 (you may leave
>> out the initial colon).
>
> or open your vimrc, change to insert mode and enter
>
> let &guifont='<c-r>=&guifont<cr>'
>
> Regards,
> Jürgen
In the vimrc, I often use
o<C-R>:<Esc>
:w
to preserve an Ex-command I just executed in the command line.
--
Andy
Yakov
> simple config file, then vim might be a bit too advanced for you?
You either (1) misunderstand the meaning of word "advanced", or
(b) are confusing it with word "primitive", or
(c) assume/think that vim itself has no ability to write/save
files which it can later read commands from.
Anyway, since when inability of a software to perform what
user expects from it counts as "advanced", or "impressive" ?
Yakov
On Mar 6, 8:16 pm, "Cyril Slobin" <slo...@ice.ru> wrote:
Yongwei Wu
>
> > Is it just me or is it too much to expect that if you can't manage
> > a simple config file, then vim might be a bit too advanced for
> > you?
>
> It is just you.
Definitely not him alone. I would not say that, but I had a similar
feeling. And I could not agree with your original idea at all, since
it was just incompatible with the Vim way.
For the record, I set the guifont in my _vimrc, and I do that
dynamically, depending on the environment. There is simply no generic
way to save the guifont setting without breaking my configuration.
> You either (1) misunderstand the meaning of word "advanced", or
> (b) are confusing it with word "primitive", or
> (c) assume/think that vim itself has no ability to write/save
> files which it can later read commands from.
>
> Anyway, since when inability of a software to perform what
> user expects from it counts as "advanced", or "impressive" ?
Some tools, like Vim and probably Emacs, demand a lot from users. If
users are not accustomed to play with their configuration file to
achieve what they want, the tool may really be not suitable. I would
also like to compare Vim to C++. If somebody think C++ does not work
as he expects, more chances are that he should learn more instead of
blaming the language. For a versatile tool like C++, Vim, or Emacs,
there is simply no way to expect it works as you like at the
beginning. Unless you are already a "guru" and know its "way",
blaming the tool will not earn you applause.
Best regards,
Yongwei
--
Wu Yongwei
URL: http://wyw.dcweb.cn/
A.Politz
>>Is it just me or is it too much to expect that if you can't manage a
>>simple config file, then vim might be a bit too advanced for you?
>>
>>
>
>[...]
>
>Anyway, since when inability of a software to perform what
>user expects from it counts as "advanced", or "impressive" ?
>
>
>
Since unix ;O)
-ap
--
:wq
A.Politz
>On 09/03/2008, Yakov <ile...@gmail.com> wrote:
>
>
>>>Is it just me or is it too much to expect that if you can't manage
>>>a simple config file, then vim might be a bit too advanced for
>>>you?
>>>
>>>
>>It is just you.
>>
>>
>
>
>
>[...]
>Some tools, like Vim and probably Emacs, demand a lot from users. If
>users are not accustomed to play with their configuration file to
>achieve what they want, the tool may really be not suitable. I would
>also like to compare Vim to C++. If somebody think C++ does not work
>as he expects, more chances are that he should learn more instead of
>blaming the language. For a versatile tool like C++, Vim, or Emacs,
>there is simply no way to expect it works as you like at the
>beginning. Unless you are already a "guru" and know its "way",
>blaming the tool will not earn you applause.
>
>Best regards,
>
>Yongwei
>
>
GNUEmacs has a feature called customize since $someversion.
It let's users install options without even seeing their
~/.emacs and w/o knowing any elisp. Though that's a bit
of a difference compared to vim, since using the set command
is easier than beeing able to assign variables in elisp.
If the OP wants somethin in his menu, he should use the amemu command.
-ap
--
:wq
Tony Mechelynck
In Vim, you can use :options and :mkvimrc -- though I much prefer to
write my own vimrc. YMMV, of course.
Best regards,
Tony.
--
ARTHUR: Well, it doesn't matter. Will you go and tell your master that
Arthur from the Court of Camelot is here.
GUARD #1: Listen, in order to maintain air-speed velocity, a swallow
needs to beat its wings 43 times every second, right?
ARTHUR: Please!
The Quest for the Holy Grail (Monty
Python)
Ben Schmidt
>> It let's users install options without even seeing their
>> ~/.emacs and w/o knowing any elisp. Though that's a bit
>> of a difference compared to vim, since using the set command
>> is easier than beeing able to assign variables in elisp.
> In Vim, you can use :options and :mkvimrc -- though I much prefer to
> write my own vimrc. YMMV, of course.
If desired, you could make a menu item that runs :mkvimrc or an autocommand that
runs it whenever you exit Vim to make any changes to settings stick between
sessions (though this could get confusing with multiple Vims open). If you do
this, be sure to put the code in ~/.vim/plugin/somefile.vim, not in your .vimrc! I
wonder if somebody has perhaps already written a plugin that does this? Together
with :options, it would make a simple entry point for new users, perhaps. But I
would suspect they would soon want to start writing their own .vimrc!
On the topic of the original thread, I do agree that setting the font, in
particular, seems hard. I think this is because it is a task that is never really
done from the commandline, but via a GUI window, and as such, doesn't lend itself
nicely to typing into a .vimrc file. Still, several good alternatives have been
mentioned in this thread for how this can be done, so one need only ask. It is
also not hard to find :options in the GUI menus and I think it is definitely fair
to expect even new users to understand where .vimrc is located and what it
does--it's even in the vimtutor tutorial. With this knowledge, it becomes a fairly
simple task.
It is also worth noting that sometimes making things too easy or predictable for
newbies can be doing them a disservice. Case study: pretty much any point and
click text editor. I think taking a little extra time/trouble to learn how to
access Vim options and store them in a .vimrc (perhaps by using the help or asking
on the mailing list) will be beneficial for users in the long run as they will
learn skills useful for many other tasks.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
ThoML
> runs it whenever you exit Vim to make any changes to settings stick between
> sessions (though this could get confusing with multiple Vims open).
well with automatically changing the directory, but options and the
like can also be stored in sessions. There are plugins that
automatically save and restore sessions on vimenter & vimleave.
With respect to emacs, I found setting the the font, the window/frame
size, and maybe even the colour scheme in emacs much more difficult
than in vim.
jerbear
to be primitive? I'm sure if you took the time to learn a bit more
about Vim, you would find it to be an extremely advanced piece of
software... including it's method of configuration.
Tony Mechelynck
In the particular case of setting the font, I myself found it so hard
when I was a newbie user of gvim, that I studied the help for it in
detail, made some experiments using the double-boot Windows/Linux system
I had at the time, and finally wrote up the result of my findings, into
what has now become
http://vim.wikia.com/wiki/Setting_the_font_in_the_GUI ; part of it can
be found in simplified form in the current help as ":help setting-guifont".
Best regards,
Tony.
--
Sex is one of the nine reasons for reincarnation ... the other eight
are unimportant.
-- Henry Miller
Steve Hall
>
> Anyway, since when inability of a software to perform what
> user expects from it counts as "advanced", or "impressive" ?
If I can just chime in here on the usability side of Vim. It's been my
observation over the years that a lot (most?) Vim users have a pretty
sophisticated level of software understanding. When that is matched
with a highly developed and longstanding piece of software like Vim,
it isn't unusual for them to defend it based on its own logic, not
that of someone just coming to it. There's nothing wrong with this,
you might think of it as a student who prefers to get rid of the black
piano keys simply because he can only play in C/a (simple keys that
don't use them). Would Chopin get rid of them?
That said, Vim *can* be simplified into a more conventional text
editor. I did it myself in Cream (http://cream.sf.net). Frankly, I
think this solves the 80/20 rule (Pareto principle) for new, casual,
or infrequent users (including the settings retention problem that
began this thread). But there is a lot that Vim can do, and against
the needs of sophisticated users, it is unlikely that the current
state will change due to the approachability argument.
--
Steve Hall [ digitect dancingpaper com ]