RE: Jed Development

[SANGOI DINO <SANGOID@xxxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Josh Guilfoyle [mailto:jasta@xxxxxxxxxxxx]
> Sent: lunedì 13 gennaio 2003 11.16
> Subject: Re: Jed Development
> 
> > You mean, you added "#if 0" "#endif" as a comment pair in c_mode?
> 
> Yeah, but I doubt I did this properly.  When I originally 
> looked it seemed
> that each mode could have only one multi-line comment 
> pair...maybe I was wrong
> :/
> 
JED has one slot for multiline comments and two slots for single line
comments. This is boring mainly for pascal (Turbo pascal and delphi both may
use '(*' '*)' and '{' '}' as comments). I did a patch to change this to four
slots usable for multiline or single line comments. The patch however is not
trivial, but I used it for months without any problem. The bigest problem is
that my patch does not apply to jed 0.99.16, I need to find a bit of time to
forward port it.

> 
> This is part of the problem: this kind of stuff needs to be 
> in a centralized
> distribution so that you don't have to go hunting all over 
> the internet for
> the basic functionality you want.

Francesc Rocher created a project on sourceforge to keep jed extensions.
Everyone can contribute, see http://jedmodes.sf.net/

(I see that Guenter wrote just now about it, so you can read his mail for
more info about JMR)

A lot of other people have personal pages with a section about jed. at
http://www.jedsoft.org/jed (I hope the link is correct) there's a colletion
of links you can see.
I know, is not easy to wander around while you are looking for a precise
answer, but you will find lots of interesting things.

> 
> After work tomorrow I will begin assembling all my stuff into 
> some meaningful
> patches that can be considered.  This may take some time, I 
> just wanted to see
> if there was any possible way that they could get committed 
> to the main
> tree...it seems there is :)
> 

Is definitely possible to have changes pushed to the main distribution. But
one thing that John seems to do very well is to keep JED a very stable and
reliable editor. I heavily use it both on windows and on a variety of
unixes, and I don't remember of a single JED crash in four years.

> 
> Not exactly.  "^" and "$" is the best example of a zero-width 
> assertion...ther
> is no "beginning of line" character that can be matched but 
> it is asserting
> that it's there, thus it is a zero-width assertion.  Perl 
> regular expressions
> provide an extremely flexible method of using your own 
> assertions that can be
> found through man perlre.  A brief example would be:
> 
> $str = "garbage foo foobar foo garbage";
> $str =~ s/foo(?=bar)/FOO/;
> 
> would change $str to:
> 
> garbage foo FOObar foo garbage

Powerful, but maybe a bit complex to use. I think that DFA misses three
things right know:
1) multiline matches (you also said this). This will make possible to have a
decent DFA based syntax highlighting for C and other programming languages.
2) highlight only some characters in a bigger match (this means that we can
see a bit of context without highlighting everything)
3) (this needs the point 2) the sections not highlighted may overlap: for
example, suppose I want to match strings like 1234:5678 and have the first
number of color1, the second number of color2, and the colon of color3. I
wish to be able to write something like:

dfa_define_highlight_rule("\([0-9A-F][0-9A-F]+\):", "color1", name);
dfa_define_highlight_rule(":\([0-9A-F][0-9A-F]+\)", "color2", name);
dfa_define_highlight_rule(":", "color3", name);

but as far as I can see it would require some heavy changes to the current
dfa code for this (I looked briefly, and was some time ago).

> 
> I really don't mean to attack anyone, but it seems that the 
> point of the DFA
> syntax was to remove a lot of the hardcoded logic and 
> functionality that was
> in the old system, however the DFA implementation has tons of 
> that cruft still
> left behind.  It is not truly as flexible as it ought to be, 
> I really wish I
> had the time to rewrite it :(

Another idea may be to port the highlighing engine of mcedit (the internal
editor of the Midnight Commander). It is based on DFA, but has contexts. I
never looked at that code though, so I don't know if is even possible.

> Yeah, I already thought of that of course.  Try changing 
> TAB_DEFAULT yourself
> and then try getting it to reload the file seamlessly.  It 
> should, ideally,
> have a function that behaves as if jed was reloaded entirely, 
> and redisplays
> all open buffers, etc.

This means that you have to know for what buffer you have changed TAB
manually (this would mean a C code change), and let those unchanged, ad go
through all the remaining buffers setting TAB = TAB_DEFAULT. You should keep
in mind that a small limitation for you may be a big drawback for someone
else. Adding features that in some way limit the user choice is a bad thing
IMHO.

This is why John prefers to have new features implemented in slang code
instead of inside jed: we can always put an if(new_version_wanted) {  new
behaviour } else { old behaviour }
and let the user choose what he prefers.

Later,
					Dino
-- 
In theory, there is no difference between theory and practice.
In practice, there is.

--------------------------
To unsubscribe send email to <jed-users-request@xxxxxxxxxxx> with
the word "unsubscribe" in the message body.
Need help? Email <jed-users-owner@xxxxxxxxxxx>.