Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added the pretty brackets feature for "()", "[]" & "||" #41

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

jatin-47
Copy link
Contributor

@jatin-47 jatin-47 commented Oct 1, 2023

#32
Whenever a bracket is inserted, a corresponding invisible bracket is inserted at either end of the expression or the current block. Seeking left and seeking right are updated accordingly, making the cursor always stay in between the invisible brackets. Backspace deletion is also managed, making the invisible bracket delete whenever it's pairing bracket is deleted.

Whenever a bracket is inserted a corresponding invisible bracket is inserted at either ends of the expression or the current block. Seeking left and seeking right are updated accordingly making the cursor always stay in between the invisible brackets. Backspace deletion is also managed making the invisible bracket delete whenever it's pairing bracket is deleted.
@jatin-47 jatin-47 changed the title Added the pretty brackets feature for "()" &"[]" Added the pretty brackets feature for "()", "[]" & "||" Oct 1, 2023
@hrushikeshrv
Copy link
Owner

Hi @jatin-47, thanks for the patch 👍🏻

It mostly looks good, however one problem I noticed was the final generated LaTeX contains the invisible brackets (\left. and \right.) as well. If users nest brackets, the invisible brackets as duplicated as well.

While invisible brackets are necessary when we want to show users a preview of the equation, the correct behavior would be to only include the invisible brackets in the final generated LaTeX when we have a mismatch of opening and closing brackets.

One way to solve this could be to detect the mismatch just before the LaTeX is generated and add/remove invisible brackets as necessary, but that would add considerable complexity to the generation process.

I just thought of a better approach (IMO) - what if we include all brackets ({ }, [ ], ( ), < >) as functions in the Functions tab of the editor? Then whenever a user clicks on a bracket, the corresponding bracket pair will be inserted, without us needing to insert invisible brackets.

We could create a BracketOneBlockComponent extends OneBlockComponent class that looks something like this -

class BracketOneBlockComponent extends OneBlockComponent {
    constructor(parent, startBracket, endBracket) {
        super(parent);
        this.startBracket = startBracket;
        this.endBracket = endBracket;
    }

    toLatex() {
        return `\\left${this.startBracket} ${this.blocks[0].toLatex()} \\right${this.endBracket}`;
    }
}

Then provide this class in the Functions tab like how it is done from lines 178 to 196 in the MJXGUI constructor.

I hope I could explain my thinking.

@jatin-47
Copy link
Contributor Author

jatin-47 commented Oct 1, 2023

I thought of this method before implementing the present solution, but I discarded it because it spoils the User Experience as the brackets are present on the keyboard, and then also, if the user has to click them on the screen, it becomes annoying. 😅
IMO, giving it as a function can be the easiest way around, but doing it on our side will make it a good UX for users.
Possible fixes:

  1. Doing the post-processing of the final LaTeX to remove the invisible brackets from the main expression and all the blocks. (Easy)
    OR
  2. Changing the insertion and deletion algorithms a bit. (Medium)

Please give suggestions.

@hrushikeshrv
Copy link
Owner

IMO it would be best to just implement the brackets as functions, since even Google Docs and Microsoft Word do it that way. While it would be best UX-wise to handle the brackets using the keyboard, but the insertion and deletion algorithms would be too complex for it to be worth it (as far as I can tell).

However, if you can come up with an algorithm that gives the correct behavior (without the invisible brackets) in all cases, then that would be fine too. So I would say you can try using the second approach (changing the insertion and deletion algorithms), but if it seems too complex, then we should go with the function-based approach. I would be opposed to the first approach (postprocessing) since that would make the code bulkier and harder to maintain in the future.

@jatin-47
Copy link
Contributor Author

jatin-47 commented Oct 1, 2023

Instead of comparing with Google Docs or MS Word, we should compare with Desmos Graphing Calculator's UI for inserting equations because I find it best as per the UX is concerned.

The first approach is also not that bad because the time complexity of post processing is at max O(10^4) [as per my assumptions of max 200 expression length and block length in each component and taking 4 blocked components on average].

The second approach can be implemented.

So, for now I will update the branch with the second approach.

@hrushikeshrv
Copy link
Owner

I agree with your point about desmos. I think if we can implement that behavior correctly we should go for it 👍🏻

@jatin-47
Copy link
Contributor Author

jatin-47 commented Oct 2, 2023

Please have a look. @hrushikeshrv

@hrushikeshrv
Copy link
Owner

Hi @jatin-47, sorry for the delay. I'm a little buried in work this week, so I will need some time to review this, but I'll do it this week.

@jatin-47
Copy link
Contributor Author

jatin-47 commented Oct 7, 2023

Please have a look. @hrushikeshrv

@jatin-47
Copy link
Contributor Author

@hrushikeshrv is this project still gonna participate in Hacktoberfest or is it abandoned?

@hrushikeshrv
Copy link
Owner

Hi @jatin-47, I don't think this project will be part of Hacktoberfest. I will still be maintaining it, but I'm afraid I don't have enough time in the month of October to be reviewing pull requests by contributors.

I appreciate your contribution! If you're okay with some delay while I review your PR's, please do keep contributing. However, if you want to take part in Hacktoberfest, I'm afraid I won't be able to review your PR's fast enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants