I decided to go read the mwedit mailing list archives myself.

Hey guys we might have a problem here. I of course haven't followed the whole thing but it appears that mwedit is going to disappear. Martin is totally disgusted with the project, for reasons I did catch, and is stopping any work on mwedit and starting a totally new editor. The problem is the licensing. It appears that mwedit isn't really open source so it is somewhat quasi legal using the code. It might behoove someone to write the mwedit list and ask just what issues we might have in using the mwedit code.

If there isn't a problem I would suggest that we monkey with the mwedit code we have in whatever fashion we wish since it might not be of any concern whether it is compatible with the original mwedit and Delphi code or not.

Could someone who follows the list confirm if my assumptions about what I read are correct?

Hi!

Hongli Lai wrote

I have a weird idea that might prevent mwEdit disappering.

The mw in mwEdit will go away, that's all.

Martin wants to get rid of mwEdit, mainly because he think he isn't respected anymore.

Sorry to say that, but mwEdit has turned to the worst. It needs to be recreated to something that can be my joy and my pride again.
I'll create a new, hopefully better mwEdit under the MPL. However there will be more control of what's going into it, while everybody has the right to derive own versions according to the MPL.

Martin

Was wird hier eingefuegt ? :

      ecImeStr:
        if not ReadOnly then begin
          SetString(s, PChar(Data), StrLen(Data));
          if SelAvail then begin
            FUndoList.AddChange(mwcrDelete, fBlockBegin, fBlockEnd,
              PChar(Helper), smNormal);
...

In der letzten Zeile wird Helper verschickt. Aber Helper hat ja noch gar keinen Wert. 2 Zeilen unten drunter schon wieder. Was soll das ? Kennst du die Antwort oder ist das wieder eine der vielen komischen Dinge ?

Kindest regards, Alexander Mehlhorn (AHM)
_____________________________________________________________________ Home of the AHM Triton Tools 2000 for Delphi and C++ Builder URL: http://www.tritontools.com
E-Mail :
You are welcome to contact in regards to any
questions, ideas or problems you might have.
______________________________________________________________________ Copyright � 2000 Alexander Mehlhorn (AHM) and Tritontools.com. All rights reserved.

----- Original Message -----

You have all my agreements, we must play our card.

Vital Tremblay

Anyone else on the mwEdit mailing list. There is a soap-opera playing out there that makes the future of mwEdit a little uncertain.

I'm not on the list, could you give us the story in a nut shell?

I don't know for sure. It was suggested that Martin might pull any code he has written. That would leave a very big gap in the mwEdit code. He also said something about it not being morally correct to use his code. I really don't understand where he is coming from. It also appears that the new version of mwEdit will NOT be open source and he will control the whole thing.

Can someone who is on the list ask the question point blank? Ask what is the issue with Lazarus using mwEdit. Can we continue to use it?

Would it mean that the actual mwEdit couldn't be used any more or just it get no longer supported.

Vital Tremblay

Hi!

Peter Dyson wrote

Does this mean you have no objections to us continuing to try to use the existing version? We wish at least get a working editor up and running in Lazarus.

I don't have objections to you continuing to try to use the existing version.
I just don't want to see my name assigned to the current version any longer.

Martin

Hi!

Would it mean that the actual mwEdit couldn't be used any more or just it get no longer supported.

The actual mwEdit can be used without mw.
With other words use it under any name you like
but without mw in it.

Martin

Sorry ... You can choose to ignore the last message or have a look if mwEdit in Lazarus has the same problem. The message was actually agains sent of elsewhere. I keep doing this and apologize.

Under Processing the command in ecImeStr the Variable Helper gets passed on unassigned.

      ecImeStr:
        if not ReadOnly then begin
          SetString(s, PChar(Data), StrLen(Data));
          if SelAvail then begin
            FUndoList.AddChange(mwcrDelete, fBlockBegin, fBlockEnd,
              PChar(Helper), smNormal);
...

Regards, Alexander Mehlhorn (AHM)
_____________________________________________________________________

Op Fri, 03 Mar 2000, schreef Michael A. Hess:

Yes, what you read is correct. Martin called mwEdit a "large and unmaintainable monster" or something.
But I don't think mwEdit will really disappear.
It's still an open project, right?

Anyone else on the mwEdit mailing list. There is a soap-opera playing out there that makes the future of mwEdit a little uncertain.

01010011
01100101
01100001
01101110

Ok, sorry to sound such a pain, but I am only trying to put forward niggles that would annoy the point and click world.

In trying to modify the nwEdit sources as little as possible I have been trying to keep the file names in the original mixed case format. Make seems to cope fine if you ensure the filename is correctly capitalised and for most of the source files this works fine.

However where there is a circular dependancy in the source unit files, UnitA uses UnitB and UnitB uses UnitA then only one of the files needs to be passed through make and fpc takes over the circular dependency resolution.

I know, circular dependencies are 'A Bad Thing'.

It is my hope, that we could, in the future, sumbit the changes required to the sources back into the mwEdit team. This would give some good free press to fpc and
lazarus if windows users saw this code was being compiled under Linux and also show how much work is involved in porting.
It would also make future maintenance much, much easier.

As Pascal is case insensitive it would be impossible to have, Uses UNITA, unita; even if the underlying filesystem allowed this, so could fpc be made to resolve UnitA.pp, unita.pp or any variant of the filename under case sensitive filesystems?

I realise that to do ths fully would require grepping all the search dirs which is not a good thing, but if the users wants to used mixed case capitisation and he has a filename UnitA.p[p|as] could we accept 'uses UnitA;' but not uses 'unita', ie case sensitive file system = case exact match case sensive unit name or lowercase unit name. This, I think, would be acceptable, after all this is *nix. The case of the .ppu file is irrelevant to all but fpcmake as the compiled unit filenames would probably be lowercase for ease of linking etc. Only mod there though would be in how it handles the make clean cycles.

I know searching for the include files takes up a large time slice of the compilation process so maybe a compiler
switch/directive would also be required for the single platform speed freaks who would view this as a waste of time

As to the tile of this, the Holy Grail is typing
make
make install
in a dos box
then
make
make install
in the telnet window and ensuring cross platfom code has just been written all from the same source files.

Peter

I have a weird idea that might prevent mwEdit disappering. Martin wants to get rid of mwEdit, mainly because he think he isn't respected anymore.
Why don't we try to end emails to the mwEdit list and say we all like mwEdit and respect Martin?
It can work.

Like I said, it's a weird idea. You don't have to agree with it.