Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Generalizing programming language patterns in CodeBlocks
beqroson:
If I create a tool based on a variant of UTF-8, that I call UTF-82. The only thing that differs between UTF-8 and UTF-82 is that the forbidden byte sequences C0-C1, F9-FF are accepted in the string. In order to scan and display an UTF-82 string is to just ignore those byte sequences. Would you include UTF-82 as a file format in CodeBlocks? That would be very helpful.
Update: Or, if I am supposed to include it myself? If I post patches, would you accept me doing this and have it added? Or is this the task of someone else? I do not know what rules apply here.
dmoore:
As a native english speaker, it's hard for me to judge how much of an impediment not being able to work in ones native language is. I guess it must be some, but it's not like English == C++, and sometimes the English names for programming constructs are actually misleading (e.g. "Cookie").
It's not clear that modifying the IDE itself is the best way to achieve what you want. If I am reading correctly, I think what you have in mind is sort of a pre-processor that converts the users native language source to language that the compiler understands ("program langauge") using a dictionary that maps native "words" to their compile-able equivalent. You also need to be able to convert the compiler messages back to their native language equivalents. At least from the compiler perspective, the best way to do this might be a command line tool that wraps around the GCC toolchain that handles the necessary conversions. You could then add support for this in Code::Blocks (or any other IDE that has flexible build system) by calling your commandline tool instead of the regular GCC toolchain.
On the other hand, allowing the user to use their native language for code completion (and other things like class and project wizards) would require very significant changes to the IDE. The CC parser would need to convert the native language to program language when parsing, and tokens would need to be converted from program language to native language for display in the UI.
beqroson:
--- Quote from: dmoore on November 10, 2013, 08:33:13 pm ---As a native english speaker, it's hard for me to judge how much of an impediment not being able to work in ones native language is. I guess it must be some, but it's not like English == C++, and sometimes the English names for programming constructs are actually misleading (e.g. "Cookie").
--- End quote ---
The effect is not noticeable at first. After years of programming, at least for me, it was bugging me increasingly. Even though I am quite fluent in the English language, that still bugged the crap out of me. Maybe I am sensitive. But there are more than just the comfort in it. If you think about how many times you use each syntactic term in C++ when programming. Maybe you print in the term "if" thousands of times each project. The effect adds up. Even so if I would be using my native language, the equivalent "om" in Swedish, that would eventually bug the crap out of me as well. But with a translator, I can switch between two or more variants of that. Now, the most important thing is of course to have the first term in the native language. I also notice that when I use "if", I would prefer writing the comments in English. When I switch to "om", my mind prefer writing the comment in Swedish (my native language). This is because the lowest level of terms, such as "if" would be hard coded in my mind after years of use, and that switches over my mind to its respective language. Each switch to another language takes an additional toll on the mind. (Not huge, but enough to make the mind outside of the comfort zone). So, this is not just an idea. My whole mind actually crave to be able to write in my native language, such as coding. I could get by continue to use the "normal" English terms. But I would be disappointed and less vital in my work.
--- Quote from: dmoore on November 10, 2013, 08:33:13 pm ---It's not clear that modifying the IDE itself is the best way to achieve what you want. If I am reading correctly, I think what you have in mind is sort of a pre-processor that converts the users native language source to language that the compiler understands ("program langauge") using a dictionary that maps native "words" to their compile-able equivalent. You also need to be able to convert the compiler messages back to their native language equivalents. At least from the compiler perspective, the best way to do this might be a command line tool that wraps around the GCC toolchain that handles the necessary conversions. You could then add support for this in Code::Blocks (or any other IDE that has flexible build system) by calling your commandline tool instead of the regular GCC toolchain.
--- End quote ---
A such wrapper may indeed be the best way to do it. If it is decided that such is the way to go, then I will do it. The problem may be that I need to write one such tool wrapper for each compiler. That can get nasty considering how variants of MinGW, MinGW64, and now TDM keeps emerging.
--- Quote from: dmoore on November 10, 2013, 08:33:13 pm ---On the other hand, allowing the user to use their native language for code completion (and other things like class and project wizards) would require very significant changes to the IDE. The CC parser would need to convert the native language to program language when parsing, and tokens would need to be converted from program language to native language for display in the UI.
--- End quote ---
I was kind of hoping that there would be a solution that would not require huge changes to the IDE. Actually, I am already running a command line tool for all my programming tasks that already translates the code. And this works. Also it works for debugging.
The reason that I still am bugging you over this are first, I like to make this available to everyone as an option in the world of programming. Also, an additional bonus would be if the code completion would work with this, but for me personally, that is not necessary. I get by without the full code completion.
At least, I do not want to place any burden on you folks, so I hope a simple solution is possible without too much effort. That is why this needs to be discussed, so we can figure out if there is a solution that simple enough to implement in CodeBlocks. I think it could be a good reputation for CodeBlocks if it could brag about this feature. I am not sure, just intuitively I think it would be a winning concept.
beqroson:
--- Quote from: beqroson on November 10, 2013, 07:43:33 pm ---If I create a tool based on a variant of UTF-8, that I call UTF-82. The only thing that differs between UTF-8 and UTF-82 is that the forbidden byte sequences C0-C1, F9-FF are accepted in the string. In order to scan and display an UTF-82 string is to just ignore those byte sequences. Would you include UTF-82 as a file format in CodeBlocks? That would be very helpful.
Update: Or, if I am supposed to include it myself? If I post patches, would you accept me doing this and have it added? Or is this the task of someone else? I do not know what rules apply here.
--- End quote ---
I am working on designing the console application to use xml files. Later on, when creating the plugin, the code can just be copied over, I hope. But there is a design issue that I am pondering. And that is whether to at all try to use the UTF82 for this. The good thing with UTF82 is that one can include control strings embedded in the string. Instead of creating a document format, the UTF82 could provide a standardized way of creating your own document format, but with the ground structure already in place such as the encoding of UTF. The down side would be the hassle to implement the possibility to open any UTF82 document for example in CodeBlocks. It would make a totally different IDE, but for what purpuse, just to add the translation capability. Hardly worth the effort. Then again, in order to get such a versatile translation mechanism, UTF82 looks like a creamy cake to me. What do you think, should I ignore worldly facts and implement it as UTF82?
stahta01:
Code::Blocks uses a very slightly modified version of tinyXML in the CB SVN path of src/base/tinyxml
If UTF82 is NOT supported by tinyXML, you would have to write your own way of reading/writing XML.
Or, submit patches and have them accepted at tinyXML.
Edit2: The above is based on the idea you are making a CB Plugin or might in the future.
Edit: Have you ever built CB from SVN source? If not, I suggest doing so.
Tim S.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version