build error

[rofl0r]

 You have called ADD_LIBRARY for library scintilla without any source files. This typically indicater
 oblem with your CMakeLists.txt file
                                                                                              Yo hve
 called ADD_LIBRARY for library scilexers without any source files. This typically indicate a robem w
 ith your CMakeLists.txt file
                                                                                               CMake
 Error at CMakeLists.txt:61 (add_executable):
   add_executable called with incorrect number of arguments

 CMake Error at CMakeLists.txt:68 (target_include_directories):
   Cannot specify include directories for target "turbo" which is not built by
   this project.

 CMake Error at CMakeLists.txt:75 (target_sources):
   Cannot specify sources for target "turbo" which is not built by this

Errors occurred during the last pass                                                                  
                                                                                   CMake Version 3.9.3
Press [e] to exit help

[magiblot]

Hi! This looks like a CMake backward-compatibility issue: I'm using the commands in a way that was not supported in older versions. I can fix this, but in the meantime it can be easier for you to upgrade to a more recent version of CMake.

Cheers!

[rofl0r]

I can fix this

that would be appreciated, thanks! i don't want to update CMake because it takes > 1 hr on my machine to build it again (i'm using a build-from-source distro).

[magiblot]

Okay. Can you try again? If you use GCC, make sure to have at least version 8, because older ones don't provide a full implementation of the <filesystem> library.

[rofl0r]

thanks! your cmake fix seems to work. what's odd is that it creates the Makefile in the toplevel directory, not in build, when i do (as is usual with cmake programs):

mkdir build ; cd build
ccmake .. # configure/generate
cmake ..
make # -> no makefile found

after that i get a build error though

turbo/deps/tvision/include/tvision/internal/ansidisp.h:7:23: fatal error: string_view: No such file or directory
 #include <string_view>
                       ^
compilation terminated.

If you use GCC, make sure to have at least version 8

ouch. i use GCC 6.5.0. isn't tvision supposed to be compileable even with the 25 year old turbo C++ compiler ?

[magiblot]

what's odd is that it creates the Makefile in the toplevel directory, not in build, when i do (as is usual with cmake programs):

Hmm, strange. Does the following work?:

cmake . -B ./build
cmake --build ./build

I have never used ccmake. Add it to the steps above if necessary (it also takes the -B parameter).

isn't tvision supposed to be compileable even with the 25 year old turbo C++ compiler ?

Yes, it is. But when compiling with Borland's compiler, you only get MS-DOS and Win32 support, and no Unicode. For the modern platform integration, I used C++17.

Anyway, even if Turbo Vision could be built for Linux with older compilers, C++17 would be still needed for this text editor.

[rofl0r]

Does the following work?:

i'll try

Anyway, even if Turbo Vision could be built for Linux with older compilers, C++17 would be still needed for this text editor.

i tried to build this as a demo application for tvision (the latter is my main interest). it's too bad you only support bleeding edge compilers. for my part, i write my C stuff still in C99 because i can't reasonably expect my users to already have a full-featured C11 compiler. some projects even stay compatible with C89. i wonder why C++ people are always so keen to use the latest features.

anyway, is there a tag that can still be built with C++-14? i rather try that than investing a day of work to get a build recipe for a newer compiler working, since my GCC 6.5.0 is good enough for the entire distro consisting of ~1200 packages, including nodejs which is the only app that requires C++14.

[magiblot]

i tried to build this as a demo application for tvision (the latter is my main interest).

Oh, in that case you can focus on the tvision project exclusively. It already comes with a few demo applications.

anyway, is there a tag that can still be built with C++-14?

I don't think so. But there are no critical features that I can think of which require a very new compiler. I'll take a look at it and see what I can do.

[magiblot]

Can you upgrade to https://github.com/magiblot/tvision/commit/16b3693cbf39d10e51775140f6008e516ca27a3c and try again (tvision only)?

[rofl0r]

Can you upgrade to magiblot/tvision@16b3693 and try again (tvision only)?

cool, thanks! the library build successfully, but during the compilation of the examples i get:

[ 94%] Building CXX object CMakeFiles/tvedit.dir/examples/tvedit/tvedit3.cpp.o
/home/user/tmp/tvision/examples/tvdemo/gadgets.cpp: In member function 'virtual long int THeapView::heapSize()':
/home/user/tmp/tvision/examples/tvdemo/gadgets.cpp:113:35: error: 'mallinfo' was not declared in this scope
     int allocatedBytes = mallinfo().uordblks;
                                   ^
make[2]: *** [CMakeFiles/tvdemo.dir/examples/tvdemo/gadgets.cpp.o] Error 1
make[1]: *** [CMakeFiles/tvdemo.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

afaik mallinfo is a glibc-specific function (using musl libc here)

will report back later on the examples that built

[magiblot]

afaik mallinfo is a glibc-specific function (using musl libc here)

Good to know. One more thing I learned today :)

I tried to address this issue in https://github.com/magiblot/tvision/commit/2ca6aa35c5ff03f87930bb1a8aed315e2a6fca5b. So please upgrade and let's see if it works at once.

[rofl0r]

I tried to address this issue in magiblot/tvision@2ca6aa3. So please upgrade and let's see if it works at once.

yay, it finally built all the way through! thanks for the prompt support.

the only issue i'm currently facing is that when i use https://github.com/sabotage-linux/netbsd-curses and xterm with TERM set to either xterm or xterm-256color, the alt-xxx keyboard shortcuts don't work, i have to hit F10 to make the cursor enter the menu so i can select an item (e.g. exit) with the cursor keys and hit enter. the same happens with lxterminal, which pretends to be an xterm too. it does however work with st, the suckless terminal.

edit: btw, i disabled the GPM option in ccmake.

[magiblot]

the only issue i'm currently facing is that when i use https://github.com/sabotage-linux/netbsd-curses and xterm with TERM set to either xterm or xterm-256color, the alt-xxx keyboard shortcuts don't work

Mhmm... I'm not sure I can help you with this. What I do to detect the Alt modifier is something like this:

nodelay(stdscr, true); // non-blocking getch()
set_escdelay(10); // but wait this much time on ESC characters in order to detect sequences

bool isAlt = false;
int key = getch();
if (key == '\x1B') // ESC
{
    int tmp = getch();
    if (tmp != ERR)
    {
        key = tmp;
        isAlt = true;
    }
}

I don't know of a better way of doing this.

You can play with the TVISION_ESCDELAY environment variable, which is 10 (milliseconds) by default. Set it to a higher value and check if anything changes. If you use a very huge delay (e.g. 500 ms), you should be able to use the Esc key instead of Alt.

edit: btw, i disabled the GPM option in ccmake.

Don't worry, it wouldn't have caused the compilation to fail anyway.

EDIT:

the same happens with lxterminal, which pretends to be an xterm too.

LXTerminal has an option that affects this behaviour. Make sure you have it enabled.

[rofl0r]

LXTerminal has an option that affects this behaviour. Make sure you have it enabled.

yeah, i checked that one, otherwise the alt key would open its own menu.

[rofl0r]

@rsmarples : do you happen to know whether this is correct ? https://github.com/magiblot/turbo/issues/6#issuecomment-727286709

[rsmarples]

For a pure curses solution you could do something like this:

int ch = getch();
const char *kn = keyname(ch);
bool is_alt = (kn != NULL && kn[0] == 'M' && kn[1] == '-');
bool is_ctrl = (kn != NULL && (kn[0] == '^' && kn[1] != '\0') || (kn[0] == 'M' && kn[1] == '-' && kn[2] == '^' && kn[3] != '\0'));

You could skip the keyname call and interrogate the value of ch directly, but that's your choice.

[magiblot]

Thanks, @rsmarples.

In your example it looks like you can retrieve both the character and the modifiers in a single getch() call. This is not what I see here. Maybe I am making non-standard assumptions? Or is there a curses function controlling this behaviour?

@rofl0r, can you please try this program?

input_test.cc

```c++ #include #include #include #include #include #include #include using namespace std; template string toHex(int_t n) { char expr[32]; char hexa[32]; sprintf(expr, "%%0%lullX", 2*sizeof(int_t)); sprintf(hexa, expr, n); return string(hexa).substr(int(strlen(hexa))-2*sizeof(int_t)); } template string toBinary(int_t n) { return bitset<8*sizeof(int_t)>(n).to_string(); } int main() { setlocale(LC_ALL, ""); initscr(); raw(); keypad(stdscr, TRUE); set_escdelay(10); nodelay(stdscr, FALSE); noecho(); do { int key = wgetch(stdscr); if (key == 'C' - 'A' + 1) // ^C break; nodelay(stdscr, TRUE); do { cerr << "> " << (key < 10 ? "00" : key < 100 ? "0" : "") << key << " <> 0x" << toHex(key) << " <> 0b" << toBinary(key) << " < (" << keyname(key) << ")\r\n"; key = wgetch(stdscr); } while (key != ERR); cerr << "\r\n"; nodelay(stdscr, FALSE); } while (1); endwin(); return 0; } ```

You can run it like this:

g++ -std=c++11 -o input_test input_test.cc -lncursesw
./input_test

And you should be able to exit with Ctrl+C.

When I press Alt+C, Alt+1 and ñ i get the following output:

> 027 <> 0x0000001B <> 0b00000000000000000000000000011011 < (^[)
> 067 <> 0x00000043 <> 0b00000000000000000000000001000011 < (C)

> 027 <> 0x0000001B <> 0b00000000000000000000000000011011 < (^[)
> 049 <> 0x00000031 <> 0b00000000000000000000000000110001 < (1)

> 195 <> 0x000000C3 <> 0b00000000000000000000000011000011 < (M-C)
> 177 <> 0x000000B1 <> 0b00000000000000000000000010110001 < (M-1)

What do you see?

[magiblot]

Note: I tried with the master branch of https://github.com/sabotage-linux/netbsd-curses, and I get the same results.

[rofl0r]

> 195 <> 0x000000C3 <> 0b00000000000000000000000011000011 < (M-C)
> 163 <> 0x000000A3 <> 0b00000000000000000000000010100011 < (M-#)

> 194 <> 0x000000C2 <> 0b00000000000000000000000011000010 < (M-B)
> 177 <> 0x000000B1 <> 0b00000000000000000000000010110001 < (M-1)

> 195 <> 0x000000C3 <> 0b00000000000000000000000011000011 < (M-C)
> 177 <> 0x000000B1 <> 0b00000000000000000000000010110001 < (M-1)

this is the result with xterm and TERM set to either xterm or xterm-256color (using Alt+C, Alt+1 and ñ). odd that you get different results, maybe it's due to your use of glibc or the locale you're using. @rsmarples: thanks for chiming in!

[rofl0r]

probably related: https://osdn.net/projects/yash/ticket/40959#comment:3863:40959:1605420631

[magiblot]

Thanks.

I have found a few pages mentioning the meta modifier:

[1] http://www.leonerd.org.uk/hacks/hints/xterm-8bit.html [2] https://invisible-island.net/ncurses/ncurses.faq.html#bash_meta_mode

The Bash manual also mentions several options related to meta, although I'm not sure whether they can affect user applications:

convert-meta
enable-meta-key
input-meta
output-meta

Ncurses exposes a meta function which, on my end, can discard the 8th bit in all characters returned by getch, but does not change whether Alt adds an ESC prefix or not.

I'm using a UTF-8 locale. I tried switching to a non-UTF-8 one and using different combinations of the options above (including the Xterm ones mentioned in [1]) but still was unable to reproduce what you see.

[magiblot]

Ah, I have found something. I had the following setting in ~/.Xresources:

XTerm.vt100.metaSendsEscape: true

I probably added it years ago after reading https://wiki.archlinux.org/index.php/Xterm#Make_'Alt'_key_behave_as_on_other_terminal_emulators. If I disable it, I do get the same behaviour as you.

You can try to add it (and then xrdb ~/.Xresources before opening a new xterm instance) and see if it works for you. I don't think this will affect other applications, though.

[rofl0r]

You can try to add it (and then xrdb ~/.Xresources before opening a new xterm instance) and see if it works for you.

indeed, this fixes it in both tvision and "ht editor" (hte.sf.net, which seem to have its own custom turbovision version/clone btw). thanks for your thorough research, i didn't expect this to be such a complicated problem. arguably, when one sets xterm to utf8, it should automatically enable the corresponding options do disable the meta bit for keyboard combinations - since having the 2 active at the same time doesn't make much sense.

anyway, closing this now as all turbo-related issues (apart from compiling the turbo demo itself without C++17 compiler) have been resolved. cheers!

[magiblot]

Turbo Vision enables metaSendsEscape automatically since https://github.com/magiblot/tvision/commit/74fd26aa3321830e330140f8c20a6456df160733. I'm afraid C++ 17 will keep being a build requirement for this application since Scintilla needs it, although Turbo Vision itself builds fine with GCC 5.5.