On 10/02/2026 2:54 AM, Maxim Kim wrote: > https://github.com/vim/vim/issues/21427 > > The help topic for 'modified' specifically mention some events that do not > set it, although missing the Filetype event. Yes, I saw this as well. Perhaps it should be part of the bug-fix.> > On Friday, October 2, 2026 at 4:31:21 PM UTC+10 Maxim Kim wrote: > >> This looks like a bug, worth creating an issue in vim's github. >> >> echo getbufinfo(bufnr()) says that `changed: 0` however `changedtick` is >> greater than 0 >> >> As for >> >>> It's purpose is to automatically insert lines in files that have a >> specified filetype or to provide that service for other files >> >> check :h skeleton >> >> But it would have the same issue as with Filetype >> >> On Friday, October 2, 2026 at 12:41:59 PM UTC+10 Mike wrote: >> >>> Hi all, >>> >>> I'm seeing unexpected behavior when using an autocmd defined in a >>> plugin. A simplified version of the plugin is the following: >>> >>> function! InsertText() >>> echomsg "modified option is " .. &modified >>> call append(line("$"), "section title") >>> echomsg "modified option is " .. &modified >>> endfunction >>> >>> autocmd FileType fortran call InsertText() >>> command -nargs=0 ForNoFT call InsertText() >>> >>> It's purpose is to automatically insert lines in files that have a >>> specified filetype or to provide that service for other files. In the >>> above example, I've used "fortran" but I think any vim-recognized >>> filetype will do. >>> >>> To show the problem, edit a Fortran file, e.g. run "vim test.f90". You >>> will see the text "section title" in the buffer. However, even though >>> the 'modified' option is set, I am allowed to quit vim (:q). Also, ^G >>> does not show modified. This behavior occurs whether the file >>> "test.f90" is new or has content. >>> >>> A user-command has been defined in the plugin, intended for files >>> without a filetype. When you run "vim test.unknown" and then run the >>> user-command "ForNoFT", quit will fail as expected and ^G will show >>> modified. >>> >>> Interestingly, if 'modified' is explicitly set in the function, then vim >>> will not quit because it sees test.f90 as modified. >>> >>> My question is why the difference? >>> I'm running vim 9.2.1036 with normal features on Windows 10. >>> >>> Thanks for any help. >>> -mike >>> >>> >>> >>> > -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/vim_use/119objp%24he5%242%40ciao.gmane.io.
Friday, October 2, 2026
Re: unexpected result using autocmd
Maxim, On 10/02/2026 2:31 AM, Maxim Kim wrote: > This looks like a bug, worth creating an issue in vim's github. Okay, I will do so.> > echo getbufinfo(bufnr()) says that `changed: 0` however `changedtick` is > greater than 0 > > As for > >> It's purpose is to automatically insert lines in files that have a > specified filetype or to provide that service for other files > > check :h skeleton Thanks for the tip. I've never seen this example in help even though it pre-dates Vim 7.0. Learn something new every day.> > But it would have the same issue as with Filetype > > On Friday, October 2, 2026 at 12:41:59 PM UTC+10 Mike wrote: > >> Hi all, >> >> I'm seeing unexpected behavior when using an autocmd defined in a >> plugin. A simplified version of the plugin is the following: >> >> function! InsertText() >> echomsg "modified option is " .. &modified >> call append(line("$"), "section title") >> echomsg "modified option is " .. &modified >> endfunction >> >> autocmd FileType fortran call InsertText() >> command -nargs=0 ForNoFT call InsertText() >> >> It's purpose is to automatically insert lines in files that have a >> specified filetype or to provide that service for other files. In the >> above example, I've used "fortran" but I think any vim-recognized >> filetype will do. >> >> To show the problem, edit a Fortran file, e.g. run "vim test.f90". You >> will see the text "section title" in the buffer. However, even though >> the 'modified' option is set, I am allowed to quit vim (:q). Also, ^G >> does not show modified. This behavior occurs whether the file >> "test.f90" is new or has content. >> >> A user-command has been defined in the plugin, intended for files >> without a filetype. When you run "vim test.unknown" and then run the >> user-command "ForNoFT", quit will fail as expected and ^G will show >> modified. >> >> Interestingly, if 'modified' is explicitly set in the function, then vim >> will not quit because it sees test.f90 as modified. >> >> My question is why the difference? >> I'm running vim 9.2.1036 with normal features on Windows 10. >> >> Thanks for any help. >> -mike >> >> >> >> > -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/vim_use/119obhg%24he5%241%40ciao.gmane.io.
Thursday, October 1, 2026
Re: unexpected result using autocmd
This looks like a bug, worth creating an issue in vim's github.
echo getbufinfo(bufnr()) says that `changed: 0` however `changedtick` is greater than 0
As for> It's purpose is to automatically insert lines in files that have a
specified filetype or to provide that service for other files
check :h skeleton
But it would have the same issue as with Filetype
On Friday, October 2, 2026 at 12:41:59 PM UTC+10 Mike wrote:
Hi all,
I'm seeing unexpected behavior when using an autocmd defined in a
plugin. A simplified version of the plugin is the following:
function! InsertText()
echomsg "modified option is " .. &modified
call append(line("$"), "section title")
echomsg "modified option is " .. &modified
endfunction
autocmd FileType fortran call InsertText()
command -nargs=0 ForNoFT call InsertText()
It's purpose is to automatically insert lines in files that have a
specified filetype or to provide that service for other files. In the
above example, I've used "fortran" but I think any vim-recognized
filetype will do.
To show the problem, edit a Fortran file, e.g. run "vim test.f90". You
will see the text "section title" in the buffer. However, even though
the 'modified' option is set, I am allowed to quit vim (:q). Also, ^G
does not show modified. This behavior occurs whether the file
"test.f90" is new or has content.
A user-command has been defined in the plugin, intended for files
without a filetype. When you run "vim test.unknown" and then run the
user-command "ForNoFT", quit will fail as expected and ^G will show
modified.
Interestingly, if 'modified' is explicitly set in the function, then vim
will not quit because it sees test.f90 as modified.
My question is why the difference?
I'm running vim 9.2.1036 with normal features on Windows 10.
Thanks for any help.
-mike
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/85a1e44b-f2dd-438e-82e4-d1c6b88bc7f7n%40googlegroups.com.
Re: unexpected result using autocmd
Hi all,
I'm seeing unexpected behavior when using an autocmd defined in a
plugin. A simplified version of the plugin is the following:
function! InsertText()
echomsg "modified option is " .. &modified
call append(line("$"), "section title")
echomsg "modified option is " .. &modified
endfunction
autocmd FileType fortran call InsertText()
command -nargs=0 ForNoFT call InsertText()
It's purpose is to automatically insert lines in files that have a
specified filetype or to provide that service for other files. In the
above example, I've used "fortran" but I think any vim-recognized
filetype will do.
To show the problem, edit a Fortran file, e.g. run "vim test.f90". You
will see the text "section title" in the buffer. However, even though
the 'modified' option is set, I am allowed to quit vim (:q). Also, ^G
does not show modified. This behavior occurs whether the file
"test.f90" is new or has content.
A user-command has been defined in the plugin, intended for files
without a filetype. When you run "vim test.unknown" and then run the
user-command "ForNoFT", quit will fail as expected and ^G will show
modified.
Interestingly, if 'modified' is explicitly set in the function, then vim
will not quit because it sees test.f90 as modified.
My question is why the difference?
I'm running vim 9.2.1036 with normal features on Windows 10.
Thanks for any help.
-mike
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/de73247d-1ee9-4ad8-9991-1f7ca8dca8a4n%40googlegroups.com.
unexpected result using autocmd
Hi all, I'm seeing unexpected behavior when using an autocmd defined in a plugin. A simplified version of the plugin is the following: function! InsertText() echomsg "modified option is " .. &modified call append(line("$"), "section title") echomsg "modified option is " .. &modified endfunction autocmd FileType fortran call InsertText() command -nargs=0 ForNoFT call InsertText() It's purpose is to automatically insert lines in files that have a specified filetype or to provide that service for other files. In the above example, I've used "fortran" but I think any vim-recognized filetype will do. To show the problem, edit a Fortran file, e.g. run "vim test.f90". You will see the text "section title" in the buffer. However, even though the 'modified' option is set, I am allowed to quit vim (:q). Also, ^G does not show modified. This behavior occurs whether the file "test.f90" is new or has content. A user-command has been defined in the plugin, intended for files without a filetype. When you run "vim test.unknown" and then run the user-command "ForNoFT", quit will fail as expected and ^G will show modified. Interestingly, if 'modified' is explicitly set in the function, then vim will not quit because it sees test.f90 as modified. My question is why the difference? I'm running vim 9.2.1036 with normal features on Windows 10. Thanks for any help. -mike -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/vim_use/119n5kq%241mt%241%40ciao.gmane.io.
Wednesday, September 30, 2026
[ANN] vim9ls: a language server for Vim9 script and legacy Vim script
I have released vim9ls.
https://github.com/h-east/vim9ls
vim9ls is a language server for Vim9 script and legacy Vim script, run
by Vim itself.
vim9ls is written in Vim9 script and runs in a Vim of its own, so it
answers from what that Vim knows: its builtin functions, options and
commands, its help files, and the plugins you already have. A new
function or option is there as soon as Vim has it, since nothing is
copied out of Vim. Nothing else needs to be installed.
The diagnostics are Vim's own. The script is read with :source ++dryrun,
which runs nothing in it and compiles its :def functions, so what is
reported is what Vim finds in the script, not what another parser
guesses.
As for the LSP client Vim plugin, I recommend lsp.vim.
https://github.com/h-east/lsp.vim
--
Best regards,
Hirohito Higashi (h_east) --
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/a478630f-712a-4eff-818a-9ebb63648945n%40googlegroups.com.
Re: Looking for someone albe to grant copyrights for a screenshot with Vim
Maybe this is a tangent but maybe this is the leverage you need.
Get an official statement from Linux Foundation regarding the interpretation and application of OSS Licenses in regard to the snapshots you took.
As Christian said, it's already implied by the Licences themselves, but Linux Foundation maybe their experience in contesting/defending OSS rights could offer a reference to legal decisions on record.
Just a thought.
Eric Marceau, 70
Canada
On 2026-09-28 17:51, Maciek Godek wrote:
Thanks for the response.I initially also thought that I if I take a screenshot myself,then I am the author of the screenshot, but the publishersaid that it's an incorrect interpretation, and that I needpermission from the authors of software that I screenshotin order to be able to publish it.
I mean, I understand their point of view - they just want tostay away from any legal trouble, although I do think it leadsto somewhat absurd situations, especially in case of free software
I had one screenshot with tmux running bash running cat,so I wrote to the authors of tmux and bash and cat, and I gottheir permissions (with exception of cat, where I got an indicationthat I don't need any permissions). Frankly, I don't think it wasstrictly necessary, and it would probably be justifiable to depictthis software without any permissions, by simply invoking theirlicenses, but it also gave me an opportunity to reach out tosome people I otherwise probably wouldn't reach out to.
As for now, I invoked the "fair-use" clause for my vim screenshot,and I think it is well justified here. I already sent it to the publisher,and I am waiting for their response.
There's only one week left until the conference starts, so I guessthey might be busy processing the submissions (I think the essaysshould be available some time before the conference, but I don'tknow of any exact rules here)
Best regards,Panicz
poniedziałek, 28 września 2026 o 23:11:34 UTC+2 Christian Brabandt napisał(a):
On So, 27 Sep 2026, Maciek Godek wrote:
> Hi,
> I created an essay for the Onward! conference. The essay has a visual
> (i.e. comic) form, and one of the pages features a monitor with a
> running Vim splash screen. It's going to be published in open access
> under a Creative Commons license.
>
> The publisher, ACM, told me that I need to get permission from the
> authors of all software that I screenshot. And while there might be a
> possibility to use a screenshot on a "fair use" basis, I wonder if
> now, after Bram Moolenar is no longer with us, there is any party
> (like a foundation) that would be able to grant me the right to use
> it?
>
> I can send the page containing the screenshot if needed.
I don't think it is the Vim community that should grant you the rights
to use a random screenshot of Vim. The Vim license itself does not
restrict the use of Vim and from our side, there is no reason you
shouldn't be allowed to use it.
Having said that, isn't the real issue here the copyright of the
screenshot itself, rather than of Vim? If you took the screenshot
yourself you already hold the copyright on it, but if this is someone
else's copyright, you should reach out to the creator of the screenshot
and ask about permission.
Best,
Christian
--
Disclaimer: "These opinions are my own, though for a small fee they be
yours too."
-- Dave Haynie
--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/694c2890-f4f6-48dd-af26-b3f9d85eacd0n%40googlegroups.com.
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vim_use/69d5fad7-ca7d-4544-9ad9-fd80ec9085a2n%40googlegroups.com.