> Maybe the behavior is wrong - but if the problem is that it is
> _still selected_ (i.e. hilight goes away when you select something
> else), it's not something that can be solved with anything to do
> with visual attributes only.
> That was why I was asking for clarification whether it is _still
> selected_, or just _still hilighted_.
Ok, I understand your point now. We are mixing two different things
here. The X11 selection will keep until you select other thing clicking in
other point (like you said in your previous mail). But we can control our
Selection data structure (Selection sel).
> I wasn't able to view the video or run st at the time when you
> posted the video... now I've run st and confirmed that the problem
> is that it is _still selected_. I can work on a patch to fix this
> today.
You are talking here about our Selection data structure, and you are right,
if we mark it as not enabled (sel.bx = -1), all the problem will be fixed,
and maybe in a cleaner way.
> This really has nothing to do with the visual attribute, it's that
> the logic for removing the selection when its content changes
> (whether by erasing or by text being printed within it) is broken or
> missing.
We can test it in tclearregion in this form:
for(y = y1; y <= y2; y++) {
term.dirty[y] = 1;
for(x = x1; x <= x2; x++) {
if(selected(y, x))
selclear(NULL);
term.line[y][x] = term.c.attr;
memcpy(term.line[y][x].c, " ", 2);
}
}
If all the people like this solution, I can send the patch.
