backlighting

[AVKuznetsov]

On Fri, 29 Feb 2008 01:12:58 +0100
Tony Balinski <ajbj at free.fr> wrote:

> Quoting kuzn at htsc.mephi.ru:
> 
> > >> The uncommented code is well compiled and stable works.
> > >> Is there a reason to neglect this code?
> > >
> > > The code works; in fact I use it from time to time. The interface,
> > though,is very unfriendly.
...........
> > >
> > > I wrote this stuff ages ago, around the same time as the initial rangeset
> > > stuff. I use it daily to check for tabs and trailing spaces in my files.
...........
> 
> No, I never did add those functions - I wrote macros that did the work
> of analysing the current string, then of building a new one. That's
> what I use when I manipulate backlighting. But the macro code is hard.
> The suggestions I made above would make it easier for new macro
> programmers to "take control".

Well, macro programmers will happy to have a possibility to operate on
the backlighting. Can you "revert the code",
i.e. uncomment the proper paths of macro.c and help.etx in the CVS code? 


> As for your comments, indeed the only people who use the patches tend
> to be the nedit developers themselves, and each has their own set. It seems
> that Bert Wesarg is trying to pick up the best of what's available. This
> would be (I suggest) the thrust of NEdit 5.7 (once we get past the 5.6
> release!)

It is a time to pick up the best of what's available for NEdit-CVS.
I am not sure that NEdit-5.6 will be released at this or even next year...
Who does make it now?

> That being said, there are MANY reasons why I couldn't go back
> to the "standard edition" now - I'd just be so frustrated! Possibly the
> most important reason would be multiple selection on the list_dialog() (I
> have a version now which uses my own "named arguments" convention, though
> I haven't made a patch for it yet...)

Add a patch for the list_dialog() to the NEdit source and this problem will
be solved. Your patch with the "browse_sel", "multi_sel" and "string_entry"
arguments provides very powerfull (and stable) list_dialog() which is much
more friendly than the standard one. Why do you "hide" it from users?

> So I imagine people just coming to
> NEdit thinking "brilliant editor, but if it could only..." and moving away
> because that feature only exists as a patch, albeit one a few years old!
> 
> I've got to a point where maintaining my own patches has become about 80%
> of my NEdit work. I would dearly like to check some of this in, if only
> to make my life easier.

Add a pat (most?) of them to the NEdit source and your life will a bit easier.
Who does object against, for example, macro language enhancement or
list_dialog improvement? If no code is developed NEdit die.
At present the NEdit code is only maintained.

Alexey