Cleanup, rewrite or replace vis-menu

[ghost]

I noticed that the command:

printf 'line1\nline\t2\nline 3\n' | vis-menu -l 5

Causes vis-menu to shift down one line at each key stroke, but only when the tab character is displayed (when it is among the candidate list).

I wish I can find the time to fix this! I am using it to create an interactive menu for abduco.

[ghost]

Piping a large file through vis-menu revealed that the issue only appears while the tab character are onscreen. Otherwise, it works correctly. Even if there are lines with tab above or under the visible region.

[ghost]

A solution could be to convert tabs to spaces before to displaying them to the screen, but keeping them internally.

It would also fix their alignment and highlighting:

[martanne]

Yes this is a known problem, the content is currently printed as is to the terminal.

vis-menu should really reuse some of the display related code of vis to properly handle Unicode as well as terminal escape sequences etc. The inherited slmenu code is quite bad in this regard and should be cleaned up at some point.

[ghost]

I use the workaround of converting tabs to space before to pipe to vis-menu, for now. No more issue for now. :) Thank you for this notice.

[ghost]

Filename with tabs are really rare. It is not really an issue for use with vis.

[ghost]

If you still need to replace vis-menu, you could have a look at this minimal dmenu clone.

It can open UTF-8-demo.txt or file with tabs (converted to spaces before printing).

On the other hand, it does not support arrow keys, and is C99 (+ termios) only, and then no strcasecmp and no -i option.

ISC license.

[martanne]

As expressed before I'm not really happy with the current (inherited) vis-menu code. It mixes signed/unsigned types uses macros in questionable ways, lacks proper Unicode support etc. It is also the only component of the repository which doesn't compile without warnings (at least with my ancient toolchain) under make debug. It is just that there are more important and/or interesting things to fix instead. Also in theory all these things (e.g. cursor navigation) are already implemented in vis, there should be an opportunity for code re-use.

The reason why it was imported in the first place is that it allows the editor core to depend on its availability. I feel like in this case there is no real point in depending on an external tool only for users to complain that it doesn't work because they haven't installed it etc.

I haven't actually tried iomenu as a direct vis-menu replacement (did you?), does it follow the interface needed by vis as described in 1c9c52647fe2984472246eb2c12b3412fd5fafa4?

I see you used all the wide character function version, I'm not sure I like that (vis basically assumes a UTF-8 locale at all times). Also you shouldn't define main as static.

[ghost]

I will probably not be able to take cursor manipulation functions from vis, but this is what I plan to improve this weekend (hopefully!).

1. [DONE] Test iomenu with vis.
2. In-source [small UTF-8 handling functions]() and use fgets rather than fgetws(). Still use wchar_t ?
3. [DONE] -p option for setting a prompt
4. [DONE] Investigate why I need to reopen /dev/tty, and why not just keep reading stdin again after fgets() returned EOF (and then finished to read candidates lines (1c9c526). You were right: fopen() -> freopen()
5. [DONE] static int main() -> int main()

If anything else, I can add it to the list.

[ghost]

I did a small UTF library for iomenu and other projects with help of libutf.

Vis has runetochar() in libutf.c, for printing a rune. Is there already somethind for reading an UTF-8 string into a buffer of Runes in vis?