4 ms·

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 he

by tsm 13y ago

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?

Macha 13y ago
Given that it's in a regex source file, and the variable is named c, they're probably character codes for Unicode ranges.
- jlgreco 13y ago
  This might be a good case for unicode character literals. Code dealing with unicode can be a nightmare to work with, even if you already know what those numbers are (arguably as this bug demonstrates).
  - sltkr 13y ago
    You realize you're talking about a codebase which still uses pre-standard parameter type declarations, right?
    - jlgreco 13y ago
      Oh yes, Vim's code is anything but pleasant. I worked with it a decent amount several years ago when I was maintaining, for a short period of time, a patch that would add a terminal emulator to Vim windows.
      - tsm 13y ago
        I was just searching for such a thing yesterday. Did the patch go anywhere?
        qu4z-2 13y ago
        Just curious what the advantages are of this versus C-z'ing back to the shell? EDIT: Oh, I guess that doesn't work in gvim?
        tsm 13y ago
        It's nice to see terminal output at the same time as you're editing. Right now I'm working on a Rails app, so it'd be great to see RSpec failures while fixing my code--currently I either alt-tab between terminals or use a second monitor. Also, sometimes you don't want to wait for something. `bundle install` can take a good 30 seconds...I'd rather not watch that!
        qu4z-2 13y ago
        Thanks for the answer. Seems reasonable. Although at that point I'd somewhat suggest tmux :)
- sltkr 13y ago
  Correct -- 0xfb20 through 0xfb4f are alternative glyphs for Hebrew characters. (I don't know what makes these so special that they need to be handled separately by the regexp processing code, though.)
goldfeld 13y ago
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.) Pretty much how I work with coding products, I work my best when I'm the use case, and great open source products like vi/vim and emacs excel in that legions of people share the creator's use case (and well, configurability right down to the bone.) I've found that a non-trivial amount of people do share the use case for the first project I've launched[1], I only hope for it to hold true for my most ambitious ones in the working. I don't know Bram, but I can't help but wonder why such a distinguished open source figure has ultimately ended up working for Google. Maybe he enjoys the access to resources. I wish donations could still support him directly rather than his idea of aid (well it does seem to have a bend towards education at least). I wish he wouldn't need a day job and could yet breed other new and great contributions to the world. I don't feel particularly endeared towards Google, despite all the collateral good it has done while doing a lot of evil (i.e. something to do with the looming ad empire strengthening big corporations.) [1]: https://github.com/goldfeld/vim-seek https://github.com/goldfeld/vim-seek
- virtuz 13y ago
  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).
- gbog 13y ago
  I use ctags with Python, PHP and I'm sure it will works with most other languages invented.
meritt 13y ago
http://www.unicode.org/versions/Unicode6.2.0/ch08.pdf http://www.unicode.org/versions/Unicode6.2.0/ch08.pdf page 250 Screenshot of relevant text: http://i.imgur.com/xMnHDg4.png 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.
- IvyMike 13y ago
  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.)
  - redcircle 13y ago
    It is nice to move away from the C preprocessor: enum { HebrewCharMin=0xfb20, HebrewCharMax=0xfb4f, };
    - srl 13y ago
      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...`?
      - redcircle 13y ago
        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.
      - zaphoyd 13y ago
        #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.
Kurtz79 13y ago
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.

by tsm 13y ago

Macha 13y ago

Given that it's in a regex source file, and the variable is named c, they're probably character codes for Unicode ranges.

jlgreco 13y ago
This might be a good case for unicode character literals. Code dealing with unicode can be a nightmare to work with, even if you already know what those numbers are (arguably as this bug demonstrates).
- sltkr 13y ago
  You realize you're talking about a codebase which still uses pre-standard parameter type declarations, right?
  - jlgreco 13y ago
    Oh yes, Vim's code is anything but pleasant. I worked with it a decent amount several years ago when I was maintaining, for a short period of time, a patch that would add a terminal emulator to Vim windows.
    - tsm 13y ago
      I was just searching for such a thing yesterday. Did the patch go anywhere?
      - qu4z-2 13y ago
        Just curious what the advantages are of this versus C-z'ing back to the shell? EDIT: Oh, I guess that doesn't work in gvim?
        tsm 13y ago
        It's nice to see terminal output at the same time as you're editing. Right now I'm working on a Rails app, so it'd be great to see RSpec failures while fixing my code--currently I either alt-tab between terminals or use a second monitor. Also, sometimes you don't want to wait for something. `bundle install` can take a good 30 seconds...I'd rather not watch that!
        qu4z-2 13y ago
        Thanks for the answer. Seems reasonable. Although at that point I'd somewhat suggest tmux :)
sltkr 13y ago
Correct -- 0xfb20 through 0xfb4f are alternative glyphs for Hebrew characters. (I don't know what makes these so special that they need to be handled separately by the regexp processing code, though.)

goldfeld 13y ago

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.) Pretty much how I work with coding products, I work my best when I'm the use case, and great open source products like vi/vim and emacs excel in that legions of people share the creator's use case (and well, configurability right down to the bone.) I've found that a non-trivial amount of people do share the use case for the first project I've launched[1], I only hope for it to hold true for my most ambitious ones in the working. I don't know Bram, but I can't help but wonder why such a distinguished open source figure has ultimately ended up working for Google. Maybe he enjoys the access to resources. I wish donations could still support him directly rather than his idea of aid (well it does seem to have a bend towards education at least). I wish he wouldn't need a day job and could yet breed other new and great contributions to the world. I don't feel particularly endeared towards Google, despite all the collateral good it has done while doing a lot of evil (i.e. something to do with the looming ad empire strengthening big corporations.) [1]: https://github.com/goldfeld/vim-seek https://github.com/goldfeld/vim-seek

virtuz 13y ago
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).
gbog 13y ago
I use ctags with Python, PHP and I'm sure it will works with most other languages invented.

meritt 13y ago

http://www.unicode.org/versions/Unicode6.2.0/ch08.pdf http://www.unicode.org/versions/Unicode6.2.0/ch08.pdf page 250 Screenshot of relevant text: http://i.imgur.com/xMnHDg4.png 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.

IvyMike 13y ago
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.)
- redcircle 13y ago
  It is nice to move away from the C preprocessor: enum { HebrewCharMin=0xfb20, HebrewCharMax=0xfb4f, };
  - srl 13y ago
    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...`?
    - redcircle 13y ago
      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.
    - zaphoyd 13y ago
      #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.

Kurtz79 13y ago

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.