Vim mode #236

tombh · 2018-11-09T08:54:19Z

Relates to #31

This still needs a lot of work, but I want to start a PR anyway for somewhere to have the discussion.

@tobimensch I've had a play with this and it's AMAZING! Hats off to you, this can't have been easy - you've made changes right across the spectrum from the CLI to the webextension code.

The main thing that needs to be done is fixing the tests that this breaks and adding new tests. I've already added a new test file specifically for Vim tests. Following links by link hints doesn't seem to be consistently passing its test - should the first link always be hinted with a? Also gt doesn't work for me. There may be other things that don't work, I didn't comprehensively go through everything. Which reminds me, we can start a new docs page for this, just have it hidden on the main site for now.

I'll leave my other feedback as comments on the PR's diffs.

tobimensch · 2018-11-09T10:15:01Z

@tombh
Thanks.

About the failing tests. Of the 4 tests that tend to fail because of my changes 3 are failing because of the change I made to frame_builder.go. This is a change of behavior, as the input box positioning has slightly changed, which explains the failing tests, that continue to expect old positions.

The other failing test might actually be due to a preexisting bug in our tests. Ctrl+L gets executed one too many times and because it's a toggle the input focus is taken away from the url bar and therefore some key presses are forwarded to vim handling, that shouldn't be, resulting in the failing test. If you execute this test by itself it passes (hinting at the bug possibly not being on the program side), if you execute it together with the other tests, it fails. (Because of the ctrl+l toggling twice and the focus being taken way from the url bar)

So, I essentially know what the issues are, it seems not to be anything major.

About gt not working. Well, that keybinding is simply K (vimium has gt and K per default, we only have one binding, but it's easy to add a second one in config.go). You can see the set of keybindings in config.go. With the exception of gi, all of them have an implementation. Scrolling is known not to work for the find feature.

tobimensch · 2018-11-09T10:20:40Z

@tombh
The link hint keys are intended to be user configurable. There's a default setting, and as of now it's not configurable. When there are very few links on a site, we don't need to generate two letter hints, therefore a link hint like a, e, d is enough in that case. On most sites two letter link hints will be generated, because there are a lot more links than link hint keys. Vimium does the same thing. So if you want to test the link hinting you have to test against a static site (same number of links and link positions) with the same/default link hint keys. It should be repeatable.

tombh · 2018-11-11T14:31:39Z

interfacer/src/browsh/tty.go

@@ -139,34 +147,66 @@ func isMultiLineEnter(ev *tcell.EventKey) bool {
 	return activeInputBox.isMultiLine() && ev.Key() == 13 && ev.Modifiers() != 4
 }

-func handleScrolling(ev *tcell.EventKey) {
+func generateLeftClickYHack(x, y int, yHack bool) {


Can you just remind me of this hack again? Is it to do with doubling the y-coord? We should either fix this properly now, or have a good reason not to fix it.

Basically the issue is that browsh partitions the screen into a number of columns and rows (grid) and that these rows times columns areas are the only places that can be clicked with the mouse per default. Sometimes user elements (like an input field, clickable image or the like) in the browser backend aren't placed exactly in the middle of a row/cell pair, but instead in the middle of two neighbouring cells. This hack allows to generate a click in between them and therefore increases the click resolution so to speak, so maybe this shouldn't even be called hack and another name instead. But looking at the code it definitely looks hackish, so the name came to me easily. The reason I created this was that I had input fields that weren't properly aligned in the grid and therefore it wasn't straightforward to translate clicks from the link hint data (generated by the backend and sent to the tty for processing) that has a higher resolution (pixels) so to speak into clicks on the tty (with the lower tty resolution). I think this will prove useful again, even though it looks unpleasant.

Looking at the code I realize that this functionality actually is in use for exactly the use case I describe above. It makes misclicking less likely in some situations.

Ah right I understand now, so the hack just allows you to click in the middle of a TTY cell, rather than at the top right? So is there a reason to not actually just make this the default? Considering the code I've already written I think defaulting to clicking in the middle will be fine.

@tombh
It allows to generate a click, that's between two cells (the cell the click is generated for and the cell directly below(y) it), and that's what I referred to as the middle. From the top of my head I can't tell you why this shouldn't be the default, but I feel it'd be good to have more control over where generated clicks in the tty go when they're received in the backend. The terminal mouse has a low resolution anyway, so picking the middle of the cell seems reasonable for this translation.
Defaulting to the middle might indeed be fine, but I needed this YHack only to fix a corner case, so hopefully we'll not run into new corner cases where we need the old version of the code again.

If you remember what the corner case is then we can write a test and then hopefully any problems arising for switching the default to this new behaviour will show up.

Oh and do you remember why 2 mouse events with a pause in between are sent for each click?

@tombh
One is for pressing the button, and one is for releasing it. Generating a single click. The pause is there to make it appear human-like. I tested different setups, and this one seemed to work by far the best, while it allowed me to reuse existing code.

Ah yes of course!

webext/src/dom/commands_mixin.js

tombh · 2018-11-11T14:38:39Z

webext/src/vimium.js

@@ -0,0 +1,1249 @@
+// The code in this file was copied and adapted from vimium's codebase.


How did you get the raw code here? Was there a build process?

As I mentioned before, ideally I don't want to be committing this to the main code base. If there's a way to independently build it and include as a dependency, that would be ideal. Perhaps there's even a PR we could send to Vimium to help us?

This was all done manually by copying the code from the webinspector while vimium was running in Chrome, until I could do something useful with the code.

There are three main issues:

vimium's code is originally written in coffeescript. Assuming we don't want to switch over to using coffeescript and assuming we don't want a codebase that mixes javascript and coffeescript I copied the compiled code.

there doesn't exist a single file containing all relevant code (that we as browsh need) in vimium like the vimium.js file I created. The code is spread over multiple modules and not structured in a way that makes it easy to load in a 3rd party application. I think it's good to fetch only the relevant bits from vimium and not the 3/4ths we don't have much use for.

I made some (mostly minor) modifications to the code I documented at the top of vimium.js

I agree it's not the ideal solution, maybe we can create a issue on the vimium github site asking for the best way to share this particular code among the code bases. Unfortunately nobody answered my last question/issue I created there, so I went ahead anyway with the intention of making it work.

It should be possible to write a script(bash/python or the like) to recreate vimium.js. A lot of special case handling would be required (I took some liberty in splicing everything together) and we would have to maintain a patch set.

Depending on how much more functionality we want to use from vimium we could need to import additional code. To make the gi(focus first input) feature work there are some vimium bits we're still missing. Sometimes we can implement stuff our own way, I focused on importing vimium code for features that are most difficult to get right(i.e. link hinting).

Finally I ran the code through prettier in order to make Travis happy. Unfortunately this makes the code even less closely resemble the compiled coffeescript code. I think it also makes the line numbers I mention in the top of vimium.js somewhat wrong.

Oh you copied it from the inspector! Ha, ok nice. Well then what about just renaming vimium.js to link_hinting.js? It doesn't seem so necessary to have a formal dependency mechanism if we're just pulling out a quarter of the code. We should still of course reference the source of the code. And we can also mention at the top of the file that we would still ideally like to formalise the mechanism by which the code is included. Like you say, that would just be some scripts that convert the Coffee Script to JS at build time.

@tombh
I disagree about renaming it to link_hinting.js. It contains more than just the bits for link hinting, and I think vimium.js will grow a bit more and contain even more bits of vimium code, for example for input box selection. Link hinting is just an example of something not worth recreating the wheel for (lot's of work!). Adding more comments at the top is always a good idea.

Last but not least I strongly feel we are showing the vimium project our thankfulness by naming the file this way.

Sure, no problem. Ok, I'll have a quick go at importing with some build scripts. First thing though is to flesh out the tests so that any changes we make aren't going to break a bunch of the Vim features.

@tombh
It will be especially difficult to import the MiscVimium() function, because I created it. The code in there is for initializing stuff that other vimium code expects. It was put together from different vimium parts and also contains some modifications. This is the only part that you won't see in similar form in vimium.

I think MiscVimium would be a good candidate for just including in the main Browsh code though. It's not very big. BTW I don't understand what any of that function does. It'd be good to have a few comments. That's another good reason for depending on the original Vimium Coffee Script, it already comes with some comments.

@tombh
The Non-MiscVimium-Vimium code was complaining about missing global objects and the like, so I had to figure out what those were and initialized them in MiscVimium (with code I took from vimium). I would advise against putting it into main Browsh code, as it has no relation to any core Browsh logic, and would look very out of place. I should've put more comments into MiscVimium though, this is a obscure function to the uninitiated! Good point about the comments not being included, maybe there's an option to compile CoffeeScript with intact comments. The missing comments didn't bother me much. Using coffee script for compiling our own vimium.js makes sense, but I do think the vimium.js should be precompiled in the repository and coffeescript shouldn't be required part of the toolchain for every Browsh developer or packager.

I created an issue at the github site of the vimium project about using their code in another application:
philc/vimium#3133

So far there is no response.

If I understand this already merged pull request correctly, this makes it possible to keep all types of comments in the transpiled coffescript code.
jashkenas/coffeescript#4572

tombh · 2018-11-11T14:40:56Z

interfacer/src/browsh/vim_mode.go

+	"github.com/gdamore/tcell"
+)
+
+// TODO: A little description as to the respective responsibilties of this code versus the


@tobimensch could you answer the TODO briefly?

Mode based keyboard navigation.

This was somewhat answered by the previous comment. This file is only the link hinting code right? So the JS just just generates the position and dimensions of the link hints and then the Go code actually places the link hints on the screen. Right?

I disagree about the word "only". Getting the link hint positions is the hardest part and therefore we're lucky we can use vimium code for it and don't have to reinvent the wheel. And I disagree about it for a second reason, because vimium.js contains a lot of useful code besides link hinting, that I strongly believe we're going to use. For example I'm using vimium.js also for going to the next/previous page (this isn't the same as history, try [[ and ]] to see how it works) on websites like Google, which requires finding the correct links in the page, but is separate from the link hinting code. So vimium.js is an integral part of the whole keyboard navigation and not only link hinting.
You're right that we receive the link positions in the go code and display it directly in the terminal, contrary to how it's done in the original vimium. I think this gives us the best of both worlds.

The management of modes and disposing of actions based on the current mode is all done in go code.

Yeah, I've got a better idea of what's going on now. It's definitely more than just link hinting.

tombh · 2018-11-11T14:41:52Z

interfacer/src/browsh/vim_mode.go

+	}
+}
+
+func searchScreenForText(text string) []Coordinate {


Should this also scroll to the currently found text hint?

This was my first implementation of link clicking by typing in and searching for text on the screen. It works, too. But it's not enabled by default, so my plan was to allow for this with some alternative key combination or making it a configurable link selection mode replacing the normal mode. It's possible to click all text with this, not just links, which might enable a few additional use cases.

No this shouldn't scroll. This is intended to search for text in the currently visible screen only, hence the name searchScreenForText. This makes it very fast/efficient as no communication with the backend is required in this process. However in the future this could be combined automatically/optionally with the find (/) feature. I.e. when the typed text isn't found on the screen a search for it could be initiated over the whole page (using the same code as the find (/) feature), it would scroll there if scrolling was fixed for the find feature (we talked about this before), and finally searchScreenForText could be called again in order to click on the text.

Ok, no problem. I just added the word visible to the function name.

So anyway, my point was, that when I use this feature the screen doesn't scroll when focussing matches outside the screen. Is that intended?

@tombh
I'm not sure we're talking about the same thing here. The function you reference wasn't enabled in the current code and got replaced by the vimium link hinting based navigation. Unless you changed some code to make this functionality active again, you can't possibly have tried it. But you definitely should give it a go(pun intended), since I believe this way of navigation/clicking might even be preferred by some people, or work better in some situations.

The find feature (activated by the / key like in vim) is something completely different and is implemented in the webextension code. searchScreenForText and / have nothing to do with each other at the moment, but they could be combined in the future (what I was talking about in the last comment).

The find feature (/ key) can't scroll at the moment because of the scrolling not synchronizing issue I wrote you about. The window.find method is used to implement it in the webextension and this method handles the scrolling, too. The problem is that browsh ignores/reverts the scrolling that is being done by window.find.

To be honest I dislike your choice of adding visible to the name of searchScreenForText, because I can't imagine a logical scenario where someone would search an invisible screen. You can only search what's on the screen, and that's visible, or otherwise it wouldn't be on the screen. The word screen refers to the terminal here, not the screen of the browser backend.

I now realize I might have created the idea of using the term "visible screen" myself by using it in my last comment. It nevertheless makes little sense to me. The screen is the active view.

Ok, understood.

So what about providing a setting for changing the navigation behaviour? So others can try it out, I mean give it a go :D Otherwise how do you feel about removing the unused code? We could leave a comment referencing the commit hash so future devs can find it again?

Regarding visible; is not the default behaviour of search in a browser to search the whole document, including the invisible areas?

And where shall we make a note about the broken scrolling? Is that something I could fix now for this PR?

@tombh
We should provide a setting for it! It could also be used in parallel to link hinting. Ie. by simply binding it to a different key. I never intended for the code to be obsoleted, leave it up to the users to decide if it's useful.

The searchScreenForText function is used by findAndHighlightTextOnScreen, which was written for the purpose of link navigation by text based clicking. This isn't intended as the find text feature, which indeed should scroll and search the whole page. The find text feature (like vim / and also bound to /) is implemented correctly and the window.find method used in the webextension does scrolling by itself. Unfortunately browsh somehow overwrites that scrolling, therefore it doesn't really scroll (only for a few milliseconds in the webextension, then it is being reverted/overwritten). This could and should be fixed. You wrote to me about this, saying that we also have to solve this for pages that want to scroll to a #hash position, pages that scroll to comments and the like.

Ok, this is bringing back memories. I can fix the scrolling. The only difficulty I think will be the potential for positive feedback loops. I'll need to place a scroll listener that will trigger for both internally automated scrolling (eg; anchor tags) and Browsh initiated scrolling. Browsh scrolls its own copy of the page and then tells the main web page to scroll, the main web page then receives a scroll trigger and tells Browsh of the new scroll position, which Browsh should honour. So either there needs to be a way to distinguish Browsh-intiated scrolling from internal scrolling, or the scrolling values have to be precisely identical.

@tombh
Makes sense. Fixing this will be a huge step forward. Thank you for looking into it.

tombh · 2018-11-11T14:46:09Z

Thanks for the comments. I've fixed the tests now (at least locally). The only things that need to be done are adding a few comments and fleshing out the tests.

The more I go through this the more I realise how epic this PR is and how great this feature is going to be! Thanks so much @tobimensch

tobimensch · 2018-11-11T20:38:14Z

@tombh
Thank you.

Btw. the init function you removed had a purpose. Functions named init get called automatically at startup in golang. This helps to prepare link hint texts. To generate them every time a user requests link hints would be a waste of resources as they stay the same (unless the linkHintKeys variable is changed, then it should be regenerated, this variable isn't configurable yet and typically wouldn't be changed on the fly) almost all the time.

tombh · 2018-11-12T05:18:54Z

Oh I didn't know that about init()! I put it in TTYStart() instead then, just so all the init is in one place.

tombh · 2018-11-12T13:36:15Z

interfacer/src/browsh/vim_mode.go

+						switch currentVimMode {
+						case linkMode:
+							if (*r).Height == 2 {
+								generateLeftClickYHack((*r).Left, (*r).Top, true)


Is this the corner case for the yhack?

Yeah. A height of 2 actually implies a height of 1. This is a bit confusing I have to admit, look into parseJSONLinkHints to get some of the logic behind that. Basically we're getting rectangles for the total size of links and we're moving them into a vertical middle position if they're higher than one row, and we're also moving them a bit to the right if there's enough space in that direction. The only positions we need for displaying link hints are r.Top and r.Left, so those are the ones that are being adapted, while r.Height is unchanged.

When the height is 1 we want to ensure we really hit the input box and not the corner of it, because when the border of an input box is clicked, it doesn't actually get focused.

This is not only needed to make input boxes work though, I remember that I tested some websites where I hit on corner cases that were solved by this type of positioning in combination with the "YHack".

I'm glad you're creating test cases, because this will make things much easier going forward. I tested with links, navigation links and input boxes on multiple sites, among them google, osnews, lwn.net, bing. Maybe we can capture static versions of these complex sites to make our testcases with. Is this legal to do?

tobimensch · 2018-11-13T12:04:43Z

Oh I didn't know that about init()! I put it in TTYStart() instead then, just so all the init is in one place.

I just tested your changes. Putting setupLinkHints into TTYStart doesn't work here, I get an index out of range error when I hit f or F. Putting it into init() again fixes that. I'm not sure what's the reason for that, but assuming we're both using very similar Linux systems and go versions I wonder why this is working for you and not for me.

tobimensch · 2018-11-13T12:12:53Z

I found some bugs that I'm having trouble wrapping my head around. When I open a new tab and enter brow.sh the page never loads correctly and stays completely white. As start page brow.sh works, but not in a new tab, not sure if this has anything to do with vim-mode-experimental.

tobimensch · 2018-11-13T12:46:45Z

@tombh
Pushed a commit for a pretty annoying bug where key combinations did only work consistently after a certain number of them were entered.

tombh · 2018-11-14T16:00:32Z

Hmm, that's an interesting bug. I don't see it on my machine. Which makes me think that the only possible difference is that I've recently run dep ensure and npm update. So maybe your Go and JS deps are out of sync?

Interestingly though, I'm really struggling with Travis at the moment, the tests are just freezing half way through, which could possible be caused by the same thing your seeing.

tobimensch · 2018-11-14T16:51:09Z

@tombh
Which bug did you refer to? The brow.sh not showing up correctly in a new page one or the index out of range error without the init() function one?

tobimensch · 2018-11-15T16:00:08Z

@tombh
I did some rebasing/merging and that seems to have changed your two latest commits (not their content, they're now listed as being authored by you and commited by me). Feel free to revert this, if you think it is bad.
And I pushed this commit: 6882327 , that allows for using the ESC key for leaving input boxes. Now you can fill out input forms and use login fields without having to use the mouse to switch from one input box to the next.

j-rewerts · 2018-12-18T23:31:28Z

I'm looking at writing some tests for the link hinting. I'd like to test the multi character link hints, which I think will require a new test web page. Is the preference to add a new folder within the /test/sites folder and add css/html in there, or should I add a new HTML file within the existing /test/sites/smorgasbord folder?

j-rewerts

I'm working on adding some tests for link hinting.

tombh · 2018-12-24T06:52:25Z

Thanks Jared :) Either is fine. I guess I'd lean towards adding a new folder for those tests.

j-rewerts · 2018-12-31T16:13:26Z

What would be the best way for me to contribute to this PR? I don't have write access to this branch, but I could submit a separate PR to this branch, which if it was accepted would probably affect this PR. Any advice?

tobimensch · 2018-12-31T17:45:52Z

@j-rewerts
Make a pull request to this branch.

Hultner · 2019-04-26T11:14:45Z

Any plan on integrating this any time soon? Just tried browsh and really like the idea but current keybinds wouldn't even work on tmux on my Mac (cmd+l did nothing) so I'll keep using w3m (which have acceptable vi-bindings) as my in terminal browser for now when doing quick lookups. Another prime example of a great vi-mode browser is qtbrowser.

tombh · 2019-05-06T17:43:31Z

The biggest thing stopping this being merged is the failing tests. Travis is just hanging so it's hard to debug. I've got some WIP code locally overhauling the test setup code, but I'm just really slow at working on it :(

The keybindings are hardcoded for now, but this is going to change.

Added moveTabLeft and moveTabRight functions, which take a tab ID and try to move the tab as far right or left in the tabOrder as possible. Added previouslyVisitedTab function that switches to the previously selected tab.

with activating input boxes using link hinting.

Vim mode still needs a lot more tests

…to key combinations only working after a certain number of key strokes.

This is because Travis' logs had 2 problems. 1. it doesn't capture the entire log output 2. it doesn't show logs when there's a timeout

… event could get interpreted repeatedly. Also some rewrites/improvements of the code. Key mappings can now contain control characters and meta keys with a vim-like notation. There's a hard insert mode, which disables all of browsh's shortcuts and requires 4 hits on ESC to leave. There's a new multiple link opening feature analogous to vimium, that's still incomplete.

dmadisetti · 2019-09-26T04:18:37Z

Link hint generation is broken. e.g. "fa" and "f" will be marked as a flags. Thus trying to type "fa" causes "f" to be selected. Vimium does this by generating link flags on the fly
https://github.com/philc/vimium/blob/881a6fdc3644f55fc02ad56454203f654cc76618/content_scripts/link_hints.coffee#L449

While currently in this implementation, the flags just come from a prepopulated list.

I might grab this myself, just documenting somewhere.

GameKyuubi · 2020-05-27T17:50:23Z

Hello lovely people. In my opinion this is the current killer feature for brow.sh. If this PR got merged even if some features are missing I have no doubt it would drive adoption of the app.

tombh · 2020-05-27T19:45:55Z

Hey Lovely Commenter. I'm so sorry that I haven't had time to look at this. It's been so long now that I've looked at the code, it would take me weeks to get back up to speed. And I just have too much to do at my my day job :/

tobimensch mentioned this pull request Nov 9, 2018

Help with testing vim-mode-experimental #233

Open

tobimensch requested a review from j-rewerts November 9, 2018 13:19

tombh commented Nov 11, 2018

View reviewed changes

webext/src/dom/commands_mixin.js Show resolved Hide resolved

tombh commented Nov 11, 2018

View reviewed changes

tombh commented Nov 12, 2018

View reviewed changes

tombh force-pushed the vim-mode-experimental branch from d745f21 to 134aa4b Compare November 13, 2018 08:13

tobimensch force-pushed the vim-mode-experimental branch from a51db9c to 15f541c Compare November 13, 2018 11:48

tobimensch force-pushed the vim-mode-experimental branch from d034497 to 2bf920b Compare November 15, 2018 15:53

j-rewerts reviewed Dec 20, 2018

View reviewed changes

tombh force-pushed the master branch from a7ab870 to c329e80 Compare June 18, 2019 13:52

tobimensch and others added 24 commits June 24, 2019 09:09

added command for links hints

ca30b77

Set default DISPLAY environment variable for xclipboard functionality

dc95339

ignore manifest.json backup file

ebc8de9

ignore debug log in interfacer/ directory

8fc15f3

Fixed typo in comment

fac1af7

Added sessions permission

c794f10

Added initial configuration for vim like keybindings.

631483b

The keybindings are hardcoded for now, but this is going to change.

Added duplicate_tab, restore_tab commands.

86acac6

Refactored code using switchToTab and added new features.

7b7e6bc

Added moveTabLeft and moveTabRight functions, which take a tab ID and try to move the tab as far right or left in the tabOrder as possible. Added previouslyVisitedTab function that switches to the previously selected tab.

Added features needed for vim like navigation to the webextension.

15c7b45

Added vim like navigation. This is still in an early stage.

0b7d1dc

Instead of adding 1 to Y coord, add 1 to height. This fixes an issues

bd5c306

with activating input boxes using link hinting.

Prettified js files

d3fff67

Fixed typo

49eebee

Refactors Vim code from tty.go into its own file

e039233

Adds some Vim-specific integration tests

eae72e9

Fixes tests for Vim mode

59d2c31

Vim mode still needs a lot more tests

Vim mode: convert unexported symbols to lowercase

8161ea3

Vim mode: Small updates from PR review

ed79db0

Fixed bug where keyEvents variable was initialized wrongly. This led …

7a622b2

…to key combinations only working after a certain number of key strokes.

Travis: upload logs to text host

714cad8

This is because Travis' logs had 2 problems. 1. it doesn't capture the entire log output 2. it doesn't show logs when there's a timeout

Gofmt: some minor capitalisation

b780a79

Added vim feature for editing URL in new tab

9359837

tombh force-pushed the vim-mode-experimental branch from 0c0b907 to b2ade39 Compare June 24, 2019 06:19

tombh mentioned this pull request Jul 26, 2022

Vim Mode 2022 #439

Open

martin-braun mentioned this pull request Jan 17, 2024

brow.sh support lalitmee/browse.nvim#23

Open

		@@ -0,0 +1,1249 @@
		// The code in this file was copied and adapted from vimium's codebase.

Vim mode #236

Are you sure you want to change the base?

Vim mode #236

Conversation

tombh commented Nov 9, 2018

tobimensch commented Nov 9, 2018 • edited Loading

tobimensch commented Nov 9, 2018 • edited Loading

Choose a reason for hiding this comment

tobimensch Nov 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobimensch Nov 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobimensch Nov 12, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobimensch Nov 14, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobimensch Nov 14, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobimensch Nov 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobimensch Nov 12, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobimensch Nov 11, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobimensch Nov 12, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tobimensch Nov 12, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tombh commented Nov 11, 2018

tobimensch commented Nov 11, 2018

tombh commented Nov 12, 2018

Choose a reason for hiding this comment

tobimensch Nov 12, 2018 • edited Loading

Choose a reason for hiding this comment

tobimensch commented Nov 13, 2018

tobimensch commented Nov 13, 2018

tobimensch commented Nov 13, 2018

tombh commented Nov 14, 2018

tobimensch commented Nov 14, 2018

tobimensch commented Nov 15, 2018 • edited Loading

j-rewerts commented Dec 18, 2018

j-rewerts left a comment

Choose a reason for hiding this comment

tombh commented Dec 24, 2018

j-rewerts commented Dec 31, 2018

tobimensch commented Dec 31, 2018

Hultner commented Apr 26, 2019

tombh commented May 6, 2019

dmadisetti commented Sep 26, 2019

GameKyuubi commented May 27, 2020

tombh commented May 27, 2020

tobimensch commented Nov 9, 2018 •

edited

Loading

tobimensch commented Nov 9, 2018 •

edited

Loading

tobimensch Nov 11, 2018 •

edited

Loading

tobimensch Nov 11, 2018 •

edited

Loading

tobimensch Nov 12, 2018 •

edited

Loading

tobimensch Nov 14, 2018 •

edited

Loading

tobimensch Nov 14, 2018 •

edited

Loading

tobimensch Nov 11, 2018 •

edited

Loading

tobimensch Nov 12, 2018 •

edited

Loading

tobimensch Nov 11, 2018 •

edited

Loading

tobimensch Nov 12, 2018 •

edited

Loading

tobimensch Nov 12, 2018 •

edited

Loading

tobimensch Nov 12, 2018 •

edited

Loading

tobimensch commented Nov 15, 2018 •

edited

Loading