From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21040 invoked by alias); 3 Jun 2015 14:16:11 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 21026 invoked by uid 89); 3 Jun 2015 14:16:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_05,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: mail-ob0-f181.google.com Received: from mail-ob0-f181.google.com (HELO mail-ob0-f181.google.com) (209.85.214.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 03 Jun 2015 14:16:09 +0000 Received: by obbea3 with SMTP id ea3so8704846obb.0 for ; Wed, 03 Jun 2015 07:16:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=YwUfQOAB0EjT9GusHZCvBjobRNZGnxr/PyCmVieLFMc=; b=jn0VAO4cKbGBvDiDnWfYUOS1etfeDOlHEraVQRZi+H0o/iGwN1/fT735Xz++3r0raQ D+fMuxIiVEKZFG5QhKaUn6IB2E6rMsxDYVqQTTzqYS2N9rDn+pegU7znqc14tmjkOLMr JKYju5ztXaGf9iFQEAcb6cExuTEerBTveOYamlp4gFhqTof9m8q+/Cb3mQPcfH1LnVFX 4iJPH/xfVmCTLgG3yW3uXN2VR/hyMUK8zBEq4kWvoP/BqnQx3L2lD3q88Pd3fxCtmE4S yX2fUENM8Dqv3UaIT0Ch/sUi5pJsuIy426rfvNfmol2MeT3OnsOewPnjOL9yUA1DHOEh v2dA== X-Gm-Message-State: ALoCoQml6uVq3j2rDWGXZkwsNHFcdMSLPm842mEPmcT1IM2NKPTn6MKVmeTV+3aZtEmEgG5djG6u X-Received: by 10.60.125.169 with SMTP id mr9mr27264823oeb.14.1433340967923; Wed, 03 Jun 2015 07:16:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.96.167 with HTTP; Wed, 3 Jun 2015 07:15:47 -0700 (PDT) In-Reply-To: <20150603082036.GR17330@embecosm.com> References: <1433301766-20101-1-git-send-email-patrick@parcs.ath.cx> <20150603082036.GR17330@embecosm.com> From: Patrick Palka Date: Wed, 03 Jun 2015 14:16:00 -0000 Message-ID: Subject: Re: [PATCH] Prune duplicate command history entries To: Andrew Burgess Cc: "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-06/txt/msg00039.txt.bz2 On Wed, Jun 3, 2015 at 4:20 AM, Andrew Burgess wrote: > * Patrick Palka [2015-06-02 23:22:46 -0400]: > >> This patch implements pruning of duplicate command-history entries using >> a modest amount of lookbehind. The motivation for this patch is to >> reduce the prevalence of basic commands such as "up" and "down" in the >> history file. > > Dropping commands such as up / down could be pretty annoying if you > wanted to figure out where you were in the past. Dropping things like > bt from the history would be less annoying. > > I wonder if we should classify commands into navigation or > state-changing commands and diagnostic commands. > I'd be happier see repeated diagnostic commands disappear, and less so > for commands that change inferior state, or navigate me around the > stack. Hmm, but doesn't the empty-command shorthand already make it mostly impossible to figure out where you were in the past? If you run "up" twice by typing "up\n\n" then only one history entry for "up" gets added to the history file (with or without the patch). So you won't really be sure, by looking at your history, whether that "up"/"down"/"continue"/"step" entry was invoked once or 5 times in a row. It seems that this existing behavior throws any semblance of state recovery out the window (unless you carefully avoid using the shorthand :)). > >> The maximum lookbehind is fixed to 50 (an arbitrary number) so that the >> operation will be guaranteed to not take too long. > > I think at the very least you should make this threshold > configurable. I'd then argue for off by default due to the loss of > state changing commands being too annoying (for me). > > You should probably have some tests too, we already test C-p in > readline.exp, so it should be possible to test that this feature > works. I did not think to make the threshold configurable (as opposed to making some boolean variable configurable). That makes sense. > > Thanks, > Andrew