Re: Jed Development

[Josh Guilfoyle <jasta@xxxxxxxxxxxx>]

On Mon, Jan 13, 2003 at 09:05:13AM +0100, SANGOI DINO wrote:
> > -----Original Message-----
> > From: Josh Guilfoyle [mailto:jasta@xxxxxxxxxxxx]
> > Sent: luned? 13 gennaio 2003 5.56
> > Subject: Jed Development
> > 
> > 
> > Over the past several months I have written a plethora of 
> > customized patches
> > for jed that went unanswered when directly contacting the jed 
> > developer
> > (perhaps I was using the wrong e-mail address).  I recently 
> > discovered the
> > "new" mailing list and would like to see if anyone here is 
> > authorized to
> > officially merge patches into the tree, and to discuss the 
> > specifics of the
> > changes that I have added.  Aside from many many tiny changes 
> > I have added the
> > following features (held in my local CVS repositories):
> 
> The JED maintainer is, as ever, John E. Davis. He said some time ago that he
> has a long list of pending patches, so he prefers to see the patches posted
> to this mailing list, and let the other jeddies to review those before
> consider the integration.
> 
> > 
> >   * c_mode now treats #if 0 ... #endif as a comment (this is 
> > very broken, and
> >     I believe I hardcoded this somewhere in the C 
> > source...some advice on how
> >     to cleanly do this would be greatly appreciate).
> 
> 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
:/

> 
> > 
> >   * GDB support very similar to Emacs, although it needs a 
> > lot of work before
> >     it can be formally introduced, however I do use it on a 
> > nearly daily basis
> >     so it is at least functional.
> 
> There was already a gdb mode floating around some time ago, I don't know who
> wrote it, maybe is yours. 
> (It was posted to the old mailing list some time ago, you can find it in my
> jed pages at 
> http://www.paneura.com/~dino, in the "all files together" section (get the
> archive, the file is local/jed-sau/others/gdb.sl).
> Anyways it would be a great tool, could you post it to this mailing list? or
> maybe a pointer to a web page.

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.

> 
> >   * Massive improvements to the ctags support that currently exists
> >     (specifically related to exuberent-ctags).  Eventually I'd like to
> >     introduce some better configuration options for this, 
> > including the
> >     ability to specify multiple tags paths on a per-project 
> > or global basis.
> 
> I have done a ctags support rewrite some time ago, you can find my version
> at 
> http://www.paneura.com/~dino/ntags.html (is a bit old, I have very little
> time lately).

See above :)

> 
> I have also the "per project configuration", not limited to tags settings.
> For example, I use mainly two indentation styles, one for the program I
> write for my employer, and one for my own programs. I have the right
> configuration files in the right directories, and the indentation style is
> set automagically.
> 
> > 
> >   * Added my custom color scheme to the list of defaults, 
> > which is notably
> >     much more visually pleasing than the previous ones :)         
> 
> Uhm... this is a  matter of taste... :))) I don't know if John has a policy
> about adding new color schemes to the main distribution... anyways, post it
> here, and if it is really so beatiful, we will start to scream loud to have
> it integrated... :))

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

> 
> [SNIPPED other changes to features not used by me]
> 
> > My WISHLIST (I'm willing to work on these directly, but I 
> > would need a bit
> > more guidance from the core developer(s)):
> > 
> >   * Optional libpcre regular expression backend.
> > 
> >   * DFA syntax that can persist across lines.  Also, regular 
> > expressions
> >     should include the support for zero-width assertions so 
> > that expressions
> >     can be required without actually highlighting them.
> 
> This means that I can do something like:
> 
> dfa_define_highlight_rule("\.\([0-9A-F][0-9A-F]+\):", "number", name);
> 
> and have only the number (without the '.' and ':' highlighted) ???
> It would be very useful for some custom modes...

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

> 
> >     NOTE: I tried this at one point a while ago, but I didn't 
> > know anywhere 
> >     near enough about jed's internals to pull it off...sigh.  
> > I feel that with
> >     a little help from the core developers I have more than 
> > enough actual C
> >     knowledge to do both of these.
> 
> If I remember correctly, the DFA support was not written by John. I don't
> know who did it, and if he is still around.

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

> 
> >   * Ability to change settings which would affect rendering 
> > without having to
> >     reload the file manually.  Such as TAB_DEFAULT.  Perhaps 
> > some kind of real
> >     redraw function?  Maybe this is already there and I've 
> > just missed it.
> > 
> call("redraw") ?

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.

> 
> > 
> > Hope to get a reply soon!  Thanks!
> 
> I Hope this gave you some useful answers...
> 
> Later,
> 						Dino

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