resume a helm session without previous input?

[mooseyboots]

i just discovered the :resume keyword for helm, and i wanted to use it with helm-dictionary, which with three dictionaries enabled takes a long time (too long) to load.

but when i set resume to t, the session does reappear when i call helm-dictionary, but narrowing is already in effect according to my previous input. and there is no new input, neither as :input nor :default.

what i would like to be able to do is resume the previous session, but with a new input, ideally one that i would provide programmatically when calling helm-dictionary, so the session would instantly resume with narrowing to my new input, and i wouldn't need to provide any new information.

is this possible with `:resume', or is there perhaps another way to workaround this?

[thierryvolpiatto]

mooseyboots ***@***.***> writes:

i just discovered the :resume keyword for helm, and i wanted to use it with helm-dictionary, which with three dictionaries enabled takes a long time (too long) to load. but when i set resume to t,

You don't have to do that, this flag is used only to notify helm to NOT resume its session, by default resuming is enabled unless you specify it with 'noresume.

the session does reappear when i call helm-dictionary, but narrowing is already in effect according to my previous input. and there is no new input, neither as :input nor :default.

Yes, this is what resume is for: restituing exactly what you had before quitting (or exiting).

what i would like to be able to do is resume the previous session, but with a new input, ideally one that i would provide programmatically when calling helm-dictionary, so the session would instantly resume with narrowing to my new input, and i wouldn't need to provide any new information.

This would not be a resume session but a new one with a new input ;-)

is this possible with `:resume', or is there perhaps another way to workaround this?

No, the only approach I see is rewriting helm-dictionary source to make it faster with possibly cached candidates.

…

-- Thierry

[thierryvolpiatto]

Note that here with two sources (fr_en and en_fr) + the online source, performances are correct, not specially fast but really usable.

[mooseyboots]

thanks @thierryvolpiatto for clarifying the :resume keyword for this helm newbie.

caching would be cool, but for now i'll go with my other solution: modifying helm-dictionary so it can be called with only one dictionary enabled.

with three dictionaries in use, helm-dict performance is slow enough for me to avoid calling it and call other dicts (even online dicts are faster). mooseyboots/helm-dictionary@de34f04

but also for me, each dict is a diff lang pair, and each time i call helm-dict i usually only want to search in one of them.

[thierryvolpiatto]

mooseyboots ***@***.***> writes:

thanks @thierryvolpiatto for clarifying the :resume keyword for this helm newbie. caching would be cool, but for now i'll go with my other solution: modifying helm-dictionary so it can be called with only one dictionary enabled. with three dictionaries in use, helm-dict performance is slow enough for me to avoid calling it and call other dicts

You should report your issue on helm-dictionary, with a link to your dictionaries so that we can reproduce issue, then we will see if performances can be improved for such large directories.

…

(even online dicts are faster). ***@***.*** but also for me, each dict is a diff lang pair, and each time i call helm-dict i usually only want to search in one of them. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.*Message ID: ***@***.***>

-- Thierry

[thierryvolpiatto]

I installed a change that makes initialization of in-file source much faster (see commit 2f89214).