sloganking/codevis

Turns your code into one large image

codevis's Issues

Update ReadMe

Make Prodash "impl prodash::Progress" optional?

Not everyone may be interested in using Prodash, or creating an instance of impl prodash::Progress before calling our render function. So wrapping that paramater in an Option may make more sense.

padding

Add option to put spacing between columns, or around the entire image. Spacing around the entire image could be used to better conform to requested aspect ratio.

Optionally render line numbers

Only possible when --readable

version command

The CLI should be able to display it's version.

handle tabs

Variable resolution

It would be nice to create a higher resolution image so that code remains readable.

force text to bottom right corner

Output resolution

User should be able to define a desired resolution that the render function will output an image as. This may require upscaling or down scaling the output image.

Questions

• Outputted aspect ratio is not perfect. What should we do about the differences?

Default output file name should be name of input folder/file

Separate binary and library crates?

Is it better practice to have binaries and libraries as separate crates? If now, how should semantic versioning work when changes are made to one but not the other? Especially if there is a breaking change in the library but not the CLI binary.

I think gitoxide and gitoxide-core, are an example of this being done.

Cargo.lock is missing

codevis/.gitignore

Lines 5 to 7 in 996843a

	# Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
	# More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
	Cargo.lock

Handle grapheme clusters

Grapheme clusters represent a single visual character as perceived by the user. But these may contain multiple UTF-8 characters. Currently CodeVis renders each UTF-8 character in it's own space. Improperly rendering multi-character graphemes. unicode-segmentation is a crate that may let us easilly tell where grapheme clusters begin and end.

output to image tiles

Rendering to one large image requires allocating that uncompressed image in memory. This is prohibitively expensive when rendering large repositories. Rendering the 30 million line Linux Kernel as readable would require allocating around 1.3TB of memory, just to render the image. Another bottleneck would be that, after rendering, saving the entire image to one PNG file would involve compressing the entire image using only a single thread.

A solution to this, might be to slice the image up into tiles, and only cache a certain number of tiles in memory. This means cached tiles (ones used recently) could be written to quickly for rendering. And once we are done writing to them, they could be compressed to a PNG and offloaded to Disk. Saving memory, and allowing image compression to be made parallel.

Failed to compile installing v0.2.0 from crates.io

$ cargo install --force --locked codevis

error[E0425]: cannot find value `SIGWINCH` in module `signal_hook::consts`
   --> C:\Users\Atk\.cargo\registry\src\github.com-1ecc6299db9ec823\prodash-20.0.0\src\render\line\engine.rs:234:67
    |
234 |             signal_hook::low_level::register(signal_hook::consts::SIGWINCH, || {
    |                                                                   ^^^^^^^^ not found in `signal_hook::consts`

For more information about this error, try `rustc --explain E0425`.
error: could not compile `prodash` due to previous error

Issue appears to be downstream but creating an issue here for your awareness too

Issue in prodash: Byron/prodash#12

Optionally render file name

(when --readable) File name could be put at the top of each file. Visually showing what file is being looked at.

Wrap lines?

Instead of just cutting off, add an option to wrap lines.

Installation failed, use of unstable library feature.

Do I need to switch to rust nightly version to install codevis?

[ERROR]

error[E0658]: use of unstable library feature 'scoped_threads'
   --> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/codevis-0.3.1/src/render.rs:338:13
    |
338 |             std::thread::scope(|scope| -> anyhow::Result<()> {
    |             ^^^^^^^^^^^^^^^^^^
    |
    = note: see issue #93203 <https://github.com/rust-lang/rust/issues/93203> for more information

error[E0658]: use of unstable library feature 'scoped_threads'
   --> /data/data/com.termux/files/home/.cargo/registry/src/github.com-1ecc6299db9ec823/codevis-0.3.1/src/render.rs:342:27
    |
342 |                     scope.spawn({
    |                           ^^^^^
    |
    = note: see issue #93203 <https://github.com/rust-lang/rust/issues/93203> for more information

For more information about this error, try `rustc --explain E0658`.

I use termux.

• Linux localhost 4.14.186-gfbf7287bd5c9-dirty
• aarch64 @
• Android

more tests

CLI utility

main.rs should be runnable as a CLI utility. It's first arg taking the location of a file or folder to visualize. See #8

Clippy warning: attempt to mutate range bound within loop

Just wanted to check this isn't intended to change the range over which the for loop iterates, as it won't. If the code is correct as-is, you can suppress the lint by adding #[allow(clippy::mut_range_bound)] above the for loop. Otherwise, this may be something to fix?

warning: attempt to mutate range bound within loop
   --> src\lib.rs:270:41
    |
270 | ...                   cur_line_x += 1;
    |                       ^^^^^^^^^^
    |
    = note: `#[warn(clippy::mut_range_bound)]` on by default
    = note: the range of the loop is unchanged
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#mut_range_bound

Better character color shuffling

I feel our character color changing could improve by making the color change for every pixel in the same character. As it stands, each character has all of it's pixels be painted the same color.

Examples:

VsCode scrollbar:

Ours:

Host on crates.io

Failure to render large files.

I can't get codevis to render the Linux kernel, on machines with only 16GB of memory. This is unexpected since it was thought that mmap would allow working on images larger than could be stored in memory.

When attempting to render the Linux kernel:

On my 16GB Arch linux system with no allocated swap, I get

Error: Cannot allocate memory (os error 12)

On my 16GB Manjaro Linux system with 17GB of swap, I get

Killed

Sometimes Killed pops up before the image is done rendering, sometimes it happens after the render has finished and while the program is attempting to save the image to disk.

The second system also definitely has it's swap memory filled by codevis. 12.9GB of it.

--theme foo does not list themes

The description of --theme says that passing foo as a value will list possible themes. but it does not.

let --ignore-extension take multiple arguments

Inspired by #30

move to lib.rs

Usage examples

example pictures of how various commands change things.

Feature Request: Image Label/Watermark

It would be helpful to be able to add some text to the image in a corner to identify the project name/version. For example, I'm using this utility (technically, the version from #11) to render packages (i.e. linux-lts) that I have installed as a wallpaper, and I would like to add either a watermark or a block of text that identifies what it is. I don't know what appropriate cli arguments for this would look like or exactly how it would best be specified, but I spent a few seconds in GIMP to simulate the idea:

Throwing out ideas, the cli (building off of #11's cli) could add a heading for "LABEL" with the following options:

• --label: Text to include in the label
• --label-relative-to: One of "top-left", "top-right", "bottom-left", "bottom-right"
• --label-size: Percent of the image for the label to take up vertically (example 10)
• --label-color: Color of the label in hex RGBA format
• --label-font: Font used for the label
  I would be happy to implement this myself after a cli lands in this repo, if you aren't interested in doing it yourself. Thank you for this interesting project!

--whitelist-extension option

inspired by #30