Ok, here's a translation to C. Some variable names changed. Lightly tested:
int scriptclose(char *line, unsigned int len) {
int rparen= 0;
for (unsigned int j= 0; j wrote:
> The firstunmatched verb needs to run only on visible
> portion of text and I think it should be fast enough, but
> i
Not surprisingly, some of us have developed similar tools. I have a verb
(as) which, by chance, given your (sample) argument almost reproduces your
(target) product,
as'qq((a(bd(c))g)gg())g'
┌──┬──┬─┐
│qq│┌──┬──┬──┐│g│
│ ││┌─┬┬─┐│gg│┌┐││
The firstunmatched verb needs to run only on visible
portion of text and I think it should be fast enough, but
it requires some effort to translate the scan operator to
its equivalent in c or c#.
--
regards,
GPG key 1024D/4434BAB3 2008-08-24
g
There is no detail explicit rule for that, what I can find is
the following inside ~config/cfcolsav.ijs in J602 which I might
misread
00-19 system colors
20-39 class colors
40-59 keyword colors
0 bkgnd
1 text
2 selbkgnd
3 seltext
4 margin
5 mark (character d
With this design, there should be no need to refresh syntax
highlighting for lines which are off-screen.
Thanks,
--
Raul
On Mon, Dec 26, 2016 at 9:14 PM, bill lam wrote:
> The primary reason is efficiency. Every change or scrolling in text
> will trigger a highlighting routine to refresh. If
It seems to me that in ((() the first two parenthesis are unmatched
and the last two are matched.
Or, at least, I do not see why I would arbitrarily pick the middle
parenthesis of the three to be the first unmatched one.
Remember also, that in your original post in this thread you posed this exam
Also whitespace in j tokenizer includes TAB, so that
the first line can be revised to
> if. ')' -:&(-.&(' ',TAB)) y=. ,y do. #y return. end.
the ,y for fixing singleton atom to array.
Вт, 27 дек 2016, bill lam написал(а):
> '((()'
> shouldn't the first unmatched at index 1 instead of 0? ie us
The primary reason is efficiency. Every change or scrolling in text
will trigger a highlighting routine to refresh. If a file
contains several thousand of lines, and if it takes several
seconds to refresh, the editor would become un-usable.
Пн, 26 дек 2016, Devon McCormick написал(а):
> Is there a
Thanks, I got it now and I had never paid attention to it since
I seldom use jqt ide and did not enable syntax coloring on it.
Apparently the scheme used in jqt syntax coloring is faulty,
since if applies rules as independent and let the last rule to
overwrite the previous one.
Please feel free t
Yes, try
commentstart =. 'NB.' E. line
Henry Rich
On 12/26/2016 7:10 PM, bill lam wrote:
I can't get what you meant. Did you mean there are some bugs in qtide
syntax coloring?
On 27 Dec, 2016 3:25 am, "Henry Rich" wrote:
The parenthesis and comment delimiter in J have the part of speech
'((()'
shouldn't the first unmatched at index 1 instead of 0? ie use i: instead of
i. for unmatched (.
On 27 Dec, 2016 8:31 am, "Raul Miller" wrote:
Ah, good point - I was not properly handling the case where the first
unmatched parenthesis was the first character on the line.
Also, the clos
Ah, good point - I was not properly handling the case where the first
unmatched parenthesis was the first character on the line.
Also, the close script line is something of a special case, but it's
easy enough to check for:
With that fix and this change, I'd do something like this:
firstunmatche
I can't get what you meant. Did you mean there are some bugs in qtide
syntax coloring?
On 27 Dec, 2016 3:25 am, "Henry Rich" wrote:
The parenthesis and comment delimiter in J have the part of speech 'control
word'.
I didn't mean readable in the usual why-can't-anybody-write-comments-any-more
your verb seemed to find unmatched ) only, e.g. failed for
'(()' or '(()('
also a line of ) and whitespace belongs to class 'close definition' and
should not be flagged as mismatch.
On 27 Dec, 2016 2:42 am, "Raul Miller" wrote:
> I'm not sure what you mean by "containing control words" but code
Is there a particular reason to do this with regex? There are a couple of
essays about doing this in J like this one -
http://code.jsoftware.com/wiki/Essays/Parentheses_Matching - and my own
contribution:
http://code.jsoftware.com/wiki/User:Devon_McCormick/ArrayThinking/JConferenceTalk2014#Simplif
I meant 'punctuation' instead of 'control word' for ) and NB. .
Henry Rich
On 12/26/2016 2:25 PM, Henry Rich wrote:
The parenthesis and comment delimiter in J have the part of speech
'control word'.
I didn't mean readable in the usual
why-can't-anybody-write-comments-any-more sense, but as
The parenthesis and comment delimiter in J have the part of speech
'control word'.
I didn't mean readable in the usual
why-can't-anybody-write-comments-any-more sense, but as a reference to
the Qt IDE's habit of treating quoted control words as active, and
giving the wrong font to everything
I'm not sure what you mean by "containing control words" but code
readability issues are usually a call for better code.
For this, perhaps (warning: lightly tested code):
firstunmatched=:3 :0
q=. unquoted=. -.~:/\y=
c=. uncommented=. -. +./\ q * 'NB.' E. y
n=. parendepth=. +/\q*c*-/'()'
I don't think it is reasonable to treat ')' and 'NB.' as containing
control words. It makes the code very hard to read.
Showing the mismatched parenthesis is important enough that it might be
better to have it even with this deficiency, but it IS a deficiency and
should be treated as a bug to
I double checked with j602, it has no problem in high lighting
the unmatched )( in
a '+' ((mno - rst) % b NB. )unmatched paren
^
a '+' ((mno - rst) % b ')' NB. )unmatched paren
^
and
'(' (=:))
^
But this is matched and is correct
a '+' ((mno - rst) % b ')') NB. )unmatched par
Right, this is a hard problem for regex, there may more "(" or more ")"
.jqt syntax coloring did not support it either.
On Dec 26, 2016 11:37 PM, "Don Guinn" wrote:
I'm a little confused as to where this is going. If the number of "("
equals the number of ")" does that mean that they are matche
I'm a little confused as to where this is going. If the number of "("
equals the number of ")" does that mean that they are matched? Not
necessarily. The running sum of "(" minus ")" should never be negative.
What about a parin being inside a quoted string? Then there is the more
general problem wh
22 matches
Mail list logo
