4 ms·

How do you deal with having to scroll such a large file? That's the biggest turn-off to literate programming for me. I don't like code files more than a couple

by Touche 8y ago

How do you deal with having to scroll such a large file? That's the biggest turn-off to literate programming for me. I don't like code files more than a couple hundred lines of code. Search isn't enough for me.

Jtsummers 8y ago
Org mode will let you collapse trees and source blocks. You can also narrow the view to a sub tree. This makes navigation much easier.
- heavenlyblue 8y ago
  So how is navigating the file tree any different from navigating the source code tree? Just don’t tell me “you can see the context” as any proper codebase would probably not be linear in code flow anyway.
  - jacobush 8y ago
    That it's not different is kind of a good point? Some people use several Emacs windows (or frames or whatever) but all of them peeking into the same file, but in to different locations of it.
  - Jtsummers 8y ago
    I mean, it isn't, if you organize your file identically to the source tree. But I break it out differently when I use this approach. I'll use the noweb references and scatter my code across the document in a logical way that's not reflective of the generated source tree. For instance, I group all include or equivalent statements in an appendix, rather than within the primary code discussion. If a block of code can't be directly reused, but for some reason needs to be in every (or several) source files (think standard boilerplate), I'll write it once in a place that makes sense, and reference it from all the places where it actually gets tangled into the output. Additionally, I include the Makefile (or whatever equivalent) and other scripts within this same document. Learning docker? Make a dockerfile in here, fully annotated, along with the shell commands to actually deploy it. Mine will only mirror the original source tree if it's: Very simple. I've imported a bunch of code into it and don't, yet, know how to break it down. An example C project may look like: * Purpose Statement * README * Usage This program can be executed from the command line by calling: #+BEGIN_EXAMPLE $ ./foo #+END_EXAMPLE It accepts the following command line parameters: - =-c= :: something - =-d= :: something else ** Implementation To process the command line flags we use <some library>. it has the following API calls... Here's the code for processing our commands... * Business Logic We communicate with the server via some REST API described in <location> and <library> to make the calls. -- Here I'd intermingle the REST API I'm using and the C API I'm producing -- for my own consumption, or something similar. * Code that's not fully organized yet ** Main Function This is the entry point, blah, blah, blah: #+BEGIN_SRC c :noweb yes :tangle src/main.c #+END_SRC * Appendix: Includes
  - ehaliewicz2 8y ago
    If it's all the same, why use separate files?
emidln 8y ago
When your IDE (or Emacs in this case) offers go jumping/searching functionality, it doesn't really matter how many files your code is in. When I used bare vim, I cared a lot more about code organization than I do with an IDE that makes jumping around the codebase easy.

by Touche 8y ago

Jtsummers 8y ago

Org mode will let you collapse trees and source blocks. You can also narrow the view to a sub tree. This makes navigation much easier.

heavenlyblue 8y ago
So how is navigating the file tree any different from navigating the source code tree? Just don’t tell me “you can see the context” as any proper codebase would probably not be linear in code flow anyway.
- jacobush 8y ago
  That it's not different is kind of a good point? Some people use several Emacs windows (or frames or whatever) but all of them peeking into the same file, but in to different locations of it.
- Jtsummers 8y ago
  I mean, it isn't, if you organize your file identically to the source tree. But I break it out differently when I use this approach. I'll use the noweb references and scatter my code across the document in a logical way that's not reflective of the generated source tree. For instance, I group all include or equivalent statements in an appendix, rather than within the primary code discussion. If a block of code can't be directly reused, but for some reason needs to be in every (or several) source files (think standard boilerplate), I'll write it once in a place that makes sense, and reference it from all the places where it actually gets tangled into the output. Additionally, I include the Makefile (or whatever equivalent) and other scripts within this same document. Learning docker? Make a dockerfile in here, fully annotated, along with the shell commands to actually deploy it. Mine will only mirror the original source tree if it's: Very simple. I've imported a bunch of code into it and don't, yet, know how to break it down. An example C project may look like: * Purpose Statement * README * Usage This program can be executed from the command line by calling: #+BEGIN_EXAMPLE $ ./foo #+END_EXAMPLE It accepts the following command line parameters: - =-c= :: something - =-d= :: something else ** Implementation To process the command line flags we use <some library>. it has the following API calls... Here's the code for processing our commands... * Business Logic We communicate with the server via some REST API described in <location> and <library> to make the calls. -- Here I'd intermingle the REST API I'm using and the C API I'm producing -- for my own consumption, or something similar. * Code that's not fully organized yet ** Main Function This is the entry point, blah, blah, blah: #+BEGIN_SRC c :noweb yes :tangle src/main.c #+END_SRC * Appendix: Includes
- ehaliewicz2 8y ago
  If it's all the same, why use separate files?

emidln 8y ago

When your IDE (or Emacs in this case) offers go jumping/searching functionality, it doesn't really matter how many files your code is in. When I used bare vim, I cared a lot more about code organization than I do with an IDE that makes jumping around the codebase easy.