Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[idea] Use black --line-length while resizing the buffer #46

Open
JulienPalard opened this issue Dec 1, 2021 · 3 comments
Open

[idea] Use black --line-length while resizing the buffer #46

JulienPalard opened this issue Dec 1, 2021 · 3 comments

Comments

@JulienPalard
Copy link

Idea is: reflow the code when the window is resized.

  • When emacs open a file blacken could pass black with --line-length equal to the number of column of the buffer the file is displayed on.
  • Every time the buffer is resized, blacken could pass black again with an updated --line-length so adapt the code to the new width.
  • When the file is saved, blacken could pass black one last time without --line-length for diff stability.

So one could work with a file in full-width with comfort of a big screen, then split the screen in two vertical windows and have the code rewrapped accordingly, the get back to a single buffer and get the code rewrapped automatically again to use the available space.

To be really nice and smooth it would need for the file cursor not to jump to another place, which is probably the hardest thing here...

@CeleritasCelery
Copy link
Contributor

does setting toggle-truncate-lines get the behavior you desire?

@JulienPalard
Copy link
Author

No, it does not looks like this. The idea is that a function, wrapped at 88th column by black on disk, say:

def update_makefile(cpython_repo: Path) -> None:
    makefile = Path("Makefile").read_text(encoding="UTF-8")
    head = run(
        "git", "-C", cpython_repo, "rev-parse", "HEAD", stdout=PIPE
    ).stdout.strip()
    makefile = re.sub(
        "^CPYTHON_CURRENT_COMMIT :=.*$",
        f"CPYTHON_CURRENT_COMMIT := {head}",
        makefile,
        flags=re.M,
    )
    Path("Makefile").write_text(makefile, encoding="UTF-8")
    run("git", "add", "Makefile")

Could be displayed in a 100 chars wide buffer as:

def update_makefile(cpython_repo: Path) -> None:
    makefile = Path("Makefile").read_text(encoding="UTF-8")
    head = run("git", "-C", cpython_repo, "rev-parse", "HEAD", stdout=PIPE).stdout.strip()
    makefile = re.sub(
        "^CPYTHON_CURRENT_COMMIT :=.*$", f"CPYTHON_CURRENT_COMMIT := {head}", makefile, flags=re.M
    )
    Path("Makefile").write_text(makefile, encoding="UTF-8")
    run("git", "add", "Makefile")

and if I widen my window to display 120 chars it could be rendered as:

def update_makefile(cpython_repo: Path) -> None:
    makefile = Path("Makefile").read_text(encoding="UTF-8")
    head = run("git", "-C", cpython_repo, "rev-parse", "HEAD", stdout=PIPE).stdout.strip()
    makefile = re.sub("^CPYTHON_CURRENT_COMMIT :=.*$", f"CPYTHON_CURRENT_COMMIT := {head}", makefile, flags=re.M)
    Path("Makefile").write_text(makefile, encoding="UTF-8")
    run("git", "add", "Makefile")

then If I split my frame vertically, leaving only 60 chars wide for each window it could be rendered as:

def update_makefile(cpython_repo: Path) -> None:
    makefile = Path("Makefile").read_text(encoding="UTF-8")
    head = run(
        "git",
        "-C",
        cpython_repo,
        "rev-parse",
        "HEAD",
        stdout=PIPE,
    ).stdout.strip()
    makefile = re.sub(
        "^CPYTHON_CURRENT_COMMIT :=.*$",
        f"CPYTHON_CURRENT_COMMIT := {head}",
        makefile,
        flags=re.M,
    )
    Path("Makefile").write_text(makefile, encoding="UTF-8")
    run("git", "add", "Makefile")

Obviously without changing the on-disk representation of not using --line-length while saving the file.

@CeleritasCelery
Copy link
Contributor

I like the idea. If someone put together a PR for these changes, I would test it and merge it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants