How should be positioned recently used items at identifier completion list

[WooBean]

At configuration panel for Idenfifier Completion [Tools > Options > Codetools > Identifier Completion]  there is an option "Show recently used identifier on top". Despite this clear description such identifiers can be placed not on top but (in some situations) somewhere below (especially when code completion is invoked by CTRL + SPACE - not by pressing "." after some identifiers where it is appropriate).

Such behaviour of Lazarus IDE can be explained by the  idea to propose identifiers which can be more "matching"  a context of source code.

Since Lazarus 3.0 RC1 (since commit 761e1107bb52b1051560a540e2b70e41135e83a9) exist options to define color of recently used items presented at identifier completion hint window and a limit of those items displayed.

My opinion is that that identifiers should be definitively at top of list (as it is decribed at configuration box).
What is your opinion?

[Thaddy]

LIFO: Last used on top.

[WooBean]

Let's imagine a scenario - we have selected several identifiers via identifier completion tool (option "Show recently used identifiers at top" is active and value "History items limit" is set to 5) and we start writing a prefix while identifier completion window is active.

How should be filtered and positioned recent identifiers?
(They are coloured, so it is clear that they were recently used).

For me, the best choice would be to keep the highest priority for matching prefix and mark recent identifiers by colouring - it  will/would produce a list order with recent items not on top of list. 

[Martin_fr]

Bit of background.

*** There are 3 sort orders (used to be 2)
- alphabetic
- scoped, then alphabetic
- scoped, then pos in source (new in 3.0)

scope means: current procedure, then class, then parent .., then current unit, ... (need to lookup all the details)

The true sorting behind those is more complex

Items have different "compatibility" => how well does the item match the context.

1)  "read" or "write" when completing "property foo: int64 " have the highest quality.
2) under some (not sure which) condition: certain unit names
3) identifiers
4) random words found in the unit

Items are sorted into those groups. Recent used items are also sorted into those groups (so a recent used "random word" is at the top of that group, but other groups are above)

Also items only containing the current typed letters (not matching as prefix, but only containing) are always sorted below anything that matches the prefix as prefix

*** Content of the completion list
The following can be toggled on/off (from memory)
- "code templates" (otherwise ctrl-j)
- random words from unit(s)
- more keywords

Afaik the above is true for 2.2.6 and 3.0 and 3.99 (there were changes between those/ 3.99 has ordering changes)

*** filter prefix or contained
Completing "MyObj.B" will show
- any field/method starting with "B"
- can optional include items containing "B" in the middle



Then there are a few question about recent items: sorting / limit / grouping


Limit:
The history holds overall 30 items.
But the current list may not contain all of them (e.g. if you completed the local var "LocalInProcFoo", and are now invoking completion in procedure Bar, and bar does not have this, then "LocalInProcFoo" is not in the proposed completion. So it wont show.
A limit of 5 would then mean 5 items that are in the current list AND in the memory for recent. (probably expected / only pointing out for the next bit)

Now you may have 20 recent items in the current list (most recent first) a1,a2,a3,a4,a5,b1,b21,b22,b3,b4,b5,c1...
- With a limit of 5 and completion opened after a space (no prefix to filter) you will see the 5 items starting with "a" (expected)
- typing a "b" of prefix and you will see 5 items starting with "b" as recent.

In other words a limit of 5
- is not just the most recent 5 (and then less, if they get filtered out)
- it is the 5 most recent that haven't been filtered out.

So here is the first question: Expect "just the most recent 5" or "the most recent 5 that are visible after filter" (if there are that many avail)


Order:
As described: bound to group.
If you completed with a "random word from unit", then it will be below all the fields/variables/....


Order:
If you have items containing the filter in the result.
say you completed
- "Form1.C" => "Form1.Caption"
- "Form1.A" => "Form1.Cascade"
- "Form1.A" => "Form1.Align

Your recent list if you try to complete "Form1.A" will be  (and that does not matter in which order the above happened)
- Align   (because it matches the prefix / and is recent)
- Cascade (always lower, because it is not a prefix, but contains
  This violates "contains is always below", this is up here because you have recently used it via contains.
  But it is still within the recent group, below any recent matching as prefix
- other possible identifiers
- Cascade (only matches as "contains", but was never used via "contains")



template vs variable:
If you complete a variable named "b" then the template named "b" will be marked as recent.
IMHO a bug => the template should only be history if it was used as such.


There probably is more....

For me, the best choice would be to keep the highest priority for matching prefix and mark recent identifiers by colouring - it  will/would produce a list order with recent items not on top of list.

This is something I had not realized in our recent conversion. (Maybe I missed it / or forgot it at some point) This may be a good idea.

E.g. this could happen, if history is turned off - but a color is configured.

[WooBean]

...

So here is the first question: Expect "just the most recent 5" or "the most recent 5 that are visible after filter" (if there are that many avail)

At this point I could vote for version  "the most recent 5 that are visible after filter" (if there are that many avail). In practice it will look like the picture below.

So the final rule could be:
if prefix is empty then show <limit count> available recent identifiers at top, otherwise mark as recent first <limit count> filtered identifiers with its HistoryIndex less then history buffer capacity.

[WooBean]

So the final rule could be:
if prefix is empty then show <limit count> available recent identifiers at top, otherwise mark as recent first <limit count> filtered identifiers with its HistoryIndex less then history buffer capacity.


In addition to the previous I think that description of the option "Show recently used items at top" should by changed to reflect a new identifier completion behaviour.

Maybe this?
   
Checkbox caption: "Mark recently used items"
+
Hint (for checkbox): "Show at top - if not filled a prefix for items at the list".

In my opinion the feature is so convenient that average (and above) user will prefer this.

[Чебурашка]

My opinion is that that identifiers should be definitively at top of list (as it is decribed at configuration box).
What is your opinion?

One possible approch could also be:

Section 1: CDLRU, context dependent last recently used with 3-5 elements = for each file have a memory of the last used and show last 3-5
Section 2: CDMFU, context dependent most frequently used = for each file have a memory of most frequently used and show most > less