aboutsummaryrefslogtreecommitdiff
path: root/src/nvim/window.c
Commit message (Collapse)AuthorAge
* Merge pull request #31597 from bfredl/deletionismbfredl2025-01-20
|\ | | | | fix(wininfo): when freeing windows, free the lowest priority wininfo
| * fix(wininfo): when freeing windows, free the lowest priority wininfobfredl2025-01-14
| | | | | | | | | | | | | | | | | | | | | | On master (and also before #31539) closing a window could cause the used wininfo for a buffer to change. This is due to always removing the previous NULL wininfo when deleting a window, even if that wininfo had higher priority than the the deleted window's own wininfo. Instead delete the wininfo with lowest priority. This retains the memory saving efect while not affecting the effective value of window options and so on.
* | feat(api): nvim_open_win() relative to tabline and laststatus #32006luukvbaal2025-01-14
| | | | | | | | | | | | | | Problem: Anchoring a floating window to the tabline and laststatus is cumbersome; requiring autocommands and looping over all windows/tabpages. Solution: Add new "tabline" and "laststatus" options to the `relative` field of nvim_open_win() to place a window relative to.
* | docs: miscdundargoc2025-01-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Co-authored-by: Axel <axelhjq@gmail.com> Co-authored-by: Colin Kennedy <colinvfx@gmail.com> Co-authored-by: Daiki Noda <sys9kdr@users.noreply.github.com> Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com> Co-authored-by: Jean-Jacq du Plessis <1030058+jj-du-plessis@users.noreply.github.com> Co-authored-by: Juan Giordana <juangiordana@gmail.com> Co-authored-by: Lincoln Wallace <locnnil0@gmail.com> Co-authored-by: Matti Hellström <hellstrom@scm.com> Co-authored-by: Steven Locorotondo <steven.locorotondo@justeattakeaway.com> Co-authored-by: Yochem van Rosmalen <git@yochem.nl> Co-authored-by: glepnir <glephunter@gmail.com> Co-authored-by: ifish <fishioon@live.com>
* | vim-patch:9.1.0993: New 'cmdheight' behavior may be surprising #31892luukvbaal2025-01-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Although patch 9.1.0990 fixed a real problem/inconsistency, it also introduced new behavior that may break BWC and/or be unexpected. Before 9.1.0990, window commands could make the topframe smaller (without changing 'cmdheight'; quirk that is now fixed), but did not allow extending the topframe beyond the 'cmdheight' set by the user. After 9.1.0990, the user can reduce the 'cmdheight' below the value they set explicitly, through window commands, which may lead to confusion. (aftere v9.1.0990) Solution: Store the value explicitly set by the user and clamp the 'cmdheight' when resizing the topframe. This also applies to dragging laststatus, which in contrast to window commands _did_ allow reducing the 'cmdheight' to values below the one set by the user. So with this patch there is still new behavior, but I think in a way that is less surprising. While at it, also fix a Coverity warning, introduced in v9.1.0990 (Luuk van Baal) https://github.com/vim/vim/commit/c97e8695353565d6b20adffa48aad47f6e09967f
* | vim-patch:9.1.0990: Inconsistent behavior when changing cmdheight (#31830)luukvbaal2025-01-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Inconsistent behavior when changing cmdheight by resizing the topframe through wincmds and dragging laststatus. Changing cmdheight by resizing the topframe does not trigger OptionSet. Solution: Consolidate logic for changing the cmdheight, set the option value to handle side-effects (Luuk van Baal) https://github.com/vim/vim/commit/e15cbc1af47e9dea90448c714eb4908e5d4302fc vim-patch:9.0.0187: command line height changes when maximizing window height Problem: Command line height changes when maximizing window height. Solution: Do not change the command line height. (closes vim/vim#10885) https://github.com/vim/vim/commit/96bde99bf890acd9952863a02c1d15edca2000e1
* | refactor: iwyu #31637Justin M. Keyes2024-12-23
| | | | | | Result of `make iwyu` (after some "fixups").
* | Merge pull request #31539 from bfredl/wininfobfredl2024-12-16
|\| | | | | refactor(wininfo): change wininfo from a linked list to an array
| * refactor(wininfo): change wininfo from a linked list to an arraybfredl2024-12-16
| | | | | | | | | | | | | | | | | | | | "wininfo" is going to be my next victim. The main problem with wininfo is that it is "all or nothing", i e either all state about a buffer in a window is considered valid or none of it is. This needs to be fixed to address some long running grievances. For now this is just a warmup: refactor it from a linked list to a vector.
* | fix(api): not using TRY_WRAP, generic error messages #31595Justin M. Keyes2024-12-16
|/ | | | | | | | | | | Problem: - API functions using `try_start` directly instead of `TRY_WRAP`, do not surface the underlying error message, and instead show generic things like "Failed to set buffer". - Error handling code is duplicated in the API impl, instead of delegating to the vim buffer/window handling logic. Solution: - Use `TRY_WRAP`.
* fix(float): re-sort layers when grid zindex changed #30259glepnir2024-12-12
| | | | | | Problem: when zindex is changed in vim.schedule the zindex sort in layers not changed. Solution: resort layers when zindex changed.
* fix(ui): clamp 'cmdheight' for other tabpages on screen resize (#31419)zeertzjq2024-12-02
|
* vim-patch:9.1.0892: the max value of 'cmdheight' is limited by other ↵zeertzjq2024-11-29
| | | | | | | | | | | | | | | | | | | | | | | | | | tabpages (#31378) Problem: the max value of 'cmdheight' is limited by other tabpages Solution: Limit the maximum value of 'cmdheight' to the current tabpage only. (Milly) The Help says that cmdheight is local to the tab page, but says nothing about the maximum value depending on the state of all tab pages. Users may wonder why they can't increase cmdheight when there are still rows available on the current tab page. This PR changes the behavior of cmdheight so that its maximum value depends only on the state of the current tab page. Also, since magic numbers were embedded in various places with the minimum value of cmdheight being 1, we defined a constant to make it easier to understand. closes: vim/vim#16131 https://github.com/vim/vim/commit/2cddf0e85a7f8304476397e1c51dcd0e41835ac3 Cherry-pick Test_cmdheight_not_changed() from patch 9.0.0187. Co-authored-by: Milly <milly.ca@gmail.com>
* refactor(options): autogenerate valid values and flag enums for options (#31089)Famiu Haque2024-11-23
| | | | | | | | | | | | | | Problem: Option metadata like list of valid values for an option and option flags are not listed in the `options.lua` file and are instead manually defined in C, which means option metadata is split between several places. Solution: Put metadata such as list of valid values for an option and option flags in `options.lua`, and autogenerate the corresponding C variables and enums. Supersedes #28659 Co-authored-by: glepnir <glephunter@gmail.com>
* refactor(options): remove `.indir`, redesign option scopes #31066Famiu Haque2024-11-16
| | | | | | | | | | | | | | | | | | | | | | Problem: The way option scopes currently work is inflexible and does not allow for nested option scopes or easily finding the value of an option at any arbitrary scope without having to do long handwritten switch-case statements like in `get_varp()`. `.indir` is also confusing and redundant since option indices for each scope can be autogenerated. Solution: Expand option scopes in such a way that an option can support any amount of scopes using a set of scope flags, similarly to how it's already done for option types. Also make options contain information about its index at each scope it supports. This allows for massively simplifying `get_varp()` and `get_varp_scope()` in the future by just using a struct for options at each scope. This would be done by creating a table that stores the offset of an option's variable at a scope by using the option's index at that scope as a key. This PR also autogenerates enums for option indices at each scope to remove the need for `.indir` entirely, and also to allow easily iterating over options all options that support any scope. Ref: #29314
* vim-patch:9.1.0855: setting 'cmdheight' may missing output (#31216)zeertzjq2024-11-15
| | | | | | | | | | | | Problem: setting 'cmdheight' may cause hit-enter-prompt and echo output to be missing Solution: Before cleaning the cmdline, check the need_wait_return flag (nwounkn) closes: vim/vim#13432 https://github.com/vim/vim/commit/2e48567007f2becd484a3c3dd0706bf3a0beeae7 Co-authored-by: nwounkn <nwounkn@gmail.com>
* vim-patch:9.1.0812: Coverity warns about dereferencing NULL ptrzeertzjq2024-10-24
| | | | | | | | | | | | Problem: Coverity warns about dereferencing NULL ptr in check_colorcolumn() Solution: verify that wp is not null before accessing it related: vim/vim#15914 https://github.com/vim/vim/commit/d0809869d6445faecd323fb33dc271d8c74a94fb Co-authored-by: Christian Brabandt <cb@256bit.org>
* vim-patch:9.1.0804: tests: no error check when setting global 'cc'zeertzjq2024-10-24
| | | | | | | | | | | Problem: tests: no error check when setting global 'cc' Solution: also parse and check global 'cc' value (Milly) closes: vim/vim#15914 https://github.com/vim/vim/commit/a441a3eaabbfc14b4772e07ecbecaaff3bd06a58 Co-authored-by: Milly <milly.ca@gmail.com>
* feat(float): allow enabling mouse for non-focusable window (#30844)zeertzjq2024-10-20
| | | | Problem: Cannot allow mouse interaction for non-focusable float window. Solution: Add a "mouse" field to float window config.
* fix(window): making float with title/footer non-float leaks memory (#30551)zeertzjq2024-09-28
|
* fix(window): respect hide flag of float windows when switching (#30507)glepnir2024-09-28
|
* vim-patch:9.1.0678: [security]: use-after-free in alist_add()zeertzjq2024-08-17
| | | | | | | | | | | | | Problem: [security]: use-after-free in alist_add() (SuyueGuo) Solution: Lock the current window, so that the reference to the argument list remains valid. This fixes CVE-2024-43374 https://github.com/vim/vim/commit/0a6e57b09bc8c76691b367a5babfb79b31b770e8 Co-authored-by: Christian Brabandt <cb@256bit.org>
* vim-patch:partial:8.1.0914: code related to findfile() is spread out (#30000)zeertzjq2024-08-07
| | | | | | | | | | Problem: Code related to findfile() is spread out. Solution: Put findfile() related code into a new source file. (Yegappan Lakshmanan, closes vim/vim#3934) https://github.com/vim/vim/commit/5fd0f5052f9a312bb4cfe7b4176b1211d45127ee Keep functions related to wildcard expansion in path.c, as in Vim they are now spread out among multiple files, which isn't really ideal.
* vim-patch:9.1.0647: [security] use-after-free in tagstack_clear_entryzeertzjq2024-08-02
| | | | | | | | | | | | | | | | | | | Problem: [security] use-after-free in tagstack_clear_entry (Suyue Guo ) Solution: Instead of manually calling vim_free() on each of the tagstack entries, let's use tagstack_clear_entry(), which will also free the stack, but using the VIM_CLEAR macro, which prevents a use-after-free by setting those pointers to NULL This addresses CVE-2024-41957 Github advisory: https://github.com/vim/vim/security/advisories/GHSA-f9cr-gv85-hcr4 https://github.com/vim/vim/commit/8a0bbe7b8aad6f8da28dee218c01bc8a0185a2d5 Co-authored-by: Christian Brabandt <cb@256bit.org>
* refactor: collapse statements in single assignmentsLewis Russell2024-07-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: Variables are often assigned multiple places in common patterns. Solution: Replace these common patterns with different patterns that reduce the number of assignments. Use `MAX` and `MIN`: ```c if (x < y) { x = y; } // --> x = MAX(x, y); ``` ```c if (x > y) { x = y; } // --> x = MIN(x, y); ``` Use ternary: ```c int a; if (cond) { a = b; } els { a = c; } // --> int a = cond ? b : c; ```
* vim-patch:9.1.0575: Wrong comments in alt_tabpage() (#29692)zeertzjq2024-07-14
| | | | | | | | | Problem: Wrong comments in alt_tabpage() (after v9.1.0572) Solution: Correct the comments (zeertzjq). closes: vim/vim#15235 https://github.com/vim/vim/commit/1a3dd7dc7847a3568fe96192a21e478f46c07929
* vim-patch:9.1.0572: cannot specify tab page closing behaviour (#29682)zeertzjq2024-07-13
| | | | | | | | | | | | Problem: cannot specify tab page closing behaviour (Gianluca Pacchiella) Solution: Add the 'tabclose' option (LemonBoy). fixes: vim/vim#5967 closes: vim/vim#15204 https://github.com/vim/vim/commit/5247b0b92e191a046b034171a3b34031e317735f Co-authored-by: LemonBoy <thatlemon@gmail.com>
* revert: "refactor: use S_LEN macro" (#29319)Lewis Russell2024-06-14
| | | | | revert: "refactor: use S_LEN(s) instead of s, n (#29219)" This reverts commit c37695a5d5f2e8914fff86f3581bed70b4c85d3c.
* refactor: use S_LEN(s) instead of s, n (#29219)James2024-06-11
|
* refactor: move shared messages to errors.h #26214Justin M. Keyes2024-06-01
|
* vim-patch:9.1.0374: wrong botline in BufEnter (#28530)zeertzjq2024-04-27
| | | | | | | | | | | | | | | | Problem: When :edit an existing buffer, line('w$') may return a wrong result. Solution: Reset w_valid in curwin_init() (Jaehwang Jung) `do_ecmd()` reinitializes the current window (`curwin_init()`) whose `w_valid` field may have `VALID_BOTLINE` set. Resetting `w_botline` without marking it as invalid makes subsequent `validate_botline()` calls a no-op, thus resulting in wrong `line('w$')` value. closes: vim/vim#14642 https://github.com/vim/vim/commit/eb80b8304efb6dfeaa8d01dd41fe281df4894240 Co-authored-by: Jaehwang Jung <tomtomjhj@gmail.com>
* feat(api): allow floats to be opened in non-current tabpage (#28480)Will Hopkins2024-04-25
| | | \
* Merge pull request #28434 from glepnir/23120bfredl2024-04-22
|\ | | | | fix(float): wrong position when bufpos is out of range
| * fix(float): wrong position when bufpos is setglepnir2024-04-21
| | | | | | | | | | | | Problem: when lnum in bufpos is out of range the position of float is wired. Solution: avoid the height value out of buffer line range.
* | fix(window): don't go to unfocusable float when closing (#28455)zeertzjq2024-04-22
| |
* | fix(ui): don't force 'cmdheight' to zero with ext_messagesLuuk van Baal2024-04-20
|/ | | | Remove remaining code that prevents non-zero 'cmdheight' with ext_messages.
* fix(api): ignore 'autochdir' when renaming other buf (#28376)zeertzjq2024-04-16
| | | | | | Problem: Renaming non-current buffer changes working directory when 'autochdir' is set. Solution: Temporarily disable 'autochdir'. Add more tests for the win_set_buf change.
* fix(api): ignore 'autochdir' when setting buf in other win (#28371)Raphael2024-04-16
| | | | | Problem: Wrong working directory when setting buffer in another window with 'autochdir' enabled. Solution: Temporarily disable 'autochdir'.
* feat(api)!: nvim_open_win: noautocmd blocks all autocmds #28192Sean Dewar2024-04-14
| | | | | | | | | | | | | | | | | | | | | | | | | | Problem: noautocmd is confusing; despite its name, it doesn't block all autocommands (instead it blocks only those related to setting the buffer), and is commonly used by plugins to open windows while producing minimal side-effects. Solution: be consistent and block all autocommands when noautocmd is set. This includes WinNew (again), plus autocommands from entering the window (if enter is set) like WinEnter, WinLeave, TabEnter, .etc. See the discussion at https://github.com/neovim/neovim/pull/14659#issuecomment-2040029517 for more information. Remove win_set_buf's noautocmd argument, as it's no longer needed. NOTE: pum_create_float_preview sets noautocmd for win_set_buf, but all its callers already use block_autocmds. Despite that, pum_create_float_preview doesn't actually properly handle autocommands (it has no checks for whether those from win_enter or nvim_create_buf free the window). For now, ensure autocommands are blocked within it for correctness (in case it's ever called outside of a block_autocmds context; the function seems to have been refactored in #26739 anyway).
* refactor: fix clang NonNullParamChecker warnings (#28327)zeertzjq2024-04-14
|
* vim-patch:9.1.0272: autocmd may change cwd after :tcd and :lcd (#28223)zeertzjq2024-04-08
| | | | | | | | | Problem: Autocommand may change currect directory after :tcd and :lcd. Solution: Also clear tp_localdir and w_localdir when using aucmd_win. (zeertzjq) closes: vim/vim#14435 https://github.com/vim/vim/commit/9d956ee8eab64a0d412b045305fde5bc03d95d4a
* feat(ui): indicate margins for the area used by win_viewportbfredl2024-03-29
| | | | | | | | Problem: using win_viewport for implementing smooth scrolling in an external UI might run into problems when winbar or borders is used, as there is no indication that the entire grid is not used for scrolled buffer text. Solution: add `win_viewport_margins` event.
* vim-patch:9.1.0175: wrong window positions with 'winfix{width,height}' (#27845)Sean Dewar2024-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: winframe functions incorrectly recompute window positions if the altframe wasn't adjacent to the closed frame, which is possible if adjacent windows had 'winfix{width,height}' set. Solution: recompute for windows within the parent of the altframe and closed frame. Skip this (as before) if the altframe was top/left, but only if adjacent to the closed frame, as positions won't change in that case. Also correct the return value documentation for win_screenpos. (Sean Dewar) The issue revealed itself after removing the win_comp_pos call below winframe_restore in win_splitmove. Similarly, wrong positions could result from windows closed in other tabpages, as win_free_mem uses winframe_remove (at least until it is entered later, where enter_tabpage calls win_comp_pos). NOTE: As win_comp_pos handles only curtab, it's possible via other means for positions in non-current tabpages to be wrong (e.g: after changing 'laststatus', 'showtabline', etc.). Given enter_tabpage recomputes it, maybe it's intentional as an optimization? Should probably be documented in win_screenpos then, but I won't address that here. closes: vim/vim#14191 Nvim: don't reuse "wp" for "topleft" in winframe_remove, so the change integrates better with the call to winframe_find_altwin before it. https://github.com/vim/vim/commit/5866bc3a0f54115d5982fdc09bdbe4c45069265a
* fix(api/buffer): fix handling of viewport of non-current bufferbfredl2024-03-13
| | | | | | | | | | | A lot of functions in move.c only worked for curwin, alternatively took a `wp` arg but still only work if that happens to be curwin. Refactor those that are needed for update_topline(wp) to work for any window. fixes #27723 fixes #27720
* vim-patch:9.1.0171: Small split-move related improvementsSean Dewar2024-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: small improvements can be made to split-move related functions. Solution: apply them (Sean Dewar): Some of these changes were already applied to Nvim. Here are the ones which were missing: - Improve some doc comments (frame_flatten should still work for non-current tabpages, despite the topframe check, which looks benign, though I'm unsure if it's still needed; see vim/vim#2467). - f_win_splitmove should check_split_disallowed on wp, not targetwin, as that's what win_splitmove checks (though it's probably unnecessary to check b_locked_split at all; see vim/vim#14109, which I hope to get around to finishing at some point). - Apply the winframe_restore comment changes, and remove win_comp_pos from after winframe_restore in win_splitmove, as it shouldn't be necessary (no need to remove it from nvim_win_set_config too, as it was already omitted). Move win_append after winframe_restore in win_splitmove to match Vim. closes: vim/vim#14185 https://github.com/vim/vim/commit/5cac1a9bee0798d70a7fd80363a1f697759638e8
* vim-patch:9.1.0170: Re-allow curwin == prevwin, but document it insteadSean Dewar2024-03-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: more places exist where curwin == prevwin, and it may even be expected in some cases. Solution: revert v9.1.0001, but document that it's possible instead. (Sean Dewar) I've had a change of heart for the following reasons: - A quick 'n dirty [GitHub code search](https://github.com/search?q=%2F%28winnr%5C%28%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%7Cwinnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5C%29%29%2F&type=code) reveals some cases where it's expected in the wild. Particularly, it made me aware `winnr() == winnr('#')` is possible when curwin is changed temporarily during the evaluation of a &statusline expression item (`%{...}`), and is used to show something different on the statusline belonging to the previous window; that behaviour wasn't changed in v9.1.0001, but it means curwin == prevwin makes sense in some cases. - The definition and call sites of back_to_prevwin imply some expectation that prevwin == wp (== curwin) is possible, as it's used to skip entering the prevwin in that case. - Prior to v9.1.0001, `:wincmd p` would not beep in the case that was patched in v9.1.0001, but now does. That resulted in vim/vim#14047 being opened, as it affected the CtrlP plugin. I find it odd that `:wincmd p` had cases where it wouldn't beep despite doing nothing, but it may be preferable to keep things that way (or instead also beep if curwin == prevwin, if that's preferred). - After more digging, I found cases in win_free_mem, enter_tabpage, aucmd_restbuf and qf_open_new_cwindow where curwin == prevwin is possible (many of them from autocommands). Others probably exist too, especially in places where curwin is changed temporarily. fixes: vim/vim#14047 closes: vim/vim#14186 https://github.com/vim/vim/commit/d64801e913314d2e19dbb38f60e6d285238debff
* vim-patch:9.1.0150: Several minor 'winfixbuf' issuesColin Kennedy2024-03-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: several minor 'winfixbuf' issues exist, mostly relating to the quickfix list Solution: address them and adjust tests. Retab and reflow a few things too. (Sean Dewar) Things touched include: - Replace the semsgs with gettext'd emsgs. - Handle window switching in ex_listdo properly, so curbuf and curwin are kept in-sync and trigger autocommands; handle those properly. - Don't change the list entry index in qf_jump_edit_buffer if we fail due to 'wfb' (achieved by returning FAIL; QF_ABORT should only be used if the list was changed). - Make qf_jump_edit_buffer actually switch to prevwin when using `:cXX` commands **outside** of the list window if 'wfb' is set in curwin. Handle autocommands properly in case they mess with the list. NOTE: previously, it seemed to split if 'wfb' was set, but do nothing and fail if prevwin is *valid*. This behaviour seemed strange, and maybe unintentional? Now it aligns more with what's described for the `:cXX` commands in the original PR description when used outside a list window, I think. - In both functions, only consider prevwin if 'wfb' isn't set for it; fallback to splitting otherwise. - Use win_split to split. Not sure if there was a specific reason for using ex_splitview. win_split is simpler and respects modifiers like :vertical that may have been used. Plus, its return value can be checked for setting opened_window in qf code (technically win_split_ins autocmds could immediately close it or change windows, in which the qf code might close some other window on failure; it's already the case elsewhere, though). closes: vim/vim#14142 https://github.com/vim/vim/commit/4bb505e28cac0389561fff78d8bbe0319c2bcf2f Co-authored-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
* vim-patch:9.1.0147: Cannot keep a buffer focused in a windowColin Kennedy2024-03-11
| | | | | | | | | | | | | | | Problem: Cannot keep a buffer focused in a window (Amit Levy) Solution: Add the 'winfixbuf' window-local option (Colin Kennedy) fixes: vim/vim#6445 closes: vim/vim#13903 https://github.com/vim/vim/commit/215703563757a4464907ead6fb9edaeb7f430bea N/A patch: vim-patch:58f1e5c0893a
* revert: "fix(window): :close crash with autocmd, floats and tabpage" (#27796)zeertzjq2024-03-10
| | | | | | | | This reverts PR #27793. On second thought, this solution may still crash, because it can leave a window with a NULL buffer if there are autocommand windows or if closing a floating window fails. It also makes close_last_window_tabpage() more complicated, so revert it.
* fix(window): :close crash if WinClosed from float closes window (#27794)zeertzjq2024-03-10
| | | | Problem: :close crash if WinClosed from float closes window. Solution: Check if window has already been closed.
generated by cgit (git 2.34.1) at 2025-06-25 08:54:26 +0000