Created attachment 156910 [details] [review]
Don't add duplicates to the history

When the user runs the same command as the last one saved there
is no need to save it again, otherwise we the history might end
up having lots of dupes which makes searching for an old command
harder.

Review of attachment 156910 [details] [review]:

Could use a comment "// Avoid saving duplicates".

May be better idea is save last command and remove dups.

(In reply to comment #3)
> May be better idea is save last command and remove dups.

Sorry pushed it before seeing your reply.

So you are proposing to to remove all duplicates from the list?

ex:
a
b
c
d
a
d
a

You'd only save
b
c
d
d
a

?

(In reply to comment #4)

> You'd only save
> b
> c
> d
> a
> 
> ?

(In reply to comment #4)
> (In reply to comment #3)
> > May be better idea is save last command and remove dups.
> 
> Sorry pushed it before seeing your reply.
> 
> So you are proposing to to remove all duplicates from the list?
> 
> ex:
> a
> b
> c
> d
> a
> d
> a
> 
> You'd only save
> b
> c
> d
> d
> a
> 
> ?
yes. I can expect that last command is a.

Created attachment 156915 [details] [review]
Avoid saving any duplicates in the history

Instead of avoiding duplicates only at the end of the list,
avoid them altogether.

(In reply to comment #2)
> Review of attachment 156910 [details] [review]:
> 
> Could use a comment "// Avoid saving duplicates".

Gah ... I pushed the version without the comment :/

Mmmh, the pushed version is what good old bash is doing (when HISTCONTROL=ignoredups is set) ...

Created attachment 156918 [details] [review]
[runDialog] Avoid saving any duplicates in the history

*) Use filter() instead of a loop ...

Florian has a valid point though ... so not sure which version we actually want.

Created attachment 156920 [details] [review]
[runDialog] Avoid saving any duplicates in the history

(In reply to comment #9)
> Mmmh, the pushed version is what good old bash is doing (when
> HISTCONTROL=ignoredups is set) ...

It can be configurable.
In my opinion, The most useful in history is last command. So I should expect it.
Example:
a
....[long list]
a
What I expect see when put 'up arrow'?

(In reply to comment #12)
> In my opinion, The most useful in history is last command.

Definitively true, but I think both patch versions do that already (I didn't apply the new one, but at least the pushed one does).

I don't think it makes sense to add an option for this - this is gnome after all ;)

Seriously, the first patch is slightly faster and catches a good part of duplicates, the second patch is slightly slower and catches all duplicates - just pick one and be done with it ...

(Note that this does _not_ count as review)

I've no experience with Bash's IGNOREDUPs, but I would find it annoying if 'ls' was thousands of commands up in my history because I first typed it on this machine months ago. It seems right that typing a command should move it to the closest part of the history.

(In reply to comment #14)
> I've no experience with Bash's IGNOREDUPs, but I would find it annoying if 'ls'
> was thousands of commands up in my history because I first typed it on this
> machine months ago. It seems right that typing a command should move it to the
> closest part of the history.

Err ... that is not how the patch works .. it would remove the ls that is "thousands of commands up in the list" and add the new one to the end of the list.

So "...,ls,...." you type ls it ends up being "......,ls".

(I don't have a strong opinion on which one should go in though)

(In reply to comment #14)
> It seems right that typing a command should move it to the
> closest part of the history.

My point here was that both patches should behave like this already (though I only ran the pushed one).

(IGNOREDUPS reduces repeated commands to a single history entry - so "ls; ls -a; ls; ls" would become "ls; ls -a; ls")

Let's go with the pushed patch.