Hi, * Jörg Fischer wrote (2008-01-04 11:33): >Thorsten Haude wrote: >> So I take it you want to get back to phase 1 again? > >No, I'd like to proceed with the release progress. It's a bit >ambitious to discuss things like full Unicode support, migration to a >new toolkit and whatever else fantasies come to mind while we need >a couple of years for a simple maintenance release, isn't it?
It sure is, that's why I wondered why you would bring these things up. I don't mind if additional bugs are closed before the release, but we should focus on the release-criticals. >> Is this your list of release-critical bugs? I have to say that I >> don't think most of them are this important. > >This is a list of work currently going on just to keep track. >Personally, I wouldn't see any of the bugs in the tracker as >release-critical, but this isn't the point. It just doesn't help to >start working on a bug, and a couple of weeks later we forget about >it, because it wasn't completed - 'completed' means including tested >and comitted to cvs. I regularly put in patches, discuss them, wait a bit, put in a new version etc. Also as a rule, I wait four weeks between the final patch the the commit, so that everybody has a chance to object. So these were not forgotten, just postponed due to my NEditbreak. >> >#1628593 Unnecessary window grow when opening file >> > >> > annoying for line number users >> > fix submitted - not in cvs >> >> Yeah, it's kind of nasty and I got distracted while looking it over. > >I have applied it for testing. I got compiler warnings about const in >static int updateGutterWidth(const WindowInfo* window) and >static int updateLineNumDisp(const WindowInfo* window) That's my const, and it's more documentation than of real value. I wonder about the warnings though, what compiler do you use and at what -W level? >> >#1760116 Negated escape sequences misinterpreted in character class >> > >> > fix ready, but would trigger more changes (like proposed) >> >> I didn't follow that discussion too closely. You two have fun. > >Tony and I both agreed with each other that the matching of newlines >should be changed. Now changing the regex syntax, although the syntax >will be made more consistent and useful, might affect some other users >as well. So, the question was wether or not this would be alright. I think it's clearly a bug, why would anyone want this? >> >- Macro built-in function registration >> > >> > Tony's proposal, ready, available here >> > http://ajbj.free.fr/nedit/nedit5.5dev/patches/newMacroFnRegistration2.diff >> >> Seems to be ok. > >It isn't in the tracker, so don't forget about it. Hm. Neither it's release-critical, so why would I have to remember it? I think it would be ok to commit it, but I won't keep track. >> >- Remove non-existing files from Open Previous? >> >> Is that a patch? > >Yes, it's available (don't know if it is on SF), and I listed this >because it makes a lot of sense IMO (close to a bug fix). Neither tracker seems to know it, so where is the code? >> >#1600102 Add example .nedit to release tarball >> > >> > Looks like additional work. >> >> Is there something major missing? > >It is one of the things set to priority 9. Maintaining such a macro >set will be more work - just like problems with the built-in macros >fire back now and then. I think it rather comes down to a project of >its own (somewhat similar to jedit's plug-ins project) than to be >coupled with nedit releases, especially longly overdue maintenance >releases. I don't think that these macros will require much work. They are all pretty stable, and I will keep them up to date anyway. Yes, because this is the first time we do this, some things will come up which we don't expect, but it has to be done eventually, and the problems will come up after the release is done. We should do a project of its own when we ever have something similar to jEdit's plugins. (We already had a website for this shortly.) >> >#1731384 problems with default macros >> > >> > fix in cvs >> >> So you have any idea since when that bug was in the code? We need to >> add it to the ReleaseNotes if it's an old bug. > >I guess right from the start, ie the 1st committed version of these macros. At least replace_in_string() was changed since then, so I wondered what might have triggered it. Anyway, I added it to my local ReleaseNotes. >> >#1479505 Odd Replace Behavior with Long (> 510 chars) Search Result >> > >> > Is this fixed already? >> >> Nope, doesn't look like it. > >Yes, there I was a bit confused, since something similar is mentioned >in the release notes: > > - Replace operation where the result exceeded a fixed length > silently clipped the result. The limit has been increased and the > behaviour on failure is now configurable. (SF bug #1015499) See other thread. >> #579913 VMS language mode inconsistencies >> >> Access to VMS would be a big help here. > >This one is over 5 years in the tracker, and without help from someone >with VMS it's likely to stay there, so we have no release? Back when that was added to the release-crits we just got a new developer with VMS resources. I'll notch it down. Thorsten -- Auch Hunger ist Krieg. - Willy Brandt
pgp9aBZtTnMEd.pgp
Description: PGP signature
-- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
