The last commited word seems to forgotten too soon

[psads-git]

Dear Mike,

Suppose that you commit the word

friendships

to save typing time when the word that you wanted is

friendly

Then you edit

friendships

using backspace down to

friend

and then add "ly". So what goes to the ibus-typing-booster database is "ly" and not "friendly". This behavior causes noise in the database e degrades the learning speed of ibus-typing-booster.

Best wishes!

[mike-fabian]

https://user-images.githubusercontent.com/2330175/127403203-c15c2608-f3e9-4528-b698-a2b11584591a.mp4

[mike-fabian]

The option “[✔️] Arrow keys can reopen preedit ” basically does what you want.

It is not named correctly because originally it affected only the arrow keys and backspace still reopened a preedit but as it was too buggy, I also switched it off for backspace by default.

The option should be named:

[✔️] Use surrounding text to reopen a preedit

That would better describe what it does. I didn’t yet rename it because I didn’t want to trigger retranslation of that message.

Maybe there should be even two such options:

[✔️] Use surrounding text to reopen a preedit
[✔️] Use surrounding text for context

“Surrounding text” means that the input method (here ibus-typing-booster) can ask the program (here gedit) what text is in the vicinity of the cursor and then modify that text.

That means when surrounding text works, and the cursor is moved for example left with arrow-left or backspace, ibus-typing-booster can get the contents of the line and check whether there is a word to the left of the cursor position. If yes, it can delete that word from gedit and put it back into preedit. I.e. when you type “friendships” and commit with space, then type Backspace you reach the right border of “friendships” again and the word “friendships” is deleted from gedit and put into preedit again. You see that because “friendships” suddenly becomes underlined again. Now when you continue typing backspace, you delete in the preedit and when you have “friend” left you see the correct predictions and they you can add “ly”, see reasonable predictions and commit.

Ideally, this should also work when positioning the cursor somewhere else using the mouse.

Some toolkits/programs don’t support surrounding text at all and say so. I think Qt4/Qt5 don’t support this and old X11 programs like xterm don’t. If surrounding text is not supported at all, this is not nice but at least ibus-typing-booster can know. If ibus-typing-booster asks “Do you support surrounding text” and gets a “No!” it isn’t nice but it can try to workaround as good as possible without using surrounding text. Some things are impossible to get right without surrounding text like getting a already commited work back into preedit or getting the right context after moving the cursor with the arrow keys or the mouse. With surrounding text one can fetch that context, without there is no way.

There is no toolkit/program to my knowledge which implements surroundings texts really well. Gnome/gtk programs like gedit seem to be best, but even these have very buggy surrounding text support.

So ibus-typing-booster asks gedit “Do you support surrounding text?” gets a “Yes!” and then tries to use it, but then it often doesn’t work right because all sorts of bugs.

If you switch on that option “[✔️] Arrow keys can reopen a preedit” and type not too fast into geedit, you will see that this mostly works.

But it seems to depend on speed and system load. If you type many arrow-left very quickly over a longer text, you will notice that strange things happen, sometimes ibus-typing-booster gets completely wrong information and deletes wrong things or puts wrong stuff back into the preedit.

Problems can also occur when switching focus between different windows. When switching to a new window and the window says it supports surrounding text, fetching the surrounding text almost always results in nonsense before the first commit in the new window has happened. I work around that by only using surrounding text when at least one commit has happened. And sometimes the surrounding text requests in a new window get surrounding text results from a previous window instead which messes up stuff very badly.

See for example this commit:

https://github.com/mike-fabian/ibus-typing-booster/commit/fdf1b8b84c6c9ad34dceaf91a6366b3f28348950

which avoids the mess caused by gnome-terminal and xfce4-terminal getting the surrounding text from the previous application.

[psads-git]

Thanks, Mike! But it doesn’t work with backspace (at least, in my case).

[mike-fabian]

Without good surrounding text support, the “good” behaviour we desire here is impossible to achieve. You can switch the mentioned option on and try, if you type not very fast in gedit, it mostly works.

But it is overall so buggy that it is off by default. The bugs are not the fault of ibus-typing-booster, the surrounding text support in gtk/gnome/gedit is broken (even though it is the best surrounding text support available at the moment, other programs/toolkits are even worse).

The real fix would be to implement really good surrounding text support in gtk/gedit/gnome, then this option could be on by default and would work well.

But that is very difficult, I lack expertise and time to look into that my self and there seems to have been no progress in gtk/gnome/gedit for several years. In Gnome Wayland it seems even worse.

[mike-fabian]

Thanks, Mike! But it doesn’t work with backspace (at least, in my case).

Did you switch on the option?:

 [✔️] Arrow keys can reopen preedit

[psads-git]

Yes, Mike.

[mike-fabian]

And did you type into gedit?

[psads-git]

Both in Gedit and Chrome, while commenting here, Mike.

[mike-fabian]

So moving left with backspace until you reach a word does not put that word into preedit for you, as seen in my video?

[mike-fabian]

If you are trying this on Gnome Wayland, try Gnome Xorg instead, it is even more badly broken on Gnome Wayland.

[psads-git]

No, Mike. That does not work in my case. Well, as you say, the option is buggy! :-)

I am using XFCE.

[mike-fabian]

Trying XFCE ...

[mike-fabian]

Works for me in gedit in XFCE:

https://user-images.githubusercontent.com/2330175/127407639-42339f47-8f80-4f5e-a6f8-4eb352bcfc49.mp4

[mike-fabian]

You can try to grep for “surrounding” in the log file (Debug level must be > 1 ! You can set the debug level in the setup tool).

Grep like this:

[mfabian@fedora ~]$ tail -F ~/.local/share/ibus-typing-booster/debug.log | grep -i surrounding

When typing “friendships”, committing with space, typing Backspace to reach the left end of “friendships” again, the debug log should show something like this:

[mfabian@fedora ~]$ tail -F ~/.local/share/ibus-typing-booster/debug.log | grep -i surrounding

2021-07-29 01:11:45,548 hunspell_table.py line 2750 get_context DEBUG: Getting context: surrounding_text = [text = "''", cursor_pos = 0, anchor_pos = 0]
2021-07-29 01:11:45,549 hunspell_table.py line 2759 get_context DEBUG: Skipping context from surrounding_text, no commit yet.
2021-07-29 01:11:53,160 hunspell_table.py line 2750 get_context DEBUG: Getting context: surrounding_text = [text = "''", cursor_pos = 0, anchor_pos = 12]
2021-07-29 01:11:53,160 hunspell_table.py line 2766 get_context DEBUG: Found from surrounding text: tokens=[]
2021-07-29 01:11:53,160 hunspell_table.py line 2775 get_context DEBUG: Updated context from surrounding text=“” “” “friendships”

When typing “a b c d e ” and then Backspace you should see something like:

2021-07-29 01:16:45,901 hunspell_table.py line 2750 get_context DEBUG: Getting context: surrounding_text = [text = "'a b c d '", cursor_pos = 8, anchor_pos = 10]
2021-07-29 01:16:45,901 hunspell_table.py line 2766 get_context DEBUG: Found from surrounding text: tokens=['b', 'c', 'd']
2021-07-29 01:16:45,901 hunspell_table.py line 2775 get_context DEBUG: Updated context from surrounding text=“b” “c” “d”

[psads-git]

Got the following, Mike:

$ tail -F ~/.local/share/ibus-typing-booster/debug.log | grep -i surrounding
2021-07-29 00:24:04,901 hunspell_table.py line 2750 get_context DEBUG: Getting context: surrounding_text = [text = "''", cursor_pos = 0, anchor_pos = 0]
2021-07-29 00:24:04,902 hunspell_table.py line 2759 get_context DEBUG: Skipping context from surrounding_text, no commit yet.
2021-07-29 00:24:11,357 hunspell_table.py line 2750 get_context DEBUG: Getting context: surrounding_text = [text = "'friend'", cursor_pos = 6, anchor_pos = 6]
2021-07-29 00:24:11,358 hunspell_table.py line 2766 get_context DEBUG: Found from surrounding text: tokens=['friend']
2021-07-29 00:24:11,358 hunspell_table.py line 2775 get_context DEBUG: Updated context from surrounding text=“” “” “friend”
2021-07-29 00:24:16,205 hunspell_table.py line 2750 get_context DEBUG: Getting context: surrounding_text = [text = "''", cursor_pos = 0, anchor_pos = 0]
2021-07-29 00:24:16,206 hunspell_table.py line 2766 get_context DEBUG: Found from surrounding text: tokens=[]
2021-07-29 00:24:16,206 hunspell_table.py line 2775 get_context DEBUG: Updated context from surrounding text=“” “friend” “ly”
2021-07-29 00:24:21,221 hunspell_table.py line 2750 get_context DEBUG: Getting context: surrounding_text = [text = "'friend'", cursor_pos = 6, anchor_pos = 6]
2021-07-29 00:24:21,222 hunspell_table.py line 2766 get_context DEBUG: Found from surrounding text: tokens=['friend']
2021-07-29 00:24:21,222 hunspell_table.py line 2775 get_context DEBUG: Updated context from surrounding text=“” “” “friend”

[mike-fabian]

https://user-images.githubusercontent.com/2330175/127409479-020826a2-17b0-4bac-b876-b002c0b2b5cd.mp4

[mike-fabian]

Could it be that you have NumLock on?

I just found a bug that reopening the preedit again when reaching a previous word with backspace or the arrow keys doesn’t work when NumLock is on.

Trying to fix this ...

[psads-git]

By default, I have NumLock on, Mike. However, I have just tried with NumLock off, but again with no reopening of the preedit.

[mike-fabian]

Really? Very strange. I usually have NumLock off, but had it on today and was surprised why my preedits didn’t reopen anymore.

[mike-fabian]

I don’t try to reopen the preedit if modifiers are set, CapsLock was the only exception so far, now I add NumLock as another exception.

https://github.com/mike-fabian/ibus-typing-booster/blob/master/engine/hunspell_table.py#L2624

and see the comment here:

https://github.com/mike-fabian/ibus-typing-booster/blob/master/engine/hunspell_table.py#L2661

[mike-fabian]

So could it be that any other modifier is surprisingly set in your case?

[psads-git]

Apart of NumLock and CapsLock, are there further modifiers, Mike? Maybe Insert, but it is off.

[mike-fabian]

Insert is not a modifier.

[mike-fabian]

There is ScrollLock, which is kind of weird.

[psads-git]

ScrollLock appears to have no effect in my case.

[mike-fabian]

I have added some more debugging code to the function _reopen_preedit_or_return_false()

I'll make a 2.13.1 release probably tomorrow including the new debugging code. Then

tail -F ~/.local/share/ibus-typing-booster/debug.log | grep reopen_preedit_or_return_false

might tell us why the preedit is not reopened in your case. Until now, that function made no debugging output at all.

[psads-git]

Thanks, Mike! I will try the new release as soon as it will be made available.

[mike-fabian]

A Fedora 34 build is now available here:

https://copr.fedorainfracloud.org/coprs/mfabian/ibus-typing-booster/build/2357639/

Please try:

tail -F ~/.local/share/ibus-typing-booster/debug.log | grep reopen_preedit_or_return_false

Type a few words into gedit, type BackSpace until you reach the end of a word and see what happens in the log file.

[psads-git]

Thanks, Mike! I have just found out that, if after pressing TAB I press a space, it works fine. However, without pressing the space, it does not work. Please, see the attached video.

$ tail -F ~/.local/share/ibus-typing-booster/debug.log | grep reopen_preedit_or_return_false
2021-08-03 12:13:33,843 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:33,843 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:33,843 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendship'", cursor_pos = 10, anchor_pos = 10]
2021-08-03 12:13:34,042 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:34,043 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:34,043 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendshi'", cursor_pos = 9, anchor_pos = 9]
2021-08-03 12:13:34,267 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:34,267 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:34,267 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendsh'", cursor_pos = 8, anchor_pos = 8]
2021-08-03 12:13:34,835 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:34,835 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:34,835 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friends'", cursor_pos = 7, anchor_pos = 7]
2021-08-03 12:13:41,219 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:41,219 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:41,219 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendships friendl'", cursor_pos = 19, anchor_pos = 19]
2021-08-03 12:13:41,387 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:41,387 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:41,387 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendships friend'", cursor_pos = 18, anchor_pos = 18]
2021-08-03 12:13:41,555 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:41,555 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:41,555 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendships frien'", cursor_pos = 17, anchor_pos = 17]
2021-08-03 12:13:41,731 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:41,731 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:41,731 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendships frie'", cursor_pos = 16, anchor_pos = 16]
2021-08-03 12:13:41,899 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:41,899 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:41,899 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendships fri'", cursor_pos = 15, anchor_pos = 15]
2021-08-03 12:13:42,074 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:42,075 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:42,075 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendships fr'", cursor_pos = 14, anchor_pos = 14]
2021-08-03 12:13:42,251 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:42,251 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:42,251 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendships f'", cursor_pos = 13, anchor_pos = 13]
2021-08-03 12:13:42,635 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:42,635 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:42,635 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendships '", cursor_pos = 12, anchor_pos = 12]
2021-08-03 12:13:52,787 hunspell_table.py line 2641 _reopen_preedit_or_return_false DEBUG: KeyEvent object: val=65288 code=14 state=0x00000010 name=“BackSpace” unicode=” msymbol=” shift=False lock=False control=False super=False hyper=False meta=False mod1=False mod2=True mod3=False mod4=False mod5=False button1=False button2=False button3=False button4=False button5=False release=False modifier=True
2021-08-03 12:13:52,787 hunspell_table.py line 2642 _reopen_preedit_or_return_false DEBUG: self._arrow_keys_reopen_preedit=True
2021-08-03 12:13:52,787 hunspell_table.py line 2656 _reopen_preedit_or_return_false DEBUG: Getting context: surrounding_text = [text = "'friendships '", cursor_pos = 12, anchor_pos = 12]
^C

https://user-images.githubusercontent.com/75945439/128007181-fb950fd1-0f96-48b3-bd04-89a3c2fe467d.mp4

[mike-fabian]

That it works when you commit with space after selecting with Tab shows that reopening the preëdit is working now for you.

The log file shows that as well.

That it doesn’t work when you type "f r i e Tab BackSpace” is a different bug.

The BackSpace causes a commit here. You see that because the underline vanishes. And then the cursor is already at the end of a word after commit and is not moved there, so the preëdit is not reopened.

Looking into that problem ⏳

[mike-fabian]

Your video made it clear to me. This is not really a bug, rather an enhancement.

If BackSpace, Left, or Control+Left is pressed while a candidate is selected (selected because you pressed Tab!), then the natural thing seems to be that you want to further edit that candidate.

But if BackSpace, Left, or Control+Left commit already, then I would need to use surrounding text to get the word left of the cursor back into preedit. Which I didn’t do when after a commit the cursor ends up directly at the end of a word.

And think I should not always put a word back into preedit when a commit results in the cursor being at the end of the word. For example when committing with Right (arrow-right), and you are already at the end of the document, the cursor cannot move away from the committed word. In that situation the preedit should not be reopened.

But in the special case of BackSpace, Left, or Control+Left, the selected text should certainly end up in the preedit.

In this situation, it makes no sense to commit that candidate and then try to get it back with unreliable surrounding text, which would often fail.

If I already know that I want it back, I can just skip the commit and keep it, just move the candidate into the preedit, put the cursor to the end of the preëdit and then apply the Backspace, the Left, or the Control+Left.

[mike-fabian]

Here is a ibus-typing-booster-2.13.2 build with the enhancement I described in my previous comment:

https://copr.fedorainfracloud.org/coprs/mfabian/ibus-typing-booster/build/2358172/

[psads-git]

Thanks, Mike! The enhancement is working properly. Ibus-typing-booster is now even greater than before!

[psads-git]

I suspect the enhancement is causing a bug that auto-deletes words previously committed, Mike. Please, see the attached video.

https://user-images.githubusercontent.com/75945439/128358210-e614b32c-4c27-492f-b74a-e8c27b475e55.mp4

[mike-fabian]

I am pretty sure this has nothing to do with the enhancement, the enhancement avoids using surrounding text by keeping the preedit if you press BackSpace, Left, or Control+Left while a candidate is selected, so it avoids having to fetch the text from gedit again and put it back into preedit.

In you video, the word “tomorrow” is already committed when you press arrow left. You see

“friendships yellow tomorrow ”

before you press arrow-left. Nothing is underlined anymore, so nothing is in preedit.

When you type arrow left, the cursor reaches the right end of the word “tomorrow” again and tries to put this word into preedit again. To do that, it has to ask gtk for the contents of the buffer in the vicinity of the cursor, then delete the word tomorrow from gedit and put it into preedit.

This is a very difficult thing to do and surrounding text is very buggy and using it even depends on timing and systemload sometimes. Many such issues happen only sometimes and depend on how fast you hit the keys.

But the issue with the word tommorrow disappearing is actually 100% reproducible and I already opened an issue for this myself. See:

https://github.com/mike-fabian/ibus-typing-booster/issues/196

See the video there and the explanation below the video.