Fixes#7077
This follows pretty standard behavior across native or popular
applications on both platforms macOS and Linux. The basic behavior is
that if you do a mouse down event and then drag the mouse beyond the
current character, then any mouse up actions are canceled (beyond
emiting the event itself).
This fixes a specific scenario where you could do the following:
1. Click anywhere (mouse down)
2. Drag over a valid link
3. Press command/control (to activate the link)
4. Release the mouse button (mouse up)
5. The link is triggered
Now, step 3 and step 5 do not happen. Links are not even highlighted in
this scenario. This matches iTerm2 on macOS which has a similar
command-to-activate-links behavior.
## Demo
https://github.com/user-attachments/assets/f79767b1-78fd-432b-af46-28194b816747
Fixes#7071
When the mouse is being actively dragged, AppKit continues to emit
mouseDragged events which will update our position appropriately. The
mouseExit event we were sending sends a synthetic (-1, -1) position
which was causing a scroll up.
Fixes#7077
This follows pretty standard behavior across native or popular applications
on both platforms macOS and Linux. The basic behavior is that if you
do a mouse down event and then drag the mouse beyond the current
character, then any mouse up actions are canceled (beyond emiting the
event itself).
This fixes a specific scenario where you could do the following:
1. Click anywhere (mouse down)
2. Drag over a valid link
3. Press command/control (to activate the link)
4. Release the mouse button (mouse up)
5. The link is triggered
Now, step 3 and step 5 do not happen. Links are not even highlighted in
this scenario. This matches iTerm2 on macOS which has a similar
command-to-activate-links behavior.
Fixes#7071
When the mouse is being actively dragged, AppKit continues to emit
mouseDragged events which will update our position appropriately. The
mouseExit event we were sending sends a synthetic (-1, -1) position
which was causing a scroll up.
The helper team has been discussing some common issues we see with
Discussion submissions (missing info, duplicates, etc.), and pluie's
#6937 has been a huge step forward - this PR introduces a template for
the Issue Triage Discussion type.
The template has gone through a few revisions prior to this PR, but I am
certain there are probably a few places to be cleaned up. You can test
it out by [opening a new "Issue Triage" Discussion in my
fork](https://github.com/taylrfnt/ghostty/discussions/new?category=issue-triage).
~~Creating this as a draft for now, since I may not be able to respond
to any review comments in a timely manner.~~
With this PR now it supports the brazilian portuguese language for
ghostty, native speaker and resident, want to bring this language to
this new terminal that is starting to become very fondly to me! Any
questions about it i am free to answer.
Hi!
I have followed the instructions and added translations for Spanish,
Country Latin America 419 according to
[this](https://localizely.com/locale-code/es-419/) and other online
sources.
In the provided links there was no references to 419, but I created it
via the suggested command:
`msginit -i po/com.mitchellh.ghostty.pot -l es_419.UTF-8 -o
"po/es_419.UTF-8.po" `
Glad to be able to contribute to this excellent product!
Cheers!
