[vim/vim] Binding '.fs' files to forth lang in default distribution suboptimal (Issue #9182)
daz10000
At risk of angering the whole forth community, I was wondering why vim started behaving oddly editing FSharp code (stepping by word completely broken for period separated words) and traced the change back to binding .fs files to the forth language which apparently considers periods part of a word.
For example for the construct
mary.had.a.little.lamb
I would expect w to advance through each 'word' stopping at a period. The default vim experience does this, but editing a file foo.fs would cause the cursor to advance through the entire construct (and other punctuation as well ). I traced the change back to the language definition for Forth in the filetypes.vim file.
" Forth
au BufNewFile,BufRead *.fs,*.ft setf forth
Now I understand I can edit the distribution (I did) but again at risk of angering the forth community, this is a pretty obscure binding that broke everything in F# for vim (it took me a while no notice why I'd stopped using 'w' moves in vim all of a sudden), and that particular iskeyword definition is an anathema to any modern language with dot notation which is pretty much every language at this point. I'd politely suggest (and I know I'm probably doing this in vain but had to mention it), either dropping the forth binding or at least putting periods back into the iskeyword definition to preserve the usability for FSharp currently 34 on stackoverflow language rankings FWIW
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.
lacygoill
Is there a way to distinguish a forth file from a FSharp one inspecting the contents of its first few lines?
daz10000
Good question - I know very little about forth, but there is nothing that MUST be at the top of an F# file. There is commonly a module or namespace keywordnear the start. Taking a random survey of a bunch of small projects here the most common entries for the first line were
//- a commentopen- opening a module or namespacenamespace- defined namespacemodule- defined module[<- some directive like autoopen(**- opening with a multi line comment
lacygoill
This is probably not the right fix but it might give an idea to someone else:
diff --git a/runtime/filetype.vim b/runtime/filetype.vim index c4c9cb904..d8c40196f 100644 --- a/runtime/filetype.vim +++ b/runtime/filetype.vim @@ -632,7 +632,8 @@ au BufNewFile,BufRead auto.master setf conf au BufNewFile,BufRead *.mas,*.master setf master " Forth -au BufNewFile,BufRead *.fs,*.ft,*.fth setf forth +au BufNewFile,BufRead *.ft,*.fth setf forth +au BufNewFile,BufRead *.fs setf FALLBACK fsharp " Reva Forth au BufNewFile,BufRead *.frt setf reva diff --git a/runtime/scripts.vim b/runtime/scripts.vim index 0ff8e4908..612ed8dfd 100644 --- a/runtime/scripts.vim +++ b/runtime/scripts.vim @@ -270,6 +270,14 @@ else \ || s:line5 =~# '^\s*dnl\>' set ft=m4 + " forth scripts: Guess there is a line that starts with a colon + elseif s:line1 =~# '^\s*:\s\+' + \ || s:line2 =~# '^\s*:\s\+' + \ || s:line3 =~# '^\s*:\s\+' + \ || s:line4 =~# '^\s*:\s\+' + \ || s:line5 =~# '^\s*:\s\+' + set ft=forth + " AmigaDos scripts elseif $TERM == "amiga" \ && (s:line1 =~# "^;" || s:line1 =~? '^\.bra')
With this patch, a file with an .fs extension is detected as fsharp by default. But if one of the first 5 lines starts with a colon, it's detected as forth instead.
For anyone who can think of a better detection logic but doesn't know how to implement it, see :help new-filetype-scripts for more help. Then start Vim with this shell command:
VIMRUNTIME=/path/to/my/local/vim vim -Nu NORC --cmd 'filetype plugin on' /tmp/fs.fs
Gary Johnson
However, I think it is bad form to change the default behavior of
Vim so that existing users who are used to behavior that has always
"just worked" have to change their behavior for the sake of that
accommodation. If Vim can't determine the filetype of an .fs file
with reasonable confidence, it should default to Forth, not F#.
How about adding a global configuration variable, to be used by
$VIMRUNTIME/filetype.vim, that Forth users could set in their vimrc
files? This would be simpler than requiring all of them to add
their own ~/.vim/filetype.vim or ~/vimfiles/filetype.vim file or to
add an autocommand to their vimrc. For example:
let g:fs_is_fsharp = 1
Regards,
Gary
vim-dev ML
daz10000
I think it is bad form to change the default behavior of
Vim so that existing users who are used to behavior that has always
"just worked" have to change their behavior for the sake of that
accommodation. If Vim can't determine the filetype of an .fs file
with reasonable confidence, it should default to Forth, not F#.
But that's exactly what happened with the original Forth implementation. I've been using vim on and off with F# for 17 years and a recent upgrade which I'll admit I do rarely completely broke the default out of the box vim experience (which was fine) by adding forth bindings.
—
You are receiving this because you commented.
daz10000
though to be fair, it looks like it has been treating .fs as forth for a while, but the changes to the forth definition (more recent but not terribly recent) pushed it over the edge. The right thing to do probably would be to include a decent F# definition and determine what you are dealing with and use the right one. I'm willing to take a bet that the vast majority of the .fs forth definition consumers are F# programmers at this point though :( - I struggled to even find any forth code to see what it looked like.
—
You are receiving this because you commented.
Gary Johnson
> though to be fair, it looks like it has been treating .fs as forth for a while,
> but the changes to the forth definition (more recent but not terribly recent)
> pushed it over the edge. The right thing to do probably would be to include a
> decent F# definition and determine what you are dealing with and use the right
> one. I'm willing to take a bet that the vast majority of the .fs forth
> definition consumers are F# programmers at this point though :( - I struggled
> to even find any forth code to see what it looked like.
I can't. Since Vim 7.0, I found one change to syntax/forth.vim
that [improperly] sets 'iskeyword' and one change to filetype.vim
that adds .fth as a forth file extension.
I also tried to find examples of Forth code as I've never used it,
and found an interesting answer to this question on StackOverflow,
https://stackoverflow.com/questions/18246756/what-is-the-most-common-filename-extension-of-a-forth-source-code-file,
that claims that in May, 2021, Github had:
148303 F# files with .fs extensions; and
83217 Forth files with .fs extensions.
That's only twice as many F# files as Forth files using .fs.
Regards,
Gary
vim-dev ML
Gary Johnson
> On 2021-11-21, daz10000 wrote:
> > though to be fair, it looks like it has been treating .fs as forth for a while,
> > but the changes to the forth definition (more recent but not terribly recent)
> > pushed it over the edge. The right thing to do probably would be to include a
> > decent F# definition and determine what you are dealing with and use the right
> > one. I'm willing to take a bet that the vast majority of the .fs forth
> > definition consumers are F# programmers at this point though :( - I struggled
> > to even find any forth code to see what it looked like.
>
> I tried to find a change that would explain what you observed, but
> I can't. Since Vim 7.0, I found one change to syntax/forth.vim
> that [improperly] sets 'iskeyword' and one change to filetype.vim
> that adds .fth as a forth file extension.
system. Even it set 'filetype' to "forth" and added '.' to
'iskeyword' when I opened foo.fs.
I'm not seeing any "recent" changes to Vim's handling of .fs files.
Regards,
Gary
vim-dev ML
daz10000
Fair enough - forth seems to be popular in ROM definitions. I don't completely trust those SO numbers. I picked some more reasonable F#y keywords like let and |> and got over 1/4 million files. The F# compiler itself is reported to be 5-10% forth by the github id, and that seems unlikely https://github.com/dotnet/fsharp/search?l=f%23
I'll think on this - I would love vim to have beautiful F# support. I can get by with a hacked distribution for now. I am interested in the language integration in neovim too, so this might be the catalyst to switch which would be a bit sad, but I appreciate the principled discussion.
—
You are receiving this because you commented.
Doug Kearns
If Vim can't determine the filetype of an .fs file with reasonable confidence, it should default to Forth, not F#. How about adding a global configuration variable, to be used by $VIMRUNTIME/filetype.vim, that Forth users could set in their vimrc files? This would be simpler than requiring all of them to add their own ~/.vim/filetype.vim or ~/vimfiles/filetype.vim file or to add an autocommand to their vimrc. For example: let g:fs_is_fsharp = 1
There is a 'standard' way to do this sort of thing. See :help filetype-overrule
It's usually used to overrule content based filetype detection.
—
You are receiving this because you commented.
Bram Moolenaar
> Fair enough - forth seems to be popular in ROM definitions. I don't
> completely trust those SO numbers. I picked some more reasonable F#y
> keywords like `let` and `|>` and got over 1/4 million files. The F#
> compiler itself is reported to be 5-10% `forth` by the github id, and
> that seems unlikely https://github.com/dotnet/fsharp/search?l=f%23
>
>
> I'll think on this - I would love vim to have beautiful F# support. I
> can get by with a hacked distribution for now. I am interested in the
> language integration in neovim too, so this might be the catalyst to
> switch which would be a bit sad, but I appreciate the principled
> discussion.
would think popularite goes down. It doesn't show up in the list that
github provides: https://madnight.github.io/githut/#/pull_requests/2021/3
While F# is in position 38. Still below Vim script.
I wonder why Forth files would end in ".fs", it's more logical to read
it as F Sharp.
--
Every exit is an entrance into something else.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
Gary Johnson
>
> > Fair enough - forth seems to be popular in ROM definitions. I don't
> > completely trust those SO numbers. I picked some more reasonable F#y
> > keywords like `let` and `|>` and got over 1/4 million files. The F#
> > compiler itself is reported to be 5-10% `forth` by the github id, and
> > that seems unlikely https://github.com/dotnet/fsharp/search?l=f%23
> >
> > 
> >
> > I'll think on this - I would love vim to have beautiful F# support. I
> > can get by with a hacked distribution for now. I am interested in the
> > language integration in neovim too, so this might be the catalyst to
> > switch which would be a bit sad, but I appreciate the principled
> > discussion.
>
> I don't think forth is a popular language. It's also very old and I
> would think popularite goes down. It doesn't show up in the list that
> github provides: https://madnight.github.io/githut/#/pull_requests/2021/3
> While F# is in position 38. Still below Vim script.
is still active. It's hard to tell how much it's actually used.
I didn't look for projects using it.
> I wonder why Forth files would end in ".fs", it's more logical to read
> it as F Sharp.
FORTH files needed an extension and .f was already taken by FORTRAN,
so someone thought of .fs. F# wasn't a consideration since it
didn't appear until 2005.
Regards,
Gary
vim-dev ML
Bram Moolenaar
much like "fart"? :-)
--
Citizens are not allowed to attend a movie house or theater nor ride in a
public streetcar within at least four hours after eating garlic.
[real standing law in Indiana, United States of America]
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
vim-dev ML
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Doug Kearns
FORTH files needed an extension and .f was already taken by FORTRAN, so someone thought of .fs.
SwiftForth (Forth, Inc) use .f. They're not afraid to fight it out with Fortran.
—
You are receiving this because you commented.
daz10000
I'm learning things! - thanks for keeping the thread educational. It seems like the least intrusive way to at least make F# a decent backup option would be to add a g:filetype_fs variable with ft-fsharp-syntax as an option. I have been staring at forth ROM code for a while now and just fascinated at all the things that hold the hardware world together.
—
You are receiving this because you commented.
Doug Kearns
@daz10000 What runtime files are you using for F# support?
I sent Bram a patch included in 3d14c0f, which attempts to guess what filetype we have in a *.fs file. I used fs for the F# filetype name to match cs used for C# but I've noticed that Ionide uses fsharp.
While I'd prefer that C# and F# used the same scheme @brammool usually favours compatibility so perhaps we should change it to fsharp too? I'm assuming renaming the cs filetype is out of the question.
—
You are receiving this because you commented.
Nick Jensen
I think changing the cs filetype would be a very bad idea. There are many C# vim plugins that would have to be modified, and who-knows-how-many-thousands of custom user ~/.vim/ftplugin/cs.vim files in the wild that would break.
It would be nice to strive for consistency between C# and F# but I think that horse has bolted. There doesn't appear to be a huge F# vim eco-system but there are existing plugins out there (https://github.com/DrTom/fsharp-vim is another, 11 years old), and users with custom ~/.vim/ftplugin/fsharp.vim scripts - I have one myself.
—
You are receiving this because you commented.
daz10000
I wouldn't mess with the C# defs - and I imagine most F# folks would be happy with consistency with C# for what it's worth. Thanks for looking into all of this by the way. I have not done an extensive tour of the insides for vim definitions for quite a while. Re @dkearns question above, I haven't been using anything special - just vanilla vim most of the time, but I see there are some nice ones out there. I was thinking of going down the whole neovim rabbit hole and actually using language service support for dynamic compilation / checking of code but I'm stuck right now on being unable to cut and paste/scroll with a mouse - one has to have priorities.
—
You are receiving this because you commented.
Nick Jensen
You don't need to use neovim to get language server support - it has been plugin-supported in both Vim and neovim long before neovim integrated it. There are lots of good Vim language server client plugins, including ALE, vim-lsp, vim-lsc and YouCompleteMe. I currently use vim-lsp.
—
You are receiving this because you commented.
Doug Kearns
OK, I'll send an updated patch using fsharp as the filetype later today.
—
You are receiving this because you commented.
Bram Moolenaar
Closed #9182.
Bram Moolenaar
Included as 8.2.3703
Johan Kotlinski
Hi, sorry for necro-post. I am current maintainer of forth.vim syntax file, and happened to find this thread by accident.
Since Vim 7.0, I found one change to syntax/forth.vim
that [improperly] sets 'iskeyword' and one change to filetype.vim
that adds .fth as a forth file extension.
Could you please explain what is improper about the iskeyword usage in forth.vim ? I am not familiar with the this keyword myself.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
daz10000
It has been quite a while since I started this, but I think it was just the semantics around dot separated identified strings mary.had.a.little.lamb - whether that's considered one 'word' in vim land or multiple dot separated words. My experience (totally personal) with languages like java/python/F#/C# is that advancing a single word would step though each [A-Za-z0-9] block (e.g to end of mary in that example, and stop at the dot. Vim was advancing to the end of the whole string (past lamb) making editing difficult. I don't have enough forth experience to tell you what the preference would be for a forth user.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Johan Kotlinski
is totally OK, given that filetype detection works.
tis 4 apr. 2023 kl. 23:39 skrev daz10000 ***@***.***>:
> It has been quite a while since I started this, but I think it was just
> the semantics around dot separated identified strings
> mary.had.a.little.lamb - whether that's considered one 'word' in vim land
> or multiple dot separated words. My experience (totally personal) with
> languages like java/python/F#/C# is that advancing a single word would step
> though each [A-Za-z0-9] block (e.g to end of mary in that example, and
> stop at the dot. Vim was advancing to the end of the whole string (past
> lamb) making editing difficult. I don't have enough forth experience to
> tell you what the preference would be for a forth user.
>
> —
> Reply to this email directly, view it on GitHub
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAY34O5323WFUUFUAUEJDP3W7SIJHANCNFSM5IPOK2SA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
Bram Moolenaar
> Hi, sorry for necro-post. I am current maintainer of forth.vim syntax
> file, and happened to find this thread by accident.
>
> > Since Vim 7.0, I found one change to syntax/forth.vim
> > that [improperly] sets 'iskeyword' and one change to filetype.vim
> > that adds .fth as a forth file extension.
>
> Could you please explain what is improper about the `iskeyword` usage
> in forth.vim ? I am not familiar with the this keyword myself.
behavior of many commands. It should not be set in the syntax file.
Instead, the ":syn iskeyword" command should be used. That way the
syntax file does not depend on how movement commands work, and the other
way around.
Setting the 'iskeyword' option may be done in the filetype plugin.
Currently there is no forth filetype plugin, thus this would need to be
added.
--
FATHER: You only killed the bride's father - that's all -
LAUNCELOT: Oh dear, I didn't really mean to...
FATHER: Didn't mean to? You put your sword right through his head!
LAUNCELOT: Gosh - Is he all right?
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
Christian Brabandt
Please see this reply by Bram: https://groups.google.com/d/msgid/vim_dev/20230405170818.286B71C0B8A%40moolenaar.net
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Doug Kearns
Thanks @chrisbra I've started addressing this over at jkotlinski/forth.vim#9.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.