Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Nov 24 06:02
    sindresorhus closed #617
  • Nov 24 01:01
    Waxxx333 opened #617
  • Nov 23 20:17
    e-roux edited #616
  • Nov 23 19:27
    e-roux opened #616
  • Oct 19 15:31

    mafredri on main

    1.18.0 (compare)

  • Oct 19 15:31

    mafredri on v1.18.0

    (compare)

  • Oct 19 15:29

    mafredri on main

    Allow configuring nix-shell int… (compare)

  • Oct 19 15:29
    mafredri closed #613
  • Oct 19 15:29
    mafredri edited #613
  • Oct 12 08:15
    sindresorhus labeled #614
  • Oct 12 08:15
    sindresorhus labeled #614
  • Oct 11 20:51
    acantepie edited #614
  • Oct 11 20:51
    acantepie opened #614
  • Oct 08 17:48
    andresilva synchronize #613
  • Oct 08 14:39
    andresilva synchronize #613
  • Oct 08 14:03
    andresilva opened #613
  • Oct 07 10:36
    mafredri closed #612
  • Oct 07 05:58
    reportaman opened #612
  • Oct 02 23:14
    Skyearn closed #589
  • Sep 18 14:14

    sindresorhus on main

    1.17.3 (compare)

Mathias Fredriksson
@mafredri
Didn't realize everyone gets a notification about this, heh. But since there's been a lot of commenting lately on PRs and issues, thought it might be good to have a place to offload the noise to.
Sindre Sorhus
@sindresorhus
@mafredri Sure, good idea! :)
Mathias Fredriksson
@mafredri
:)
Thoughts on adding the badge to pure readme as well? Looks like gitter automatically made a PR
Don't really fell it's necessary though
Sindre Sorhus
@sindresorhus
@mafredri Are you willing to answer support question in here? If yes, we should add it, if no, then no.
Mathias Fredriksson
@mafredri
Good point. I do prefer to see support requests raised as issues instead of monitoring this chat room :).
Sindre Sorhus
@sindresorhus
I would prefer not to have support request in issues though.
Asking in a chat room is a lot less scary than opening an issue, so this might be more welcoming for people.
But yeah. I don't have a lot of time to monitor this chat room either. So really up to you.
Mathias Fredriksson
@mafredri
Well, I can't argue with that. I'll think about it.
Sindre Sorhus
@sindresorhus
@mafredri I've noticed a lot of prompts use zstyle for prompt options. Is this correct usage? Should we be doing that instead of env vars? Eg. https://github.com/pasberth/promptway // @/all
Mathias Fredriksson
@mafredri
@sindresorhus I’ve noticed that as well with frameworks like oh-my-zsh, prezto, etc. But I’ve never really used it myself. I guess it would save a few env variables, but wondering if there’s any overhead (probably not considerable though).
Mathias Fredriksson
@mafredri
Themes that ship with ZSH though usually seem to take all their configuration options as parameters (usually colors), e.g.: prompt theme1 blue yellow white.
Since vcs_info relies on zstyle, we’re not getting rid of that at least. But I can’t say I’ve ever seen anything that indicates that you should use zstyle for these sorts of things.
Sindre Sorhus
@sindresorhus
Alright, then let's don't then.
Mathias Fredriksson
@mafredri
I’ve been entartaining an idea on how to decrease pure options, but increase configurability. Instead of having separate options for the symbols, we could e.g. have something like: PROMPT_PURE_SYMBOLS=(❯ ⇣ ⇡ *). If you only want to change down arrow, you could set PROMPT_PURE_SYMBOLS[2]=“v”. Thoughts?
Partially related: sindresorhus/pure#158
Zhiming Wang
@zmwangx
I'm not sure if I like PROMPT_PURE_SYMBOLS, but at least the idea can be improved by having an associative array (compared to random, meaningless numerical indices).
Mathias Fredriksson
@mafredri
I agree, I put 0 thought into that name ;). Anyway, the benefit of using numerical indices is that you can just type PROMPT_PURE_SYMBOLS[2]=“v” anywhere without defining it via typeset -a first. AFAIK for an associative array you must first do typeset -A PROMPT_PURE_SYMBOLS, or am I wrong?
Zhiming Wang
@zmwangx
Oh, I hold nothing against the name, I was talking about the whole idea. "you must first do typeset -A PROMPT_PURE_SYMBOLS" Yeah, that's true, see http://zsh.sourceforge.net/Doc/Release/Parameters.html#Array-Parameters. To me it's perfectly fine (I mean, do you mind one extra line in your zshrc? I don't), but I guess it does come off as kinda odd to folks not into associative arrays.
Mathias Fredriksson
@mafredri
Ah ok, I misunderstood you. I don’t mind adding a typeset in my zshrc either, it’s just more explaining to do to the users… “You need to do this, and it must come before this and this”.
Mathias Fredriksson
@mafredri
Oh wow, this is great! I’ve managed to make zsh-async much more responsive with a patch sent to me by Bart on the zsh-workers mailing list. With it, kill signals would no longer be needed so let’s hope it makes it’s way into 5.0.9 :)! http://www.zsh.org/mla/workers/2015/msg02015.html
Mathias Fredriksson
@mafredri
Ok, much is perhaps exaggerating, but still, feels a bit more responsive.
Zhiming Wang
@zmwangx
That was a hell of a long thread... Anyway, glad it's fixed, and thanks for your effort that led up to the fix!
Mathias Fredriksson
@mafredri
Hehe, thanks zmwangx. The message I linked to is quite unrelated to the deadlock stuff though, just a nice bonus :).
Pushed a branch of async that utilizes the new patch, it’s pretty neat! https://github.com/mafredri/zsh-async/commits/zle-test
Zhiming Wang
@zmwangx
Yeah seen that. I actually also went through the entire thread.
Mathias Fredriksson
@mafredri
Cool!
With all the patches that went in though, I’m surprised not more people have run into this.
Sindre Sorhus
@sindresorhus
@mafredri With sindresorhus/pure@f396975 landed, should we do a new release?
Mathias Fredriksson
@mafredri
@sindresorhus I was thinking of including the latest release of zsh-async in the next update but haven’t gotten around to it. What’s new there is that the stderr and stdout streams are separated, so there should be no more possibility for garbled output in the preprompt.
Mathias Fredriksson
@mafredri
Ok, just pushed the updated zsh-async to pure, do we go for version 1.2?
Sindre Sorhus
@sindresorhus
@mafredri Awesome! I tried out master now. Looks good to me. Feel free to do a 1.2.0 release ;)
Mathias Fredriksson
@mafredri
Great, I’ll do so! :)
Btw @sindresorhus, I’ve noticed your npm releases are of type 1.2.0 whereas npm version minor produces a v1.2.0 for me
Mathias Fredriksson
@mafredri
Although it looks like it’s only on the git tag, not the version number in the commit :S
Mathias Fredriksson
@mafredri
Sindre Sorhus
@sindresorhus
@mafredri Yeah, I hate the v npm adds so I used an option to remove it. Did that for a while, then realized every other person needs to do that for it to be consistent, so I dropped it. Not worth the inconsistency it causes.
Mathias Fredriksson
@mafredri
Ah, that explains it. I never really reached a consencus with myself about which I prefer, with or without v-prefix.
Brian Millar
@brianmillar
Hi, I'm having a problem with the Pure prompt, when I start zsh with prompt pure or run prompt -p I get "set_prompt:100: fatal error: out of memory", I can only see this error when running zsh on top of another shell as it cause zsh to crash and if another shell is not running the session obviously disappears. I'm using ZSH 5.0.8 on Gentoo. I tried looking into the issue and could not find documentation relating to the out of memory error anywhere, I'm not sure what memory they mean whether prompts need to fix inside some sized buffer or something.
Sindre Sorhus
@sindresorhus
@mafredri ^ Any ideas?
Brian Millar
@brianmillar
I've traced the crash and found zsh trying to allocate an astronomical amount of memory which obviously fails. While this error has shown up by trying to run pure I am doubtful that pure is actually the cause
Brian Millar
@brianmillar
I've fixed the problem, thanks for you time anyway and sorry for bothering you