On Tue, Aug 19, 2008 at 23:05, Tony Balinski <[EMAIL PROTECTED]> wrote:
> Quoting Bert Wesarg <[EMAIL PROTECTED]>:
>
>> As reported here [1], we shuold force a final newline in macro files,
>> to prevent syntax errors.
>>
>> Regards
>> Bert
>>
>> [1]
>>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2038921&group_id=11005&atid=111005
>>
> Looks good to me.
Than I start committing again. The macro clean-up in interpret.c is
overdue, and I have similar (but way smaller) patches for macro.c and
parse.y
>
> Tony
>
> PS re your comments about my fastConcat3 patch: you're right, of course...
> I'll need to fix it some time, but I'm very behind in keeping my patch set up
> to date. Sorry. The easiest, I suppose, is to return the negative of the
> length
> and a positive number for failure. A bit unnatural, but there you go...
>
> I've been playing in parse.y, implemented (both)
> for ([k] = v in array) { ... }
> and
> for (v = [k] in array) { ... }
I saw this too (see below). But I don't see a benefit for both
syntaxes. I fixed today my extended for-array patches [2]:
The problem was, that I like to have the ability to iterate only over
n-dimensional keys.
So the simple [k]=v was not possible anymore (because the case for
N==1 was missing), and the simple k=v didn't work, because the parser
bails now out by the 'normal' for (i=0;;) loop. And my previous
solution with k:v looks nasty. So, I fixed this by a big look ahead
function for the '=' sign ('= SYMBOL IN'). A new feature is the
k[0]=v/k[]=v syntax, for all keys, but nicely split-up and put into
the k array.
Here is all in one rush:
for (k in a) .. # all keys assigned to k
for (k = v in a) .. # -"- with v := a[k]
for ([k1,..,kN] in a) .. # all N-dim keys assigned to k1,..,kN
for ([k1,..,kN] = v in a) .. # -"- with v := a[k1,..,kN]
for (k[N] in a) .. # all N-dim keys assigned to k[0],..,k[N-1]
# N == 0 => all keys, same as missing N
(i.e. 'k[] in a')
for (k[N] = v in a) .. # -"- with v := a[join(k, $array_sep)]
> meaning the same thing, and similarly
> if (v = [k] in array) { ... }
true if array[k] == v, right?
> if ([k] ! in in array) { ... }
true if k is not a key in array, right?
Both sounds reasonable, except my previous concern about v=[k].
> ex-or (^^) and conditional (?:) operators; and adding parser location
> information so you can go from an instruction to a position in a source code
> string. I'd like to get it to the point of being able to provide a debugging
> service.
Ahh, thats these CALL_TAG/LINK_TAG tags in your code at [1]. I just
'discovered' this last week. I just started coding with Nedit again.
> But building patch files for each of these and combining with the
> others is turning into a real can of worms!
Sounds like its time to change your tools ;-)
> We need the next release and a new branch!
ACK.
Good Night
Bert
[1] http://ajbj.free.fr/nedit/neditHome/neditHome-2008-08-04.tar.gz
[2] http://kgb.endoftheinternet.org/git/nedit-bw/
but its currently down :(
--
NEdit Develop mailing list - [email protected]
http://www.nedit.org/mailman/listinfo/develop
