[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Review Request: Use blanks, escaped char, inline comme

From: Darcy Shen
Subject: Re: [Texmacs-dev] Review Request: Use blanks, escaped char, inline comment and number to simplify code
Date: Mon, 6 Jan 2020 00:44:05 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1

Hi Darcy,

First of all, a very happy new year!

Thanks for your parsing patch. It seems like a good idea indeed to
have a more systematic way to parse programming languages.
I quickly went through your code and noticed a few things:

- You often use the list<...> template when you really should be
using the array<...> template (which is more efficient for arrays ;^)

- You may simplify some lines such as

+ if (blanks_parser.parse (s, pos)) {
+ break;
+ }


+ if (blanks_parser.parse (s, pos)) break;

As a general rule, I am happy to see that you adhered quite well to
my coding style. This makes it much easier for me to read your code ;^)

I will improve the code later.

Do you want me to apply the patch before version 2.1, or do you prefer
me to wait a bit? I just got good news from my employer that I will
be allowed to auto-edit my book on TeXmacs. I still have to go through
some legal business, but TeXmacs 2.1 is definitely approaching fast now.

Sorry, I have committed the patch.  Well, I thought I waited a week but did not

notice that 2020/01/01 is Wednesday.

Good news for your book on TeXmacs!

For TeXmacs 2.1, is TeXmacs 2.1 right after TeXmacs 1.99.12?

One other thing that we have to address at a certain point is coloring schemes. There is quite a lot of ad hoc coloring going on in TeXmacs (syntax highlighting, but also the color of the cursor, selections, the surroundings of the window, etc.). It would be nice to make all this stylable and make it part of the infra-structure
for themes that I have been starting to design.

Good idea!

Currently, I am still busy on improving the code base of the current xxx_language.cpp.

Find the common routines and do some abstractions. I submitted the issue for a long

time: https://savannah.gnu.org/bugs/?54888

Finally, there will be no xxx_language.cpp, we wrote the base parsers in cpp and combines

the parsing components in scheme. To support a new language, we only need to write a new

scheme file.

I have a vague roadmap in my mind, but the destination is clear.

Best wishes, --Joris

Texmacs-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]