Storable contexts as the missing link halfway between bookmarks and sessions?

[rhogez]

• Bookmarks can not be saved “on the fly” because they depend on the environment variable NNN_BMK. When set, they do not upset the state of the current state of contexts but merely navigate the user somewhere.
• Sessions can be saved “on the fly” and given mnemonic names. When set, however, they replace the complete current set of contexts.
• Contexts somehow act as a tool between bookmarks and sessions, but they cannot be stored individually.

So the feature request is basically to allow saving individual contexts in a way that is very similar to sessions. When a saved context is set it should replace only the current context but not all contexts. There is a plugin based on the idea of using symlinks as bookmarks. That already comes close. It would, however, be great to be able also to save other features of a context like “show hidden files”, sort criteria, etc. Plus: contexts are already a part of n3. Just making them individually storable would not bloat the basic design of n3 and could probably make re-use of code and concepts already tested for sessions?

[jarun]

Seems like a good improvement to be able to save only the current context but I am not sure how complex the code would be.

@KlzXS or @leovilok can any of you take it up?

[jarun]

@rhogez it doesn't look like anyone has free time to pick this up. I don't see any use case where I will need this feature.

Please check the APIs load_session() and save_session() and see if you can work on it yourself.

[rhogez]

I'd love to have this. Don't know if my knowledge of C is sufficient but as it appears to be mostly a stripped-down version of the session functionality I guess I have a chance. Thanks for the pointer.

[jarun]

All the best! I am adding this as a line item in the ToDo and closing this defect. Note that you'll have to load the current session data and then update the dta for the specific context.

[Kabouik]

Would it be within scope to enable doing it the other way around as well? In other words, the request here is to allow saving contexts individually, and I would be curious if setting a context as "non-savable" despite -S would be doable. Perhaps the easiest would just be to save 3 contexts individually when this todo item is implemented, and leave the 4th context unsaved?

Context:

The nmail dev accepted a feature request to implement a way to invoke nnn within nmail via script for advanced manipulations of mail attachments, and to take advantage of nnn's great flexibility.

It works great but opens nnn in a temporary folder (mkdtemp -d) where mail attachments are extracted with munpack, and the name of this temporary folder changes every time a new email is extracted. This means using nnn -S in the script will makes it fail to open nnn in the right temporary folder, and not using -S prevents taking advantage of sessions and saved contexts. Saving all nnn contexts but one and starting nnn in the unsaved context would cover this.

[jarun]

I do not want any further complexity, unnecessary prompts and roundabout workflows in this perfectly working feature.

The scope is to update just the current context. Period.

[Kabouik]

I suspected it but it was worth asking what you thought about it. Maybe I'll be able to achieve what I want by saving contexts individually when this todo item is added, and leaving one unsaved for my mail client. Atworst I'll edit the nmail-nnn launch script to create non-random names for the temporary directory.

[jarun]

I don't think this is something that we need to add as a feature. You can always open a session, modify the one context you want to update and same the session. There would be no additional flexibility in this regard.