Kein-Hong Man

If you can understand how bash is parsing the backslashes, that is half the battle won. I got hopelessly stuck with command strings a few years ago. Glad the bash people have fixed some things. Remember also to check their behaviour inside nested levels of delimiters. Presumably, backslash handling will change depending on what the inner delimiter is. If everything is predictable, then a general implementation is possible -- which would be great, yay! :-) I don't have a github account, so I'll just...

For my old bash 3.1.23, N=2,6,10 failed. The others seems to be the same. On the old bash, backslash processing may have been working inconsistently with (nested) delimiter processing. The result of that was haywire and the test results were nothing I could understand. I tried looking at it a bit just now and couldn't figure out what went wrong with N=2,6,10 on the old bash. So old bash is should be regarded as deprecated. Newer bash seems to be working much better, good to know that. This scheme...

Hi Zufu, Neil. If anyone wants to update the bash/shell lexer, feel free to do so. I can't realistically work on the lexers I hack anymore... unless I find an enormous chunk of free time. Non-coding things get in the way. C++ used to be small(ish) and easier to code, but these days it's hard to keep abreast of things. I read one of Stroustrup's very long, talky books and thought -- I can only keep up with this if coding C++ is my only pasttime. Not gonna happen. The problem with bash is that its...

It's not a huge bug but it can be fixed after checking and verifying bash and zsh behaviour. I'm busy these days so anyone out there please feel free to tackle it. I can confirm that bash handles comment lines in its own function, thus bypassing line continuation processing. I took a look at bash-5.0 sources, in parse.y [3268], in read_token (command), if the '#' char is found, then it performs discard_until ('\n'); which is a simple function that zaps everything until the newline. Ray, there are...

I have updated my files to hg HEAD and tested it, works fine, thanks!

Thanks for taking a look. [[ ]] nesting (and folding) for both SCE_LUA_LITERALSTRING and SCE_LUA_COMMENT can be removed or disabled. The syntax was only present in Lua 5.0, I believe. From Lua 5.1 onwards, [==[ ]==] can be used so nesting was more like a failed experiment. I did not ever recall reading of anyone complaining that their nested [[ ]] failed when folks moved from Lua 5.0 to Lua 5.1, so the probability of anyone still relying on nested [[ ]] today is pretty miniscule. I think disabling...

My bad, heh. I have non-coding stuff that is taking all my free time, so I am quite behind on the curve these days. Here is the explanation for the issue: The incorrect highlighting is due to my attempt at supporting multiple Lua versions. Specifically, nested -[[ ]] long comments. Since that is long ago in the past, I guess nested [[ ]] should be removed. Will users care enough that it should be made an option? Perhaps not. If I am working on a patch, I'll ping here.

Here is a recent discussion at the Help-Bash list where Chet Ramey reminded folks that $(< has command semantics, and should not be regarded as an operator: https://lists.gnu.org/archive/html/help-bash/2019-09/msg00002.html The bash refman also supports this view. Look where the $() is described. IMHO anyone who actually needs highlighting inside a $() is doing it wrong. You are not supposed to write tens of lines of code in what you suppose is a syntax structure. It's a command string. IMHO the...