Forked VSCode for Delphi

[Nasreddine 2]

This is posted on QR if you want to vote

 

 

I'm new to the whole pascal thing compared to your customers (I'm only two year old), and I'm using Delphi community edition 10.2.3 for my current development.

I just spent more than 6 hours reading posts and topics about the quality of the IDE and how there are many bugs in it (flagging inline variables as error is funny though) and how it is lacking a lot of quality features that are now a days something for granted.

I'm being honest here and I would like to say that the first two things I did after those 6 hours was:

1) look for Delphi alternatives (I found few of them that show promise c# and c++ the vs version)
2) come to propose an Idea here.

This is mainly coming from love to the Delphi language and its power, but lets be forward here and say that there is no way I'm going to stick around for as long as those guys in stackOverflow did (some of them 20 years!!!!)
with an IDE like the current one.

So at the end I would like to propose an Idea that could help a bit, Why not fork the VSCode editor and add the basic form designer to it, it is already supporting Delphi through OminiPascal extension and it could even use syntax highlighters and more features that come out of the box that are not in the Delphi IDE for now.
It could support every lacking part from the IDE and it is open sourced so you could get some help from other developers on it.

I'm only looking for an answer that could heal the hole in my hart for now.

Best regards Nasreddine.

Edited April 27, 2019 by Nasreddine

[David Heffernan 2345]

There's absolutely no reason why you should not do this. 

[Rudy Velthuis 91]

3 hours ago, Nasreddine said:

I'm only two year old

I assume you have been using Delphi for two years now and not that your actual age is 2 years?

 

3 hours ago, Nasreddine said:

there is no way I'm going to stick around for as long as those guys in stackOverflow did (some of them 20 years!!!!)

I've been using Turbo Pascal since 1985 and later Delphi since 1995, so a little longer than that.

 

3 hours ago, Nasreddine said:

Why not fork the VSCode editor and add the basic form designer to it, it is already supporting Delphi through OminiPascal extension and it could even use syntax highlighters and more features that come out of the box that are not in the Delphi IDE for now.

If you want to do that, feel free. But I rather stay with Delphi's IDE. It is as tightly coupled to Dephi as can be, and changes to FMX or VCL will be reflected in the designer too.

 

FWIW, the Delphi IDE can easily be extended too, and you could implement the features you find lacking. Take a look at GExperts or cnPack or some of the other experts/wizards/plugins that extend the IDE.

Edited April 27, 2019 by Rudy Velthuis

[Darian Miller 361]

Not a horrible idea for Embarcadero to consider internally... but they would need to invest a large amount of dev effort into it.

[Stefan Glienke 2002]

I guess you are a bit naive in your assumption of what it takes to get from something like VSCode to a fully featured IDE like RAD Studio or Visual Studio...

Because otherwise why is there still that thing called Visual Studio that MS is putting significant resources into it if they could slap a few extensions onto VSCode?

[Darian Miller 361]

You may want to check out:

https://www.omnipascal.com/

 

https://marketplace.visualstudio.com/items?itemName=alefragnani.delphi-pack

[dummzeuch 1505]

26 minutes ago, Darian Miller said:

Not a horrible idea for Embarcadero to consider internally... but they would need to invest a large amount of dev effort into it.

Revolutionary idea: If Embarcadero wanted to invest a large amount of dev effort (which translates mostly but not only into spending money) into Delphi, they could put that effort into fixing bugs in the existing IDE.

 

Since the number of bugs seems to be growing rather than dwindling, what does that tell you about their priorities?

[Nasreddine 2]

@David Heffernan I'm in the process of this and it is far better than what the IDE is featuring for now. And by that I mean the following

1. Better source editor (I spend most of my time writing code not moving buttons a round).
2. Better extensions (I had once to hard code a public key and with out a hex extension I would never found the bug I was having)
3. Better refactoring tools.
4. Better themes and long hours relaxing editor (I spend more than 10 hours a day in front of a monitor).
5. I could easily switch to other languages without changing the editor I'm using (talk productivity here),
6. It never spits an AV when you use code completion (Never could reproduce that bug).
7. And the last one. every one is using this thing and rare are who complained about it (I'm speaking quality).

@Rudy Velthuis I'm 26 Hydrocarbons and chemistry graduate but I'm not a chemist, this is what you can do best in my country Algeria,

I was using c# and c++ for most what I do. The first time I used Delphi 7 I was hooked by the simplicity and power. I created a whole set of components, a crypto library, custom threading component and a very customizable VCL ListView with only asking 20 questions on Stack Overflow (good luck understanding those in c#).

I also want to say that Delphi has opened my eyes about how to code and be good at debugging things, so I really love it.

As for extending the IDE, well you just said it, what I have in VSCode is not an extension to the editor it is already built into it.

@Stefan Glienke I think when coding you use the editor most of the time, every thing else is a feature that saves more time, but if the editor is slowing you down then the rest is just a signal of hope you see time to time. and what I'm suggesting is not an extension, it is a rework to the Delphi IDE on something that proved quality and productivity over time. 

@Darian Miller I did and thank you.

@dummzeuch My concern exactly.

 

 

I would like to say thank you for all of you at Stack Overflow  and here for helping others get to the Delphi world, It is an honor reading what you post.

 

Edited April 27, 2019 by Nasreddine

[AlekXL 8]

@Nasreddine It's not that's difficult to create decent editor. Intellisense/Code Insight -- that's more tricky, but still doable. There are  lots of examples of this. Creating yet another source editor is boring, low hanging fruit

 

But here the catch, the real, cruel truth: it's the  debugger - the thing that makes all the difference.. Do you know many debuggers? Decent ones? Especially for languages which compile to real executable?

Even Delphi IDE native debuggers are horrible on non-windows platforms. If you really want to contribute, you should probably give your effort to tweak existing debugger engines, like LLDB, GDB, Titan for usage with generated-from-Pascal executable -- and especially on android.

Edited April 28, 2019 by AlekXL

[Der schöne Günther 316]

There's not just VSC.

 

Have a look at this:

 

I honestly couldn't care less about the form designer. As horrible as it actually is, it's probably just too much work to completely rewrite it for another environment. Proper debugging capabilities are way more important.

 

[AlekXL 8]

2 hours ago, Der schöne Günther said:

Proper debugging capabilities are way more important

That's it! It's the debugger that makes all the difference. Merlin pants, I'm working on Lazarus project right now, and multi-threaded to boot.

Do you know that there is no way to switch thread while debugging? No even in trunk Lazarus? Neither on Win, nor Linux?

This is show stopper!

--

@Nasreddine Lazarus may look ugly, but it's the only real way to improve things for pascal now. We need to concentrate our efforts on Lazarus. Additionally you can actually write IDE-agnosttic pascal language server -- debugger, code-insight, etc -- and sell it, after creating bindings for Lazarus, VS-code, IDEA, etc..

Edited April 28, 2019 by AlekXL

[Rudy Velthuis 91]

15 hours ago, Nasreddine said:

@David Heffernan I'm in the process of this and it is far better than what the IDE is featuring for now. And by that I mean the following

1. Better source editor (I spend most of my time writing code not moving buttons a round).
2. Better extensions (I had once to hard code a public key and with out a hex extension I would never found the bug I was having)
3. Better refactoring tools.
4. Better themes and long hours relaxing editor (I spend more than 10 hours a day in front of a monitor).
5. I could easily switch to other languages without changing the editor I'm using (talk productivity here),
6. It never spits an AV when you use code completion (Never could reproduce that bug).
7. And the last one. every one is using this thing and rare are who complained about it (I'm speaking quality).

@Rudy Velthuis I'm 26 Hydrocarbons and chemistry graduate but I'm not a chemist, this is what you can do best in my country Algeria,

I was using c# and c++ for most what I do. The first time I used Delphi 7 I was hooked by the simplicity and power. I created a whole set of components, a crypto library, custom threading component and a very customizable VCL ListView with only asking 20 questions on Stack Overflow (good luck understanding those in c#).

I also want to say that Delphi has opened my eyes about how to code and be good at debugging things, so I really love it.

As for extending the IDE, well you just said it, what I have in VSCode is not an extension to the editor it is already built into it.

@Stefan Glienke I think when coding you use the editor most of the time, every thing else is a feature that saves more time, but if the editor is slowing you down then the rest is just a signal of hope you see time to time. and what I'm suggesting is not an extension, it is a rework to the Delphi IDE on something that proved quality and productivity over time. 

@Darian Miller I did and thank you.

@dummzeuch My concern exactly.

 

 

I would like to say thank you for all of you at Stack Overflow  and here for helping others get to the Delphi world, It is an honor reading what you post.

 

Most of the time you write code. But sometimes you do need a form designer, and if you don't have it, things get very, very tedious. If you want to code FMX, this gets even worse.

 

I may be biased, because I have been using it since Delphi 1 was released, but IMO, the code editor is fine. I have used many many other editors, on different platforms (DOS, OS/2, Windows, macOS, Linux), but I don't think they are much better. Especially the Delphi editor is the best to search code, to search implementation and everything else that only can be done with a dedicated editor. Other editors may have some niceties, but in my experience, they don't weigh up against the many conveniences a dedicated editor provides.

 

I don't care about themes or languages like python or JavaScript in the Delphi editor.

 

And the dedicated debugger in the Delphi IDE beats all others.

[Leif Uneus 43]

• The code editor works for me. I still use the Wordstar keyboard shortcuts as I did in the beginning of the 80s, programming in CP/M and then the MS-DOS environment. I turn off code completion, since that slows down typing and disrupts my intention more that it helps. My fingers do the typing, while I can concentrate on the code.
• The form designer is ok for layout. But there is one big shortcoming with how it lures a novice programmer to make a mess of separating the GUI from business logic. I wish a more sophisticated default scheme would be introduced to handle that.
• The error insight function is best turned off as well, since it introduces more doubts than it really helps.
• Comparing code is easy with the Beyond Compare plugin.
• The integration with different types of code repositories could be better. 
• The debugger is fine and with the use of FastMM memory leaks are easy to find and remove. 

The biggest concern for me is not the state of the IDE. Every new version introduces errors in the compilers and the RTL. Using a new version in a 24/7 application is out of the question. 

I wish all Embarcaderos efforts could focus on bringing out quality compilers comparable with industry standard C++ compilers and a RTL that can be trusted. 

 

 

[Lars Fosdal 1791]

Totally agree on the lure of RAD UI design and how it causes newbies to write code that is both relying on states in the UI as well as in their business model, instead of the UI reflecting states from the internal model and delivering changes to that model.

As far as possible, I try to write my code without a UI, and I try to make the interfacing between the internal business logic and the UI as simple as possible, with the UI as far as possible being oblivious about why its values and settings are what they are. I often have separate reusable classes as glue between the UI and the biz objects, so that they remain isolated.

 

The debugger is not fine when you venture past 32-bit single UI thread.

The 64-bit Delphi debugger leaves so much to be desired, that it is better to do the debugging in a 32-bit version of the app.

Multi-threaded debugging - combined with anonymous methods - often causes also the 32-bit debugger to stop working - such as not resuming after a break, or no longer breaking where it was supposed to.

Debugging code that runs multiple identical threads is a challenge as there is no simple way to specify that you only want to debug a specific thread instance.

 

[dummzeuch 1505]

2 hours ago, Lars Fosdal said:

Totally agree on the lure of RAD UI design and how it causes newbies to write code that is both relying on states in the UI as well as in their business model, instead of the UI reflecting states from the internal model and delivering changes to that model.

And then there are the small tools, that are (planned to be) used only for a special problem and then probably never again. It's OK, if you tightly couple UI and business logic if it makes writing them faster (true RAD).

Unfortunately some of these tend to live longer than expected and functionality tends to be added later, which would require a redesign. But of course that never happens, because "it works as it is" and the new functionality is "just a very simple addition".

Edited April 29, 2019 by dummzeuch

[Jacek Laskowski 57]

4 hours ago, Lars Fosdal said:

Debugging code that runs multiple identical threads is a challenge as there is no simple way to specify that you only want to debug a specific thread instance. 

You can freeze all threads except the debug thread (in Threads window).

[Georgge Bakh 29]

Yes, when someone from "outer world" comes to Delphi ecosystem IDE is the first thing to be discouraged with.

Because there are many serious problems indeed.

It's a good idea to take an existing high quality and extensible IDE and use it as a base for new Pascal IDE.

I think it's much better than try to extend Delphi IDE with plugins.

The base platform should be designed with many things in mind: indexing, threading, data integrity, real time code analysis, cross platform to name a few.

UI is also an important (and often underestimated!) part.

On the other side I see no reason to recreate a form designer. It's good enough in Delphi (or Lazarus).

What's about a language server - it's good to have to bring Pascal support to many editors at once, but it's not a way for first-class IDE.

[Rudy Velthuis 91]

On 4/29/2019 at 12:45 AM, Leif Uneus said:

I still use the Wordstar keyboard shortcuts

Like the late  Ed Mulroy (TeamB) once wrote:

Quote

Bible, Dijkstra 5:15
"and the clueless shall spend their time reinventing the wheel
 while the elite merely use the Wordstar key mappings"

 

Edited May 2, 2019 by Rudy Velthuis

[Nasreddine 2]

@Rudy Velthuis Elites reinvent the wheel when the wheel stops rolling.

Clueless become elites when the wheel don't hold them back from solving problems (currently it is slowing them down)  

[vhanla 2]

I just wish Vim mode support. I found one "extension" but it is very slow.

[Rudy Velthuis 91]

On 5/3/2019 at 4:42 PM, Nasreddine said:

@Rudy Velthuis Elites reinvent the wheel when the wheel stops rolling.

Clueless become elites when the wheel don't hold them back from solving problems (currently it is slowing them down)  

I very much doubt the Wordstar key bindings hold you back.

 

And when wheels stop rolling, you don't reinvent the wheel. That's plain silly. You clear the way so the wheels are free to roll again.

[Rudy Velthuis 91]

2 hours ago, vhanla said:

I just wish Vim mode support. I found one "extension" but it is very slow.

Slow? Keybindings are not slow. Or do you mean a little more than just keybindings?

 

The entire (new, themed) IDE is slow. It constantly redraws and needs ages to do simple things like showing the options dialog.

[Nasreddine 2]

@Rudy Velthuis You completely missed the point of my post. I meant the IDE not the WordStar key bindings. in the SO post I linked your comment to the asker was that he should wait for the next major release (Isn't this holding back the wheel).

 

I really like the language but that IDE kills it.

[Rudy Velthuis 91]

1 hour ago, Nasreddine said:

@Rudy Velthuis You completely missed the point of my post. I meant the IDE not the WordStar key bindings.

 

Then you should not have replied to a message purely about (the superiority of) the Wordstar keybindings.

 

Actually, the current Rio IDE is terribly slow. Previous IDEs, especially Tokyo, were fine. Not with every gimmick some other IDEs provide, but very usable.

 

Actually, on my system, VS is terribly slow too, perhaps even slower than Rio, but certainly slower than Tokyo or Berlin. Had some C# code to try out and it took ages before I could do anything.

Edited May 5, 2019 by Rudy Velthuis

[Nasreddine 2]

@Rudy Velthuis You are right the VS loading time is terribly slow. but I think If Embarcadero continues like this, we will not only have to deal with an IDE that lacks "good gimmicks" but also a very slow one too.

 

If they Continue down this road, they will make it easier to dump the IDE than trying to fix any thing anymore.  

Edited May 6, 2019 by Nasreddine