Thoughts on the Codepad

[5cript]

I didn't formulate a pull request for the specs, because I would love to hear other peoples opinions on this.

• Code highlighting is a very non trivial thing since its tightly coupled to the language. They way its implemented should be a simple but powerful interface where the individual language highlighting implementations are attached to, so that contributing highlighters is easier. This way highlighting support may grow over time (eg. multiple languages, swapping the highlighter implementation for individual file extensions)
  • Potential "Highlightables": keywords, literals, string literals, comments, macros, user defined identifiers (like user macros).
• Highlighting for searches.

I suggest to pass the code parsing to an interface (maybe the same as the highlighting) too to provide tokens (maybe more) which can then be used for editor features like highlighting.

To suggest more concrete ideas, I would need to try and implement everything myself to see where issues and complications with these ideas arrise.

Less necessary features:

• Indentation Guides?
• Multi Carret Editing?
• Code folding?

[cnjinhao]

Thanks for your suggesions! To avoid complexity of intial work, I only focus on C++ and write straightforward code to support C++ languages at earlier stage. However, the extension of multi-language support will always be considered during the development.

IMO, we should design a complete dynamic analyzer, it's a foundation of highlighting(keywords and user-defined identifiers), auto-complete and syntax error.

[5cript]

IMO, we should design a complete dynamic analyzer, it's a foundation of highlighting(keywords and user-defined identifiers), auto-complete and syntax error.

I guess what I try to "plea" is, that decoupling this from the visual part (rendering) and plugging them together via interfaces (or techniques that do the same thing) would benefit future contributions, if the IDE lands on github at some point in the future.
Having to figure out how the entire codepad component works, how it renders and all the nooks and crannies can become overwhelming (which is probably why the nana textbox component issue that wishes for better highlighting hasn't been touched by contributors, even though people said they would).

[5cript]

Oh and please dont try to parse and analyze C++ yourself.
The language develops so fast and is probably the hardest language of the world to analyze by far.
Plugging an existing backend into it bumps it immediately to modern capabilities. clang for instances provides AST output.

A lot of IDEs are failed garbage because they captitulate early, rendering the code completion part etc worthless or even potentially obstructive, since some IDEs lock up, because parsing and analysis takes forever, forcing you to disable them.

[I started my own IDE with nana a year+ ago for fun and to learn nana. I hence made some research into certain things and thought about overall project structure and design. Only reason its not "done" is the editor component, which is a prerequisite to tie the debugger and code help to it. I would have to write my own, which turns me off of the project, because to me this is where success or failure is decided over usability and maintainability. (And how the IDE handles builds, but thats a different topic)]

[qPCR4vir]

Sorry, I will just copy/paste myself:
Probable major advantages of Kunlun: small and fast. Also: portable and flexible, with "native" support for clang and gcc (it is possible to use VC++ too?) in windows and linux and prefereably macs too. The way to achieve this is to transparently use external tools, absolutely independently installed by users in the normal way they do following the standard instructions of the original "vendors". And Kunlun just take a reference to them with some preferences the user sets.
As you see people immediately want a lot of very advanced features, like code completion and refactoring: use clang tools. (but in a few years this will need to be AI...)
No matter how ugly cmake is, but the new projects today, need to be just cmake - I don't see any option here. No new syntax not supported by cmake and all the other tools for packing. A new sintax for the project may be a completally separated project, based in cpp modules.
Repeating what Code::Blocks and CodeLite are, will end with the same problems.

[cnjinhao]

absolutely independently installed by users in the normal way they do following the standard instructions of the original "vendors"

It sounds good, but it is a bit complicated. IMO, it will confuse user with project build options when switching a different compiler.

but in a few years this will need to be AI...

I simply thought about the machine learning, but I didn't get a picture how to use ML in this area.

Just repeating what Code::Blocks and CodeLite do is not interesting and will end with the same problems.

Good point.

[qPCR4vir]

It sounds good, but it is a bit complicated. IMO, it will confuse user with project build options when switching a different compiler.

that is why cmake is good as project. See Clion and VS, both using cmake.
But you can distribute the IDE with all options with a default values defined, so that it works inmediately with the combination you recomend.

[5cript]

When we're on this topic now anyway: The way i did it is: I use cmake for projects, and profiles for the environment variables. This way my IDE does not get confused by poluted PATH and does not require installations to be made in certain ways.
I can then switch effortlessly between an msys environment and a vc environment etc. cmake takes the environment (execve) and the - G option and does the rest of the work.

EDIT: I obviously use a library for processes (tiny-process-library) and not syscalls directly for portability. The execve remark was just there to explain what i mean when i say "pass cmake an environment".

[5cript]

[moved]