From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9184 invoked by alias); 21 Jun 2017 17:16:02 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41340 Received: (qmail 3547 invoked from network); 21 Jun 2017 17:16:01 -0000 X-Qmail-Scanner-Diagnostics: from mail-ua0-f171.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.217.171):SA:0(-1.0/5.0):. Processed in 1.960245 secs); 21 Jun 2017 17:16:01 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.217.171 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject:cc :mime-version; bh=Qh8fX4OM7VQ3xQqptyWU8uqzdiOhRhWaFUqg04Oku5o=; b=ZudDb51RapfZKpYzyrR1cXTy0fGpp0QFN9GJ/i5OEN0+4y+77hs64SoN84YXM9gEz+ YelIRdqMvm/JyU/4/AU8AfgLKP6hEKIk1UBpubG/aP3n0c97PCHwu/3+5OvgMPj793lO wO00cLJpauxNnDUBjJaiHH/70XCgbrKFn0hbSJqmWsPhPfVjNsJdjytrUs9T/eQNj2uS YqXD+/1qU0sZ+1jFf2RUXxTHKWDCUAxL7RDSsmM1T/mUEInkdYWkCY3wvBM6OzhOtJAP SXvgKo4SUZg38rLMp0aaRwRoVuTQYZi6qsxDE2RYr6jTZD20Ryimq/rSzB/OATiy7NuS 9f8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:cc:mime-version; bh=Qh8fX4OM7VQ3xQqptyWU8uqzdiOhRhWaFUqg04Oku5o=; b=RZJ2x2KRviv/8CUyr3hl9GCkmAkGS9zkdmFXcox6vPIDzMmSdGlk+Zj+v7z3KUIVxE Sb2sIxGExToEG0xIbhDqteSySUkxswtpDiWbNFEd8WJqHOANw0gdcX0hZAFxDbseJC07 aWO/9IFPKcSRdUPCjf6LdwOF5rRAA67CBfCbRvDOu6kV1nQjAJ6wWWe2NusrJC1m4g/l 5XNqiSU+dpQP1+ovTy8fIt1rXWw4nTzjn1AL9n7xNX/1x+n0vBR5/R4XV4hM9spDLnpB 1wFlOh0CZyyp8NtJqVbs40OGC2Mexj0HW/48vz7U69M5zAqGOk25k/qYoVjqvXZ4b/Jv o4JA== X-Gm-Message-State: AKS2vOzYqxZgQ8w+jGvRRpDm5rf1s3YRvAIvo785mR5u67dDCTu5Ewm1 HjNHwZzhl6TVon6Tv3o= X-Received: by 10.159.34.227 with SMTP id 90mr18603257uan.131.1498065352013; Wed, 21 Jun 2017 10:15:52 -0700 (PDT) From: Bart Schaefer Message-Id: <170621101645.ZM9838@torch.brasslantern.com> Date: Wed, 21 Jun 2017 10:16:45 -0700 In-Reply-To: Comments: In reply to Jim "Re: When RPROMPT != RPS1" (Jun 20, 1:22pm) References: X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: When RPROMPT != RPS1 Cc: linuxtechguy@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 20, 1:22pm, Jim wrote: } } > After switching from walters to say adam, I unset "RPS1", } > but the right prompt remained. I then typed } > "unset RPROMPT" and the right prompt was no longer there. } } I should have checked earlier. I'm seeing the same thing with } RPS2 and RPROMPT2. What's going on here is that RPROMPT, RPS1, RROMPT2, and RPS2 always start out as unset, so assigning to one of each pair does not cause the second one to magically become set. Then if you unset any one that is already unset, nothing happens (including not unsetting the paired one). The assumption is that under normal circumstances the user will not be arbitrarily/randomly switching which name he prefers to use. The prompt themes mess with that because they combine code from several different users. The reason they start out as unset is explained here: http://www.zsh.org/mla/workers/2014/msg00128.html The argument/complaint was that if those parameters have no meaning in an emulation mode, then they should not be set at all, thereby allowing scripts in the emulation to use those names any way they want without triggering the pairing behavior. I don't have a good suggestion for how to satisfy both constraints. Anyone? The parameter initialization code has been broken up into a few more sections already, maybe there's a way to rearrange these as well. } In addition the promptinit function doesn't set RPS2: } } local +h PS1=$PS1 PS2=$PS2 PS3=$PS3 PS4=$PS4 RPS1=$RPS1 Yeah, I'm not sure why it's done that way; the prompt_bart_setup doc even says: If a fifth color is specified and there is no RPS2, PS2 (PROMPT2) is colored and moved to RPS2. Changes to RPS1/RPS2 are currently not reverted when the theme is switched off. Obviously, though, that "local" command was written before the change from workers/32337 was applied.