Received-SPF: pass (google.com: best guess record for domain of linux-bluetooth-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   "=?utf-8?Q?Micha=C5=82?= Lowas-Rzechonek" 
        <michal.lowas-rzechonek@silvair.com>
Date:   Mon, 20 Jan 2020 23:32:28 +0100
To:     Marijn Suijten <marijns95@gmail.com>
Cc:     linux-bluetooth@vger.kernel.org, luiz.von.dentz@intel.com
Subject: Re: [BlueZ PATCH] shared: shell: Only omit consecutive duplicate
 history lines.
Message-ID: <20200120223228.onfe3orcusf3vhsb@kynes>
Mail-Followup-To: Marijn Suijten <marijns95@gmail.com>,
        linux-bluetooth@vger.kernel.org, luiz.von.dentz@intel.com
References: <20200118204423.494209-1-marijns95@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200118204423.494209-1-marijns95@gmail.com>
User-Agent: NeoMutt/20180716
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

On 01/18, Marijn Suijten wrote:
> Change rl_handler to append duplicate history, as long as it isn't
> identical to the last line. It prevents consecutive duplicates while
> still having an accurate overview of the most recent commands used,
> mimicking most modern shells.
> 
> This addresses my only major gripe with bluetoothctl: pressing UP does
> not retrieve the last typed command when it is a duplicate of something
> else written (much) earlier in the history. It is especially noticeable
> when needing the same command repeatedly.

Works like a charm, thank you!

I was wondering why btshell utils are so weird and never thought it was
that obvious...

-- 
Michał Lowas-Rzechonek <michal.lowas-rzechonek@silvair.com>
Silvair http://silvair.com
Jasnogórska 44, 31-358 Krakow, POLAND