Ignoring entries starting with space

Ignoring entries starting with space

[Francesc Rocher]

[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]

Hello all,

The same way it is possible to delete duplicates in minibuffer history, I
think it is also very useful to have the possibility to ignore entries
starting with space(s). The new variable `history-ignore-space' would take
care of this, being `nil' its defaut value.

Here you can see the changes needed.


Index: lisp/cus-start.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/cus-start.el,v
retrieving revision 1.136
diff -u -r1.136 cus-start.el
--- lisp/cus-start.el    27 Mar 2009 16:50:25 -0000    1.136
+++ lisp/cus-start.el    21 Jun 2009 21:17:22 -0000
@@ -216,6 +216,7 @@
                  (choice (const :tag "Infinite" t) integer)
                  "22.1")
          (history-delete-duplicates minibuffer boolean "22.1")
+             (history-ignore-space minibuffer boolean "23.2")
          (read-buffer-completion-ignore-case minibuffer boolean "23.1")

          (minibuffer-prompt-properties
Index: src/minibuf.c
===================================================================
RCS file: /sources/emacs/emacs/src/minibuf.c,v
retrieving revision 1.362
diff -u -r1.362 minibuf.c
--- src/minibuf.c    17 Mar 2009 04:37:41 -0000    1.362
+++ src/minibuf.c    21 Jun 2009 21:17:26 -0000
@@ -61,6 +61,10 @@

 int history_delete_duplicates;

+/* No entries starting with space. */
+
+int history_ignore_space;
+
 /* Non-nil means add new input to history.  */

 Lisp_Object Vhistory_add_new_input;
@@ -776,6 +780,12 @@
   else
     histstring = Qnil;

+  /* Make sure the string must be strored.  */
+  if (history_ignore_space
+      && !NILP (histstring)
+      && SREF (histstring,0) == ' ')
+    histstring = Qnil;
+
   /* Add the value to the appropriate history list, if any.  */
   if (!NILP (Vhistory_add_new_input)
       && SYMBOLP (Vminibuffer_history_variable)
@@ -2156,6 +2166,12 @@
 elements are deleted from the history list.  */);
   history_delete_duplicates = 0;

+  DEFVAR_BOOL ("history-ignore-space", &history_ignore_space,
+               doc: /* *Non-nil means to ignore entries starting with
space.
+If set to t, elements starting with space are not stored into the
+history list.  */);
+  history_ignore_space = 0;
+
   DEFVAR_LISP ("history-add-new-input", &Vhistory_add_new_input,
            doc: /* *Non-nil means to add new elements in history.
 If set to nil, minibuffer reading functions don't add new elements to the



If you like the idea I can install them in the trunk for release 23.2.

-- Francesc Rocher

[-- Attachment #2: Type: text/html, Size: 2909 bytes --]

Re: Ignoring entries starting with space

[Juri Linkov]

> The same way it is possible to delete duplicates in minibuffer history, I
> think it is also very useful to have the possibility to ignore entries
> starting with space(s). The new variable `history-ignore-space' would take
> care of this, being `nil' its defaut value.

I think it's good since bash provides this option in HISTCONTROL
and it is useful:

  HISTCONTROL
    A colon-separated list of values controlling how commands are saved
    on the history list.

    If the list of values includes ignorespace, lines which begin with
    a space character are not saved in the history list.

    A value of ignoredups causes lines matching the previous history
    entry to not be saved.

    A value of ignoreboth is shorthand for ignorespace and ignoredups.

    A value of erasedups causes all previous lines matching the current
    line to be removed from the history list before that line is saved.

We already have `history-delete-duplicates' that corresponds to the bash
option `ignoredups'.  So a new option that corresponds to `ignorespace'
would be good too.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Ignoring entries starting with space

[Stefan Monnier]

> The same way it is possible to delete duplicates in minibuffer history, I
> think it is also very useful to have the possibility to ignore entries
> starting with space(s). The new variable `history-ignore-space' would take
> care of this, being `nil' its defaut value.

Could you explain some use cases?


        Stefan

Re: Ignoring entries starting with space

[Juri Linkov]

>> The same way it is possible to delete duplicates in minibuffer history,
>> I think it is also very useful to have the possibility to ignore
>> entries starting with space(s). The new variable `history-ignore-space'
>> would take care of this, being `nil' its defaut value.
>
> Could you explain some use cases?

I have one use case where this will be useful.

In http://thread.gmane.org/gmane.emacs.devel/91359/focus=92106
I suggested a piece of code for .emacs that removes potentially
dangerous commands from the minibuffer history.

With a new variable `history-ignore-space'=t this will be unnecessary
since it's possible to not put dangerous commands to the minibuffer history
with just prepending a command with a space like e.g. " rm -rf ."

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Ignoring entries starting with space

[Francesc Rocher]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

> >> The same way it is possible to delete duplicates in minibuffer history,
> >> I think it is also very useful to have the possibility to ignore
> >> entries starting with space(s). The new variable `history-ignore-space'
> >> would take care of this, being `nil' its defaut value.
> >
> > Could you explain some use cases?
>
> I have one use case where this will be useful.
>
> In http://thread.gmane.org/gmane.emacs.devel/91359/focus=92106
> I suggested a piece of code for .emacs that removes potentially
> dangerous commands from the minibuffer history.
>
> With a new variable `history-ignore-space'=t this will be unnecessary
> since it's possible to not put dangerous commands to the minibuffer history
> with just prepending a command with a space like e.g. " rm -rf ."
>


Yes, that's the point. In general, any potentially dangerous command won't
be stored
into the history by simply pre-pending an space. Its the same as in Bash,
the source
of inspiration of this patch, especially when you are typing dangerous
commands
as root. It's better not to store them into the history.

-- Francesc Rocher

[-- Attachment #2: Type: text/html, Size: 1571 bytes --]

Re: Ignoring entries starting with space

[Stefan Monnier]

>> In http://thread.gmane.org/gmane.emacs.devel/91359/focus=92106
>> I suggested a piece of code for .emacs that removes potentially
>> dangerous commands from the minibuffer history.

There are many minibuffer history variables.

> Yes, that's the point.  In general, any potentially dangerous command
> won't be stored into the history by simply pre-pending an space.
> Its the same as in Bash, the source of inspiration of this patch,
> especially when you are typing dangerous commands as root.
> It's better not to store them into the history.

Most minibuffer input is not commands but just "data" (e.g. file names).
So maybe, you should write something more specific that only applies to
those cases where the input takes the form of a (shell) command.

Having a blanket "throw away anything startign with a space for any
minibufffer input" sounds a bit too radical to me.  After all, bash only
applies this rule to the history of commands, doesn't it?


        Stefan

Re: Ignoring entries starting with space

[Juri Linkov]

> Most minibuffer input is not commands but just "data" (e.g. file names).
> So maybe, you should write something more specific that only applies to
> those cases where the input takes the form of a (shell) command.
>
> Having a blanket "throw away anything startign with a space for any
> minibufffer input" sounds a bit too radical to me.  After all, bash only
> applies this rule to the history of commands, doesn't it?

This feature is useful not only for commands, but also for other
minibuffer history variables.  I use the minibuffer history lists
as "bookmarks" saved in .emacs.desktop to keep most often used items
(shell/compile/grep commands and Emacs commands, file and directory names,
search and replace strings) that can be quickly retrieved via
minibuffer history search commands.  However, this have one problem:
history lists become polluted with one-off items that are unlikely
to be reused later.  So periodically I have to purge manually the
history lists using a special command `delete-history-element'
(http://thread.gmane.org/gmane.emacs.devel/24353/focus=25269).

But this cleaning takes too much time.  Much better would be to have
a special feature to not add undesirable items to the history at all.
I am not saying that a leading space is the best way to do this.
For example, I use C-RET to quit Isearch without adding the search
string to the search ring:

(define-key isearch-mode-map [(control return)] 'isearch-exit)
(add-hook 'isearch-mode-end-hook
          (lambda ()
            ;; On typing C-RET
            (when (eq last-input-char 'C-return)
              ;; Don't add the search string to the search ring
              (if isearch-regexp
                  (setq regexp-search-ring (cdr regexp-search-ring))
                (setq search-ring (cdr search-ring))))))

So maybe a configurable key like C-RET, M-RET or S-RET could exit the
minibuffer without adding the minibuffer contents to the history
as an alternative to the leading space if typing a space character
poses a problem with completion or with file names.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Ignoring entries starting with space

[Stefan Monnier]

> So maybe a configurable key like C-RET, M-RET or S-RET could exit the
> minibuffer without adding the minibuffer contents to the history
> as an alternative to the leading space if typing a space character
> poses a problem with completion or with file names.

That would inded make more sense to me.  Maybe even a separate command
that wouldn't exit but just set a local var that would then cause the
next exit to refrain from recording the data in the history (that
command could even instead just provide a way to switch to some other
history var, so you could throw stuff away by selecting a dummy history
var, but you could also choose some other history var if you so wanted).


        Stefan

Re: Ignoring entries starting with space

[Lennart Borgman]

On Fri, Jun 26, 2009 at 12:57 AM, Stefan
Monnier<monnier@iro.umontreal.ca> wrote:
>> So maybe a configurable key like C-RET, M-RET or S-RET could exit the
>> minibuffer without adding the minibuffer contents to the history
>> as an alternative to the leading space if typing a space character
>> poses a problem with completion or with file names.
>
> That would inded make more sense to me.  Maybe even a separate command
> that wouldn't exit but just set a local var that would then cause the
> next exit to refrain from recording the data in the history (that
> command could even instead just provide a way to switch to some other
> history var, so you could throw stuff away by selecting a dummy history
> var, but you could also choose some other history var if you so wanted).

And that command could also be a toggle which informed the user about
the state (ie that the input would not (or would) be saved in the
history list).

Re: Ignoring entries starting with space

[Francesc Rocher]

[-- Attachment #1: Type: text/plain, Size: 1864 bytes --]

On Fri, Jun 26, 2009 at 1:03 AM, Lennart Borgman
<lennart.borgman@gmail.com>wrote:

> On Fri, Jun 26, 2009 at 12:57 AM, Stefan
> Monnier<monnier@iro.umontreal.ca> wrote:
> >> So maybe a configurable key like C-RET, M-RET or S-RET could exit the
> >> minibuffer without adding the minibuffer contents to the history
> >> as an alternative to the leading space if typing a space character
> >> poses a problem with completion or with file names.
>

I agree that this solution is much better than the initial one "discarding
by space".
I would start to implement this one.


> > That would inded make more sense to me.  Maybe even a separate command
> > that wouldn't exit but just set a local var that would then cause the
> > next exit to refrain from recording the data in the history (that
> > command could even instead just provide a way to switch to some other
> > history var, so you could throw stuff away by selecting a dummy history
> > var, but you could also choose some other history var if you so wanted).
>


> And that command could also be a toggle which informed the user about
> the state (ie that the input would not (or would) be saved in the
> history list).
>

I think all this could be done by a combination between toggling the status
of
the `history-add-new-input' variable and a mode-line indicator (or a
different
face or background for the strings written in the minibuffer).

To switch the history variable while you are typing at the minibuffer seems
more
complex and confusing, because this could have conflicts with the variable
from
which you can currently recall previous commands or text.


By the way, several years ago I wrote `minued', a minibuffer history editor
for JED
http://jedmodes.sourceforge.net/mode/minued/
Is there something similar for Emacs?
Do you think it would be worth having it for Emacs?

-- Francesc Rocher

[-- Attachment #2: Type: text/html, Size: 2800 bytes --]

RE: Ignoring entries starting with space

[Drew Adams]

It is better not to have the key that does this also exit the minibuffer.

That is, it is better to have exiting be independent of this. There can be
multiple ways to exit, including, with customization, multiple keys for exiting
in different ways. This action is logically independent from exiting, and it
should be kept independent, so that you can combine it with any possible exit
behavior.
 
My own preference for this kind of thing is to have a user option, say
`save-input-in-history-flag', and then to have a simple command to toggle it,
bound in a minibuffer keymap. That is, just this:

(defcustom save-input-in-history-flag t
  "Non-nil means save minibuffer input in a history variable."
  :type 'boolean :group 'whatever)

(defun toggle-save-input-in-history ()
  (interactive)
  (setq save-input-in-history-flag
        (not save-input-in-history-flag)))
 
Code can also bind the variable, to change behavior locally.

The key binding for such a command need not be one that is particularly
easy/quick or repeatable. This is not something that you will do very often or
something that you will repeat multiple times. A key with prefix `C-x' would be
fine for this. 

A design question is whether this action should affect only the current
minibuffer input or also subsequent inputting. I would keep it simple and do as
described above: a simple toggle, which affects the global state. In that case,
for a one-off you would need to toggle twice.

Another possibility that I'd favor is to use not a boolean flag but a regexp, to
be matched against the input that is returned. If it matches, then the input is
not saved.

The advantage of this approach is that a command could bind the variable to a
particular regexp (e.g. that matches a whitespace prefix), to save all inputs
except those that match (e.g. start with a space). This approach gives the
command additional control.

A toggle could still work with a regexp-valued option. Turning such filtering
off could be done with a nil value or a regexp that matches everything. To turn
it back on, we would need to have saved the last non-match-everything value.

Re: Ignoring entries starting with space

[Juri Linkov]

> By the way, several years ago I wrote `minued', a minibuffer history editor
> for JED
> http://jedmodes.sourceforge.net/mode/minued/
> Is there something similar for Emacs?
> Do you think it would be worth having it for Emacs?

There is `list-command-history' for the history of commands only,
but the same would be useful for other history lists as well.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Ignoring entries starting with space

[Stefan Monnier]

> To switch the history variable while you are typing at the minibuffer
> seems more complex and confusing, because this could have conflicts
> with the variable from which you can currently recall previous
> commands or text.

That wouldn't be a conflict: it'd part of the defined behavior (i.e. it
wouldn't be a bug but a feature).


        Stefan