Re: C syntax problem with C99 initializers.
On 19/03/2007 17:39, David Brown wrote:
Martin Krischik wrote:
Am Montag 19 März 2007 schrieb David Brown:
A macro like this:
#define FOO ((fooy) { field: 4 })
Whenever I thougth I saw it all C comes with another suprise. What
the heck is this good for?
It is a constant structure, useful, in this case, as a macro to
indicate a constant value. The "field:" thing is gcc, the proper C99
syntax is:
{ .field = 4 }
But what is confusing vim is the braces inside of the parens. As Bram
mentioned in another email, this can be disabled, but it makes vim not
able to detect unclosed parens.
Have you tried the alternate C syntax highlight file here?
http://www.vim.org/scripts/script.php?script_id=234
TTFN
Mike
--
At least the doctors find me fascinating.
Re: vim via console in eclipse
Hi Asim Imdad, you wrote: > Hi, > There is one idea to use eclipse console class and extend to > incorporate vim into it. > It is defined in org.eclipse.ui.console. I am currently looking into > details related to this. > There will be no rewriting of code for eclipse and original can be used. > > Asim Imdad This console class emulates only stdout, stderr and stdin. I believe VIM needs much more. Basically, Eclipse console is not a terminal emulator. -- Alexei Alexandrov
Re: C syntax problem with C99 initializers.
Martin Krischik wrote:
> Am Montag 19 März 2007 schrieb David Brown:
>> A macro like this:
>>
>> #define FOO ((fooy) { field: 4 })
>
> Whenever I thougth I saw it all C comes with another suprise. What
> the heck is this good for?
It is a constant structure, useful, in this case, as a macro to
indicate a constant value. The "field:" thing is gcc, the proper C99
syntax is:
{ .field = 4 }
But what is confusing vim is the braces inside of the parens. As Bram
mentioned in another email, this can be disabled, but it makes vim not
able to detect unclosed parens.
Dave
Re: C syntax problem with C99 initializers.
Am Montag 19 März 2007 schrieb David Brown:
> A macro like this:
>
> #define FOO ((fooy) { field: 4 })
Whenever I thougth I saw it all C comes with another suprise. What the heck is
this good for?
Martin
--
Martin Krischik
mailto://[EMAIL PROTECTED]
pgpqr1CVAZVlY.pgp
Description: PGP signature
Re: improving encryption in vim
Josh wrote: > The main problem that I see is that adding a strong encryption > function can have regulation issues. That was the only reason that I > thought about using the external library is to get around this. > > How secure does the encryption need to be? As far as I know Blowfish is practicaly unbreakable, fast and has no issues with exporting. It does have a problem with padding, so perhaps there is a better alternative. - Bram -- GUEST:He's killed the best man! SECOND GUEST: (holding a limp WOMAN) He's killed my auntie. FATHER: No, please! This is supposed to be a happy occasion! Let's not bicker and argue about who killed who ... "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\download, build and distribute -- http://www.A-A-P.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: C syntax problem with C99 initializers.
David Brown wrote:
> A macro like this:
>
> #define FOO ((fooy) { field: 4 })
>
> causes vim to highlight the braces (in an angry fashion), and seems to
> cause it consider all of the remaining braces in the file to be in
> error as well.
>
> Any ideas?
Highlighting curly braces inside parenthesis is about the only way to
detect a missing closing parenthesis.
You can disable this with:
:let c_no_curly_error = 1
You won't be able to see missing parenthesis then. Blame C99 to make a
syntax that's hard to check.
--
LAUNCELOT: I am, sir. I am a Knight of King Arthur.
FATHER:'Mm ... very nice castle, Camelot ... very good pig country
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\download, build and distribute -- http://www.A-A-P.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
Re: Understanding regxp implementation
On Mon, Mar 19, 2007 at 01:49:53PM +0100, Nikolai Weibull wrote: > On 1/1/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: > >On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote: > >> On 3/19/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: > >> > Hi Bram, Nicolai, > >> > >> A 'k' would be greatly appreciated. > > > >I'm really really sorry, won't happen again... > > Hehe, don't take it too hard, it happens to me all the time. If I had > a dime for every misspelling of my name, I'd have...more money than I > do now. Now I know, why Bram said in his Google Talk that he even uses ctrl-n completion for names, as it helps not misspelling names :) -- Martin
C syntax problem with C99 initializers.
A macro like this:
#define FOO ((fooy) { field: 4 })
causes vim to highlight the braces (in an angry fashion), and seems to
cause it consider all of the remaining braces in the file to be in
error as well.
Any ideas?
Thanks,
David Brown
Re: improving encryption in vim
There are no patent issues, but there is export issues, I live in the US -- Josh
Re: Understanding regxp implementation
On 1/1/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote: > On 3/19/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: > > Hi Bram, Nicolai, > > A 'k' would be greatly appreciated. I'm really really sorry, won't happen again... Hehe, don't take it too hard, it happens to me all the time. If I had a dime for every misspelling of my name, I'd have...more money than I do now. nikolai
Re: Understanding regxp implementation
On Mon, 2007-03-19 at 11:55 +0100, Nikolai Weibull wrote: > On 3/19/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: > > Hi Bram, Nicolai, > > A 'k' would be greatly appreciated. I'm really really sorry, won't happen again... > > I'm unable to grasp the description ( attachment ) given in the regxp.c > > file. For a moment they seem like NFA fragments for operators |,+,* > > Well, yes, that's what they are. The diagrams show you how the > different operators are represented. I think the representation can > be a bit difficult to grasp at first, because the representation isn't > like a state diagram/tree/DAG, but more of a list of assembler > instructions.These assembler-like instructions are then executed > by an interpreter that executes the appropriate C code for doing the > matching. This is (mainly) done in regmatch(). Thanks a bunch, I was completely lost... - Asiri > nikolai
Re: Understanding regxp implementation
On 3/19/07, Asiri Rathnayake <[EMAIL PROTECTED]> wrote: Hi Bram, Nicolai, A 'k' would be greatly appreciated. I'm unable to grasp the description ( attachment ) given in the regxp.c file. For a moment they seem like NFA fragments for operators |,+,* Well, yes, that's what they are. The diagrams show you how the different operators are represented. I think the representation can be a bit difficult to grasp at first, because the representation isn't like a state diagram/tree/DAG, but more of a list of assembler instructions.These assembler-like instructions are then executed by an interpreter that executes the appropriate C code for doing the matching. This is (mainly) done in regmatch(). nikolai
Understanding regxp implementation
Hi Bram, Nicolai,
I'm unable to grasp the description ( attachment ) given in the regxp.c
file. For a moment they seem like NFA fragments for operators |,+,* and
so on, but then again I'm in doubt ( specially i don't understand what a
node in this context is ). A little help is greatly appreciated
( perhaps a pointer to some other information ). I believe this is a
very simple thing, sorry for my incompetence...
- Asiri
/*
* Structure for regexp "program". This is essentially a linear encoding
* of a nondeterministic finite-state machine (aka syntax charts or
* "railroad normal form" in parsing technology). Each node is an opcode
* plus a "next" pointer, possibly plus an operand. "Next" pointers of
* all nodes except BRANCH and BRACES_COMPLEX implement concatenation; a "next"
* pointer with a BRANCH on both ends of it is connecting two alternatives.
* (Here we have one of the subtle syntax dependencies: an individual BRANCH
* (as opposed to a collection of them) is never concatenated with anything
* because of operator precedence). The "next" pointer of a BRACES_COMPLEX
* node points to the node after the stuff to be repeated.
* The operand of some types of node is a literal string; for others, it is a
* node leading into a sub-FSM. In particular, the operand of a BRANCH node
* is the first node of the branch.
* (NB this is *not* a tree structure: the tail of the branch connects to the
* thing following the set of BRANCHes.)
*
* pattern is coded like:
*
*+-+
*| V
* \| BRANCH BRANCH --> END
* | ^| ^
* +--++--+
*
*
* +--+
* V |
* *BRANCH BRANCH --> BACK BRANCH --> NOTHING --> END
* | | ^ ^
* | +---+ |
* +-+
*
*
* +--+
* V |
* \+ BRANCH --> BRANCH --> BACK BRANCH --> NOTHING --> END
* | | ^ ^
* | +---+ |
* +--+
*
*
* +-+
* V |
* \{} BRANCH BRACE_LIMITS --> BRACE_COMPLEX --> BACK END
* | |^
* | ++
* +---+
*
*
* [EMAIL PROTECTED]BRANCH NOMATCH --> END --> END
* | |^ ^
* | ++ |
* ++
*
*+-+
*| V
* \z[abc] BRANCH BRANCH a BRANCH b BRANCH c BRANCH NOTHING --> END
* | | | | ^ ^
* | | | +-+ |
* | | ++ |
* | +---+ |
* +--+
*
* They all start with a BRANCH for "\|" alternaties, even when there is only
* one alternative.
*/
Re: improving encryption in vim
On Sun, 18 Mar 2007 15:57:33 -0600, Josh <[EMAIL PROTECTED]> wrote: > The main problem that I see is that adding a strong encryption > function can have regulation issues. That was the only reason that I > thought about using the external library is to get around this. With an algorithm like Rijndael there are no patent issues (and there is even unencumbered public source code available), and the only problem is with countries that forbid the use of encryption software. I imagine that can be solved in the same way as other conditional compilation matters are tacked in Vim: putting the code in a separate file and using a compile-time option to include it where available. > How secure does the encryption need to be? Considering that Rijndael offers 128-bit, 192-bit and 256-bit security with very fast and simple code, it's more a matter of: why would you bother with anything less than the best encryption you can get? -- Matthew Winn
