backlighting

[Dale Whitfield]

> 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. What's really needed is something that allows you to
> > > modify the backlighting a bit at a time, eg
> > >   set_backlighting("red", "\x01-\x1f")
> > >   set_backlighting("lightgrey", "\t")
> > >   set_backlighting("white", "abcdefghijklmnopqrstuvwxyz")
> > > and
> > >   col = get_backlighting(c)["rgb"]
> > > say. This can be done by manipulating the backlighting resource for the
> > > text widget.
> > >
> > > 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.
> > > My own patched build turns all that stuff on again, then adds some more
> > > (foreground "backlighting", taking precedence over SH, aimed at providing
> > > visible spaces one day). But it can certainly be improved.
> > >
> > > Tony
> >
> > Hi,
> >
> > unfriendly interface is better then nothing. I think, this code
> > can (must?) be uncommented. Tony, if you have improved interface,
> > please, can you add it to code?
> >
> > Seems, the main problem of the NEdit developing is that no developers
> > use it. (That is problem of users, not developers or programmers).
> > "Strongly-patched, self-made editor" having many nice features
> > strongly differs from both NEdit-5.5  and NEdit-CVS.
> > That is practical point.
> >
> > Tony, I am not hurl reproaches at you or other developers.
> > Thanks all developers for the best editor.
> >
> > Alexey
> 
> 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".
> 
> 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!) 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...) 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.
> 
> Tony
> -- 
> NEdit Discuss mailing list - Discuss at nedit.org
> http://www.nedit.org/mailman/listinfo/discuss
> 

Please, please check these in. The multiple selection list_dialog is
something I curse not having on a regular basis.

There's also a bug in the development source in the list_dialog which
unceremoniously dumps me out of Nedit every now and then. I'm too
swamped to debug it...

I'd like to add my vote to adding these features and getting a new
release out asap. There are so many excellent features that are buried
in Nedit. There's also a lack of one place to find all these patches and
macros.

/rant on
I'd also put forward that one can be too precious about ensuring all
platforms and all compilers are always supported by all versions of Nedit. 

In my view this is slowing progress. Rather get out a version that works
on Linux, say, where there is plenty of active development and then work
to ensure other platforms are supported. Otherwise the argument just
becomes circular and development stalls.

I prefer the positive approach - to be finding reasons to add code
rather than reasons to leave it out.
/rant off

-- 

Dale