Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Planning the 2.0.0 #214

Open
43 of 62 tasks
zero-plusplus opened this issue May 21, 2022 · 2 comments
Open
43 of 62 tasks

Planning the 2.0.0 #214

zero-plusplus opened this issue May 21, 2022 · 2 comments

Comments

@zero-plusplus
Copy link
Owner

zero-plusplus commented May 21, 2022

Work on another project has been difficult, so I will resume work on this one.


Add

Change

Fix


Remove


Task

Confirmation


Backlog


Remaining work to release

  • Test
  • Check security patches
@zero-plusplus zero-plusplus pinned this issue May 21, 2022
@zero-plusplus zero-plusplus changed the title Planning the 1.12.0 Planning the 2.0.0 Dec 3, 2022
@mark-wiemer
Copy link

Hi, I worked with Stef Levesque to discontinue slevesque.vscode-autohotkey, see stef-levesque/vscode-autohotkey#32. My extension, AutoHotkey Plus Plus, shouldn't cause conflicts with the debugger as it's hardcoded to use your extension if it exists.

My goal is to have one extension (or extension pack) that AHK coders can use to write both AHK v1 and AHK v2 scripts with full language support--good IntelliSense, syntax highlighting, formatting, and debug support.

I'm hoping we can work together to discover the best way to support AHK coders moving forward, I'd hate for us to both do the same thing. Please let me know if there are any conflicts between AutoHotkey Plus Plus and your extension, and I'll work to remove them.

@zero-plusplus
Copy link
Owner Author

Thanks for the explanation.

You and I have different goals. My initial goal was to assist in the creation of my own library.
Therefore, I want the extension to fulfill 100% of my requirements. This can only be achieved by my own creation.

And unfortunately we will not be able to cooperate. I would also not collaborate, because the multi-person development would be a barrier to incorporating my own ideas.

We will create similar extensions, but they will each have their own good and bad points.
They may lead to better subsequent extensions.

That would be preferable to me.


I will report back to you when there is a possible conflict😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants