The Hammer

Hi Todd,

Actually you have commit access, not sure if you remember your password.

But I think it might be better to did what you did today, just attach the files you changed and I'll commit on your behalf (using your account).
That's what I did with your patch earlier today, I'll use the bug descriptions in the commit descriptions.

We like the new editor too. There's a quite a bit more that can be done and that has to be done over time.
But it is already pretty great and with the new GUI and features it is a vast improvement over TheHammer 2.0

I love small contributions :)

There are several editor related features that are in the DF Studio that I don't see here. I know, it all takes time and effort.

I'd like like to start logging these as "Features" to implement. I will put each as "low" priority, unless I REALLY want it. LOL. You can adjust priority as you see fit.

I will even try to handle as many as I can. I have no knowledge of the inner workings of the new editor, but I'm willing to learn.

Well if you were familiar with the old editor then you can do most as the programming interface is mostly the same.
So you can port your old codemax patches to the new hammer really quickly.

That API will change once we completely drop codemax support (if that ever happens, our decision on that is not final yet, although I tend to think yes, remove in one of the next version and clean up).

Note that we are not aiming to be another Studio, but yes there's a number of functions in the Studio that I still miss myself too.

Here's what's on the list for 3.0 (quick list, I do forget to include most as usual)
- Print (C++)
- Copy as RTF (C++)
- Include more languages to support (easy)
- Fix bugs

Then for a later version (3.1?)
- Add support for macro recording
- Add editor split screen
..
not sure what version
- Merge VdfSplat into the Hammer, so that we have a debugger
- Go To Definition (needs full source parser)

Just top of my memory, there's so much more that we can and want to do.

But yes please, use the features/suggestion functionality, at least then we can consider it and think about how-to implement.

I have a basic knowledge of the codemax editor... Although a bit rusty since I have not used it in a LONG time.

The thing I really like about The Hammer is NOT as a replacement for the Studio as you said (I agree), but that if I want to build a feature into it for my own needs, I can do it. That is very COOL!

To be honest I have not used the The Hammer for about 8 years... Before that I really did use it a lot. I am gonna change my ways. I do a lot of class level programming were the visual modeling of DF Studio is not needed. For these tasks, I will start to use The Hammer again.

FYI: The one of the first editor items I noticed, that I missed also was: Click on a "Begin", and then see the "End" (highlighted) associated with that "Begin"

Todd Forsberg wrote:

I have a basic knowledge of the codemax editor... Although a bit rusty since I have not used it in a LONG time.

You can still use that knowledge.
If you want to do something scintilla specific or use one of its features then look at their documentation here:

http://www.scintilla.org/ScintillaDoc.html

The thing I really like about The Hammer is NOT as a replacement for the Studio as you said (I agree), but that if I want to build a feature into it for my own needs, I can do it. That is very COOL!

Yes there's more people who did that and it does indeed allow you to do some very nice things.

FYI: The one of the first editor items I noticed, that I missed also was: Click on a "Begin", and then see the "End" (highlighted) associated with that "Begin"

Correct, please log.

There's brace matching on ( ) but not on begin/end. I have not looked at how difficult that would be to implement that part.
One thing that will make this easier to implement is that the lexer already identifies begin/end and you can ask the lexer for that, these words are identified as

SCE_DF_SCOPEWORD

We also use this feature for text adjust so that we do not have to parse the line again by hand, just check the type of the word under the cursor and if it matches then verify if the word is "begin" or "end".
In my attached screenshot you can see a custom theme where scope keywords are set to be painted bold, as you see begin/end is part of that.

edit: The Adjust Text case logic is found in method doNormalizeCase in cSciLexer.pkg

In in the source code I see some of the code is indented by 2 spaces and in other places it is indented by 4 spaces.

What is your preference?

Actually you have commit access, not sure if you remember your password.
No. I don't recall the password, but that is fine for now.

But I think it might be better to did what you did today, just attach the files you changed and I'll commit on your behalf (using your account).
That's what I did with your patch earlier today, I'll use the bug descriptions in the commit descriptions.
Ya, I'll just attach my code changes to the issue. This will work fine for small contributions. If I start doing larger changes then I'd probably ask you for that password and create a branch for my work. This way you can still review it before the changes go into the mainline repo.

I love small contributions :)
Me too! Great things come in small packages. LOL.

Todd Forsberg wrote:

In in the source code I see some of the code is indented by 2 spaces and in other places it is indented by 4 spaces.

What is your preference?

This is a bit of a personal thing and a religious subject for many.

My personal preference is 2 spaces and that's because I use screens on a relatively low screen resolution.
This way I get to better overview code that has a few nesting levels without having to scroll the text horizontally.
So the preference for me is based on practical reasons. Shorter text also improves readability for me.
Of course with a lot of nesting it is probably better to break out the functionality into a new function to improve readability.

I'm not really of the opinion to force a particular coding style for contributions.
Although I do have my preferences and might rework submission so that it matches the rest of the code.
Usually however I accept the suggestion of others, as long as it is a bit in balance with the rest of the code.
I will not just edit a file to match a preferred coding style as that creates a lot of source code control noise in the code with little or no benefit.
When code is already touched because it needs a patch or fix then I might also adjust the style.