Skip to content

Conversation

@Jint-lzxy
Copy link
Collaborator

This PR reverts commit a1c76b2.

The main rationale behind this is IMO the current implementation of this function has several limitations that need to be addressed:

  1. It works with only a single file, which is not typical for most use cases
  2. It only supports gcc as the compiler, whereas other compilers (most notably clang, xlc, cl.exe and friends) are not supported
  3. There's no way to control compile and/or build flags
  4. File type detection is too restrictive and doesn't cover all cases (using vim's ftplugins may be more effective)
    and
  5. Violating any of these assumptions results in errors, rendering this keymap completely ineffective

This PR reverts commit a1c76b2.

The main rationale behind this is IMO the current implementation of this
function has several limitations that need to be addressed:

1. It works with only a single file, which is not typical for most use cases
2. It only supports gcc as the compiler, whereas other compilers (most notably
   clang, xlc, cl.exe and friends) are not supported
3. There's no way to control compile and/or build flags
4. File type detection is too restrictive and doesn't cover all cases (using
   vim's ftplugins may be more effective)
and
5. Violating any of these assumptions results in errors, rendering this keymap
   completely ineffective
@ayamir
Copy link
Owner

ayamir commented Jan 19, 2025

Tend to improve it rather than eliminate it b/c this will break compatiable. Especially this is an enhancement made in response to a issue: #1367, which means someone maybe uses it now.

@Jint-lzxy
Copy link
Collaborator Author

Tend to improve it rather than eliminate it b/c this will break compatiable.

Agreed, but I think it might be better to move this to eg the FAQ instead of keeping it in the base config...? cuz imo there's just too much to consider if we're actually planning to support it. Even if we managed to make it work, it would be strenuous to maintain. Maybe we could even turn it into a plugin and delegate the work there?

@charliie-dev
Copy link
Collaborator

charliie-dev commented Jan 26, 2025

https://github.com/stevearc/overseer.nvim: A task runner and job management plugin for Neovim

@ayamir
Copy link
Owner

ayamir commented Feb 5, 2025

Tend to improve it rather than eliminate it b/c this will break compatiable.

Agreed, but I think it might be better to move this to eg the FAQ instead of keeping it in the base config...? cuz imo there's just too much to consider if we're actually planning to support it. Even if we managed to make it work, it would be strenuous to maintain. Maybe we could even turn it into a plugin and delegate the work there?

Move it to FAQ is acceptable for me.

@ayamir
Copy link
Owner

ayamir commented Feb 5, 2025

DONE: https://github.com/ayamir/nvimdots/wiki/Knowledge-Garden#-dap-related-issues

@ayamir ayamir merged commit 1e5769f into main Feb 5, 2025
4 checks passed
@ayamir ayamir deleted the revert/auto-compile branch February 5, 2025 02:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants