"Natural" mouse scroll direction

[vik]

Please add the "natural scroll direction" feature to scroll with mouse using natural scroll direction as it is done in the macos.
It could be done in 10-15 minutes by adding new boolean parameter in the CONFIG_MISC_SECTION, for example "mouse_reverse_scroll", loading it in the setup.c, and then to change mouse.c by reversing the mouse scroll direction if it's set, like:

midnight/mc/lib/widget $ diff mouse.c mouse.c.original
104,107c104
< if (mouse_reverse_scroll)
< msg = MSG_MOUSE_SCROLL_DOWN;
< else
< msg = MSG_MOUSE_SCROLL_UP;
---

msg = MSG_MOUSE_SCROLL_UP;

109,112c106
< if (mouse_reverse_scroll)
< msg = MSG_MOUSE_SCROLL_UP;
< else
< msg = MSG_MOUSE_SCROLL_DOWN;
---

msg = MSG_MOUSE_SCROLL_DOWN;

All Mac users will say you big "thank you" for that ))

[vik]

mplementation example (not sure is it correct but it works)

[vik]

Sorry, forgot one more change for viewer

[egmont]

Hi,

It's not only Mac, the GNOME desktop also defaults to natural scrolling.

I don't think that requiring to configure each and every terminal-based app separately is a viable approach. It might be a temporary workaround until a standard is designed and implemented. But there should be a standard that the world is converging to.

It might be for example an environment variable that's commonly recognized by terminal-based apps.

It might be a terminfo capability, and a different $TERM variable for natural scrolling.

It might also be the terminal emulator simply swapping the two directions, according to how the emulator itself behaves outside of mc, when scrolling the scrollbar. Which, in turn, should (and usually does) match the desktop's setting.

Oh, wait a second...

VTE (gnome-terminal and many others) actually does swap the reported directions when natural scrolling is enabled. That is, in these terminal emulators you automatically get your expected (that is, natural) scrolling behavior without the patch, and hence the patch's new config option would break it.

Now, it might be that VTE shouldn't do it and swapping should happen somewhere else. In any case, however, I'd rather see this topic being discussed among key players, a consensus being made, and then that getting implemented; rather than each and every player doing whatever random approach they feel like doing, leading towards a bigger and bigger mess.

What do popular terminal emulators on macOS (at least the default Terminal.app, as well as iTerm2) do?

Execute

printf "\e[?1000h"
cat

and then scroll.

In case of legacy (non-natural) scrolling, rotating the mouse wheel or moving your fingers on the touchpad upwards should result in letter M followed by backtick, whereas rotating or moving fingers downwards should print stuff containing Ma. Is this indeed the case?

With new-style natural scrolling, is it the same, or is it swapped in these terminal emulators?

[vik]

---

1) It's proposed to be a setting, it could even be "hidden" i. e. don't have the dialog representation to change it, just a string in the ini file. So anyone who needs it could set it, like mac users. And it is disabled by default in the proposed patch, so behavior wouldn't change till user will explicitly set it. Sure, we can wait for the solution for years, but it's a simple patch that took about 30 minutes to made, as I haven't seen the mc sources since 1995, I suppose ;)) And I think it's not about the terminal but about the MC -how to treat "natural" scrolling in the panels.
And (afaik) the mac approach is, that apps shall interpret the scrolling events as they'd like to; i.e. when user scrolls down it's application decision what to do - to scroll document down or to move the caret down. The natural way in the midnight panel case, i suppose, is to move the selection up when SCROLL_UP has been done. Currently the selection moves up when user scrolls down. Maybe it could be a bit reasonable for a panel with a lot of files, but if there's just a few files, it looks odd - user scrolls down but selection moves up.

2) As for the viewer, the current behavior is ok( i.e. "natural"). Not sure about the editor - as for me it's more "natural" to move the cursor up then scrolling up, not the document, so it might be a good idea to have a separate setting for this

3) Mac terminals (terminal, xterm and iterm2) reports "Ma" for scrolling up and "M`" for scrolling down. Not sure if I understood what do you mean by the "new-style" correctly, if you meant the proposed mc patch, it does not affect terminal, just mc as you can see in the attached sources

[egmont]

Re 3) I meant "new-style" as a synonym for "natural". Based on what you say here ("Ma" for scrolling up...) and based on 2) mcview having "natural" scroll, these terminal emulators work just like VTE: they swap the two reported directions when natural scrolling is enabled.

(By the way, I checked VTE, and it doesn't do any explicit swapping on its own. It's an implicit result of receiving swapped directions of GTK+.)

In the panels, with a long file listing, eventually moving the selection up is the same action as moving the listing down (and vice versa).

So what you're actually asking for here is not natural scrolling, it's quite the opposite. You're asking here in this particular context to revert to the legacy behavior that mc has on non-natural-scrolling systems. And because your terminal emulator swaps the directions, you'd need to swap them back in mc.

"Not sure about the editor - as for me it's more "natural" to move the cursor up then scrolling up, not the document" – again, here you're asking for the traditional, "non-natural" scrolling.

I don't think it makes too much sense for mcedit to scroll in opposite directions than mcview, I don't think it makes sense to invert the scrolling direction based on the presence vs. absence of an insertion cursor, I could hardly imagine anything more confusing than this. (And what about mcview's hex mode which also has a cursor?) I'd say if you choose natural scrolling, you have to accept that you're no longer moving the cursor, but moving the content instead. And with short file listing, yes, it's confusing. A mixture of the two behaviors sounds terrible to me. (Mind you, I don't have a Mac, and once I tried to get used to natural scrolling but I couldn't live with it for more than about a day.)

Is there any precedence in other apps of what you're asking for? For example, a word processor where you move the document if it's read-only, but move the cursor (and hence the document eventually scrolls in the opposite direction) if the document is writable? Or an app where the global setting of "natural scrolling" affects the scrolling direction in some, but not all of its functionality?

[vik]

Well, looks like with your help I understood the problem. I'll try to explain my point as I believe now I even understood it myself ;)
Mac apps have different approach. Scrolling does not move the cursor at all, but the content. It might be a bit confusing at the beginning for the "PC" users, but very handy when user get used to it. macs rarely use scrolling wheels now but surfaces like a touchpads or magicMouses. And when user drags the UI element on the screen using the touchpad, it gives a really "natural" experience like user really drags it up or down with his fingers. If there's not enough content to scroll, the scrolling just does nothing but the cursor stands still.
In the MC case, both the content and the cursor are moving; that leads to the strange experience when user hardly understand what's going on - like in the case there are just a few files in the panel and the cursor scrolls up when user actually scrolls down. In mac's native natural scrolling it does not scroll at all in such a case. But even if there are a lot of items to scroll, MC starts to move the cursor first (if there's a space to move it), and MC always moves it in the wrong direction. that what I meant in the original request.
So it's not a question of "natural" or "not natural" scrolling, it's the question how it's done in the MC. "Natural" means that user like drags something and this "something" moves in the dragging direction on the screen.Just imagine you drag a piece of paper on the table surface with your fingers. That's why, when cursor is moving during the scrolling, user expects it to move in the scrolling direction. In case there's no cursor (viewer not in the hex mode) it's ok, but in the rest it looks very odd and confusing
So, I suppose there are following solutions:
0) Just to move the cursor in the scrolling direction, UX will be like user "drags" the cursor, not content, of course there shall be the setting to enable/disable this, as I requested. It's not really "natural" scrolling, but much more "natural" than current
1) To achieve really natural scrolling like it's done in other apps - do not move cursor at all but the content. Obviously, the setting will be required to enable/disable this as well
I suppose, first solution is the easiest to implement, I checked it with the submitted patch and found it good enough at least for me, although last solution might be the best from the UX point of view. But it will require the "natural scroll" setting anyway for those users who don't like such behavior, but have mice with scrolling wheels instead ;)
And I understand your feelings, I felt the same for a few days a long time ago when I switched to mac, but now I cannot imagine another behavior, it's really very convenient if implemented in proper way. And for people like me, who accustomed to the "natural scrolling", current Midnight implementation is just terrible (

[egmont]

Replying to vik:

Mac apps have different approach. Scrolling does not move the cursor at all, but the content.

You said this, I'll get back to this later :)

It might be a bit confusing at the beginning for the "PC" users, but very handy when user get used to it.

<off>It's not clear to me why I couldn't switch, since I use natural scrolling all the time on my smartphone. I have three theories. One is that actually touching the content mentally differs so much from touching and scrolling somewhere else. The second is that on the smartphone I'm mostly consuming content, whereas on my laptop I'm producing a lot, and that might be so much different. The third is that it's just so hard to change something you've been used to for so many years. Anyway...</off>

[...] But even if there are a lot of items to scroll, MC starts to move the cursor first (if there's a space to move it)

Nope, or at least not for me. (We're talking about the standard file listing here, right?) First mc scrolls the content (the visible sublist of file names) as long as it can, and by the way does so by entire pages at each step. When it can no longer do so, then it switches to moving the cursor, by a single row at each step.

(At the very least, the drastic change in the amount doesn't make any sense to me, even with non-natural scrolling. Page Up / Page Down on the other hand first scroll the view exactly as the touchpad, but when it no longer can scroll, the cursor suddenly jumps to the top or bottom. This already makes more sense to me.)

So it's not a question of "natural" or "not natural" scrolling, it's the question how it's done in the MC. "Natural" means that user like drags something and this "something" moves in the dragging direction on the screen.

This is where I refer back to your previous statement. Natural scrolling is not about dragging "something", it's about dragging "the contents" in particular, that is, definitely not the cursor. (Or let me know if I'm wrong here and back it up with examples please.) Clicking is the action that moves the cursor instead.

Just imagine you drag a piece of paper on the table surface with your fingers. That's why, when cursor is moving during the scrolling, user expects it to move in the scrolling direction. In case there's no cursor (viewer not in the hex mode) it's ok, but in the rest it looks very odd and confusing

Again, I'm referring back to your statement I quoted at the top. According to that, the presence of a cursor should not influence the scrolling behavior, it should still scroll the contents. Do you call this confusing, or current mc's behavior?

0) Just to move the cursor in the scrolling direction, UX will be like user "drags" the cursor, not content, of course there shall be the setting to enable/disable this, as I requested. It's not really "natural" scrolling, but much more "natural" than current

As per the above, I'm firmly against this approach. And as you also say, this wouldn't be "natural" scrolling. Whether it's more "natural" than the current, or more confusing, is at least heavily debatable. I'd guess it would be even more confusing, by swapping back the up/down directions at some places. It might feel "okay" to you, but we have no data on how others would perceive it.

1) To achieve really natural scrolling like it's done in other apps - do not move cursor at all but the content.

I definitely like this one much better. This is what "natural" scrolling is about, so this is the natural scrolling behavior by definition, and not something random that is just debatably "more natural" (or not) than the current one.

As far as I understand, this would require that no change occurs to the code that handles scrolling of the file listing, it should still scroll in the direction that it scrolls currently. The special code that moves the cursor by a single row if the contents can no longer be scrolled, should, however, be removed – maybe conditionally to a new config option.

Here I'd be brave enough to go one step further, and unconditionally remove this moving of the cursor by a single entry, even for non-natural scrolling. As said above, I find it weird anyway how the "speed" drastically changes. The behavior would still not be exactly the same as the behavior of Page Up / Page Down, but I don't think it's a problem.

---

I primarly had the file listing in mind while writing this answer, but other uses (most notably mcedit) should also be investigated. I'd say we should check how most other popular apps, especially native macOS ones (simple text editors, complex word processors etc.) behave, and mimic them.

Oh, by the way, when scrolling in these apps, does the cursor try to stay at the same physical position on the screen (the behavior equivalent to mc's), or does it drift to the top or bottom of the viewport (that is, try to stay at the same position within the document, as long as possible)? I'm truly curious about this. If the latter, we might need to adjust mc's behavior too.

Mouse scrolling jumps the viewport by 2 lines in mcedit, and by an entire page in the file listing. This is inconsistent. Jumping by entire pages is not the expected behavior with touchpad scrolling, and IMO isn't too useful either, touchpad should operate in much more fine-grained steps (especially with kinetic scrolling in mind). Why not make both the same, maybe let's say somewhere from 2 to 5 lines?

(Well well well, it should scroll by a single line upon every smaller movement of the fingers, but this requires an extension to the existing terminal emulator mouse protocols, see ​VTE #755183.)

When the contents can no longer scroll, mcedit still moves the cursor by the same amount (2 lines). Would be a sane behavior on the file listing, too.

mcedit's scrolling philosophy seems to be: Move the cursor by 2 lines within the document, and scroll so that the cursor stays at the same screen position as much as possible. Reasonable behavior. Not exactly what you'd expect with natural scrolling, though. So maybe that new config option, which I said I might be brave enough not even to introduce, just switch to the new behavior, so now I guess maybe that new config option would really be nice to have.

[vik]

Well, I just tried to explain how it's done in macos and what can be done in the MC.
I have no idea why you cannot switch, but this approach is quite convenient and used by a lot of users around - all mac users as well as many graphical designers with their digitizers. But It's just a question of personal preferences, of course. It does not matter, either content is produced or consumed, the "natural" way is to move a paper when you write something on it. Anyway, you prefer this way, another users prefer another way, why just don't let them choose?
About the scrolling - what I tried to explain. The "native" mac scrolling scrolls content and cursor remains stand still in it's place in the content. Always. In any application. It is how "natural scrolling" works. Every mac app behaves this way - pages, textedit, msword and excel, finder, commander one, itunes - any. It's understood, because current MC behavior, when user drags down and cursor moves up, is just weird. Mac apps just do not move cursor as I explained before, content moves instead in the scrolling direction and cursor may be moved out of visible content area.
That's why, the really good idea is to adopt the MC to this behavior as it is the standard and a lot of users found it very convenient. Obviously, there shall be the setting to enable/disable this.
I quickly looked in the current code and found that it would be not so easy to implement this (at least for me, as I told you before, last time I looked in the MC sources was more than 20 years ago). At the other hand, moving cursor up when user drags/scrolls down is unacceptable, I suppose you'd agree with that. That's why I proposed a compromise solution that requires minimum effort and implemented a setting that reverse the scroll direction, so it wouldn't look and feel so confusing and odd. You shall definitely try to scroll it with the touchpad and you'd understand what I'm talking about in seconds )
The main idea of "natural" scrolling along with the touchpads is not about just "what to scroll" but "how to scroll". If content is scrolling, it shall be scrolled in the direction user drags his fingers on the touchpad surface. So, if MC moves the cursor, it definitely shall be moved in the same direction. So, if MC moves cursor, it shall be moved in the same direction, user moves his fingers, it's so obvious. It's like you'd scroll your phone up but something on the screen will move down - weird. Just imagine, you drag the pen down the sheet but it moves up.
The idea to scroll just a content is very good, but harder to implement, I suppose.Anyway, MC shall be adopted to that in some way.
Regarding two-lines scrolling - I found this in the source as well and found it strange since scrolling will generate as many of the scroll events, as far user will move his fingers. The longer is the distance, the more events will be generated, there's no need to "double".

Conclusion: the best way to implement natural scrolling is to scroll the content and do not move the cursor at all. Never. Scrolling shall be done line-by-line - one line per one mouse scroll event.
As another not-so-good but quick solution, cursor could be moved in the scroling direction, not the opposite as it's done now.. Current MC behavior is very weird and inconvenient - to move cursor up when user scrolls down. That's what I wanted to say ))

And about investigations - I did it and found that any mac app scrolls the content, cursor stands still in the same position in the CONTENT, not screen. I can make a short video, if you'd like, but hope I can explain without it. So, the content is scrolling, cursor remains in the same position in the content, so cursor can be moved away of visible area with the content because it remains on the same position in the content.
Kinetic scrolling is good idea, but probably not for the terminal app; anyway, as long as the amount of generated mouse scrolling events depends on the actual touchpad scrolling distance.
mcedit/cooledit has the same problem - when there's no space to scroll the content, it moves cursor in the opposite direction.

[egmont]

[...] and cursor may be moved out of visible content area.

What happens if I scroll far away, then press a key (e.g. a letter to be inserted into the document, or an arrow to move the cursor)? Does the viewport suddenly jump back so that the cursor (the place of edit) becomes visible?

So if I wish to scroll far away and edit the document there, I guess I need to scroll and then click, correct?

I'm not sure mc should implement this behavior, i.e. offscreen cursor. It would introduce a couple of other issues, e.g. how to show to the user which of the two panels is the currently active one (with its invisible cursor), what to do on TAB keypress. At the very least, implementing this behavior would require quite some design/behavior changes, so it may not be feasible right now. I guess I'd rather explore what's the best compromise between having natural scrolling, while forcing the cursor onscreen.

I quickly looked in the current code and found that it would be not so easy to implement this (at least for me, as I told you before, last time I looked in the MC sources was more than 20 years ago). At the other hand, moving cursor up when user drags/scrolls down is unacceptable, I suppose you'd agree with that.

Here I understand you now. Moving the cursor isn't unacceptable for me, no, because for me, ultimately the single most important question is: which file is focused currently. And with that in mind, scrolling the viewport upwards while keeping the cursor at the same visual position is almost the same action as moving the cursor downwards; and vice versa. I understand that you wish this to work differently, and I'm fine with that.

That's why I proposed a compromise solution that requires minimum effort and implemented a setting that reverse the scroll direction, so it wouldn't look and feel so confusing and odd. You shall definitely try to scroll it with the touchpad and you'd understand what I'm talking about in seconds

I still totally don't understand this one. You keep claiming that you wish to have natural scrolling experience, yet you implement something that is the exact opposite of that and claim that it's good enough for you, so should be part of mc. Like, errrrr... sorry, no.

Do you want to have natural scrolling experience? Absolutely fine by me, I'd be happy to see it. But then let's implemenet natural scrolling, and not something different.

Easiness of implementation, to the extent that someone hardly familiar with the code can do it in 15 minutes, cannot justify an incorrect solution.

The main idea of "natural" scrolling along with the touchpads is not about just "what to scroll" but "how to scroll". If content is scrolling, it shall be scrolled in the direction user drags his fingers on the touchpad surface. So, if MC moves the cursor, it definitely shall be moved in the same direction.

Again, you contradict yourself. You clearly stated that natural scrolling always scrolls the content, never the cursor. And yet you imagine how it would work if it moved the cursor, and want that to happen. Whereas I'd rather guess it would work the other way around. There's no use arguing about this. If natural scrolling always scrolls the content and never the cursor, we cannot start moving the cursor in whichever direction in the name of natural scrolling.

---

[...] there's no need to "double".

2-3-4-5x speed can be justified if without a multiplier scrolling would be very slow (you'd have to scroll way too much). Typically terminal emulators scroll about 3-5 lines on a single mouse wheel rotating click. In order to achieve the same behavior in a terminal-based app such as mc, it would need to scroll by one line upon every 1/3-1/5 of traditional unit seen from the touchpad. This requires extending the mouse protocol. Since it's not yet available, jumping by 3-5 lines at once might be a better overall experience than always jumping by 1 line, since the latter case scrolling is just painfully slow.

Moreover, for touchscreen devices scrolling should exactly follow the fingers' movement, see my brand new comment and link at the aforementioned VTE bug.

---

Conclusion: the best way to implement natural scrolling is to scroll the content and do not move the cursor at all. Never.

Sounds good to me.

Scrolling shall be done line-by-line - one line per one mouse scroll event.

I'm not sure. Anyway, the scrolling speed should be unified across mc. It could receive a new config option.

As another not-so-good but quick solution, cursor could be moved in the scroling direction, not the opposite as it's done now.. Current MC behavior is very weird and inconvenient - to move cursor up when user scrolls down.

Veto from me on this one.

Kinetic scrolling is good idea, but probably not for the terminal app; anyway, as long as the amount of generated mouse scrolling events depends on the actual touchpad scrolling distance.

I agree that kinetic scrolling should be handled elsewhere, not in mc. (I do have kinetic scrolling, and I don't have the slightest idea who does that for me: the hardware, X11 or GNOME.)

[vik]

Replying to egmont:

[...] and cursor may be moved out of visible content area.

What happens if I scroll far away, then press a key (e.g. a letter to be inserted into the document, or an arrow to move the cursor)? Does the viewport suddenly jump back so that the cursor (the place of edit) becomes visible?

So if I wish to scroll far away and edit the document there, I guess I need to scroll and then click, correct?

Exactly.
When user press a key, applications scrolls cursor back to the view by scrolling entire content back. If user scrolled far from the current cursor position and cursor is not visible, user can either click in the visible part of the content to set cursor there, or to press an arrow (or other active) key to scroll content back to the cursor. m$word the only app I found so far, that just moves cursor to some random (?) visible line when cursor is out of the visible content zone and the key is pressed.

I'm not sure mc should implement this behavior, i.e. offscreen cursor. It would introduce a couple of other issues, e.g. how to show to the user which of the two panels is the currently active one (with its invisible cursor), what to do on TAB keypress. At the very least, implementing this behavior would require quite some design/behavior changes, so it may not be feasible right now. I guess I'd rather explore what's the best compromise between having natural scrolling, while forcing the cursor onscreen.

I don't understand you. I told you that at the very beginning that it could be a bit difficult to implement this in the MC, and you answered that there shall be "standard" solution and called this behavior as a standard. So, here it is )))
Now you repeated what I wrote at the beginning and what you've been arguing with )))
That's why I proposed just to make a setting for the scroll direction. It's easy and will give users a chance to get rid of this reverse scrolling.

But it's not a problem really, if user scrolled the cursor away from the visible area and forgot where it was, he can press a key or mouse to explicitly repositioning the cursor. So, the only problem is, that a lot of effort required to implement this. And on tab, as I checked in another file managers, cursor moves to another panel and currently active stays untouched with the active item out of the screen, but when tab is pressed again, the app scrolls the current item into the view.

I quickly looked in the current code and found that it would be not so easy to implement this (at least for me, as I told you before, last time I looked in the MC sources was more than 20 years ago). At the other hand, moving cursor up when user drags/scrolls down is unacceptable, I suppose you'd agree with that.

Here I understand you now. Moving the cursor isn't unacceptable for me, no, because for me, ultimately the single most important question is: which file is focused currently. And with that in mind, scrolling the viewport upwards while keeping the cursor at the same visual position is almost the same action as moving the cursor downwards; and vice versa. I understand that you wish this to work differently, and I'm fine with that.

Not visual position but position within the document. For example, cursor is on the third file - it will remains there but the whole content will scroll and third file will remains "current", marked by the cursor. The same for the editor - if the current cursor position is on the 5th line at the 11th character, cursor will stay there and whole document will scroll. What file is active is an important question, but from the UX point of view, if user cannot understand what is the current file, user will just select another one- it's "natural" decision and "natural" behavior. And, if user came to such a situation, it means that user used the scrolling feature to achieve that. And it means that user has a pointing/scrolling device. And it means that user can just select a file in one click, if he forgot where he is and who.
And please bear in mind that it shall be configurable feature, so anyone who don't want it could just turn it off. It's not a "must" but the possibility.

That's why I proposed a compromise solution that requires minimum effort and implemented a setting that reverse the scroll direction, so it wouldn't look and feel so confusing and odd. You shall definitely try to scroll it with the touchpad and you'd understand what I'm talking about in seconds

I still totally don't understand this one. You keep claiming that you wish to have natural scrolling experience, yet you implement something that is the exact opposite of that and claim that it's good enough for you, so should be part of mc. Like, errrrr... sorry, no.

Let me explain it again in brief. Imagine - you move your finger down on the touchpad and cursor moves up. I don't understand how you don't understand that it's awful, terrible and annoying ))) So, if we'd take the concept that moving fingers on the touchpad reflects the cursor movement (as it is done right now but in the right direction) - such a behavior will be much more logical than the current one. Again - now, on the motionless screen, I observe the cursor moving up when I move my finger down and vice versa. So, cursor is moving in the opposite direction, and it is the most confusing on the still content.

Do you want to have natural scrolling experience? Absolutely fine by me, I'd be happy to see it. But then let's implemenet natural scrolling, and not something different.

It's just a quick fix to stop current weird behavior. Sure, natural scrolling in the way it's done in mac, would be much better.

Easiness of implementation, to the extent that someone hardly familiar with the code can do it in 15 minutes, cannot justify an incorrect solution.

Agree. Not really 15 minutes but 20+ years and 15 minutes (counting my first mc builds on sco 20+ years ago) but I completely agree anyway ))) That's why I asked for help here.

The main idea of "natural" scrolling along with the touchpads is not about just "what to scroll" but "how to scroll". If content is scrolling, it shall be scrolled in the direction user drags his fingers on the touchpad surface. So, if MC moves the cursor, it definitely shall be moved in the same direction.

Again, you contradict yourself. You clearly stated that natural scrolling always scrolls the content, never the cursor. And yet you imagine how it would work if it moved the cursor, and want that to happen. Whereas I'd rather guess it would work the other way around. There's no use arguing about this. If natural scrolling always scrolls the content and never the cursor, we cannot start moving the cursor in whichever direction in the name of natural scrolling.

No contradictions. You asked how it's done in other apps, I did the short study and reported results. But I newer said it's the only way to implement the natural scrolling, and proposed another approach based on the current and existing functionality. It differs from the one observed in the mac apps, but still better than current, when cursor moves in the direction opposite to real fingers movement. And yes, it is still natural and I tried to explain why using real life examples

[...] there's no need to "double".

2-3-4-5x speed can be justified if without a multiplier scrolling would be very slow (you'd have to scroll way too much). Typically terminal emulators scroll about 3-5 lines on a single mouse wheel rotating click. In order to achieve the same behavior in a terminal-based app such as mc, it would need to scroll by one line upon every 1/3-1/5 of traditional unit seen from the touchpad. This requires extending the mouse protocol. Since it's not yet available, jumping by 3-5 lines at once might be a better overall experience than always jumping by 1 line, since the latter case scrolling is just painfully slow.

That's what the scrollbars were invented for;)

Moreover, for touchscreen devices scrolling should exactly follow the fingers' movement, see my brand new comment and link at the aforementioned VTE bug.

Touchscreen devices are in the another story, they would require the "touch" events support as its done in the modern mobile terminals. But even for the touchscreens, it is still weird to move cursor up when user moves fingers down

Conclusion: the best way to implement natural scrolling is to scroll the content and do not move the cursor at all. Never.

Sounds good to me.

Scrolling shall be done line-by-line - one line per one mouse scroll event.

I'm not sure. Anyway, the scrolling speed should be unified across mc. It could receive a new config option.

Nice and reasonable idea. But not related to the natural scrolling

As another not-so-good but quick solution, cursor could be moved in the scroling direction, not the opposite as it's done now.. Current MC behavior is very weird and inconvenient - to move cursor up when user scrolls down.

Veto from me on this one.

Don't you agree that it's better than moving the cursor in the opposite direction?

[egmont]

I don't understand you. I told you that at the very beginning that it could be a bit difficult to implement this in the MC, and you answered that there shall be "standard" solution and called this behavior as a standard.

Initially it was absolutely not clarified what was the problem with mc's lack of natural scrolling. The fact that your patch swapped the two directions mislead me into thinking that the global configuration option of "natural scrolling" was totally ignored and mc always behaved as if this setting was disabled, and you simply swapped the up and down directions. It was later clarified that we're discussing something entirely different.

That's why I proposed just to make a setting for the scroll direction. It's easy and will give users a chance to get rid of this reverse scrolling.

I'm totally lost again with what you're trying to say... Sigh... Where does a "reverse scrolling" happen in mc? It does not, in case you meant "the reverse of whatever the «natural scrolling» option is set to". Probably you wanted to say "reverse cursor movement".

Correct me if I'm wrong anywhere here:

There's two main components to this story, and let's absolutely clearly separate these two:

1) The first is the direction. I believe toggling the desktop-wide configuration option "System Preferences -> Trackpad -> Scroll direction: Natural" does one thing and one thing only: swaps up and down (as well as left and right; irrelevant here) for scrolling events everywhere. And because terminal emulators respect this setting, the directions are also always swapped in mc. All the rest of the story (that is, that scrolling should scroll the viewport and not move the cursor within the document, so the cursor might easily go offscreen) is irrelevant here remains untouched by this config option.

Let me know if I'm mistaken and if there's any app where flipping the desktop-wide "natural scrolling" config option does more than just swaps the directions.

Now you come and say that you'd want to have this option enabled (as it's macOS's default), yet want mc to revert the scrolling direction in some places, so that e.g. on long file listings you get exactly the non-natural scrolling direction. I don't see this request being justified at all: whatever your preference for scrolling direction is, I guess it should be consistent across the desktop, including mc. If file listing in mc scrolls in the reverse direction compared to everything else on your desktop, it's the most confusing thing I could imagine.

2) The second part of the story is all the other aspects of scrolling behavior. Here I understand that mc's behavior differs from most other apps, and I'm more than open to introducing a new option where scrolling means to scroll the contents and not to move the cursor. (You can see that in #3256 (mcview rewrite, behavior when reaching the end of the file) I heavily argued in favor of the behavior seen in modern apps rather than what legacy terminal-based apps do.)

This, on the other hand, should be independent from the first part of the story, that is, from the scrolling direction.

You seem to also mean this second part when you're talking about "natural scrolling", although technically it's a quite different thing, and even the wording on the macOS's config panel, namely "[checkbox] Scroll direction: Natural" suggests to me that the term "natural scrolling" should not have anything to do with these generic design principles.

---

It seems to me that you don't clearly separate these two things, instead you mix them in really weird and unusual ways, and look for a solution that entangles them more instead of clearly separating them.

I perfectly understand that the behavior when the cursor moves opposite to the finger movement is terrible.

It is also terrible if the contents scroll in the opposite direction as the rest of the desktop, because someone somewhere believes that the value of "natural scrolling", whatever it is set to, should be disobeyed.

Now imagine for a second this weird mixture: The long file listing in the panel obeys the "natural scrolling" setting, let's say it's enabled and you move your fingers downwards. As such, the viewport scrolls downwards, that is, you get to see earlier and earlier files. Let's assume that because we're afraid of heavily modifying mc's behavior, the cursor stays at the same visual spot, that is, keeps pointing to earlier and earlier files in the list. Then scrolling hits the top, hence stops. Let's again assume that we keep the current behavior of mc that we switch to moving the cursor. As per the terrible behavior you're worried about, you'd move the cursor downwards now (according to your fingers), so it'd go to later and later files in the listing. That is, for a while the cursor would move to earlier files, and then at some point it'd switch to moving to later files. Again a terrible behavior.

The solution is not to further mix everything into more and more complicated behaviors. The solution is to clearly separate the two parts of the story, to implement a behavior that matches most apps so that scrolling only scrolls the viewport and not the cursor. This would get rid of the terrible behavior you're worried about that the cursor moves opposite to the finger, and this would also get rid of the terrible behaviors I outlined in the previous two paragraphs.

It's just a quick fix to stop current weird behavior.

Paying the price of introducing other weird behaviors (as per above) along with a probably hard to understand config option that has no clear semantics, to get a certain behavior that vik finds good enough, but has no predecence in other apps. Plus, all this falsely in the name of "natural scrolling". You won't get my buy-in for such hacks (and I don't see any point in continuing this already way too lengthy discussion in this direction.)

I understand that implementing fully the behavior of modern apps is nontrivial, requires heavily modifying the code, and it might not be feasible right now. I believe that a slightly modified behavior, where the cursor remains at the same visual position, should be pretty easy to implement (e.g. for the panel listing you'd simply have to wipe out the code that moves the cursor by 1 entry) and should result in a pretty good behavior. I believe this is a compromise we should aim for, or at least try and evaluate if it's good enough for a start. You do have my support in this approach, I'll most likely even vote for making this new behavior the default. Let me know please if you have doubts, worries, questions etc. with this approach.

[vik]

Too much words. let me summarize:
1) there's a problem for mac users with the natural scrolling - cursor moves in the wrong direction.
2) I proposed a solution - to implement a SETTING for those users who annoyed by that. Not to change the default but to give people the possibility to scroll cursor in the same direction they move their fingers
3) we spent 3 days discussing different unrelated philosophical topics
4) You said you don't want to implement this and just want to leave everything as it is now

Did I forgot something?
And I don't understand who is in charge for the features - is it you? Who make a decision what will be included in the future releases and what would be not?

[egmont]

1) You clearly describe the overall scrolling experience in other apps. According to that, the problem is not that the cursor moves in the wrong direction (although it sure does move in the wrong direction), the problem is that the cursor moves at all.

2) When there are many files in the panel listing, and hence scrolling with the touchpad actually scrolls the listing (as expected), your patch (along with enabling the new config option) breaks it: makes it scroll in the opposite direction. I can't see how anyone could ask for this behavior, I can't see how you represent "mac users" in general here.

3) I'm sad to see how you don't get that most of my comments were relevant to the story. (Sure there were a few that weren't.)

4) No, I didn't say I wanted to leave everything as it is now. I said I'd be happy to see a patch that actually addresses and properly fixes the actual problems. I'd be happy to see a patch that makes mc behave like the rest of the apps with natural scrolling. Your patch doesn't take us closer to that, in fact, it takes us even further away from that, since you "fix" something that should entirely be removed instead (the cursor movement), while break something that works correctly without your new config option (scrolling in case of many files).

And I don't understand who is in charge for the features - is it you?

I'm one of the folks whose word probably matters, not the most, but to some extent.

Something else: Your modifications were a nightmare to apply, and compiles with tons of warnings about duplicate declarations. Please use "diff -ur [original] [modified]" or "git diff" for creating a proper diff, and please don't attach the complete new version of files, as that's unmaintainable if the file changes in the meantime.

[vik]

Just leave these "another apps" alone - we're talking about MC bug ))))
There's a problem with the cursor scrolling direction in MC and it's clear - when user drags fingers down, cursor moves up and vice versa. It's a bug and it shall be fixed asap. The fast way to fix is either to disable scrolling at all or to add the setting I proposed. As for me, the decision is clear.

Looks like you just want to keep your opinion and don't want to admit it's a bug and it shall be fixed. Have no idea why, maybe you just hate the natural scrolling as you told before. But if even so, you could just not turn this option on and rest of mac users, including me, will be happy because it's really obvious - cursor shall not move up when users scroll down. It's absolutely clear.

All your comments are good and nice but it's a theory as you agreed that it's hard to implement the behavior you'd like to (as it seen in another apps). So, why don't just fix a bug, I wonder? I'd try to look at the code and implement "offscreen" scrolling when I'll have some more time than I have now, or maybe you or someone else could, but why don't just fix it now at least getting rid of that wrong opposite scrolling? It's really strange, I don't understand your motives - is it just a stubbornness? Do you really believe this setting will disturb and obstruct somebody/something? Don't understand... Sure, I can apply this patch to every new version by myself, but there must be other people having the same problem...

About my patch - sure, I removed some "spaghetti code" and added some "if" statements - maybe it's a bit confusing, but I surely didn't add anything that could produce warnings - just because there's no place to do so )))) Looking in the code I dare to suppose these warnings lasts from the 1995, they look so familiar like I've seen them all before )))
I can do the diff as well as you could, but I'm not familiar with the code so my changes just an example how to fix this bug and I supposed someone else who knows code better will implement it in the "MC way". Ok, will add the diff in 5 minutes, I'm writing this from my laptop and sources are on the another computer, just give me 5 mins and I'll made it.

[egmont]

Replying to vik:

Just leave these "another apps" alone - we're talking about MC bug ))))

I have a good reason to refer to other apps: They define the standard behavior that most people are used to. If you want to convince me that mc should work as other apps do, it'll be quite easy. If you want to convince me to do something in mc that you yourself find logical, but we've never seen anywhere else, you'll have a much harder time. (And if that behavior is inconsistent, it'll be hopeless.)

What do these 3-4 closing parentheses mean? You keep using them.

There's a problem with the cursor scrolling direction in MC and it's clear - when user drags fingers down, cursor moves up and vice versa. It's a bug and it shall be fixed asap.

IMO not by paying the price of breaking natural scrolling in some other cases.

The fast way to fix is either to disable scrolling at all or to add the setting I proposed. As for me, the decision is clear.

I have already told you I don't know how many times that adding this setting you're suggesting breaks other things. As such it's a no-go. I don't know why the other possible quick fix would be to disable scrolling. I have for many times outlined yet another possible approach: disable cursor movement generated by the touchpad (but retain scrolling as it is now). I haven't heard from you what would be wrong with this approach. You only keep repeating your preferred approach, ignoring me showing why it's broken.

Looks like you just want to keep your opinion and don't want to admit it's a bug and it shall be fixed.

No, I clearly stated I agree it's a bug and I proposed a solution, with which (unlike with your proposal) I cannot foresee any problem.

Have no idea why, maybe you just hate the natural scrolling as you told before.

I never said I hate natural scrolling. I could just not get used to it.

What I hate is the idea of sometimes having natural scrolling, while at some other places having its opposite. What your patch would do.

You keep putting words in my mouth that I absolutely did not say, in fact, said the opposite. Please stop this. Quote me literally if you need to.

All your comments are good and nice but it's a theory as you agreed that it's hard to implement the behavior you'd like to (as it seen in another apps). So, why don't just fix a bug, I wonder?

You apparently missed that that's what I'd like to see, too. Not a heavy fix that implements offscreen cursors, at least not for now, as it would be a lot of work. Instead: just stop moving the cursor, leaving it at the same visual position, but have natural (or whichever your global preference is) scrolling for the contents. This should be really easy to implement.

but why don't just fix it now at least getting rid of that wrong opposite scrolling?

Again, I don't want to get rid of this in your proposed way because it has other problems, introduces other bugs. I do want to get rid of this in a way that doesn't introduce new problems.

I don't understand your motives - is it just a stubbornness? Do you really believe this setting will disturb and obstruct somebody/something? Don't understand...

No, it is my desire to have a nice, clean, maintainable code, and config options that are usable and make sense for more than one person. A change that makes natural scrolling non-natural at some places doesn't fulfill these criteria in my eyes, even if it fixes something else.

I'd like to emphasize again that:

• I pointed out problems with your approach, which you keep ignoring,

• I suggested an alternative, which you keep refusing to consider.

Sure, I can apply this patch to every new version by myself, but there must be other people having the same problem...

That's my point too. And I can't see how your proposed fix would be good enough, rather than totally confusing, for those other people.

but I surely didn't add anything that could produce warnings - just because there's no place to do so

You're much more confident than you should be.

I get 37 warnings that go like "setup.h:101:17: warning: redundant redeclaration of ‘mouse_reverse_scroll’ [-Wredundant-decls]".

Attachment mc.scrolling.diff.tgz​ added

In case you'd like to attach files in the future, please get familiar with the "diff" and "patch" tools, study how they are used pretty much everywhere, and accordingly attach a file that can be applied with one single "patch" command, without having to locate each file to be patched manually in the tree, thanks.

[vik]

Replying to egmont:

Replying to vik:

Just leave these "another apps" alone - we're talking about MC bug ))))

I have a good reason to refer to other apps: They define the standard behavior that most people are used to. If you want to convince me that mc should work as other apps do, it'll be quite easy. If you want to convince me to do something in mc that you yourself find logical, but we've never seen anywhere else, you'll have a much harder time. (And if that behavior is inconsistent, it'll be hopeless.)

Oh my... Like my school teacher used to say: "and if they'd jump out the window, would you jump too?"
I just wonder how can you ignore your own statements writing a lot of text hiding the meaning.
Once more again - it would be good to have the same functionality as other apps offers. Good but not must. As a programmer you shall understand the difference.
But scrolling down when user scrolls up - it's a bug. And, as a bug, it shall be fixed. It's so simple to understand )))) You just have to try this in the menu - it's really funny and the only thing you could think about would be: "who's this *%*^{# who made it???" ))))}

What do these 3-4 closing parentheses mean? You keep using them.

Just smiles, never mind

There's a problem with the cursor scrolling direction in MC and it's clear - when user drags fingers down, cursor moves up and vice versa. It's a bug and it shall be fixed asap.

IMO not by paying the price of breaking natural scrolling in some other cases.

Sure. I found just one case - the viewer. And I forgot to attach it, fixed.

The fast way to fix is either to disable scrolling at all or to add the setting I proposed. As for me, the decision is clear.

I have already told you I don't know how many times that adding this setting you're suggesting breaks other things. As such it's a no-go. I don't know why the other possible quick fix would be to disable scrolling. I have for many times outlined yet another possible approach: disable cursor movement generated by the touchpad (but retain scrolling as it is now). I haven't heard from you what would be wrong with this approach. You only keep repeating your preferred approach, ignoring me showing why it's broken.

What "other things" are yu talking about???? I have no words. Every menu in the MC scrolls down when user scrolls it up and scrolls up when user scrolls it down! ))))))) This is the bug and the problem! And you keep talking about some virtual "breaking other things" - what things? Menus will be scrolled in the correct way? ))))) Just give a n example, what would be broken?

Looks like you just want to keep your opinion and don't want to admit it's a bug and it shall be fixed.

No, I clearly stated I agree it's a bug and I proposed a solution, with which (unlike with your proposal) I cannot foresee any problem.

Please provide more details about these problems. I can show you at least one problem in your approach - menu scrolling wouldn't work.

What I hate is the idea of sometimes having natural scrolling, while at some other places having its opposite. What your patch would do.

I explained you so many times, natural scrolling is not about scrolling content, it's about moving something to the same direction that user moves his fingers. But you simply ignore it )))) Ok, I can repeat it once more - natural scrolling is not about scrolling content, it's about moving something to the same direction that user moves his fingers. And since current MC approach is to move the cursor, that means that cursor shall be moved in the same direction user moves fingers.
I don't understand, are you trolling me?

You keep putting words in my mouth that I absolutely did not say, in fact, said the opposite. Please stop this. Quote me literally if you need to.

All your comments are good and nice but it's a theory as you agreed that it's hard to implement the behavior you'd like to (as it seen in another apps). So, why don't just fix a bug, I wonder?

You apparently missed that that's what I'd like to see, too. Not a heavy fix that implements offscreen cursors, at least not for now, as it would be a lot of work. Instead: just stop moving the cursor, leaving it at the same visual position, but have natural (or whichever your global preference is) scrolling for the contents. This should be really easy to implement.

THIS would definitely break a lot of things, like menus I told you before

but why don't just fix it now at least getting rid of that wrong opposite scrolling?

Again, I don't want to get rid of this in your proposed way because it has other problems, introduces other bugs. I do want to get rid of this in a way that doesn't introduce new problems.

What "bugs"? Please explain

I don't understand your motives - is it just a stubbornness? Do you really believe this setting will disturb and obstruct somebody/something? Don't understand...

No, it is my desire to have a nice, clean, maintainable code, and config options that are usable and make sense for more than one person. A change that makes natural scrolling non-natural at some places doesn't fulfill these criteria in my eyes, even if it fixes something else.

Nice clean maintainable code that scrolls in the wrong direction, I suppose? What "unclean" here in this setting? If you mean that mouse event is globally changed, I can do it not in the mouse.c but in the panel.c, tree.c, editwidget.c etc

I'd like to emphasize again that:

• I pointed out problems with your approach, which you keep ignoring,

Please, could you clearly repeat what problems? I saw just one - you wrote that this behavior would be "not the same as in the other apps". Sure, it will not be the same because it's hard to implement the same. So, lets do at least this, it's better than nothing. And you still ignore the fact, that it's just an option, and everyone who don't need it could just turn it off

• I suggested an alternative, which you keep refusing to consider.

I showed you at least one problem with this alternative. But ok, I suggested an alternative and implemented it, would you implement yours?

Sure, I can apply this patch to every new version by myself, but there must be other people having the same problem...

That's my point too. And I can't see how your proposed fix would be good enough, rather than totally confusing, for those other people.

What will be confusing for other people??? Please explain if you can. It's an option in the ini, if someone don't need it he just won't turn it on. And you're still ignoring that fact

but I surely didn't add anything that could produce warnings - just because there's no place to do so

You're much more confident than you should be.

Because I have a reasons to )))) Not sure about you
The only string I added in this file is:
$ diff setup.h.original setup.h
101a102,103

extern gboolean mouse_reverse_scroll;

Do you really want to say that it produced all these warnings? )))) I suppose you're doing something wrong because this change could not, surely, add any warnings at all.

I get 37 warnings that go like "setup.h:101:17: warning: redundant redeclaration of ‘mouse_reverse_scroll’ [-Wredundant-decls]".

Attachment mc.scrolling.diff.tgz​ added

In case you'd like to attach files in the future, please get familiar with the "diff" and "patch" tools, study how they are used pretty much everywhere, and accordingly attach a file that can be applied with one single "patch" command, without having to locate each file to be patched manually in the tree, thanks.

Dear, I'm working with the diff and patch for more than 30 years now.)) but thank you for your advice anyway! Btw, the diff I attached is just made for the patch, so if you cannot use it' I'd suggest you to execute "man patch" command and read the text on the screen carefully )) maybe all these warnings will gone then as well?

Wel, you involved me in this again - tons of text and a little meaning. You definitely trolling me, are you? )))

Ok, could you clearly describe disadvantages of the solution I proposed, and also clearly describe yours?

[egmont]

Replying to vik:

What do these 3-4 closing parentheses mean? You keep using them.

Just smiles, never mind

I have never seen smileys like this. And no, I didn't recognize them (I had a guess that these might be smileys, but I wasn't sure).

And, so it happens, this is exactly what's wrong with your approach to the bugs as well. You have found truly valid bugs (it took a couple of back and forth comments to clarify what your actual problems were, with even some brand new ones in your latest comment, nevertheless, these are actual bugs that should be fixed), but then you propose a solution that I don't see why others would understand.

Dear, I'm working with the diff and patch for more than 30 years now.))

Sorry to say, but if after having used them for 30 years you diff the files in the opposite order (as you did in the original report), or attach multiple diff files in a tgz so that I have to manually locate the files to patch (mind you, there are multiple mouse.c files in the source under different directories, I truly wonder how your tgz would look like if you needed to modify both), and after all this you tell me how to use "patch", well, that's a pretty good sign to treat anything you suggest with a certain amount of healthy doubt.

Your smileys are not well-recognized smileys, it's something that you understand, others don't. Your diffs are not well-recognized diffs, it's something that you understand, but is a pain for others. Your idea about natural scrolling (dragging something, whereas that something is quite randomly either content or cursor, resulting in opposite scrolling direction of the content between these two cases) similarly just doesn't match the well-known interpretation of natural scrolling.

Sorry, I don't have any more time for this, I'm out of here. Goodbye!

[vik]

And again, you discussed my diff, my smileys and other dark sides of my nature but nothing about this bug ))))) I didn't meant I'll patch the sources, do you realize? I suppose I patched it wrong, moreover, I have almost no doubts I did. I might missed some places that have to be patched etc. I just wanted to show to the maintainers what is a problem and how I'd suggest to fix it, i.e. WHAT shall be patched. For example, for me including this "externl" in the lib/global.h is just a hack and cannot be populated in the production code, but I don't know the directories/modules structure. So, it was just a implementation SUGGESTION

Although I asked just two simple questions:
1) What are disadvantages of the solution proposed? You told a lot about it, please be a bit more specific
2) What are advantages of yours and who will implement it?

[egmont]

Replying to vik:

I just wanted to show to the maintainers what is a problem and how I'd suggest to fix it

Interestingly, you opened this bug showing how you'd fix – but not a word about what. No wonder I misunderstood initially. It took several back and forth comments to finally clarify what your actual problem was.

Although I asked just two simple questions:
1) What are disadvantages of the solution proposed? You told a lot about it, please be a bit more specific

I have exactly told you a couple of times what my problem is with your approach. If you didn't understand it so far, I see no chance of making you understand it by phrasing it over and over again using different words. Please go back and carefully read my comments again.

2) What are advantages of yours

Ditto.

and who will implement it?

I cannot tell it right now. mc is developed by volunteers in their free time. Currently it has about 500 open bugs. I hardly have any time to work on it nowadays, some other developers apparently have somewhat more.

Your best bet, if you really want this to get addressed, is to do it yourself, listening to the developers and doing the work along their guidelines, not stubbornly against them.

If you'd like someone other than you to implement it, here's my suggestion. This bug here has become way too long, and the chances of anyone ever going through it is almost 0. Close this bug and open a new one. In the initial report describe what is wrong currently in mc, mention a couple of example on its UI where the behavior is "upside down", but the opening bug should be this and this only. You could include a link to this bug. In a followup comment you may suggest your preferred way of solving it. Be aware that I am going to respond describing why I cast a veto on that approach, and what my preferred approach would be. We will just be stating our opinions and leave it there, and not start over this debate. Then it will be short enough for others to reasonably pick it up and work on it.

[vik]

1) You wrote: "I pointed out problems with your approach, which you keep ignoring" and "Again, I don't want to get rid of this in your proposed way because it has other problems, introduces other bugs. I do want to get rid of this in a way that doesn't introduce new problems."
I asked "what bugs" You ignored the question. I assume you have nothing to say. It's understood, I just don't undertsnad why did yo start this trolling then

2) You are not all developers, just a stubborn one who don't want to admit he was wrong. All is clear for me, so bye.

[egmont]

I asked "what bugs" You ignored the question.

No, I did not ignore the question, I answered it multiple times. In fact, I started straight away by pointing out the exact problem as soon as I realized it, rather than just casually waving the "it has bugs" flag. After a while I got fed up with repeating myself over and over again and told you to look back at my previous comments.

But since so far you've understood exactly 0 of what I wrote here, I don't expect you to realize this either.

I just don't undertsnad why did yo start this trolling then

We have pretty different views on who's trolling here.

You are not all developers

Just as you are not all Mac users, and your idea about natural scrolling (which isn't backed up by any existing app you could refer to) is potentially not what others want to see. But I don't expect you to understand this either.

just a stubborn one who don't want to admit he was wrong.

Ha-ha. I told you what's wrong with your proposal. You did not comment so far on my one, despite me having asked you to point out if you see any problems with that. So who's the stubborn here, again?

All is clear for me, so bye.

It was a pleasure talking to you. (No.)