Eric, Thanks for your feedback. this is a seriously advance tool thanks.
I see what you are saying about the uncertainty without the confirm:yes option. In my fancy-fields solution I have one mode called update, basically each field type has some wikitext defining how to view and how to edit a given field (definition) and where I would use the edit-list macro, in cases where I want the selection features, Another mode I have is called update, basically it uses the view mode to display field content and provides a button to update, on clicking it replaces the view with the edit mode, this is where I was thinking I may save the field value so if desired it can be restored/reset after edit. If seems to me this may be the best point to capture the values for MRU most recently used history etc... rather than in a subset of cases where the edit-list macro is used. Especially if the user then clicks to close the "update/field edit" because I can discover the final value and if it changed. I point this out because perhaps edit-list is not the place for this history to be captured, although it can "consume the history", rather a more generic set of actions to invoke to set a data tiddler to a fieldname/value, for example in my update button. This could be used to log other actions to the data tiddler as well, then the MRU would just form part of the filter used by edit-list to find values. I suppose the question for edit-list and other macros, may be, does the designer pump up the filter parameter with the history filter? or shall we permit an additional history-filter parameter, that if used is combined with the filter parameter?. The history may only be a sortby (order in history) filter or more advanced. But, hey edit-list is already doing so much, don't be distracted by me :) Regards Tones On Monday, 26 July 2021 at 17:50:47 UTC+10 Eric Shulman wrote: > On Monday, July 26, 2021 at 12:10:01 AM UTC-7 TW Tones wrote: > >> If you area interested for a future enhancement, this is very appropriate >> to the edit-list widget, I would think it somewhat trivial each time the >> value of a field is selected/set to record it in a data tiddler so we can >> get the most recently used values, perhaps lifting it to the top of the >> list, so we get the possible values in order of use frequency (as the >> history list does). >> > > Hmm... it may be possible to use such a field/value "history" tiddler to > create a self-modifying use of edit-list, where values that are entered by > hand are then automatically added to the list filter, so that the next time > you use that specific edit-list instance, the list contains all the > previously entered values. One problem I anticipate is that it may create > a "refresh loop", so it might only be practical to do this when using the > confirm:yes option, as it defers the actual updating of the stored value > until after the "save" button is pressed. > > Let me think about this for while. I'd like to ensure that the current > implementation is stable and reasonably bug free before I dive into adding > such a significant new feature. > > -e > -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/627eab05-f068-4fa0-b405-1b2ada439d04n%40googlegroups.com.
