Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim 7.3.1000

ftp.vim.org

Post reply on HN
Print view View original

21–30 of 53 posts

Re: Vim 7.3.1000

#21

Post by redcircle »

IvyMike wrote: post #20
meritt wrote: post #11

Earlier quoted context omitted.

http://www.unicode.org/versions/Unicode6.2.0/ch08.pdf page 250 Screenshot of relevant text: http://i.imgur.com/xMnHDg4.png Basically certain Hebrew characters have descenders which can overlap with diatric marks in the next line of text. These variations are suitable replacements that alter it slightly so it won't overlap.

I'd so prefer to see #define HEBREW_CHAR_MIN 0xfb20 #define HEBREW_CHAR_MAX 0xfb4f (Probably with even more descriptive names, but I don't know the problem domain.)

It is nice to move away from the C preprocessor:

enum { HebrewCharMin=0xfb20, HebrewCharMax=0xfb4f, };

Re: Vim 7.3.1000

#22

Post by rbonvall »

mhi wrote: post #4

NOTE: If you experience troubles with more complicated regular expressions in the next time, it might be because of the new engine. :h two-engines :h 're'

Doc link for those of us that don't have a recent enough version of Vim: http://code.google.com/p/vim/source/browse/runtime/doc/patte...

Re: Vim 7.3.1000

#24

Post by virtuz »

goldfeld wrote: post #10
tsm wrote: post #7

I guess I should be thankful 98% of my programming life is in higher-level languages than C, but...am I the only one whose terrified of the magic numbers? In hex ? Can anyone provide context about what's so special about 0xfb20 and 0xfb4f?

All my programming life has been in higher-level languages, yet with Rust I'm being inexplicably drawn to down and dirty systems programming. It's cool to finally be able to use :make and all the C-oriented things like [i and ]i, ctags and the like. It's interesting seeing how much 'dogfooding' vim has in that tons of stuff are undoubtedly geared towards his own needs developing vim (and C applications in general.) P…

With Go I feel the same way – after a long time with interpreted languages it's a breath of fresh air using a strictly typed and statically compiled language.

About your point with Bram and Google, though, I can understand it. The people you're around and the environment you're in must feel so much better than working on open-source by yourself, especially with the 20% of free time you get to work on whatever you'd like.

I can't take anything else than you're jumping on the google hate bandwagon here, which I'd love to know why. As a side note, I'd love to hear everyone's responses as to why they love Go but hate Google. Odd.

(Disclaimer, I don't know Bram but know that in an environment that fosters people you get much more done and excel much faster).

Re: Vim 7.3.1000

#25

Post by lurker14 »

jlgreco wrote: post #14
jng wrote: post #5

Pretty ugly bug. Where did it happen? Anyway, congrats & long life!

Apparently this is in the code that decomposes strings so that they can be compared (necessary with Hebrew and Arabic seemingly?). This is an interesting snippet from that code...: /* decompose the character if necessary, into 'base' characters * because I don't care about Arabic, I will hard-code the Hebrew * which I *do* care about! So sue me... */ if (c1 != c2 && (!ireg_ic || utf_fold(c1) != utf_fold(c2))) { /* de…

It would be nice if someone cared about BOTH Hebrew and Arabic.

Re: Vim 7.3.1000

#27

Post by AutocorrectThis »

The raw power that you feel in your hand when using VIM is amazing, I never get that feeling with Emacs, but each to their own. Not needing to reach for the arrow keys, backspace etc. is neat too.

Re: Vim 7.3.1000

#28

Post by srl »

redcircle wrote: post #21
IvyMike wrote: post #20

Earlier quoted context omitted.

I'd so prefer to see #define HEBREW_CHAR_MIN 0xfb20 #define HEBREW_CHAR_MAX 0xfb4f (Probably with even more descriptive names, but I don't know the problem domain.)

It is nice to move away from the C preprocessor: enum { HebrewCharMin=0xfb20, HebrewCharMax=0xfb4f, };

Can you explain why this is preferable to using the preprocessor? I've always considered it a pretty fundamental principle that the "surface" interpretation of code should be as close as possible to the "real" meaning, and we're definitely not trying to represent an "enumeration". What's wrong with #define, or `const uint32_t HebrewCharMin...`?

Re: Vim 7.3.1000

#29

Post by gbog »

goldfeld wrote: post #10
tsm wrote: post #7

I guess I should be thankful 98% of my programming life is in higher-level languages than C, but...am I the only one whose terrified of the magic numbers? In hex ? Can anyone provide context about what's so special about 0xfb20 and 0xfb4f?

All my programming life has been in higher-level languages, yet with Rust I'm being inexplicably drawn to down and dirty systems programming. It's cool to finally be able to use :make and all the C-oriented things like [i and ]i, ctags and the like. It's interesting seeing how much 'dogfooding' vim has in that tons of stuff are undoubtedly geared towards his own needs developing vim (and C applications in general.) P…

I use ctags with Python, PHP and I'm sure it will works with most other languages invented.

Re: Vim 7.3.1000

#30

Post by redcircle »

srl wrote: post #28
redcircle wrote: post #21

Earlier quoted context omitted.

It is nice to move away from the C preprocessor: enum { HebrewCharMin=0xfb20, HebrewCharMax=0xfb4f, };

Can you explain why this is preferable to using the preprocessor? I've always considered it a pretty fundamental principle that the "surface" interpretation of code should be as close as possible to the "real" meaning, and we're definitely not trying to represent an "enumeration". What's wrong with #define, or `const uint32_t HebrewCharMin...`?

I don't feel that there is anything "wrong," just limiting, because the C preprocessor makes it harder to use tools that walk the abstract-syntax-tree while editing code (or to analyze code). LLVM-based tools are really nice. I don't care whether it is "const uint32_t ..." or enum, or anything else, as long as it is the C/C++/ObjC language.
Post reply on HN