text search and restriction lock bugs

[Samuel Wales <samologist@gmail.com>]

recent maint.  these are separate, but 1 and 3 might be related, and 1 and
2 might be related, so i hope you don't mind if i put them together.

1.

is it expected behavior that if you do a restriction lock on
a subtree, then do a text search, it will include matches
from org-agenda-text-search-extra-files?  imo it should not.

2.

if you remove the restriction lock and refresh the agenda,
it will produce different results.

imo, should act as if the restriction lock were still in place.  g
should refresh with the settings that were present at invocation.
sometimes you change buffer name, and run a new agenda, so that you
can have 2 agendas, one restricted and one not.

this makes sense if you think of refreshing as "get what i
got, but take into account file /content/ changes", instead
of "run again as if you ran the agenda from scratch".  the
restriction lock is not fontified nicely so it can be
desirable to remove it for editing.

3.

finally, a user will sometimes bind org-agenda-files to a
list that includes some of the
org-agenda-text-search-extra-files files.  to avoid showing
the same match twice, the user currently has to do
remove-duplicates.  imo the agenda could do
remove-duplicates to alleviate that burden.


-- 
The Kafka Pandemic: <http://thekafkapandemic.blogspot.com>

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
<http://www.meaction.net/2017/02/03/pwme-people-with-me-are-being-murdered-by-neglect>.