RE: ASCII-folded search [was: Re: Upcoming loss of usability ...]

[Drew Adams]

> > It's not a separate topic if we are now discussing whether to
> > indicate char folding in the mode-line etc.
> 
> Whether char-folding is on or off (and how to indicate that) is
> orthogonal to which char-folding table the user uses.

Not if you assume, as I do, that it can be on for one kind of
char folding and off for another.  And there can be many kinds.

You see char folding as the feature to support with UI indication.
I see char foldings (one of which is case folding, BTW).  And I'm
not sure how they would best be indicated in the UI.

> That is, unless you or someone else plans on implementing the
> possibility of combining tables and toggling them individually
> (which we don't support yet).

Let's not assume anything about the possible implementations of
char-folding possibilities at this point.  (And no, I won't be
implementing them.)

 "(which we don't support yet)" -

We don't support *any* character folding yet, in any Emacs
release (except for case folding).

The point is to not assume there will only be one kind of char
folding, so that all we need is a binary mode-line indication
that it is turned on.

More than one kind of char folding is, yes, what we should aim
for, IMO, and what I thought we were aiming for.  Multiple
predefined equivalence sets, perhaps, and certainly the ability
for users to define their own equivalence classes.

So yes, I am assuming that is the goal.  And in that case it
makes little sense to propose mode-line indication now for char
folding, I think.  It would be either unworkable (too many
possibilities) or pretty useless (an all-or-none indicator
that says only that *some* folding is currently in effect).

Better would be to think, now, about how we might let users
know which foldings are in effect - whether via mode-line, an
additional line, the prompt, mode-line single-char symbols
that provide more info when hovered over or clicked, a key to
show a help buffer, or anything else.

> Ahn... do you realise that you replied twice to the same email?

No; sorry.  I received two copies from you (with different
recipient lists) and I didn't realize it.  I was doing something
else at the same time, and I apparently edited two different
replies and then sent them both.  Mille excuses.

> > But it is irrelevant to the
> > discussion of whether to indicate char folding in the mode-line.
> > How we do char folding doesn't matter in this context.
> > What is relevant is that multiple kinds of char folding mean that
> > it makes little sense to try to indicate them in the mode-line.
> >
> > IOW, we should not even think about going down that road,
> 
> So you don't want to implement a simple visual indicator, because
> this indicator might become harder to implement in the future when we
> *might* have multiple tables that can be independently applied?
> (which no one has offered to do yet, btw)

You talk in terms of an implementation (tables).  I'm talking
about a user feature: multiple char foldings, however it might
be implemented.

And yes, I think that we should, now, assume that we will, one way
or another, offer multiple char-folding possibilities.

How to indicate the foldings that are currently in effect should be
how we think about this, now.  We should not opt for a UI that we
are pretty sure now will not work for the feature we are aiming for. 

> > unless someone has a brilliant idea of how to handle a plethora
> > of char foldings.
> 
> Well, if we ever even reach that situation:
>   - If no char-folding tables are in use, the indicator will be off.
>   - If more than zero char-folding tables are in use, the indicator
>     will be on.

That's not very helpful, IMO.  And we *should* "ever even reach
that situation".  We've been talking about it for a while now.
Various implementation possibilities have been suggested, and
you have now added one as a start.

You know, *case* folding is itself one kind of char folding.
Why should we indicate it separately, if, as you seem to think,
one size fits all?

The answer is that it is important to be able to tell, for any
given folding, whether it is on or off.  We can do that, I'm sure;
we just need to think about it a bit more instead of jumping off
the dock into the first dingy we see go by.

> I wouldn't call it brilliant (and please let's not go off on a
> tangent discussing the (de)merits of this idea),

It's not a tangent.  All-or-nothing should not be how we indicate
char folding to users, IMO.

> I'm just saying we don't need to block this feature now

What feature?  Mode-line indication of char folding?  Why not
block that for now?  Why not discuss how to properly indicate
foldings instead?

It's not like it's urgent to indicate char folding in the mode
line.  We don't even indicate case folding in the mode-line!

I proposed such case indication years ago (and provided the
code).  Indicating whether search is currently case-sensitive
is as important as indicating other char foldings, no?

If we have not found it urgent to do that (and case folding
has been a feature for decades) then what's the rush to do it
for a not-yet-released, partial implementation of char folding?

Why throw something out there now that is inappropriate for
the char folding that we've been discussing and aiming toward?

> because of the future possibility of multiple independent
> char-folding tables.

Multiple char foldings, not necessarily tables (plumbing).

And yes, that is the feature to work on and discuss at this
point, IMO.  Not how to indicate the state to users.

You made, I assume, a good first step in that direction.
That's great.  I'm very thankful that we will soon have some
additional char folding beyond case folding - believe me.

Nothing prevents us from now coming up with a good way to
indicate which char foldings are currently in effect.