Uh...right. Of course. Obvious.
Ok..let's see if I can follow what you're doing. First, you're parsing the list of indices - instead of the list of source items. Which means...probably much faster operation as the selected indices are going to be less that the source list. Make sense.
Now you're...selecting an item from the list and if it's non-nil continue. Then you add to the include list. And at the same time delete from the source list...yielding the not-included list on finish. Simple.
Couple questions come up:
1. What is the purpose of the initial (reverse)? Because these lists (at least one of them) themselves get added to other lists later the order is irrelevant - I'll need to run a sort afterwards regardless.
2. The apparently redundant (setq a (nth i thelist)) in the (cons - was that a simple oversight in a quick post or were you waiting to see if I caught it? Or is there a purpose I'm not seeing?
3. My initial setup has "indices" as strings - so I needed to adjust (nth i thelist) into (nth (atoi i) thelist). However - that had a side effect that if the "indices" list is empty - the function will always select the first item. I started with these lines in the calling function:
(setq lst_split
(split_via_indices2 lst_available
(LM:str
->lst lst_highlighted
" ")))
and changed to:
(setq lst_split
(split_via_indices2 lst_available indices
))
Now I no longer need the (atoi) in the split function and all is well.
4. In terms of "expense" - how much overhead does "vl-remove" add to the processing? I'm assuming since you recommended it it's a good choice - for some reason I got it stuck in my head that the "vl-" functions in general are "bad" and additionally I somehow thought direct list manipulation would be expensive as well. I'm probably wrong thinking all around - I'd appreciate a cognitive recalibration here.