obsidian-solve
obsidian-solve copied to clipboard
LiamRiddell
Support referring to previous values via automatic variables
I'd love to be able to refer to previous calculations in the same file via a line number reference, similar to the feature of Soulver.
This allows me to break down calculations into multiple lines to self document steps.
@pgebheim Hello! Variables are already supported in a limited state (They are scoped to what is visible on screen for performance). You can find it in the Variables page in the wiki.
Indeed! I'm looking more for the line-number variables so you can reference a certain line in the file via an automatically variable for a quick calculation.
Can also think of this as result references.
I understand, that's a good idea. However, are you using a plugin to show line numbers in Obsidian? I think it could still be useful to add. Thank you for the feature request!
Good point with the line numbers...
Maybe there's another way to end up with similar functionality without using line numbers.
Auto-generate a line variable with a short name and include it with the result text?
One weird thing with line numbers is you need to reflow variables as lines are added. Although I used this all the time in soulver it's not necessarily the best ux.
I think the best course of action would be to introduce two modes for Variables.
- Viewport Scoped - How it works today and is by far the most performant.
- Global Scoped - Search the whole document for variables this would be less performant.
This would allow the user to pick which mode they want based on the average size of documents they use. However, right now, a refresh of variables is later in the roadmap.
I love the idea of variables. That would absolutely help with some work I'm doing at the moment. I think that global scoped is the most predictable, but definitely less performant.
It might also be good to be able to give specific names. Perhaps if the line begins with var_name = then it uses that name?
This is useful to me. At minimum a $$ variable for "last solve by some line above" would be great.
This is useful to me. At minimum a
$$variable for "last solve by some line above" would be great.
Love this version
Thank you all for thoughts. I like the ideas proposed. On average, would you say your documents are a few hundred lines or thousands? I'm trying to understand whether to just implement global variables which will auto-disable on large documents which would impact performance.
It varies for me. I've definitely used solve in documents with [1..5] thousand lines due to the way that I wrap at 80 characters in strict markdown mode.
I think that it is a good thing to be concerned about global scope and performance at this point. File scope is something easy to remember and works super well when looking at automatically generated files (like daily) that use variables.
Having a specific global variable file (or selected imports) would allow file-variables to work.
On Mon, Nov 20, 2023 at 9:50 AM Ara Adkins @.***> wrote:
It varies for me. I've definitely used solve in documents with {1..5} thousand lines due to the way that I wrap at 80 characters in strict markdown mode.
— Reply to this email directly, view it on GitHub https://github.com/LiamRiddell/obsidian-solve/issues/6#issuecomment-1819326411, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACMIABXLJUWOF4QFGDPKH3YFN35RAVCNFSM6AAAAAA4CQJNJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJZGMZDMNBRGE . You are receiving this because you commented.Message ID: @.***>
Yeah I absolutely wouldn't expect this to work in the global scope between notes. Just in the scope of a given file.
That said, having a specific file like @roaet has mentioned would be pretty cool to define useful constants.
There's an issue I added to support import statements. I think import statements would be a more-better solution than a predefined or configurable global file.
On Mon, Nov 20, 2023 at 10:17 AM Ara Adkins @.***> wrote:
Yeah I absolutely wouldn't expect this to work in the global scope between notes. Just in the scope of a given file.
That said, having a specific file like @roaet https://github.com/roaet has mentioned would be pretty cool to define useful constants.
— Reply to this email directly, view it on GitHub https://github.com/LiamRiddell/obsidian-solve/issues/6#issuecomment-1819374362, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACMIAGUZXSQY3NOLJM5QYLYFN7AZAVCNFSM6AAAAAA4CQJNJSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJZGM3TIMZWGI . You are receiving this because you were mentioned.Message ID: @.***>
Thank you for all for the feedback. There are some really exciting ideas here. ❤️
I think in the short-term, I'll try introducing a reserved variable name of $$ to refer to the previous result. And for the long term, I like the idea of imports/include statements but that's going to take a lot of work to get it right due to dealing with edge-cases such as circular dependencies, duplicate variable definitions, etc. Additionally, I won't have much time over the next few months due to work/personal commitments.
Based on all of the above, we'd be looking at that as a post 1.0.0 release of Solve. Which hopefully, will have a bigger community to help support such amazing functionality!
$$ is definitely a great start. Would it be much more work to just have line results just be named $0, $1, ... and so on? That way we have some way of building complex computations even if we can't define names ourselves.
Hello all, a bit of an update.
While working on the above I have previous results working great. However, the syntax will be $prev because $$ conflicts with MathJax expressions in Obsidian. This makes me think since MathJax uses $ extensively we could use : prefix instead for example:
100 + 2 - $costOfEggsbecomes100 + 2 - :costOfEggs$prev + 200becomes:prev + 200$myVariable = 100becomes:myVariable = 100
What are your thoughts all regarding above?
@iamrecursion As for line number references support, I need to do some code refactoring before I tackle the bigger work that would include line numbers and includes together. However, with some early thoughts we'd need to change syntax to $L24 or :24 if we move to the non dollar prefix.
I've no issue with : as the prefix!
To clarify, I wasn't actually suggesting actual line numbers in this case! Just having each solve line be sequentially numbered starting at :1. I imagine this results in the same complexity, however!
Numi (https://numi.app) has the "prev" feature, and I'm really missing it in Solve, so I wholeheartedly +1 it :-)
Numi also has other similar keywords like "sum", which is very useful – sums up all the rows above until an empty line. (Also "average" works the same way.)
