If he were still alive, we could ask ask Jim. The use of "DND__" was his idea, and although I argued with him about it , I was just glad we had come up with some type of "standard".
This is all irrelevant. I don't need you to change anything. I do, however, suggest that in your spare time, you might want to update the wiki to explain the rules you use. (And yes, that was a joke, because this has got to be near the bottom of your list of things that actually require your attention.) The only reason I continued the discussion was because you asked, and you know I can't resist things like this.
That's correct. This is in a macro for me, not for the general population, and I wanted to put some of my DND variables into local variables and prompt for them, then double-check the results before I put them back into the DND variables.
This really is a moo point, so let's just drop it.
I had failed there not only to imagine why there could ever be any point in the boundary being the rightmost âunderscoreâ but also to locate the relevant part of the Wiki, which explained all:
It can be a good idea to have a common prefix in all of the variables used by the same macro. This clearly identifies the macro that uses these variables, and groups them together in the Variables section of the Keyboard Maestro Preferences. But you may not want to expose this prefix to the user running the macro.
So I now think of Local__DND__DIP_ResourcesFolder ( @griffman@DanThomas's example) as being a local variable of user category âDNDâ, and the `Prompt for User Input' action's hiding that âcommon prefixâ as being both by the book and justifiable.
I do wonder whether the idea of having âa common prefix in all of the variables used by the same macroâ is an anachronism that preceded the provision of local variables in KM. Regardless, that is the established system.
Yes, of course that's true. But I believe I explained that. In any case, it was because I wanted a prompt that let me modify some of my global variables, but using a local variable first, so I could double-check the modification. I thought it would be nice if the label matched the the target global variable name.
I found this thread interesting but picking apart its intertwined strands a bit of a challenge, so yes, I knew that there would be much that I hadn't fully absorbed, but anyway, it was the question of the logic behind how KM treated â__â that intrigued me. It was obvious to @peternlewis that KM's way was more logical, but not to me. I understand the theory now! Of course, a user's own systems can be just as logical, but the logic behind the official system is the one that I most want to comprehend.
Not âmore logicalâ, its just a choice. Arguments one way or the other are uncompelling enough that it becomes just a choice as to how it works, at which point âhow it currently worksâ wins out.
Yes, that's how I see it. When I wrote âlogicalâ I meant âsensibleââand that sense or logic is of course what seems better/best ahead of instituting a design.
Yes, and that is why âthe logic behind the official system is the one that I most want to comprehendâ. Unless one is prepared to have breaking changes, the established design decision results in a law that cannot be overturned, so any âcompelling reason splitting at the first __ makes more senseâ is by now academic. Nevertheless I still find it educational and productive to understand the logic (I did not assume that it was a whim) that was behind the decision!
The use of the word âlogicâ there is about internal logic rather than, as you had put it, âsome reasonable objective reasonâ. I took your phrase âlogical place to splitâ to mean âmost reasonable place to splitâ, but perhaps you did mean that there might be some objective criterion!
