need help compiling vifm

[aplannan]

Hi,

I have been trying to compile vifm, an ncurses based file manager which uses vim keybindings. I have tried installing all the ncurses (lib, lib-dev, and utils) extensions in the repository but am still having no luck. I believe it configures ok but I get the following error message during make:

undefined reference to 'mvwaddwstr'

for multiple lines.

The Install file states that compilation requires ncursesw and an ascii compliant term, and that Solaris and PDcurses will not work.

I hope that is enough info.

Andy

[curaga]

Our ncurses is the non-wide version. I'm afraid if an app requires the wide one, the best course is to compile the wide ncurses as a static lib.

[aplannan]

Thanks. I've never compiled a static library. Hmmm. I'll look into it. Any advice? I would like to learn more about compiling in general. I have made a number of .tcz for my own use using the wiki directions, but I have no idea how to strip the help doc and dev files like the ones found in the repository. I would love to learn how to, so that I might contribute to the repository.
andy

[curaga]

Hmm, for an extension you might want to use a separate prefix as well so as not to conflict with ncurses in the base. In this case it wouldn't be necessary to use a static one, as you could use it as a dep.

Doc files can simply be deleted. Separating the dev files is recommended, but for small extensions you can have them in as well.

edit: configure line as gleaned from the latest LFS, with a prefix:

./configure --prefix=/usr/local/ncursesw --with-shared --without-debug --enable-widec

[aplannan]

Thanks for the reply. While I haven't had much luck with vifm yet, I have learned a lot about how to manipulate what files end up in a .tcz and how they are loaded on start up, which is great.

[aplannan]

Hi,
Finished putting together vifm.tcz over the weekend and it is now available in the repository. It is my first extension so I am hoping it works well. Thank you curaga for your helpful comments. I have been using vifm for a couple of days and find it very functional. I created a symlink in my /home/tc/.vifm directory to a file on my harddrive so that I would not have to backup TC every time I added or deleted a bookmark. To do so I added;

ln -s /mnt/hda3/new_tc/vifmrc /home/tc/.vifm/vifmrc
**** This step is not necessary, read curaga's comments below****
to my /home/tc/.xsession file. The first directory listed in the line above could be changed to any location on a harddrive.

I have been using dwm with tiny core recently. Vifm does not always play nice with the tiling wm. It does not always respond well to being resized by the wm on opening. I am looking into some options. You can have vifm open as a floating app by default in dwm. However, vifm does not close after opening a file in another application, so you are stuck with the floating widow on top of the tiled app (at least that has been my experience so far). The best solution, in my opinion, would be to have vifm execute the process specified for the filetype in the vifmrc script and then close, or at least have the opened application not be connected to vifm. As it is right now, closing vifm also closes the opened app.  

I use mostly monocle in dwm. To have vifm reliably open to the correct size I modified the exec command to:

aterm -geometry 166x57 -e vifm

However, this causes a problem when opening vifm into a tiled environment. The strange thing is if I open vifm in monocle and then toggle to a tiled setting vifm adjusts correctly.

Even with these small issues, which may not effect someone using a different wm, I think vifm is great. The bookmark, command and filetype options in the vifmrc make it very extendable. If anyone has any advice on how to change the default behavior after vifm opens a file or how to better integrate it with dwm, I'm all ears.

Cheers,
Andy

[lucky13]

Those issues aren't limited to tiling managers, nor limited to vifm. It has to do with character width requirements certain applications using curses have. When the terminal window becomes too narrow (not enough characters), or when it's resized beyond a certain number of times, they can crash. That's happened to me with vifm and naim and a few others. In fact, naim checks for size when it starts (and IIRC, won't start if COLS is < 50 or whatever -- using ratpoison so I can't test to check that right now):

Code: [Select]

$ naim
Initializing ncurses... done: LINES=49 COLS=159
Checking for large enough screen dimensions... done
Enabling color support... done: COLORS=8 COLOR_PAIRS=64
Checking for enough colors... done
Initializing default colors... done
Initializing color pairs... done
If I were experiencing curses-apps crashing in dwm/ratpoison/ion/etc. during resize or splitting, I'd just stick with monocle/fullscreen views. As I ran vifm within screen, there was never a need to open additional terminals. Ironically, this was posted when I was using dwm:

http://lucky13linux.wordpress.com/2008/06/04/my-low-end-set-up/

Now I run emacs under screen and use dired-mode for file operations.

[curaga]

Backup doesn't follow symlinks, so you can just create it in ~, and do a backup. No need to recreate every session.

[aplannan]

Hi curaga,

I do not usually backup at the end of a session. I like to limit the size of the mydata.tgz so that it doesn't get too bloated. That is why I use the symlink. It provides me with a way to make a file in the home directory persistent without backing up. Am I thinking about this the wrong way? I use backup only when I am changing something I know I will want to stay the same over a longer period of time, where as I may often change bookmarks. I do a backup after adding the symlink to .xsession, and then when I change my bookmarks they are saved even without backing up.

Thank you lucky 13 for your advice. I will have to look into screen, I am not sure exactly how it works but it might be just what I am looking for.

Andy

[curaga]

I meant that instead of adding the symlink via xsession, you can just create the symlink and backup. The link itself will be saved to the backup, instead of what it points to.

[aplannan]

ahhh, thanks makes sense!

[lucky13]

Thank you lucky 13 for your advice. I will have to look into screen, I am not sure exactly how it works but it might be just what I am looking for.

Argh, hit return too many times and it posted. GNU screen is a multiplexer, which means it allows you to run several pseudo-terminals inside one terminal/console instance. In effect, it functions sort of like a window manager. Instead of running several terminals each containing an application or shell, you run them inside screen -- one terminal through which you can page through different simultaneously-running applications. Like in the screenshot on my link. That shows vifm plus other things running in screen (see the bottom of the terminal window since I was running a hard status line in it at the time). vifm works pretty seamlessly inside screen so that you don't have to spawn new terminals or what have you -- anything running in a terminal/console can be automatically spawned into a separate pseudo-terminal in screen.

[aplannan]

Thanks for the info.
I have played with screen a little now. I notice that when I edit my filetype in vifmrc to read :

FILETYPE=pdf=pdf=screen apvlv

Apvlv opens the pdf in a new window. The original window now has the

Xlib :extension "Generic Event Extension" missing on display "0:0"

message. I can close that window and apvlv stays open. Are there any arguments for screen that would close that terminal window automatically? I actually emailed Ken Steen (vifm author) to let him know that I had packaged vifm for tiny core and asked how it may be possible to control vifm's behavior after executing a filetype command, and he replied that he may try to make a macro for this purpose over the weekend.I sent the email before trying screen and am now wondering if I am troubling him about something that has a simple solution that I just don't know about. It's very possible. The reason I am interested in this is that I would like to set vifm to float in dwm by default with a keyboard shortcut. If I do that and cannot close vifm without closing the application opened by FILETYPE I am stuck with a floating vifm window on top of the opened application. Screen seems like it may solve this issue, but it would be nice to have the floating window close after opening the new app.

[aplannan]

Ok, I came up with a working solution. I wrote the following script:

#!/bin/sh
nohup "$@" &
pkill vifm

saved the script (I named it bang) and made it executable and put it in /usr/bin

In my vifmrc I set my FILETYPE settings:

FILETYPE=doc=doc=bang abiword %f

now when i open a doc file in vifm, abiword opens with the document and vifm closes. I would think that if you wanted to have vifm stay open but open abiword in the background (similar to the default behavior of emelfm2) you could just delete the pkill line from the script. In an email Ken Steen indicated that previous releases of vifm were able to open an application in the background using the &, but that this feature needs to be fixed in the current release. I will repackage vifm when/if this fix is completed.