16048Re: functional, but dysfunctional also onclipboardchange and ^!clip
- Feb 3, 2007--- In firstname.lastname@example.org, Alan <acummingsus@...> wrote:
>to convey a
> (There seems to be not yet achieved sufficient communication so as
> correct understanding about the important distinction between 1. to*launch*
> a 2nd (or 3rd, etc.) clip while a clip is already currentlyCommmunication is the hardest part about computers... knowing what the
> running --*versus*-- 2. the use of ^!Clip
other fellow is saying so we comprehend and learn...
> # 1 and # 2 are different. # 2 is *not* (not in actuality)
> another clip while a clip is already running. Instead, what # 2 isdoing is
> it is "farming out" (or contracting to) (or, even better yet,"routing the
> processing to").I think we agree on the difference between #1 and #2. #1, launching
another clip while a clip is running, produces clips that appear to be
running simultaneously. #2, using ^!Clip, which I call "nested
clips", do not produce, and are not expected to produce, simultaneous
execution: the ^!Clip operation suspends the first clips, performs the
clip named as a parameter, and when that one completes, the first
resumes at the next instruction.
As far as I can determine, OnClipboardChange is a 2nd way, besides the
user explicitly launching a clip, for a clip to be initiated. If
other unnested-Clips are already running, it seems that
OnClipboardChange can be successfully launched during ^!Delay
operations in those other clips' operation sequence. But if any
nested clip is currently running, then OnClipboardChange produces a
beep, just like the user attempting to launch another clip while a
nested clip is currently running.
>used, is to
> Continued further below is that ^!Clip, however many times it is
> be seen as a conglomeration of clips that in actuality areesentially they
> are united as one huge clip. The point is that, since ^!Clip is for"routing
> the processing to", it is only one clip that is running no matterhow many
> times ^!Clip is used.When not thinking about simultaneous clips, your "united as one huge
clip" comment is a reasonable interpretation of the matter, but when
thinking about simultaneous clips, then there is a visible distinction.
Initiation of donothing3 directly (one huge clip) does not prevent
initiation of donothing4. Initiation of donothing3invoker, which has
exactly the same set of operations as donothing3 because it calls it,
does prevent initiation of donothing4, which proves there is a
distinction between "one huge clip", and "united as one huge clip".
> Are you trying to use clip as a programming language? It is not.It is a
> macro language (a powerful macro language). Notetab is a texteditor that
> you can write clips/macros so as to "program (or automate repetitivetasks
> in) the editor".In my computer science classes, I learned that a functional computer
can be created from two instructions: subtract, and branch if
negative. For example, negation can be synthesized by subtracting
from 0, addition can be synthesized by negating and subtracting,
multiplication is a series of additions, etc. So I find that NoteTab
supports subtract [ ^!Set %x%=^$Calc(^%x%-^%y%)$ ] and branch if
negative [ ^!If ^%x% < 0 Skip_-3 ], so I conclude that it is a
programming language. To me, a macro language is simply a linear
sequence of operations, like a tape recorder/player. Once control
flow and arithmetic are added to a macro language, it becomes a
> But clip itself is *definitely not* a programming language. A"programable
> editor" is a term I've heard used about Notetab. But it is a macrolanguage
> that is used to achieve this automation or so called"programability" of the
> editor.as a
> Oh, clip has likeness to, say, qbasic. I guess qbasic is considered
> programming language. But clip is definitely macros language.So we disagree about what to call the clip language...
> It *appears* to me that I've not yet *effectively* *totally*communicated
> to/with you.quoted up
> I've no argument with you that your well made point quoted up
> above "absolutely won't work".
> But, once again (as per your lib below) and your well made point
> above, you are *launching* a second (and 3rd, etc.) clip whileanother clip
> is still running. And, AFAIK when a clip is running, it is notsupported to
> *launch* a 2nd clip (nor a 3rd, etc.) so that now two clips are runningconcurrently
> s/concurrently/simultaneously/; # perl substitution lingo
> I'm using the term "simultaneously" to replace or in place of
> term that you used.*simultaneously*.
> AFAIK it is not supported in Notetab to launch/run two clips
> That's not to say that sometimes it won't at least partially work orwork
> under some circumstances but not others.You likely have more experience with NoteTab/clip than I do, so I'm
not going to disagree with anything you say here... but I would like
to make some terminology definitions so we can communicate better.
1) documented: a feature that is explained in the documentation.
Generally all documented features are also supported (see below).
2) supported: a feature that is claimed to work by the purveyor of the
product. Generally all supported features are also documented, but
sometimes older features, while still supported, are dropped from the
documentation in favor of newer, better features that encompass all
the capability of the older feature, and sometimes the documentation
of new features lags the development of the feature and its delivery
in the product.
3) bonus: a feature that is not documented or supported, but which, by
experimentation, is found to work. There is no guarantee that such a
feature will work in future versions of the product.
> A Very *Important* distinction: If by "nested" you mean what I callparent and
> child clips (where ^!Clip clip_name is used) -- to do so, this is *not*I agree; and that is why I was surprised to discover that nested
> simultaneously running more than one clip at once.
clips, which you call parent/child clips, prevent the simultaneous
invocation of other clips, whereas "one huge clip" does not, even if
they have the same sequence of operations.
> So as to illustrate the "nested" and "levels":suggest/offer that you
> Mr. Fookes, the author of Notetab, wrote the next clip library:
> On that page, you can download the pad clip library. I
> download that library and look at it.Yes, a very complex program.
> I wonder if Mr. Fookes has something that we don't know about suchas "tags"
> for clips?Understanding such a complex program can often be better done by
looking at the individual building blocks, and understanding them
first... but I have no idea what tools Mr. Fookes might have for
building clip libraries.
> AFAIK, a *bonus* *if* it even works at all -- let alone whether ornot it
> works under more complex circumstances. AFAIK what's supported isonly 1
> clip running at a time, not 2 or 3 etc. clips launched and runningat the
> *same* time.So your theory is that simultaneous clips are a bonus feature.
Certainly I couldn't find documentation for them, so they don't seem
to be a documented feature.
Yet Jody seems to write clips that use the feature, and so do others
on this board. So it seems to be an acceptable use, perhaps it might
be a supported feature, but it could be a well-used bonus feature.
Can anyone declare that simultaneous clips are a bonus feature? What
are the chances of them being removed, deprecated, or enhanced,
respectively, in future version of NoteTab?
If I build clips that depend on them, are they likely to continue working?
Are there other limits that are likely to surface as clip complexity
- << Previous post in topic Next post in topic >>