justinmeiners / srcweave

A literate programming system for any language.
https://www.jmeiners.com/literate-programming/
GNU General Public License v2.0
78 stars 4 forks source link

Way to comment out all lines of an include? #24

Closed eihli closed 1 year ago

eihli commented 1 year ago

I've got some code like below and I'd like to comment out all of the 64 bit test loop with a single // line. But right now it only prefixes the first line of the inclusion.

--- /pagecount32vs64.c
@{Includes, initializations, and external function declarations}
int main(int argc, char** argv) {
    @{Initializations32}
    @{Baseline32}

    @{32 bit test loop}
    // @{64 bit test loop}
    @{Results output}
}
---

I see how this behavior is useful because it lets you do things like:

someArray.@{filter and map chain}

Where filter and map chain is something like:

--- filter and map chain
map(double)
.filter(even)
.reduce(add)
---

You don't want someArray to be prefixed to each line there, and srcweave doesn't know there's a difference between // and someArray. It doesn't know that one's a comment prefix and one's not.

So... I'm happy to work on the implementation. But what's the best way to go about this?

Maybe something like a "comment directive"? Something scoped project-wide? Or scoped per file? Or scoped per code-block?

Maybe something like

--- /pagecount32vs64.c --- comment: //
foo
// bar
baz
---
eihli commented 1 year ago

There are reasons to not make any changes related to this.

If you're commenting stuff out as part of development and debugging then this problem is solved by other tools. Just make two commits in version control and jump back and forth. Or use your editor to undo/redo.

Within srcweave, instead of commenting out a block you can create an empty block and use that as the include.

I'm strongly leaning towards thinking this should not change.

justinmeiners commented 1 year ago

Thanks for writing this in detail. I would prefer to keep the relationship between the particular programming language and the srcweave tool as separated as possible. Ultimately it's a text manipulation system. Keeping it focused on text makes it's behavior predictable and easier to integrate with other unix tools. For this reason, I am not a big fan of introducing a way to define what the language's comment syntax is.

With that said, here are two options I can think of:

  1. Ensure that including an unknown block only produces a warning instead of an error. Then you could just add a character to the front of the identifier, and it would create a bogus include with no effect on the source code. This is similar to your idea of including an empty block, but you don't have to make an empty block.

  2. Create a special form representing our own comments in the literate system. For example, perhaps ?{64 bit test loop} could be ignored by the system.

  3. As you mentioned, only whitespace is prefixed. You use the example of someArray.@{filter and map chain}. Now I am questioning whether that's actually very useful. What if we included the prefix regardless of what characters it contained? I think a lisp example might show me it is useful, let me see what we have.

I am leaning towards something like option 1. What are your thoughts?

eihli commented 1 year ago
  1. Ensure that including an unknown block only produces a warning instead of an error.

Yeah this sounds good and reasonable. Not erroring is closer to the behavior of at least one existing tool, Org-mode, which isn't even warning me when I export with a non-existent block.

#+begin_src shell :noweb yes
echo "hello"
<<goodbye>>
<<world>>
#+end_src

#+NAME: world
#+begin_src shell
echo "world"
#+end_src