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
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
* aa\|bb BRANCH aa BRANCH bb -- END
* | ^| ^
* +--++--+
*
*
* +--+
* V |
* aa*BRANCH BRANCH aa -- BACK BRANCH -- NOTHING -- END
* | | ^ ^
* | +---+ |
* +-+
*
*
* +--+
* V |
* aa\+ BRANCH aa -- BRANCH -- BACK BRANCH -- NOTHING -- END
* | | ^ ^
* | +---+ |
* +--+
*
*
* +-+
* V |
* aa\{} BRANCH BRACE_LIMITS -- BRACE_COMPLEX aa -- BACK END
* | |^
* | ++
* +---+
*
*
* aa[EMAIL PROTECTED]bbBRANCH NOMATCH aa -- END bb -- 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: 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 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
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: 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
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: 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: 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.
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.
