[discussion] Project goals

[Drugoy]

Hey, I hope you don't mind me opening a ticket for that, but IMO it's better to ask these questions aside from other issues.

I'd like to ask a bit about the project's goals.

The project's description says it's a reimplementation AutoHotkey v1.0.24 (2004), but why exactly this old version? Why not aim for 1.1 or even 2.0 (beta)? Do you plan to move the target at some point to something more modern? The problem with 1.0 is not only that it lacks lots of features, but that even online docs for it aren't available anymore (afaik). Or do you maybe plan to just add separate features from 1.1/2.0?

For example, I've noticed that combined hotkeys like a & b aren't supported, but I was not sure if it was worth opening a ticket about.

Or another example: hotkeys in AHK 1.1 supported namespaces/scopes via #If + #IfWin[Not]Active/#IfWin[Not]Exists. Those are directives, and the latter four are quite similar to the commands of the same name (without #), which I see are already listed as implemented in this project's description. Also, AHK had a kind of neat concept of 'WinTitle', IMO this is a quite an important part and needs to be clearly covered in the docs - could you add that?

[phil294]

Hi,

no, you're fine, please feel free to open up as many issues as you like :-) Well thought out issues are always a highly valuable contribution to any project, I think.

It looks like you haven't seen the projects documentation, linked in the Readme. Please check out https://phil294.github.io/AHK_X11/.

why exactly this old version?

1. AHK has a lot of features, and modern AHK even more so. Without libs, it is pretty much exactly 100,000 lines of C++ code. Replicating this cleanly on Linux is an immense task, so I could only tackle a small subset. Going with an old AHK version made sense because I'd be replicating what Chris Mallett thought to be the most important when he started out with the language 20 years ago. Naturally, he kept adding lesser important goodies over time, while always staying backwards compatible. That said, 1.0.24 is already quite exhaustive.
2. Implementing the parser was significantly easier this way. Almost every line is autonomous. Expressions add a lot of complexity.
3. AHK (modern, 1.1, AHK_L) is notoriously problematic for the existence of two different syntaxes: Legacy/command syntax and Expressions/functions. These don't mix well and are no. 1 reason for confusion for beginners, by a far margin. Forums etc. are full of that. This insanity started with v1.0.25, afaics. So in general, it is a good idea to keep these separated. Long time AHK users had urged me to go with modern syntax only, but I decided against that because of the other reasons. That's why this "classic" implementation is legacy only for now.
4. For a more modern syntax, active users will often suggest you skip v1 altogether and just use v2. v2 is altogether better designed, consistent, thought out, and modern. I personally prefer classic v1 to v2 though (but least people will have that preference). And if you like v2,
5. You might want to use KeySharp instead, it targets v2. It's actively being worked on, and that for several years by now, so there's quite some effort going on. Not usable yet, however, like AHK_X11 is. This is also explained in the Readme. Once (if) KeySharp takes off, this very project might become less useful.

Regardless of that, I'd absolutely add full 1.1 syntax support, add full test coverage, guarantee AHK_L script compatibility, to the point of emulating ComObject and integrate Wine for DLL calls. That'll be around $100,000, please. If not, it's probably never gonna happen and stay on 1.0.24, unless other folks join in. No luck so far.

There's also the possibility of cross-compiling AHK_L. This has been unsuccessfully attempted with ahkx (last commit 13 years ago). Perhaps this can be revived too. Please notify me if you try.

But yes, we can surely pick some features from more modern versions as desired! (such as #IfWinActive that you mentioned) I did this already with FileRead and RegExReplace, and would like to do the same with ImageSearch some day.

Project goals

With all that said, I think the current goal still stands: Get about 80% of 1.0.24 working. I'd love to hear other opinions too.

The next big milestones will be perfect Hotstring (#1) and Wayland (#2) support. I for one will keep working on this, but not as active as in the previous two months (which is when ahkx11 was born).

online docs for it aren't available anymore (afaik).

The docs I linked above are those original docs from 2004, annotated with AHK_X11 specific comments. It is very thorough and shows you an exact description of which features are present and which are yet to be done. I put a lot of effort into making it elaborate and accessible, yet somehow nobody ever even sees it. I honestly don't know what else I can do other than putting a capslock FULL DOCUMENTATION link at the top and mentioning it further below. I think I'll link this very issue at the top later. In the end, the Readme is code and part of the repo as everything else, so I always appreciate ideas or PRs how it can be improved.

At the docs, under "What is it?", the original, unaltered docs are also linked to (here it is).

combined hotkeys like a & b aren't supported

Yes, it hasn't been done yet. In the docs e.g. under Hotkeys, the section about prefix hotkeys is shown as TBD. Would be nice to have, but probably quite complex.

#If + #IfWin[Not]Active/#IfWin[Not]Exists

Didn't exist back in the old version, but would also be nice to have. The current way to do this is the same way as it was done in 2004, according to the docs (that section shouldn't be crossed out though):

Make your hotkeys context-sensitive: Have your easiest-to-reach hotkeys perform an action appropriate to the type of window you're working with. For example:

  RControl::
  IfWinActive, Untitled - Notepad
  {
     WinMenuSelectItem, , , File, Save
  }
  else IfWinActive, Calculator
  {
     Send, ^c!{tab}
  }
  return

'WinTitle'

this is here