Re: Jed Development

[Josh Guilfoyle <jasta@xxxxxxxxxxxx>]

On Mon, Jan 13, 2003 at 02:38:05PM +0100, SANGOI DINO wrote:
> > -----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.

Ideally, this should be unlimited, no?  I will look into a permanent and
flexible solution.

> 
> > 
> > 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.

Optional support doesn't necessarily hinder on stability or reliability.  So
long as the code is reasonably isolated, I can't see why refusing patches
would be anything but laziness (which I can understand, I do it myself in all
of my open source projects).

> 
> > 
> > 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:

Both 2 and 3 would be tackled by zero-width assertions.

> 
> 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 wrote a complete replacement for the DFA code that exists in jed currently
(although I would rewrite it if I ever expected anyone to use it).  My only
limitation was efficiency, it was written to piggy back off of libpcre, which
didn't have any sane hooks for retrieving the next line...it simply took a
linear string and operating on it, so I had to make extreme sacrifices to get
multi-line to work.

That said, I now know of a way to work around this limitation in libpcre and I
think it could actually be used as the DFA implementation, providing
INFINITELY more flexibility, unfortunately it would require a massive change
to the project itself (updating all the rules etc) and I seriously doubt John
is up to task...sigh, has anyone requested to takeover maint?

> 
> > 
> > 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.

All regular expression systems are "based" on DFA, so it would be beneficial
to just rip this from a freely available library.  Not to mention defining
your own syntax is just a silly idea.

> 
> > 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.

I didn't realize there was the TAB setting, that is what I really wanted,
sorry :)

> 
> 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>.

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