[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ding susceptibility (was: highlight failed part of isearch input)

From: Drew Adams
Subject: ding susceptibility (was: highlight failed part of isearch input)
Date: Tue, 10 Jul 2007 07:37:20 -0700

> > I find that this minor tweak to `isearch-message' helps a good deal when
> > using Isearch. It highlights, within your Isearch input, the
> > part that fails to match.
> I like it. I'd like to use your patch with following patch.
> `ding' is too noisy for me. Instead of `ding' your patch tells
> the failing of search calmly.
> +;     (ding)

Yes, but I can imagine that `ding' might be useful here to people with
difficulty seeing. Perhaps this could be configurable somehow, similar to
the way `ding' respects `visible-bell'.

I imagine that you don't simply want to customize `visible-bell' to non-nil,
yourself, because you want to hear the bell sometimes, right?

One possibility for this kind of thing might be to let `ding' accept a
second argument, which is a level of susceptibility. For example we could
have a wholenump user option `ding-threshold', whose value would be the ding
level above which `ding' actually rings the bell. The default value would be
0, meaning `ding' always rings the bell. Then, for example, this call in
isearch could be, say, (ding nil 2), meaning that the bell would ring only
if `ding-threshold' was 2 or greater.

`visible-bell' itself could be changed to respect an integer threshold
value, instead of adding a new option `ding-threshold'. In that case, there
would need to be a way to specify both (1) the flash frame vs bell choice
and (2) the threshold value (for both). Negative values could be used to do
this. However, in this case, the name `visible-bell' would no longer convey
the full meaning.

Just throwing this out for discussion. Sounds a bit ugly, I admit.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]