Should vifm write vifmrc on exit?

xaizek
2011-07-02
2012-09-11
  • xaizek

    xaizek - 2011-07-02

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

     
  • - 2011-07-03

    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

    xaizek - 2011-07-03

    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 ;-)

     
  • - 2011-07-03

    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 ?

     
  • - 2011-07-03

    i meant with another name (last sentence)

     
  • xaizek

    xaizek - 2011-07-03

    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.

     
  • - 2011-07-03

    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

    xaizek - 2011-07-04

    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.

     
  • - 2011-07-04

    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

    xaizek - 2011-07-04

    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).

     
  • - 2011-07-04
    • 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.

     
  • - 2011-07-04

    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.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks