Replies: 6 comments
-
|
I'd really like to hear from @sjtringali on this, especially since the macro support existed long before my involvement with nedit5, and I really have not done much in this area of the code apart from working on a small patch. In any case, wrt to the documentation, my humble opinion is that it should take priority over the code (it's strange I know, since the code is the one doing the work). Granted, there will be errors/typo in the doc, but that's the only source of info for ordinary users -- they are not going to look into the source when writing macros or using certain feature. The expectation is that, if they discover some strange behavior, they would report them and we could fix the doc, or the code. The real challenge is that we don't know if anyone is using any of the feature, so we had to assume they are all being used. I wished we had some sort of test suites for the macros. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I am generally of a similar mindset. That the docs are "the contract", and if a user breaks the contract, well, they were lucky it didn't just say "no". I am inclined to upgrade some things to "error" like if a user shoves a bunch of junk parameters on the end of a function, or passes string constants not documented to do anything... personally, I'd prefer the macro system just throw an error instead of silently ignoring these issues. |
Beta Was this translation helpful? Give feedback.
-
|
I can say though that for the absolutely trivial cases of "the docs didn't mention a parameter, but it's trivial to support"... we can just add it to the docs unless it REALLY wasn't intended to be used. |
Beta Was this translation helpful? Give feedback.
-
|
I'll be all hand-wavy and say it depends.
Yes, backwards compatibility is a big deal, and, it's even *more* important right now when we're trying to replace 5 with 6.
I wouldn't blindly start cutting things to match the doc, after all, maybe the doc is wrong. The drop in replacement is really compelling - I was so surprised that it worked with only minor breakage, I decided that day to us it full time and contribute. You followed Joel's law of never rewriting from scratch (https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/) which is essentially Hyrum's law.,
That said, if there's some obvious stupidity like the cheeseburger thing, there's no need to spend lots of effort trying to bring it back. But if there simply are undocumented options, well, those are reasonable and intentional. Someone intentionally code it, so don't remove them.
I will now negate myself.
Macros are different. Users wrote (or recorded) them themselves. So they can fix it right in NEdit without having to be come a developer. Thus, macros in my mind get a little more leeway than C++ code.
/st
On Tuesday, December 22, 2020, 10:22:57 PM EST, Evan Teran <[email protected]> wrote:
I can say though that for the absolutely trivial cases of "the docs didn't mention a parameter, but it's trivial to support"... we can just add it to the docs unless it REALLY wasn't intended to be used.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Beta Was this translation helpful? Give feedback.
-
|
OK, so it sounds like being more strict about erroring on things like a wrong number of parameters, or incorrect parameters is considered "OK", but we shouldn't drop features, functions, or wildly change functionality just because they are undocumented. Right now, there are around a dozen macro functions that aren't implemented. The biggest group are mouse related functions especially given that those are explicitly filtered when doing a learn/replay recording. But I do still need to take care of those lost few for MAXIMUM compatibility :-) |
Beta Was this translation helpful? Give feedback.
-
|
Oh, and BTW, just for clarity on the "cheeseburger" thing. It's actually easy to "bring it back", Basically the original code did a bunch of tests on the parameter, but if they all fail, it just defaults to "this window". The only reason I can think of for this to be "reasonable behavior" is if there is an expectation that a user may try to focus a window by filename, and that file may or may not be opened. So, the first parameter being silently ignored... I could make the argument for at least a console printout saying "document not found" and then raising NO windows because the request cannot be satisfied. As for the "focus" parameter, I plan to upgrade it to an invalid argument error if they pass something besides "focus" or "no focus" since anything else will simply not do anything the user would expect to be reasonable. |
Beta Was this translation helpful? Give feedback.
-
Open topic and I'm looking for genuine discussion. Because the intention with NG is to be a full drop-in replacement/upgrade from nedit5, we are inheriting the existing macro ecosystem. So backward compatibility is a big deal. That being said, nedit5 was pretty lax when it came to its enforcement of macro specifications.
@tksoh I think I know what your opinion will be on this one, but since you've worked on nedit5 for a long time, I'm curious what your thoughts are :-).
There are arguments that aren't in the documents, and there are arguments that will be silently ignored if spelled wrong.
In my endeavors to implement
raise_window, I noticed both of these issues.The docs don't mention a "focus" or "nofocus" parameter, but the nedit5 code, will accept and use it. OK, no problem, I'll make mine support it too and ideally update the online docs to reflect this. This one is easy :-).
The docs say that the first parameter can be "first", "last", "next, "previous", or a non-zero integer. But looking at the code, it will accept ANYTHING you put there and won't cause an error. (I'll happily accept that 0 can mean "this window").
as far as I can tell will cause no errors (and will raise the current window, but without focusing.
So if I enforce the actual rules as specified in the docs, is that "breaking" or a "failure to be backward compatible"? Is it reasonable to "improve" enforcement of the rules since the macro was almost certainly not doing precisely what the user intended anyway?
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions