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

🏛 Proposal: RETAB EVERYTHING! #115

Closed
pschmitt opened this issue Nov 28, 2021 · 4 comments
Closed

🏛 Proposal: RETAB EVERYTHING! #115

pschmitt opened this issue Nov 28, 2021 · 4 comments
Labels
enhancement New feature or request
Milestone

Comments

@pschmitt
Copy link
Member

pschmitt commented Nov 28, 2021

The more I work with zinit's core the more my eyes bleed.
Some lines are absurdly long.
A few examples:

  • builtin source "${ZINIT[BIN_DIR]}/zinit-side.zsh" || { builtin print -P "${ZINIT[col-error]}ERROR:%f%b Couldn't find ${ZINIT[col-obj]}zinit-side.zsh%f%b."; return 1; }
  • (( !OPTS[opt_-q,--quiet] )) && +zinit-message "Downloading {apo}\`{url}$sname{apo}\`{rst}${${ICE[svn]+" (with Subversion)"}:-" (with curl, wget, lftp)"}{…}"
  • files=( ${(@)${(@s: :)${extract##(\!-|-\!|\!|-)}}//(#b)(((#s)|([^\\])[\\]([\\][\\])#)|((#s)|([^\\])([\\][\\])#)) /${match[2]:+$match[3]$match[4] }${match[5]:+$match[6]${(l:${#match[7]}/2::\\:):-} }} )

I get that most people don't stick to 80 chars for their code but I'd at least appreciate if we re-tabbed the zsh scripts to use 2 space chars instead of 4.

TL;DR
I'm advocating for vim: ft=zsh et ts=2 sw=2 for zinit*.zsh

@pschmitt pschmitt added enhancement New feature or request 🏛 proposal labels Nov 28, 2021
@pschmitt pschmitt added this to the zinit 4.0 milestone Nov 28, 2021
@alichtman
Copy link
Member

alichtman commented Nov 28, 2021

TL;DR: Your change is alright by me but doesn't completely solve the issue. We have to refactor the massive one-liners to really improve readability.

I agree that we have a readability problem to solve here. Personally, I like ts/sw=4, but I see the argument for using ts=2 here.

That said, I think the real fix is breaking up some of the massive one-liners. For example, the first link you included has 0 leading spaces but is still unruly to read and work with.

@pschmitt
Copy link
Member Author

pschmitt commented Nov 28, 2021

Some lines we cannot split easily without refactoring it all and possibly (probably) hurting performance. zsh expansion is powerful, but afaik there's no readable way to split these lines other than storing temporary results in a variable and doing the rest of the work in a second statement.

The best way forward here is to add a bunch of comments explaining the weirdest exps IMO. And unspaghetti what we encounter along the way. For instance I "fixed" the first example in #116:

builtin source "${ZINIT[BIN_DIR]}/zinit-side.zsh" || {
builtin print -P "${ZINIT[col-error]}ERROR:%f%b Couldn't find ${ZINIT[col-obj]}zinit-side.zsh%f%b."
return 1
}

Doing it all in one go would be a huge undertaking.

Another thing: to make things better I'm all for adopting a "return early" approach (I don't know the real tech term) ie:

Instead of:

fun() {
	  if check_is_okay {
	    long_block_of_code
	    return 0
	  } elif check_not_okay {
	    another_block_of_code
	    return 1
	  }
}

that:

fun() {
	  if check_not_okay {
	    another_block_of_code
	    return 1
	  }
	  # check is okay here
	  block_of_code
	  return 0
}

It's a poor example, but I'm sure you get my point.

Edit: It's a guard clause.

@alichtman
Copy link
Member

Doing it all in one go

Yep, minor fixes over a long period of time is alright. Any improvements > no improvements :)

@pschmitt pschmitt changed the title 💡 Proposal: RETAB EVERYTHING! 🏛 Proposal: RETAB EVERYTHING! Dec 2, 2021
@vladdoster
Copy link
Member

Closing in favor of #238.

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

No branches or pull requests

3 participants