#22 disable lwinpath and rwinpath

closed
xaizek
None
5
2012-09-11
2011-07-01
No

I have used vifm for 3 years now and I really liked the old way of choosing the starting directories (vifm with no argument -> current directory for both instead of the last ones).
Besides, I often launch several vifms. And therefore I always have warnings about writing in vifmrc because of this feature (writing the the last directory in .vifmrc when closing with :q)

It would be nice to have an option to disable starting in the last visited directory.
And if we want this feature I think it would be better to write the last directory name in another file than the .vifmrc (after all it's not a configuration option ;-))

Discussion

1 2 3 .. 52 > >> (Page 1 of 52)
  • xaizek

    xaizek - 2011-07-01

    Hi ranousse,

    you're right, I shouldn't change old behaviour of vifm. And I don't like writing vifmrc on exit even when no option was changed too, but I couldn't decide how to organize this right way. So thank you for your suggestions. I'll implement them soon.

    By the way, vifmrc contains bookmarks, which are not configuration options too. What do you think about moving them to something like ~/.vifm/bookmarks? (vifm would still be able to read them from vifmrc for backward compatibility, but it wont write them back).

     
  • xaizek

    xaizek - 2011-07-01

    I've just committed the changes to the repository. Please check then and let me know if something is wrong.

     
  • - 2011-07-01

    I've just checked. It seems ok for me now, thank you for the quick answer.

    As concerns writting in the .vifmrc, I think it would be cleaner not to write in it.
    And to have an other file for the things we have to write : bookmarks and last directories.
    In fact there's another thing we can write, it's commands via :com ...
    I never understood why vifm offered this feature. Because it's much easier to write directly in the .vifmrc.
    I wonder if it would not be better the :com commands in vifm does not write anything (after all in vi when we use :map, it does not save anything in the .vimrc). Could be interesting to have the point of view of other vifm users.

    I also noticed a problem with colorschemes when switching to new version
    Here's my old colorscheme
    COLORSCHEME=Default
    DIRECTORY=/
    COLOR=MENU=white=black
    COLOR=BORDER=black=white
    COLOR=WIN=white=black
    COLOR=STATUS_BAR=white=black
    COLOR=CURR_LINE=white=blue
    COLOR=DIRECTORY=cyan=black
    COLOR=LINK=yellow=black
    COLOR=SOCKET=magenta=black
    COLOR=DEVICE=red=black
    COLOR=EXECUTABLE=green=black
    COLOR=SELECTED=magenta=black
    COLOR=CURRENT=blue=black

    COLORSCHEME=SomeName
    DIRECTORY=SomeDirectory
    COLOR=MENU=white=black
    COLOR=BORDER=black=white
    COLOR=WIN=white=black
    COLOR=STATUS_BAR=white=black
    COLOR=CURR_LINE=white=red
    COLOR=DIRECTORY=cyan=black
    COLOR=LINK=yellow=black
    COLOR=SOCKET=magenta=black
    COLOR=DEVICE=red=black
    COLOR=EXECUTABLE=green=black
    COLOR=SELECTED=magenta=black
    COLOR=CURRENT=blue=black

    It should only change the cursor color when in SomeDirectory and the rendering of SomeDirectory is in fact not good at all (almost everything in black and white)

    And here's another problem (it was already in the old version)
    Lauch vifm
    :sh
    And now close the terminal whith a clic on the cross, not ctrl-d (I know we shoud not but sometimes I forgot I am in a term opened by vifm)
    The cpu becomes 100%
    I you have an idea to correct it would be very useful for me. Because when you use vifm with ssh, and make that mistake you often do not realize the CPU is 100% and the server does not like it ;-)

    Thank you for your great work. You correct all the other bugs I had seen and added very nice features.

     
  • xaizek

    xaizek - 2011-07-02

    As concerns writting in the .vifmrc, I think it would be cleaner not to
    write in it.
    And to have an other file for the things we have to write : bookmarks and
    last directories.
    In fact there's another thing we can write, it's commands via :com ...
    I never understood why vifm offered this feature. Because it's much easier
    to write directly in the .vifmrc.
    I wonder if it would not be better the :com commands in vifm does not
    write anything (after all in vi when we use :map, it does not save anything
    in the .vimrc). Could be interesting to have the point of view of other
    vifm users.

    Vim uses two files. .vimrc for user options in which Vim don't write anything itself, and .viminfo for storing last position in files, content of registers etc. I think we could move bookmarks and filetypes to vifminfo and let users set all options and commands in the startup file (it's like .vimrc). I'll add all missing options from vifmrc to :set command to make this possible. But we still need to know what other vifm users think about this, I'll ask their opinion on vifm.sourceforge.net.

    I also noticed a problem with colorschemes when switching to new version

    It should only change the cursor color when in SomeDirectory and the
    rendering of SomeDirectory is in fact not good at all (almost everything in
    black and white)

    It's fixed now.

    And here's another problem (it was already in the old version)
    Lauch vifm
    :sh
    And now close the terminal whith a clic on the cross, not ctrl-d (I know
    we shoud not but sometimes I forgot I am in a term opened by vifm)
    The cpu becomes 100%
    I you have an idea to correct it would be very useful for me. Because when
    you use vifm with ssh, and make that mistake you often do not realize the
    CPU is 100% and the server does not like it ;-)

    I was planning to fix this one day, but I can't reproduce it now neither using ssh nor running vifm without a terminal. I'll test it on another system later.

    Thank you for your great work. You correct all the other bugs I had seen
    and added very nice features.

    Thank you for your suggestions and bug reports.

     
  • - 2011-07-02

    I do not know if it helps but or the 100% cpu problem,
    I have it on debian stable, xterm terminal, zsh shell, xfce4 or ion3 window manager.

    If you want to reproduce it
    1) launch vifm (in an opened xterm or xterm -e, no difference)
    1) :sh
    2) close terminal with the mouse (not ctrl-d or exit)

    With ssh, I often have this problem as follows
    1) launch vifm on the server
    2) :sh
    3) close the session on my computer (not the server) without closing the xterm of the ssh command

     
  • xaizek

    xaizek - 2011-07-02

    I reproduced it by building a chain of vifm and shell instances (ssh->vifm->shell->vifm->shell->...).
    It should be fixed now. Please test it.

     
  • - 2011-07-02

    I confirm. It's fixed. Thank you very much.

    If you have time you could also have a look at problems of simple quotes and double quotes in files.
    You've already done a great work since there is no problem any more with yy, dd, etc.
    However there is still problems with commands such has
    1) !command %f
    2) !!command %f
    and with all commands using %f (commands and filetype in particular)
    More annoying is the fact that the behaviour is different for 1) and 2)
    1) works with simple quote and not double quote
    2) works with double quote and not simple quote

    I looked in the code and it seems due to the fact 1) is done with
    sh -c "commande" so the double quotes does not work
    and 2) with sh -c "pauseme 'command'" with command inside simple quote

    This problem of quotes is not so important to me because I have not files with quotes in them.
    But I do have a problem of quotes with commands such as
    !for i in %f; do echo "$i"; done
    and we have to do thinks like
    !for i in %f; do echo \$i; done

    I think it is because when we lauch a command such as
    sh -c "var=3; echo $a" in a shell, due to the use of double quote the variable $a belongs to the shell in which we launch sh -c and not the sh -c shell.
    About 2 remarks :
    1) couldn't we use directly the C system command to have a clean use of sh -c
    2) in case we do not use system command, I think it would be better to always use simple quote
    sh -c ' .... '

    By the way, the pauseme script is not posix and should not begin with #!/bin/sh but #!/bin/bash.
    You can see this by launching dash pauseme echo toto. You have an error.
    (we cannot use == and [[ in posix)
    I had problem with it when dash became the default shell in debian. Seems to work know but I do not know why.
    Anyway I suggest to replace sh by bash or pauseme
    by

    !/bin/sh

    if [ "$1" = "PAUSE_ON_ERROR_ONLY" ]
    then
    ON_ERROR=1
    PROG=$2
    shift 2
    else
    ON_ERROR=0
    PROG=$1
    shift
    fi

    "$PROG" "$@"
    PRG_ST_EXIT=$?

    if [ $ON_ERROR = 0 ] || [ $ON_ERROR = 1 -a $PRG_ST_EXIT != 0 ]
    then
    echo "Press return ..."
    read dummy
    fi

    exit $PRG_ST_EXIT

     
  • - 2011-07-02

    Sorry to bother you one more time but I've detected another lilttle problem.
    I've chose n
    vi_command=vim -p
    so when I select multiple files with t
    and then :e vi opens all the files in differents tabs

    The problem is that doing so when I select n files it only opens the n-1 first ones. Perhaps in the code the -p is counted as the first one and that's why we lose one file

     
  • - 2011-07-02

    the :edit command has also problems with double quotes

     
  • xaizek

    xaizek - 2011-07-02

    About single and double quotes. I'll try to figure out why my_system() is used. :edit now works with single and double quotes. Commands like :!for i in %f; do tar -czf "$i.tgz" "$i"; done work too. In case you're interested what was the problem: commands were built with snprintf(foo, sizeof(foo), "sh -c %s", ...);, and shellout() prepended "sh -c" (in fact, my_system() adds two more calls of sh ;) it's too much, something needs to be changed).

    About pauseme script. 'bash --posix pauseme echo toto' don't print any error messages, but I've replaced pauseme script with your version, it looks more portable.

    About vim -p. vifm truncated command by one character, fixed.

    Let me know if you find more bugs :)

     
  • - 2011-07-02

    Thank you very very much !!!
    Everything seems ok now.

    About the pauseme script I can give you a little more explanation. In fact the problem is not posix or not posix but bash or sh. The script has #!/bin/sh at the beginning so is executed with sh.
    With the old old stable debian sh is a link to bash so there is no problem if we put sh at the beginning of the script and use bash commands. But with the current debian stable sh is a link to dash and therefore many bash commands does not work. That's why when I upgraded to the new debian the !!command did not work anymore.

    I did not find any more bugs. But there are still to things that I think that could be improved.
    1) about opening symlink: when you have a simlink to a file (displayed in yellow) and you want to open it with l or <return> vifm does not open it but goes to directory of the cible and only then you can open it. I think it would be better to open it directly. It's very annoying when we look at documentation files in /usr/share/doc where many files are simlink to lose the current directory because of a simlink.
    2) about background processes: suppose you lauch vifm with xterm -e vifm. Then you open a pdf file with default application which is for me xpdf %c &
    while the pdf is open you close vifm with :q it also close the pdf. And I would prefer to keep it opened.
    This problem does not appear when vifm is launched in an already opened terminal. But it also occur with almost all applications launched in the background (except gv, emacs, and xterm).
    I have a little hack to avoid this problem :
    nohup xpdf fichier >/dev/null 2>&1 &
    (the nohup avoid the killing of xpdf and the redirections to /dev/null avoid the writing of nohup.out files)
    But it would be nice if vifm had a solution to this. The menu printed with :file would also be much clearer.

     
  • - 2011-07-02

    I also thought of other nice features I think ;-)
    It's not very important so feel free to tell me you do not want to implement it ;-)

    Very often you define a command that does something with %f

    Here are two representative examples
    :Edit -> vi -p %f
    :Pack -> apack -e -F %a %f
    The first one is straightforward
    The second one use the apack command to create an archive
    :Pack .tar.tgz
    create a tar.tgz archive of all the selected directories (a kind of generalization of your for loop example with any type of compression)

    We could also want to use the first one in the following way
    :Edit .vimrc
    and the second one
    :Pack .tar.bz2 *
    That is not possible with the current behaviour

    So here is my question
    1) could you modify the edit command defined in the C code to handle the first case
    2) in the second case i do not think it is useful to type
    :Pack .tar.gz somefile
    It is more convenient to select somefile with the t key and it is very rare to compress hidden files.
    But it could be interesting if we could use some file selectors for every defined command. An example is
    :%Pack .tar.gz
    to compress every files in the directory
    Or perhaps
    :1,3Pack .tar.gz
    though perhaps less useful.
    Such selector would just have to modify the %f variable
    It would be a nice genalization a vi.
    But I'm sure you've already though about this. Perhaps it needs a lot work to implement it (because I guess it needs to redefine many things in the files that handle the creation of commands by user)

    By the way, something that would also be great would be
    :s/pattern/replace/
    as in vi to rename files
    But your rename command is already very good since I can handle this problem with
    :rename and then substitute in vi.
    However if you want to implement this :s command you could perhaps use the rename perl script
    that allow to perform sed and tr actions on filenames instead of lines in files.

    Once more thank you. It is very rare to have a developer of a free application who corrects bugs as fast as you do.

     
  • - 2011-07-02

    Here are other ideas. In fact I have many ideas because I also wanted to do what you 've just done (correct the bugs of the old vifm, and add the most important missing feature: maps). But I never had time to study the code of vifm. And I also need to learn more things about the C language. You've already done more than I intented to do.

    1) The first idea comes from the ranger file manager another vi like file manager.

    key ya : add the selected files to the list of yanked files (instead of yy that remove the previous ones)
    key da : add the selected files to the list of deleted files
    key pl : is the same as p (copy) but instead create symlinks. In this case we cannot use the same key because ranger use pp to paste so it can use pl to link. And now I'm used to p and do not want to change ;-)

    It could also be interesting to have a %something to represent the deleted file and another %something to represent the yanked file to use with user command.

    2) mouse support

    I also noted that ranger had mouse support (and mc too). As ncurses supports mouse, why not have mouse in vifm. I must admit that I use ion3 file manager and almost never use the mouse, but why not ? ;-)

    3) view of directories (just for fun)

    with :view we have a preview of files
    On directories vifm only says "File is a directory"
    why not showing the the list of files of the directory

    As I do not develop anything it is does not cost me anything to have crazy ideas that needs a lot of time to implement ;-)

     
  • - 2011-07-02

    The last one for today. Promised ;-)
    And also more useful.

    I never liked the default case dependant search of vifm.
    What about an ignorecase search option (or even better the smartcase option of vi, perhaps also harder to implement)

     
  • - 2011-07-02

    a bug of selection with v key
    suppose you have the command
    echo -> echo %f in .vifmrc

    you select several files with v key.
    :<,>echo
    it only prints one file as if %f only contains the last file

     
  • - 2011-07-02

    moreover in the previous case vifm does not accept
    <,>!echo %f
    (without defining a command)

     
  • xaizek

    xaizek - 2011-07-02

    About opening symlink. I think that new option 'runlinks' (disabled by default) would be nice compromise with old behaviour of vifm. I'll add it.

    About closing child processes. Good idea, all add this too.


    1) could you modify the edit command defined in the C code to
    handle the first case

    Yes, I thought about this too while fixing "vi -p" problem.

    As concerns %f macro and selectors, it'll take some time to implement this, but I'm sure that it's worth doing.

    By the way, something that would also be great would be
    :s/pattern/replace/
    as in vi to rename files

    I didn't think about this, but I like it ;) :rename command was designed for more complicated operations and it would be nice to have such handy command.


    key ya : add the selected files to the list of yanked files
    (instead of yy that remove the previous ones)

    This can be done with a mapping like :nmap ya "Ays , but we can't do this with the default register, because it's double quote.

    key da : add the selected files to the list of deleted files

    Do you mean remove all selected files? If the answer is yes, you can do this with ds command.

    key pl : is the same as p (copy) but instead create symlinks. In this case
    we cannot use the same key because ranger use pp to paste so it can use pl
    to link. And now I'm used to p and do not want to change ;-)

    This needs to be implemented too.

    mouse support

    I don't like using mouse ;) because it's slower than keyboard. But I must admit that sometimes it's more convenient. I'll add to TODO list.

    3) view of directories (just for fun)

    I saw this in some other file managers and think it can be helpful when you go through file system looking for something that cannot be found with find command.


    I never liked the default case dependant search
    of vifm. What about an ignorecase search option
    (or even better the smartcase option of vi, perhaps
    also harder to implement)

    I'll add smartcase option, it's pretty easy to implement.


    Bug with visual mode is fixed, except :'<'>!echo %f, I'll look into it tomorrow.

    Again thank you for the ideas. I've added them to TODO file and will start implement soon.

     
  • - 2011-07-03

    About da, I meant
    add the selected files to default register and the files in the Trash.
    But I did not know about registers so I'll look first at it.

     
  • - 2011-07-03

    while playing with registers I tried
    "add one a file
    then
    "bdd on another
    then "ap
    somewhere
    I obtain segfault.
    There's probably some bug somewhere.

     
  • - 2011-07-03

    Concerning I'm not sure you understood my idea. I explain again to be sure.
    Imagine you have 3 directories d1, d2 and d3. And you want to copy some files of d2 and d3 to d1.
    Now with vifm I go d2 yy on the files then p in d1 and the same thing with d3
    What I suggest is go to d2 yy on ghe files the go to d3 ya on the files of d3 and then go to d1 where you paste (but only once)
    ya (means adds to yanked files)
    da would be the same with cutting files.

     
  • - 2011-07-03

    The default sort is by extension and not by name as says the documentation.
    Don't you think that name sorting is more natural for the default ?

    It's a little disturbing. It took some time to me to understand what happened (at first sight I thought were was a bug in the rendering)

    Of course it's just a minor remark since we can choose the sorting criteria in the vifmrc.

     
  • - 2011-07-03

    A remark about filtering
    the default is
    LWIN_FILTER=.o$
    what can we do if we do not want to filter anything
    I thought of
    LWIN_FILTER=
    (nothing)
    but it filters everything
    I have LWIN_FILTER=^$
    but it's not entirely satisfactory since it's possible to have a file named "" (empty string) under linux I think and it will be filtered.

     
  • - 2011-07-03

    Hum my post about ya and da is difficult to read due to many mistakes while typing. This should me more readable.

    Concerning ya and da I'm not sure you understood my idea. I explain again to be
    sure.
    Imagine you have 3 directories d1, d2 and d3. And you want to copy some
    files of d2 and d3 to d1.
    Up to now, with vifm I go d2 yy on the files then p in d1 and the same thing with
    d3.
    What I suggest is going to d2 yy on the files then going to d3 ya on the files of
    d3 and then going to d1 where you paste (but only once)
    ya (means adds to yanked files)
    da would be the same with cutting files.

     
  • - 2011-07-03

    :n goes to n-th line of the screen which is the (n-1)th file. Was it your intention?

     
  • - 2011-07-03

    there is also some problems with :d
    Helps says :d is an abreviation to delete
    But it's not.
    As I thought it was perhaps an abbreviation to dellcommand, I tried :d echo an obtained a segfault
    vifm: malloc.c:3575: mremap_chunk: Assertion `((size + offset) & (mp_.pagesize-1)) == 0' failed.

    I had this command in my vifmrc (just to make tests, pause is my own script and does what its name says)
    COMMAND=echo=!echo %f; pause

     
1 2 3 .. 52 > >> (Page 1 of 52)

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks