Should vifm write vifmrc on exit?

[xaizek]

Please write here what do you think about writing vifmrc on exit.

I thougth a little since yesterday about this problem of writing the .vifmrc.
And my point of view has changed a little.

At first sight in seemed to me strange to write a configuration file because
vim does not. But now, I'm no so sure anymore because I realized that most
sofwares do this. When you use the preference menu of any sofware it write
things in config files. Except that in general they do not encourage people to
write directly in the config file.

So now my answer is yes we can write the config file.

And it has the advantage not to disturb old habits of vifm users.

However, definitively informations that are not manual customization should
not be in the .vifmrc. I think of the last visited directory, history, last
position of something, ....You never write such an information yourself. It's
always the program. It would be better to a .vifminfo for that.

Bookmarks does not seem a problem to me (it's a kind of key mapping). They can
appear in the .vifmrc. If we allow to write map command in the vifmrc we can
also allow bookmarks.

The problem if vifm is allowed to write the config file, is that if it is not
done properly it can produce a lot of mess.

Two vifm instances can write at the same time. You can edit your vifmrc while
vifm is opened. And it needs care to handle this.

I think that the current version asking y/n to write is quite good for that.

At least compared to other sofwares.

I remember having destroyed my config file when I used emelfm2 file manager
because of this. And I had many problems with the first versions of vifm.

I have some suggestion of improvement (though they have also drawbacks, so
consider them just as ideas, and see if you like it or not ;-) )

1) use several config files (one for each task, bookmarks, commands, filetype,
options, etc...). It's very customary in many sofwares (w3m has an option
file, bookmark file, map file, mailcap file, ...) It will decrease the number
of conflicts. But it is also interesting to have all the configuration at the
same place to check it quicly. Again I think that the actual behaviour is good
on condition we do not write too many things because there will be tons of
conflicts.

2) implement some kind of svn check (allowing to write at different places
without conflict, but it's probably very difficult to implement, perhaps too
difficult just for config files). I must admit I've never heard of a software
using this (is it too difficult ?).

What about the startup file? Why did you include a startup file. What's the
advantage with respect to put the content of this file directly in the .vimrc
? There's an idea of exec at the beginning but I do not see a real advantage
of having another file.

Ranousse

[xaizek]

1) use several config files (one for each task, bookmarks, commands,
filetype, options, etc...)

Maybe, but I'm not sure. I'm afraid thet someday there will be too much files,
therefore I like vifminfo idea (your idea ;-) ) more.

2) implement some kind of svn check

This is possible, not like in svn (simpler), but possible.

What about the startup file? Why did you include a startup file. What's the
advantage with respect to put the content of this file directly in the .vimrc
? There's an idea of exec at the beginning but I do not see a real advantage
of having another file.

I've added it generally for storing mappings, but then :set command was added
and options can be placed there too. Main advantage of this file is that it
has no special format. It's just a set of commands that can be used in command
line mode. It can even do not exist. It's similar to .vimrc.

Main problem with vifmrc is that it requires special and careful treating,
when startup file does not. It isn't hard to support vifmrc, but it means do
part of the work twice, thus increasing count of bugs.

So, here is my current point of view:

• move parts of vifmrc, that user would (almost) never change by hand to vifminfo;
• add all :set options to vifmrc;
• add all vifmrc options to :set command;
• add mappings to vifmrc;
• add some kind of merging for vifmrc.
  So user can ignore vifmrc and use startup file. Or it can do not create
  startup file and use vifmrc only.

I'm planning to do some changes in vifm configuration for 0.7 version, but I
don't expect it to be ready soon. So feel free to criticize this ;-)

ok i understand better (at least i hope)

So in the startup we can put things like

:com command ....

:map ....

(any command that we can type in vifm with :)

and it is executed when we start vifm (hence the name)

In fact the startup file is what the vifmrc shoud be. Could it be possible to
remove the vifmrc, put everything in the startup file and name the startup
file vifmrc.

we could perhaps add

:filetype ...

If necessary we could just keep the old vifrmc with another for things that
are difficult to write in vi syntax.

Is this your idea ?

i meant with another name (last sentence)

[xaizek]

Yes. And something like

the old vifrmc with another name for things that are difficult to write in
vi syntax

is vifminfo. vi syntax is unneeded here because user shouldn't use command
line for changing history or something similar (but maybe I'll extend syntax
to make it more Vim like).

I don't know yet how vifmrc should be treated. There are different variants:

1) leave it for compatibility

2) or if we want to use name vifmrc for new config we can rename it on startup
of new version or even provide a simple tool that would update it

1) is more user-friendly since users can continue using old format if they
want to. In the other hand, I think that most of vifm users are "Vim addict"
and they would prefer to use Vim-like configuration, but with 1) they just
will have to use configuration file with another name (startup), I don't think
it's a problem.

ok as for me I'm found of vi. I like this idea

1) a .vifmrc with vi syntax and remove the old .vifmrc.

2) a .viminfo for last directory and things like that

Just mention it well somewhere so that vifm does not overwrite the old vifmrc
of the user.

In this case I think vifm should not write the vifmrc and write the .vifminfo.

commands, maps and set should go to the vifmrc.

So we keep the :com command but remove the possiblity of writing commands from
vifm (as vi does with :map).

I thinks it's better. For a particular application you can define an
application with :com in vifm and use it. And as you just needed it for this
case you don't save. It's vi philosophy with :map.

Same thing with map, set.

Filetypes and bookmarks are different since generally when we define them we
want to keep them.

However I wonder if it would not be better to put also them in the vifmrc
without possibility of modification (in particular remove m key). The m key is
useful but also very dirty. Because very often we make mistakes typing m when
we do not want to and create bookmarks we do not want (and then the only thing
we can do is going in the vifmrc with vi and delete lines). Worst, we
sometimes overwrite bookmarks.

In this case bookmarks could almost be treated has maps

map 'key :cd somedirectory<cr>

[xaizek]

I don't think that removing m command is a good idea. Another way is to add
some kind of lock if user wants to secure his bookmarks. Or this can be done
with remapping of builtin keys (which is not present yet): nmap m <nop> |
nnoremap M m. Maybe you can use uppercase marks for now, it is less possible
to make mistake then.

About adding marks to the vifmrc in vi like syntax, it should be useful for an
upgrade, but I don't think it would be convenient to add paths by hand. But
this could be done, just need to add :mark command.

ok to keep m key but with conditions ;-)

I think there are two kind of configuration information.

The ones the users write directly in a configuration file (like the vimrc of
vi)

and the ones the sofware write when the user goes in the menu preferences and
things like that. So, for me, we should split the vifmrc in two.

1) a new vifmrc containing :set :com :map :filetype commands and this one
should not be writable by vifm

2) another file for bookmarks (that's all now ?). This one is written by vifm.
And the user should not edit it (except if he knows what he does, at least it
should not be encouraged). This second file is different from the .vifminfo
reserved for history, last directory informations, ...

Since 2) should not be edited vifm should have everything to edit it
correctly.

For instance, for bookmarks, it could be interesting that the menu obtained
with :marks could be edited (for instance make dd and cw works).

Or having a mechanism like :rename opening vi to edit bookmarks (for instance
if we type :edit in the :marks window).

:com could also be handled this way (like bookmarks) but for vi compatibility,
i think it's better to let them in vimrc.

filetype could also be handled like bookmarks but for the same reason, and as
the lines for filetypes are more complicated i think it is a better solution
to edit it in a file. Moreover it is the old way of vifm.

I insist to have 2 files.

Besides I noticed that vifm modify the order of elements (alpha order) when I
edit the vifmrc. It should not be possible I think in a file the user can
edit.

I encourage to add some checks to avoid overwritting bookmarks or creating
ones when we do not intented to (as you said)

Concerning the viminfo.

I think that vifm should have a command line option to start in the last
directory perhaps also with other informations such commands defined during
last session, ... . The best choice is to do the same thing as vi here.

And an option in the vifmrc if we want it all the time (it's already the
case).

By the way it could be interesting that vifm remembers history of command when
closing (with the .viminfo)

[xaizek]

I think there are two kind of configuration information.

According to you there are three kinds:

• user preferences, not writable by vifm (vifmrc)
• preferences that are mainly written by vifm only, but users may want to do that sometimes (bookmarks, filetypes and commands in different files)
• session information (controled with 'vifminfo' option)
  I don't like too complicate system of configuration files. But since many
  software has it, I think it provides some advantages that I don't see.

Besides I noticed that vifm modify the order of elements (alpha order) when
I edit the vifmrc. It should not be possible I think in a file the user can
edit.

vifm just recreate vifmrc on exit. I don't like that this removes my comments,
but why should I care about order of commands (for example) ? User shouldn't
edit configuration files so often that he would remember order of lines.

Concerning the viminfo. ... The best choice is to do the same thing as vi
here

I'm agree.

By the way it could be interesting that vifm remembers history of command
when closing (with the .viminfo)

I have this in secondary TODO list (it holds some questionable things).

• preferences that are mainly written by vifm only, but users may want to do
  that sometimes (bookmarks, filetypes and commands in different files)

Even I for me the do not edit this file.

And I suggest to put the :com and filetype in the other files and thus would
not be writable with vifm (now it is possible for commands, but it very
strange for me because vim does not allow that. It allow to define command but
they are not saved. For me vifm should do the same thing. )

But the vew vifmrc would look like more the startup file with commands such as

:com ...

instead of

COMMAND ....

so it would be easy to edit

vifm just recreate vifmrc on exit. I don't like that this removes my
comments, but why should I care about order of

commands (for example) ? User shouldn't edit configuration files so often
that he would remember order of lines.

with the new vifmrc file i suggest (in fact the actual startup file). It
should be possible since it is as if commands were executed the one after the
other.

But of course in the file were i want to put bookmark it would not be
possible. This problem is for me an argument to tell you vifm should not write
the vifmrc.

about the order of commands it has an importance for me

I use often Ctrl-y in vifm in insert mode to copy the line above

And I like to keep commands are almost the same the one to the other

(command for unzip, untar, etc ...)

if edit filetypes, i prefer to have pdf with postscript, images with images,
archives with archives, etc...

But I agree it's only a detail.