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

31–40 of 53 posts

Re: Vim 7.3.1000

#31

Post by zaphoyd »

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...`?

#define is a problem in general because the compiler doesn't understand as well what is happening because the substitutions take place outside of the language's type system. Extensive preprocessor use makes writing analysis tools, refactoring IDEs, and sane compiler errors much more complicated. Const in C doesn't behave similarly to #define so it isn't really a substitute.

Note: in C++, global/static const values do behave as compile time constant expressions and are an excellent tool for this purpose.

Re: Vim 7.3.1000

#32

Post by IvyMike »

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'd argue that in good old C, #defines for pure constants are pretty well established and considered idiomatic. In other words, I wouldn't ding it in a code review. (Nor would I ding the enum solution. Either one is perfectly cromulent.) In some ways, even though we now have better alternatives in C, I kinda feel like any C tool and any C programmer had better be able to deal with #define constants. Quickly browsing the vim source, it looks like they have seem to default to using #define for constants, and "when in Rome" is a good rule of thumb to live by. :)

On the other hand, I'm really a C++ guy, and in that domain, I'd prefer your "const uint32_t" solution. It just feels more idiomatic.

Additionally and somewhat pedantically, I prefer naming conventions that make it clear when values are a constant, so I'd use "kHebrewCharMin" or something simliar.

Re: Vim 7.3.1000

#33

Post by sbrother »

AutocorrectThis wrote: post #27

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.

You never need the arrow keys or backspace with emacs either: C-f, C-b, C-n, C-p, and C-d :)

Re: Vim 7.3.1000

#34

Post by tincholio »

AutocorrectThis wrote: post #27

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.

I think the raw _editing_ power of Vim is, as you say, probably unmatched in Emacs. Vim, however, cannot hold a candle to all the rest of Emacs and its elisp-y goodness. I'm a long-time Emacs user, and having recognized that Vim's modal editing and "language" are a better way of editing, opted for using Evil-mode, which gives you the best of both worlds. The transition was not without pain, but it was overall quick and worthy.

Re: Vim 7.3.1000

#35

Post by _pmf_ »

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...`?

One thing is that the compiler can warn about missing cases when using enums (GCC optionally does this); with defines, it's not clear that several values form a closed set.

The other thing is that function signatures can now show 'enum myenum e' instead of 'int v', which is much clearer.

Re: Vim 7.3.1000

#37

Post by Kurtz79 »

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?

Well, there is a place for "magic numbers" if considered within context.

Most people here would read 0xFF0000 and automatically think "red".

But I agree that in this case a define would have helped.

Re: Vim 7.3.1000

#38

Post by chris_wot »

jlgreco wrote: post #19
plorkyeran wrote: post #16

Earlier quoted context omitted.

String comparison with Unicode is pretty astonishingly complex, partially because equality is not as well defined as it seems to be on the surface. Should e and é be equal? If you're dealing with user input from people who are unlikely to know how to type é, then they probably should, but in many cases they shouldn't. A more complex case is é and é (precomposed vs decomposed forms), which nearly always should be equa…

There are a lot of things I have seen in Unicode that seem like they should not exist in the first place. MATHEMATICAL [BOLD|SANS-SERIF|DOUBLE-STRUCK|MONOSPACE] DIGIT for example... I guess those things potentially carry significant meaning in some mathematics texts though. I guess the ICU stuff probably gives you an strtol equivalent that can handle that sort of stuff.

The LibreOffice guys have told me hat ICU has security concerns and is, for all intents and purposes, no longer being developed. They are switching to another engine (hard buzz? Name escapes me).

Anyone know if this is true?

Re: Vim 7.3.1000

#39

Post by pekk »

tincholio wrote: post #34
AutocorrectThis wrote: post #27

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.

I think the raw _editing_ power of Vim is, as you say, probably unmatched in Emacs. Vim, however, cannot hold a candle to all the rest of Emacs and its elisp-y goodness. I'm a long-time Emacs user, and having recognized that Vim's modal editing and "language" are a better way of editing, opted for using Evil-mode, which gives you the best of both worlds. The transition was not without pain, but it was overall quick a…

elisp is not such a great language, so the value of editing using a pile of it is mixed. It boils down to a matter of taste. If you like elisp, it's a big win and if you don't, it's a deal-breaker.
Post reply on HN