6 ms·

Maybe you're being sarcastic, but I think it's just a hack with the formatting appearing after the end of file marker that the compiler uses.

by alayne 10y ago

jonsen 10y ago
Inlined formatting commands could be recognised and skipped, just like the //-comments.
- alayne 10y ago
  Okay, I was going off an old comment from Animats where he said "The Bravo file representation was plain text, followed by a control-Z as an EOF, followed by the formatting information. The compiler just stopped at the control-Z."
  - adf 10y ago
    So Bravo begat Word, and ^Z survived as EOF into DOS...
    - Sanddancer 10y ago
      ^Z in DOS was a holdover from its roots as a CP/M clone. CP/M in turn cribbed it from certain DEC OSes, because that's what Gary Kildall used while making CP/M. So ^Z is a case of convergent evolution.
      - jandrese 10y ago
        It's an easy mnemonic for Ctrl-Z to represent the end of something. Also fairly easy to type on a Qwerty keyboard.
      - kps 10y ago
        > So ^Z is a case of convergent evolution. More likely common ancestry, no? DG RDOS also used ^Z to end input (not sure if it was stored in the file); also PARC built their own PDP-10 clones.
akkartik 10y ago
No, not sarcastic at all. It never occurred to me that we could have a simple rich-text rendering for code. For example, render code in html, and strip all tags before passing through to the compiler. Why don't we do this?!
- smitherfield 10y ago
  But that or something along the same lines is how syntax highlighting is typically implemented.
  - akkartik 10y ago
    Syntax highlighting is nothing like that. It's one-size-fits-all. All types/keywords/whatever get the same color. It doesn't support font changes. If I was to hack this into say Neovim, I'd leave color alone and focus on just wysiwyg markup for font size/style. Imagine being able to bold the key call inside a function that does all the important work.
    - TeMPOraL 10y ago
      > Syntax highlighting is nothing like that. It's one-size-fits-all. All types/keywords/whatever get the same color. It doesn't support font changes. That's if you have a crappy editor. Emacs supports font changes for syntax coloring since... forever? ;). Here is a test I did just now: http://i.imgur.com/Xrgaixu.png http://i.imgur.com/Xrgaixu.png
      - akkartik 10y ago
        Nice![1] What happens when you quit and restart? [1] No need to get personal, though :p
        TeMPOraL 10y ago
        Didn't mean to sound personal - I was just involuntarily baiting the editor war discussion ;). > What happens when you quit and restart? I'd lose the changes because I applied them only to the runtime configuration. It'd be a few seconds more of work to save them permanently to my configuration though. In general, Emacs implements syntax highlighting by applying various "faces" to the highlighted parts. Those faces are highly customizable - including font foundry/family, various sizes, slant, as well as various decorations, foreground & background colors, etc. It has no problem rendering multiple fonts simultaneously (which is actually pretty useful if you're dealing with Unicode characters - your typical programmer's font won't have glyphs for many Unicode characters, so you can set "fallback fonts" for those). To de-bait the editor war trap, I think Eclipse can also pull that off, but I've left the only instance I have at work so I can't confirm it now :). --- EDIT: Crap, I think I misunderstood you. Did you mean "annotating" code with temporary style changes, especially in a semantic way? If so, I don't know of any editor that would support it out-of-the-box. In Emacs, you could probably hack your way around this with temporary font-locking (aka. adding an on-the-spot syntax highlighting for a particular symbol, and applying all the face-configuration-magic I described earlier), which I sometimes do when digging through log-files or grep results - there's a family of functions like "highlight-line-matching-regexp" or "highlight-symbol-at-point" with which you can quickly assign such highlights (and then there's a command that will write out all highlights in the format that you can save as a file-comment so that Emacs will reapply them the next time you open that file). But this is a hacky solution, IMO. This also brings me to my observation that there's literally zero tools out there for reading code. Something I'd love to change, and I keep gathering ideas, but I sadly lack time ATM to make even a proof-of-concept.

Maybe you're being sarcastic, but I think it's just a hack with the formatting appearing after the end of file marker that the compiler uses.

by alayne 10y ago

Maybe you're being sarcastic, but I think it's just a hack with the formatting appearing after the end of file marker that the compiler uses.

jonsen 10y ago

Inlined formatting commands could be recognised and skipped, just like the //-comments.

alayne 10y ago
Okay, I was going off an old comment from Animats where he said "The Bravo file representation was plain text, followed by a control-Z as an EOF, followed by the formatting information. The compiler just stopped at the control-Z."
- adf 10y ago
  So Bravo begat Word, and ^Z survived as EOF into DOS...
  - Sanddancer 10y ago
    ^Z in DOS was a holdover from its roots as a CP/M clone. CP/M in turn cribbed it from certain DEC OSes, because that's what Gary Kildall used while making CP/M. So ^Z is a case of convergent evolution.
    - jandrese 10y ago
      It's an easy mnemonic for Ctrl-Z to represent the end of something. Also fairly easy to type on a Qwerty keyboard.
    - kps 10y ago
      > So ^Z is a case of convergent evolution. More likely common ancestry, no? DG RDOS also used ^Z to end input (not sure if it was stored in the file); also PARC built their own PDP-10 clones.

akkartik 10y ago

No, not sarcastic at all. It never occurred to me that we could have a simple rich-text rendering for code. For example, render code in html, and strip all tags before passing through to the compiler. Why don't we do this?!

smitherfield 10y ago
But that or something along the same lines is how syntax highlighting is typically implemented.
- akkartik 10y ago
  Syntax highlighting is nothing like that. It's one-size-fits-all. All types/keywords/whatever get the same color. It doesn't support font changes. If I was to hack this into say Neovim, I'd leave color alone and focus on just wysiwyg markup for font size/style. Imagine being able to bold the key call inside a function that does all the important work.
  - TeMPOraL 10y ago
    > Syntax highlighting is nothing like that. It's one-size-fits-all. All types/keywords/whatever get the same color. It doesn't support font changes. That's if you have a crappy editor. Emacs supports font changes for syntax coloring since... forever? ;). Here is a test I did just now: http://i.imgur.com/Xrgaixu.png http://i.imgur.com/Xrgaixu.png
    - akkartik 10y ago
      Nice![1] What happens when you quit and restart? [1] No need to get personal, though :p
      - TeMPOraL 10y ago
        Didn't mean to sound personal - I was just involuntarily baiting the editor war discussion ;). > What happens when you quit and restart? I'd lose the changes because I applied them only to the runtime configuration. It'd be a few seconds more of work to save them permanently to my configuration though. In general, Emacs implements syntax highlighting by applying various "faces" to the highlighted parts. Those faces are highly customizable - including font foundry/family, various sizes, slant, as well as various decorations, foreground & background colors, etc. It has no problem rendering multiple fonts simultaneously (which is actually pretty useful if you're dealing with Unicode characters - your typical programmer's font won't have glyphs for many Unicode characters, so you can set "fallback fonts" for those). To de-bait the editor war trap, I think Eclipse can also pull that off, but I've left the only instance I have at work so I can't confirm it now :). --- EDIT: Crap, I think I misunderstood you. Did you mean "annotating" code with temporary style changes, especially in a semantic way? If so, I don't know of any editor that would support it out-of-the-box. In Emacs, you could probably hack your way around this with temporary font-locking (aka. adding an on-the-spot syntax highlighting for a particular symbol, and applying all the face-configuration-magic I described earlier), which I sometimes do when digging through log-files or grep results - there's a family of functions like "highlight-line-matching-regexp" or "highlight-symbol-at-point" with which you can quickly assign such highlights (and then there's a command that will write out all highlights in the format that you can save as a file-comment so that Emacs will reapply them the next time you open that file). But this is a hacky solution, IMO. This also brings me to my observation that there's literally zero tools out there for reading code. Something I'd love to change, and I keep gathering ideas, but I sadly lack time ATM to make even a proof-of-concept.