Multi Terminals and Persistent buffers

[rohit-kumar-j]

TODO:

• Multi terminal handling

Support

• Linux Support
• Windows Support
• OSX Support

Removed

• Child Processes

[rohit-kumar-j]

@Civitasv, a basic demo is ready (currently without window handling)... can you please take a look?

You need to run :CMakeGenerate twice inorder for it to work. There is no on_sucess() callback implemented yet.

[Civitasv]

I'm back to work, sorry for my late. Testing now.

[Civitasv]

In order to use this feature, I need to turn on cmake_use_terminals, am i right?

[Civitasv]

I modified a little for linux, now it works like this, is it expected behaviour?

[rohit-kumar-j]

In order to use this feature, I need to turn on cmake_use_terminals, am i right?

Yes

As of now,there is no window handling. You can test all other settings in cmake_terminal_opts except:

    -- Window handling
    display_single_terminal_arcoss_instance = true,
    single_terminal_pet_tab = true,
    keep_terminal_in_static_location = true,

I modified a little for linux, now it works like this, is it expected behaviour?

It should resize the window to 10(height), by default... (unless you have explicitly set ti higher)

[Civitasv]

I don't know why do you use launch_task_in_a_child_process.

[rohit-kumar-j]

I don't know why do you use launch_task_in_a_child_process.

Haven't added multiterminal support(Each executable target has it's own terminal + 1 Main Terminal) yet.
So I've kept it for now.

[Civitasv]

Okay, I understand.

[Civitasv]

• Fix first time :CMakeGenerate bug: ('E21: modifiable is off', does not prompt the user for build type after asking for the desired kit)

I cannot reproduce this problem.

[Civitasv]

I've added support for Linux.

[rohit-kumar-j]

• Fix first time :CMakeGenerate bug: ('E21: modifiable is off', does not prompt the user for build type after asking for the desired kit)

I cannot reproduce this problem.

It does not implement the on_success method in any way ...yet... (Not sure how to implement it)

[rohit-kumar-j]

Delete the build folder and try doing a :CMakeRun directly without a :CMakeGenerate and :CMakeBuild.
The commands do not chain with any on_success() methods 😞 i.e. it first generates, then on_success(), it builds, then on_success(), it runs.(each time asking for options).

Does this happen for you?

[rohit-kumar-j]

Delete the build folder and try doing a :CMakeRun directly without a :CMakeGenerate and :CMakeBuild. The commands do not chain with any on_success() methods 😞 i.e. it first generates, then on_success(), it builds, then on_success(), it runs.(each time asking for options).

Does this happen for you?

I think I will ask for a all the options from the user first(like Kit and Build Type), then do a sequentail chansend. This will be the best option, but a little tricky to implement, especially within child processes. It may be a workaround for chaining commands.

What do you think of this?

[rohit-kumar-j]

I've added support for Linux.

@Civitasv, I think you have missed one spot. Can you add support for this: utils.send_data_to_terminal() as well?

[Civitasv]

I've extracted the terminal logic to terminal.lua, and I think it is not necessary to use terminal when generating and building, but I still keep those codes in terminal.lua(in terminal.run function). Now utils.execute will invoke terminal.execute, which will send command to our unified terminal. What do you think?

[rohit-kumar-j]

And, what's the difference between check_cmake_buffers_are_displayed_in_current_tab and check_if_cmake_buffers_are_displayed_in_current_tab

Sorry, wrong naming. Pushed a fix. 700c450

[rohit-kumar-j]

The problem is: the first time I enter cmake project and invoke CMakeBuild, it will call CMakeGenerate correctly. And after finishing CMakeGenerate, it also correctly calls cmake.build, but this time, it cannot get build targets correctly.

What is the config for this?
Do you use cmake_always_use_terminal = true for this?

[Civitasv]

Yes.

[rohit-kumar-j]

I encountered (a similar/the same?) problem...

First Try

When I do a :CMakeRun on new project(unconfigured, no build directory), it chains the following:

1. :CMakeGenerate
2. :CMakeClean
3. cmake -E create_symlink ...json ...json
4. cmake -E create_symlink ...json ...json

Config:
cmake_always_use_terminal = true,

---

Second Try

When I do a :CMakeRun on a configured and built project, but Vim Just Entered (:h VimEnter), it detects the project's targets, but does not create a new terminal with the incorrect name:
[CMakeTools]: null. It does not eagerly detect the names of the targets.

Config:
cmake_always_use_terminal = true,

[rohit-kumar-j]

I have an idea.

For a new project, for the first time, when we do a :CMakeGenerate, it configures the project.
After configuring, only then we get a CMakeCache.txt. So, we can have a loop that detects if a CMakeCache.txt file is created in the build directory. Only after this it is configured, we can use the codemodel targets.

If this is done in async, I think there might not be too many calls to the filesystem, so as to block the IO. If we get a hit on the CMakeCache.txt, we can raise a flag and end the loop. This triggers the get_targets...() functions.

Although this is a CMake specific thing, I tested this for both MSVC(VS Generator) and Clang(Ninja). The CMakeCache.txt seems to be generated only after the configure step is complete.

[Civitasv]

I encountered (a similar/the same?) problem...

Kinda same. But for your second try, it works correctly on Linux.

[Civitasv]

I have an idea.

For a new project, for the first time, when we do a :CMakeGenerate, it configures the project. After configuring, only then we get a CMakeCache.txt. So, we can have a loop that detects if a CMakeCache.txt file is created in the build directory. Only after this it is configured, we can use the codemodel targets.

If this is done in async, I think there might not be too many calls to the filesystem, so as to block the IO. If we get a hit on the CMakeCache.txt, we can raise a flag and end the loop. This triggers the get_targets...() functions.

Although this is a CMake specific thing, I tested this for both MSVC(VS Generator) and Clang(Ninja). The CMakeCache.txt seems to be generated only after the configure step is complete.

Yeah, that’s a way to fix it. But it is a really weird problem.

[rohit-kumar-j]

Before doing this, I think we can do some clean up and merge PR. 😅

Can you add the description of the terminal options in the README?
I'm not sure what to write. There was so much in this PR.

[Civitasv]

I think launch_task_in_a_child_process and launch_executable_in_a_child_process can be removed.

[rohit-kumar-j]

I agree.

[rohit-kumar-j]

Let's keep it internally?

[Civitasv]

Also remember remove the logic about child procs in terminal.lua

[Civitasv]

Let's keep it internally?

Don’t think it will be useful someday.

[rohit-kumar-j]

Completely remove them or store them in a .legacy.lua file that isn't required by any of the other files?

[rohit-kumar-j]

Let's keep it internally?

Don’t think it will be useful someday.

Okay

[Civitasv]

Before doing this, I think we can do some clean up and merge PR. sweat_smile

Can you add the description of the terminal options in the README? I'm not sure what to write. There was so much in this PR.

I will add it today.

[rohit-kumar-j]

There seems to be problem with

  vim.wait(10000000, function()
    if not terminal.has_active_job() then
      -- it should have an active job
      return false
    end
    return true
  end, 10)

  vim.wait(10000000, function()
    if terminal.has_active_job() then
      -- it should not have an active job
      return false
    end
    return true
  end, 10)

I have to do CTRL C twice for seeing any output from neovim. It is blocking even the viewport.
This is for projects with and without the pre-configuration.

[Civitasv]

Yes, I don't know hot to make it async yet.

[rohit-kumar-j]

Yes, I don't know hot to make it async yet.

Although not fully async according to TJ, this can be a starting point.

I'm trying to use this.

This is only possible for configure with the CMakeCache.txt and not for fully chainning commands.

[Civitasv]

Okay... Maybe we should find another way. I will update README first.

[Civitasv]

Make a new issue, we can continue discuss there. #60