On 01.03.2010 16:59, Mart Frauenlob wrote:
> On 01.03.2010 12:06, Mart Frauenlob wrote:
>> On 28.02.2010 09:29, Mart Frauenlob wrote:
>
>>> after I upgraded from etch to lenny a few days ago (new config files
>>> have been installed for vim), I noticed that syntax highlighting for my
>>> bash scripts is not working as before.
>>>
>>> There are some things i've noticed, where of the first is worse to me.
>>>
>>> 1: If I put the following statement onto a single line, it does not
>>> cause problems:
>>> RESULT_ARR[IDX++]="[$((m_count++))]=\"${str_attr_name}[$((opt_idx++))]=\\\"${tmp_content}\\\"\""
>>>
>>> But as soon as i put it into a for loop:
>>>
>>> for tmp_content in ${str_attr_val}; do
>>>
>>> RESULT_ARR[IDX++]="[$((m_count++))]=\"${str_attr_name}[$((opt_idx++))]=\\\"${tmp_content}\\\"\""
>>> done
>>>
>>> Everything from the 'done' word is marked with as syntax error, making
>>> the whole file unreadable (could turn of syntax highlighting).
>>>
>>>
>>> 2:
>>> if [[ $1 = +([[:digit:]]) ]]; then
>>> ...
>>> fi
>>>
>>> is good, but with:
>>>
>>> case "$1" in
>>> +([[:digit:]])) :
>>> ;;
>>> esac
>>>
>>> the last 2 `]]' are shown in red background (syntax error).
>>>
>>> 3: This one causes everything after the `'' (single quote) to be
>>> rendered as error:
>>> [[ $x = *\'* ]] && ...
>>>
>>>
>>> this is my .vimrc:
>>>
>>> set ts=4
>>> set sw=4
>>> let g:is_bash= 1
>>> let sh_minlines= 500
>>>
>>> Any ideas how I could get that fixed?
>>> Many of my scripts are garbled now. they are more readable without
>>> syntax highlighting.
>
>>
>> I've tried to look up this problem with vim syntax highlighting a bit more.
>> It seems to me that escaping (single|double quotes?) in any loop
>> statement does not work.
>> So I've to correct my first report, those escaping problems lead to the
>> result, that all following code is formatted as it was inside quotes
>> (not rendered as error, like the [[:digit:]] string).
>>
>> So this one:
>> for tmp_content in ${str_attr_val}; do
>>
>> RESULT_ARR[IDX++]="[$((m_count++))]=\"${str_attr_name}[$((opt_idx++))]=\\\"${tmp_content}\\\"\""
>> done
>> needs a `"' (double quote) added, to become valid for vim (while
>> becoming invalid in case of shell syntax).
>> Same thing inside an if statement:
>> if true; then
>>
>> RESULT_ARR[IDX++]="[$((m_count++))]=\"${str_attr_name}[$((opt_idx++))]=\\\"${tmp_content}\\\"\""
>> fi
>> while inside a case statement it remains rendered valid.
>>
>> And this one:
>> [[ $x = *\'* ]] &&
>> needs `' ]]' to become valid for vim.
>>
>> I guess that could be fixed by modifying
>> /usr/share/vim/vim71/syntax/sh.vim - but I'm lost on how to.
>> It all worked out of the box on sarge and etch.
>> Most of the work I do on linux is write bash scripts with vim. This is
>> now messed up since the upgrade to lenny.
>> Any hints? Please anyone?
>
>
> Trimming it down more:
> var[0]="\"foo bar\"" is valid on a line for itself.
>
> But:
> if true; then
> echo "\"foo\""
> var="\"foo bar\""
> var[0]="\"foo bar\""
> fi
>
> the 'echo' and the 'var=' escape well, but the 'var[0]=' array member
> assignment fails.
Hello,
though I'm mainly talking to myself here, I got some updates.
I manually compiled/installed the vim versions 6.4, 7.0, 7.1 and 7.2.
Running version 6.4 and 7.0 with a slightly modified vimrc from the etch
version (vimrc.dpkg-old) (leaving out some debian specific things), I
get back the bash script syntax highlighting I was used to in sarge and
etch.
However vim versions 7.1 and 7.2 seem to have changed. I get different
results with both. I don't know if this is caused by the sh.vim or the
actual vim code, but however it does not seem to be a debian specific
problem, as far as I can tell.
Guess I need to find the time to talk to the people in the vim mailing list.
Good day
Mart
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b8d5790.6070...@chello.at
