Glenn Dufke

Just now, Jonah Jeleniewski said:

You should write a blog post on how you architected your tool

Don't worry, there will be lots of documentation.
- And I might even be generous enough to open source it.

I would, however, strongly recommend rewriting pasfmt in a more sane language sooner rather than later.
 

Just now, Jonah Jeleniewski said:

While not aligned with the goals of this project, that's an interesting concept.

Can't say I'm aware of any well-known formatting tools that operates in such a way, though.

Well, it's an interesting concept because I created one in my formatter engine which is multi language and support mixed source documents among other cool features.
- And it is high performance without using rust 🙃

47 minutes ago, Vincent Parrett said:

I don't want to be littering my code with //formatting off/on etc.

What you want in a formatter is a simple DSL where you can express your desired formatting style and the formatter uses this as the basis..
I'm glad you asked...

17 hours ago, Joshua Gardner said:

We hope that you enjoy pasfmt, let us know what you think!

Great idea crumbled by rust.

There are other languages which would have been more appropriate to use for the implementation and would make contributions easier.
Sad.

And to expand on that:
When picking an implementation language, besides evaluating what solves the problem at hand, you also have to consider target community and who are going to deal with it down the line - especially for open source projects and that weighs higher than one's favorite language.
Rust has a toxic community, an ecosystem mess akin to npm and overall just a poorly designed language with unnecessary complexity driven up by hype. (I know this from first hand experience of having to deal with rust projects before and digging inside the rust compiler)

While some have drunk the rust kool-aid, I'd rather have seen Modern Object Pascal used or, if you want to be fancy, Zig.

There are good reasons why many prominent projects are abandoning rust.

55 minutes ago, cupboy said:

I did send an email to renewals@idera.com but no response so far.

That's not the correct place to contact.

Now, when you have an active update subscription - besides always having access to the latest Delphi releases which is important nowadays - getting registration bumps is pretty straight forward and resolved quickly through support.

When your active update subscription is expired, which it is in your case according to your initial post, you would have to contact your reseller (If you got your license through that in your home country) or Embarcadero sales directly to get the license bumped.
They might offer you a renewal or new license depending on your status, but it isn't a requirement, you can decline the offer and just request a license bump.
https://www.embarcadero.com/company/contact-sales

As it is a perpetual license, you can keep continuing using that version.

You can manually check your registration limit yourself if you need to reinstall in the future.
I wrote a guide here: https://docs.code-kungfu.com/books/licensing-and-registration/page/how-to-check-your-registration-limit

Hope it helps.

7 hours ago, msohn said:

Since your post actually made me start doing a Delphi binding,

I've already made a full binding of the APIs. It isn't published yet, as it is part of my formatter and syntax highlighter product I'm building for Delphi (and C++Builder)

 

On 3/16/2024 at 3:55 PM, Dave Millington (personal) said:

I have lots of questions - things like, are you using the editor painting API to paint?

The current editor highlighter toolsapi interface is limited.
To get the full benefits of the syntax highlighting data tree-sitter can deliver, complete takeover of the editor painting is necessary.

7 hours ago, msohn said:

And I've noticed that tree-sitter-pascal in its current form could not handle some sources I threw at it

The grammar for the pascal parser needs an update indeed.

1 minute ago, softtouch said:

Thats it! It works now! Thanks.

You're welcome 🙂

1 hour ago, Fred Ahrens said:

This looks like a rounding problem in the function that calculates the toolbar sections.

As a workaround you can try to move each section of the toolbar to the right while leaving gaps with some pixels width between all sections. This should avoid the overlapping of sections due to the calculation error and prevent moving toolbar sections to the next free line on the toolbar.
(not tested just guessed)

To fix the incorrectly positioned toolbar, do the following:

• Close the IDE
• Open registry editor
• Navigate to HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0
• Delete the Toolbar node
• Start the IDE again and it is now reset to default position and scaling.