Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #26892 > unrolled thread

Making Forth official

Back to article view | Back to comp.lang.forth

Contents

  Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-21 13:23 +0000
    Re: Making Forth official Lars Brinkhoff <lars.spam@nocrew.org> - 2013-11-21 14:54 +0100
      Re: Making Forth official gavino_himself <visploveslisp@gmail.com> - 2013-12-03 11:59 -0800
    Re: Making Forth official anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-11-21 13:57 +0000
      Re: Making Forth official Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-11-21 15:49 +0000
        Re: Making Forth official "Mark" <mark@dibsco.co.uk> - 2013-11-21 16:03 +0000
          Re: Making Forth official Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2013-11-21 23:27 +0000
          Re: Making Forth official C G Montgomery <cgm@physics.utoledo.edu> - 2013-11-21 19:20 -0500
            Re: Making Forth official "Mark" <mark@dibsco.co.uk> - 2013-11-22 10:43 +0000
              Re: Making Forth official Bernd Paysan <bernd.paysan@gmx.de> - 2013-11-22 17:24 +0100
                Re: Making Forth official Hans Bezemer <the.beez.speaks@gmail.com> - 2013-11-24 14:11 +0100
          Re: Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-22 01:59 +0000
            Re: Making Forth official "Mark" <mark@dibsco.co.uk> - 2013-11-22 11:00 +0000
              Re: Making Forth official rickman <gnuarm@gmail.com> - 2013-11-22 12:05 -0500
                Re: Making Forth official "Mark" <mark@dibsco.co.uk> - 2013-11-22 21:15 +0000
      Re: Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-22 01:55 +0000
    Re: Making Forth official "Mark" <mark@dibsco.co.uk> - 2013-11-21 15:50 +0000
      Re: Making Forth official Bernd Paysan <bernd.paysan@gmx.de> - 2013-11-22 00:03 +0100
      Re: Making Forth official Lars Brinkhoff <lars.spam@nocrew.org> - 2013-11-22 08:19 +0100
        Re: Making Forth official m.a.m.hendrix@tue.nl - 2013-11-21 23:42 -0800
          Re: Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-23 17:22 +0000
            Re: Making Forth official Hans Bezemer <the.beez.speaks@gmail.com> - 2013-11-24 14:07 +0100
        Re: Making Forth official "Mark" <mark@dibsco.co.uk> - 2013-11-22 11:30 +0000
          Re: Making Forth official "Mark" <mark@dibsco.co.uk> - 2013-11-22 11:35 +0000
          Re: Making Forth official "Ed" <invalid@invalid.com> - 2013-11-23 19:11 +1100
            Re: Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-23 12:46 +0000
              Re: Making Forth official "Ed" <invalid@invalid.com> - 2013-11-27 12:42 +1100
                Re: Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-27 03:35 +0000
          Re: Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-23 17:31 +0000
            Re: Making Forth official "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2013-11-24 04:35 -0500
    Re: Making Forth official ForthFreak <forthfreak@gmail.com> - 2013-11-21 23:53 -0800
    Re: Making Forth official "Mark" <mark@dibsco.co.uk> - 2013-12-31 16:48 +0000
      Re: Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-31 22:49 +0000
        Re: Making Forth official Paul Rubin <no.email@nospam.invalid> - 2013-12-31 15:10 -0800
          Re: Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-01 14:12 +0000
            Re: Making Forth official anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 17:46 +0000
              Re: Making Forth official Paul Rubin <no.email@nospam.invalid> - 2014-01-02 13:03 -0800
                Re: Making Forth official "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-02 20:16 -0500
                Re: Making Forth official Mark Wills <markrobertwills@yahoo.co.uk> - 2014-01-03 01:24 -0800
              Re: Making Forth official "Rod Pemberton" <dont_use_email@xnohavenotit.cnm> - 2014-01-02 20:13 -0500
        Re: Making Forth official anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-01-02 17:33 +0000
          Re: Making Forth official albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-01-02 19:22 +0000

Page 1 of 3  [1] 2 3  Next page →

#26892 — Making Forth official

In Linux the language Forth doesn't exist officially, or barely so.
ctags is used by the major linux editors to jump to the place where a
word is defined.
This is a list of language supported by ctags:
Note how obscure some languages are, and that Forth is missing.

Ant      *.build.xml
Asm      *.asm *.ASM *.s *.S *.A51 *.29[kK] *.[68][68][kKsSxX] *.[xX][68][68]
Asp      *.asp *.asa
Awk      *.awk *.gawk *.mawk
Basic    *.bas *.bi *.bb *.pb
BETA     *.bet
C        *.c
C++      *.c++ *.cc *.cp *.cpp *.cxx *.h *.h++ *.hh *.hp *.hpp *.hxx *.C *.H
C#       *.cs
Cobol    *.cbl *.cob *.CBL *.COB
DosBatch *.bat *.cmd
Eiffel   *.e
Erlang   *.erl *.ERL *.hrl *.HRL
Flex     *.as *.mxml
Fortran  *.f *.for *.ftn *.f77 *.f90 *.f95 *.F *.FOR *.FTN *.F77 *.F90 *.F95
HTML     *.htm *.html
Java     *.java
JavaScript *.js
Lisp     *.cl *.clisp *.el *.l *.lisp *.lsp
Lua      *.lua
Make     *.mak *.mk [Mm]akefile GNUmakefile
MatLab   *.m
OCaml    *.ml *.mli
Pascal   *.p *.pas
Perl     *.pl *.pm *.plx *.perl
PHP      *.php *.php3 *.phtml
Python   *.py *.pyx *.pxd *.pxi *.scons
REXX     *.cmd *.rexx *.rx
Ruby     *.rb *.ruby
Scheme   *.SCM *.SM *.sch *.scheme *.scm *.sm
Sh       *.sh *.SH *.bsh *.bash *.ksh *.zsh
SLang    *.sl
SML      *.sml *.sig
SQL      *.sql
Tcl      *.tcl *.tk *.wish *.itcl
Tex      *.tex
Vera     *.vr *.vri *.vrh
Verilog  *.v
VHDL     *.vhdl *.vhd
Vim      *.vim
YACC     *.y

No file extension related to the language Forth is known to `make' rules
either.

On a related note.
To my surprise gedit does a reasonable job of syntax coloring
sources with .frt extension, gvim does so for .fs extensions.
It turns out that the reva guys have claimed the .frt extension
in gvim.

We see that the extension .frt is not taken as far as ctags is
concerned, however in the make rules it was used by FORTRAN.

Here is what I'm gonna do (unless you guys protest heavily).

1. Add Forth language detection to ctags on the .frt extensions.
(ctags is flexible, you can remap to other extensions if you're happy
with using ctags, but want to used .fs).
With this added to virtually all editors, .frt will become the
de facto extension for Forth source files under Linux which is
important since Linux has attained world domination.

2. With the leverage resulting from 1, I'm gonna claim the
extension .frt also in the makefile system.
A .frt file is turned into an executable by the rule
--------
%: %.frt
#  commands to execute (built-in):
        $(FORTH) -c $^
--------

This is just standardizing the ciforth way of making an executable.
This will promote lina. That is just the way it is. Beat me to it!
More importantly, of course, it will promote Forth, because at last
those handy tax return programs written in Forth can be built and
distributed.
(This require a .deb package for lina, that's all in place now.)

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [next] | [standalone]

#26894

Albert van der Horst wrote:
> This is a list of language supported by ctags:
> Note how obscure some languages are, and that Forth is missing.

What a coincidence.  Just the other day, I was delighted to learn that
Emacs' etags does a reasonable job of understanding Forth definitions.
However, its range of file extensions is somewhat limited: .fth and .tok.

(I have seen many file extensions for Forth, but never .tok before.)

[toc] | [prev] | [next] | [standalone]

#27129

On Thursday, November 21, 2013 5:54:19 AM UTC-8, Lars Brinkhoff wrote:
> Albert van der Horst wrote:
> 
> > This is a list of language supported by ctags:
> 
> > Note how obscure some languages are, and that Forth is missing.
> 
> 
> 
> What a coincidence.  Just the other day, I was delighted to learn that
> 
> Emacs' etags does a reasonable job of understanding Forth definitions.
> 
> However, its range of file extensions is somewhat limited: .fth and .tok.
> 
> 
> 
> (I have seen many file extensions for Forth, but never .tok before.)

vi

[toc] | [prev] | [next] | [standalone]

#26895

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>This is a list of language supported by ctags:
>Note how obscure some languages are, and that Forth is missing.

Gforth contains tags.fs for generating vi tags files (and etags.fs for
generating Emacs TAGS files); these programs use the Forth system,
which allows to support user-defined defining words automatically,
which Forth modes for ctags and etags cannot do easily; the drawback
of this method is that the Forth program must be compilable.

In any case, we don't use ctags for generating tags files, so it's no
wonder that ctags does not know about Forth.

>No file extension related to the language Forth is known to `make' rules
>either.

What kind of rules do you imagine make to use for Forth source files?

I don't define pattern rules involving Forth source files in my own
Makefiles, so I certainly don't expect any standard pattern rules for
Forth.

>1. Add Forth language detection to ctags on the .frt extensions.
>(ctags is flexible, you can remap to other extensions if you're happy
>with using ctags, but want to used .fs).
>With this added to virtually all editors, .frt will become the
>de facto extension for Forth source files under Linux which is
>important since Linux has attained world domination.

Given that .fs is the standard extension for source files in Gforth, I have my doubts about 

>2. With the leverage resulting from 1, I'm gonna claim the
>extension .frt also in the makefile system.
>A .frt file is turned into an executable by the rule
>--------
>%: %.frt
>#  commands to execute (built-in):
>        $(FORTH) -c $^
>--------

In Gforth, the undocumented -c option is an alias for
--clear-dictionary (by default, the dictionary is not initialized).
It certainly does not generate a file x from x.frt.  IYO what should x
contain?

>This is just standardizing the ciforth way of making an executable.
>This will promote lina.

Ah, ok, world domination for lina.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#26896

Anton Ertl wrote:

> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>This is a list of language supported by ctags:
>>Note how obscure some languages are, and that Forth is missing.
> 
> Gforth contains tags.fs for generating vi tags files (and etags.fs for
> generating Emacs TAGS files); these programs use the Forth system,
> which allows to support user-defined defining words automatically,
> which Forth modes for ctags and etags cannot do easily; the drawback
> of this method is that the Forth program must be compilable.
> 
> In any case, we don't use ctags for generating tags files, so it's no
> wonder that ctags does not know about Forth.
> 
>>No file extension related to the language Forth is known to `make' rules
>>either.
> 
> What kind of rules do you imagine make to use for Forth source files?
> 
> I don't define pattern rules involving Forth source files in my own
> Makefiles, so I certainly don't expect any standard pattern rules for
> Forth.
> 
>>1. Add Forth language detection to ctags on the .frt extensions.
>>(ctags is flexible, you can remap to other extensions if you're happy
>>with using ctags, but want to used .fs).
>>With this added to virtually all editors, .frt will become the
>>de facto extension for Forth source files under Linux which is
>>important since Linux has attained world domination.
> 
> Given that .fs is the standard extension for source files in Gforth, I
> have my doubts about
> 
>>2. With the leverage resulting from 1, I'm gonna claim the
>>extension .frt also in the makefile system.
>>A .frt file is turned into an executable by the rule
>>--------
>>%: %.frt
>>#  commands to execute (built-in):
>>        $(FORTH) -c $^
>>--------
> 
> In Gforth, the undocumented -c option is an alias for
> --clear-dictionary (by default, the dictionary is not initialized).
> It certainly does not generate a file x from x.frt.  IYO what should x
> contain?
> 
>>This is just standardizing the ciforth way of making an executable.
>>This will promote lina.
> 
> Ah, ok, world domination for lina.
> 
> - anton

As one who uses the .fth extension for Forth Source files and usually the 
Kwrite Editor on a linux System, I would vote for the .fth etension to be 
included.

Kwrite actually manages to do some interesting highlighting with the source 
code without having to be told about it. None of the highlighting effects 
affect the source code delivered to VfXForth. 

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [next] | [standalone]

#26898

"Paul E Bennett"  wrote in message news:bf6oboFld0gU1@mid.individual.net...
>
>As one who uses the .fth extension for Forth Source files and usually the
>Kwrite Editor on a linux System, I would vote for the .fth etension to be
>included.
>
>Kwrite actually manages to do some interesting highlighting with the source
>code without having to be told about it. None of the highlighting effects
>affect the source code delivered to VfXForth.

I guess that if you have a reasonably new version of Kwrite (post December 
2011) then this might be my syntax highlighter. I asked on CLF for commonly 
used file extensions and ended up including .4th, .f, .frt, .fs, .fth and 
.seq.

Regards

Mark 

[toc] | [prev] | [next] | [standalone]

#26900

Mark wrote:

> "Paul E Bennett"  wrote in message
> news:bf6oboFld0gU1@mid.individual.net...
>>
>>As one who uses the .fth extension for Forth Source files and usually the
>>Kwrite Editor on a linux System, I would vote for the .fth etension to be
>>included.
>>
>>Kwrite actually manages to do some interesting highlighting with the
>>source code without having to be told about it. None of the highlighting
>>effects affect the source code delivered to VfXForth.
> 
> I guess that if you have a reasonably new version of Kwrite (post December
> 2011) then this might be my syntax highlighter. I asked on CLF for
> commonly used file extensions and ended up including .4th, .f, .frt, .fs,
> .fth and .seq.
> 
> Regards
> 
> Mark

Yes, the one I am using at the moment is a very recent version. Thanks, the 
highlighting is quite nice.


-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [prev] | [next] | [standalone]

#26901

Mark mark@dibsco.co.uk wrote:

> "Paul E Bennett"  wrote in message
> news:bf6oboFld0gU1@mid.individual.net...
>>
>>As one who uses the .fth extension for Forth Source files and usually
>>the Kwrite Editor on a linux System, I would vote for the .fth etension
>>to be included.
>>
>>Kwrite actually manages to do some interesting highlighting with the
>>source code without having to be told about it. None of the highlighting
>>effects affect the source code delivered to VfXForth.
> 
> I guess that if you have a reasonably new version of Kwrite (post
> December 2011) then this might be my syntax highlighter. I asked on CLF
> for commonly used file extensions and ended up including .4th, .f, .frt,
> .fs, .fth and .seq.
> 
> Regards
> 
> Mark

KWrite Version 4.10.5, which is the version currently in Debian Testing, 
takes .f to be Fortran and .fs to be FSharp.  (I myself turn highlighting 
off.)

regards   cgm

[toc] | [prev] | [next] | [standalone]

#26907

"C G Montgomery"  wrote in message news:l6m80a$hdd$1@dont-email.me...
>
>Mark mark@dibsco.co.uk wrote:
>
>> "Paul E Bennett"  wrote in message
>> news:bf6oboFld0gU1@mid.individual.net...
>>>
>>>As one who uses the .fth extension for Forth Source files and usually
>>>the Kwrite Editor on a linux System, I would vote for the .fth etension
>>>to be included.
>>>
>>>Kwrite actually manages to do some interesting highlighting with the
>>>source code without having to be told about it. None of the highlighting
>>>effects affect the source code delivered to VfXForth.
>>
>> I guess that if you have a reasonably new version of Kwrite (post
>> December 2011) then this might be my syntax highlighter. I asked on CLF
>> for commonly used file extensions and ended up including .4th, .f, .frt,
>> .fs, .fth and .seq.
>>
>> Regards
>>
>> Mark
>
>KWrite Version 4.10.5, which is the version currently in Debian Testing,
>takes .f to be Fortran and .fs to be FSharp.  (I myself turn highlighting
>off.)
>
>regards   cgm

KWrite uses priority levels to resolve the conflict that occurs when two or 
more highlighting files use the same file extensions. The priority for ANS 
Forth is set to 5, Fortran is set to 9 and FSharp is set to 10 - highest 
priority wins. You can always set the syntax highlighting mode manually for 
files with .f or .fs extensions.

Regards

Mark

[toc] | [prev] | [next] | [standalone]

#26911

Mark wrote:
> KWrite uses priority levels to resolve the conflict that occurs when two
> or more highlighting files use the same file extensions. The priority for
> ANS Forth is set to 5, Fortran is set to 9 and FSharp is set to 10 -
> highest priority wins. You can always set the syntax highlighting mode
> manually for files with .f or .fs extensions.

This sounds a bit too dumb.  You can easily check a file for typical 
elements of that language, and choose the one that's most likely.  A Forth 
source code would for example have more ': ' and '\ ' on the left side than 
a F# source.  The easiest way for a syntax highlighter IMHO would be to try 
highlighting, count the number of matches, and choose the language with the 
most matches.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#26925

Bernd Paysan wrote:

> Mark wrote:
>> KWrite uses priority levels to resolve the conflict that occurs when two
>> or more highlighting files use the same file extensions. The priority for
>> ANS Forth is set to 5, Fortran is set to 9 and FSharp is set to 10 -
>> highest priority wins. You can always set the syntax highlighting mode
>> manually for files with .f or .fs extensions.
> 
> This sounds a bit too dumb.  You can easily check a file for typical
> elements of that language, and choose the one that's most likely.  A Forth
> source code would for example have more ': ' and '\ ' on the left side
> than
> a F# source.  The easiest way for a syntax highlighter IMHO would be to
> try highlighting, count the number of matches, and choose the language
> with the most matches.

That only seems to go that far. Ohloh uses this technique and for that
reason my FOOS (OO-sources) are recognized as HaXe. LOL!

For some time the same Ohloh didn't properly recognize Forth, and for that
reason my project was advertised for a long time as "Mostly written in
Classic Basic". ROFL!

Hans Bezemer

[toc] | [prev] | [next] | [standalone]

#26902

In article <XsidnXzxrpJSsxPPnZ2dnUVZ8m-dnZ2d@bt.com>,
Mark <mark@dibsco.co.uk> wrote:
>"Paul E Bennett"  wrote in message news:bf6oboFld0gU1@mid.individual.net...
>>
>>As one who uses the .fth extension for Forth Source files and usually the
>>Kwrite Editor on a linux System, I would vote for the .fth etension to be
>>included.
>>
>>Kwrite actually manages to do some interesting highlighting with the source
>>code without having to be told about it. None of the highlighting effects
>>affect the source code delivered to VfXForth.
>
>I guess that if you have a reasonably new version of Kwrite (post December
>2011) then this might be my syntax highlighter. I asked on CLF for commonly
>used file extensions and ended up including .4th, .f, .frt, .fs, .fth and
>.seq.

Interesting! How did you pull that off, where .f seems to be taken by FORTRAN?

>
>Regards
>
>Mark

Groetjes Albert
>
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#26908

"Albert van der Horst"  wrote in message 
news:528eba79$0$1684$e4fe514c@dreader35.news.xs4all.nl...
>
>In article <XsidnXzxrpJSsxPPnZ2dnUVZ8m-dnZ2d@bt.com>,
>Mark <mark@dibsco.co.uk> wrote:
>>"Paul E Bennett"  wrote in message 
>>news:bf6oboFld0gU1@mid.individual.net...
>>>
>>>As one who uses the .fth extension for Forth Source files and usually the
>>>Kwrite Editor on a linux System, I would vote for the .fth etension to be
>>>included.
>>>
>>>Kwrite actually manages to do some interesting highlighting with the 
>>>source
>>>code without having to be told about it. None of the highlighting effects
>>>affect the source code delivered to VfXForth.
>>
>>I guess that if you have a reasonably new version of Kwrite (post December
>>2011) then this might be my syntax highlighter. I asked on CLF for 
>>commonly
>>used file extensions and ended up including .4th, .f, .frt, .fs, .fth and
>>.seq.
>
>Interesting! How did you pull that off, where .f seems to be taken by 
>FORTRAN?

The syntax highlighting system for Kwrite/Kate/KDevelop allows highlighting 
files to reference the same file extensions. Conflicts are resolved using a 
priority level (See my reply to C G Montgomery).

Regards

Mark 

[toc] | [prev] | [next] | [standalone]

#26912

On 11/22/2013 6:00 AM, Mark wrote:
> "Albert van der Horst" wrote in message
> news:528eba79$0$1684$e4fe514c@dreader35.news.xs4all.nl...
>>
>> In article <XsidnXzxrpJSsxPPnZ2dnUVZ8m-dnZ2d@bt.com>,
>> Mark <mark@dibsco.co.uk> wrote:
>>> "Paul E Bennett" wrote in message
>>> news:bf6oboFld0gU1@mid.individual.net...
>>>>
>>>> As one who uses the .fth extension for Forth Source files and
>>>> usually the
>>>> Kwrite Editor on a linux System, I would vote for the .fth etension
>>>> to be
>>>> included.
>>>>
>>>> Kwrite actually manages to do some interesting highlighting with the
>>>> source
>>>> code without having to be told about it. None of the highlighting
>>>> effects
>>>> affect the source code delivered to VfXForth.
>>>
>>> I guess that if you have a reasonably new version of Kwrite (post
>>> December
>>> 2011) then this might be my syntax highlighter. I asked on CLF for
>>> commonly
>>> used file extensions and ended up including .4th, .f, .frt, .fs, .fth
>>> and
>>> .seq.
>>
>> Interesting! How did you pull that off, where .f seems to be taken by
>> FORTRAN?
>
> The syntax highlighting system for Kwrite/Kate/KDevelop allows
> highlighting files to reference the same file extensions. Conflicts are
> resolved using a priority level (See my reply to C G Montgomery).

I can't see the value in that.   Or are source types loaded individually 
so that you might have Forth installed, but not Fortran, but when you 
load Fortran it would then take over the .f extension?

If all source types loaded there can be only one winner for any given 
extension and all the others are disabled, no?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#26913

"rickman"  wrote in message news:l6o2s6$mkk$1@dont-email.me...
>
>On 11/22/2013 6:00 AM, Mark wrote:
>> "Albert van der Horst" wrote in message
>> news:528eba79$0$1684$e4fe514c@dreader35.news.xs4all.nl...
>>>
>>> In article <XsidnXzxrpJSsxPPnZ2dnUVZ8m-dnZ2d@bt.com>,
>>> Mark <mark@dibsco.co.uk> wrote:
>>>> "Paul E Bennett" wrote in message
>>>> news:bf6oboFld0gU1@mid.individual.net...
>>>>>
>>>>> As one who uses the .fth extension for Forth Source files and
>>>>> usually the
>>>>> Kwrite Editor on a linux System, I would vote for the .fth etension
>>>>> to be
>>>>> included.
>>>>>
>>>>> Kwrite actually manages to do some interesting highlighting with the
>>>>> source
>>>>> code without having to be told about it. None of the highlighting
>>>>> effects
>>>>> affect the source code delivered to VfXForth.
>>>>
>>>> I guess that if you have a reasonably new version of Kwrite (post
>>>> December
>>>> 2011) then this might be my syntax highlighter. I asked on CLF for
>>>> commonly
>>>> used file extensions and ended up including .4th, .f, .frt, .fs, .fth
>>>> and
>>>> .seq.
>>>
>>> Interesting! How did you pull that off, where .f seems to be taken by
>>> FORTRAN?
>>
>> The syntax highlighting system for Kwrite/Kate/KDevelop allows
>> highlighting files to reference the same file extensions. Conflicts are
>> resolved using a priority level (See my reply to C G Montgomery).
>
>I can't see the value in that.   Or are source types loaded individually so 
>that you might have Forth installed, but not Fortran, but when you load 
>Fortran it would then take over the .f extension?
>
>If all source types loaded there can be only one winner for any given 
>extension and all the others are disabled, no?

I only developed the syntax highlighter file based on the contents of the 
'Writing a Syntax Highlighting File' document. At some point after I had 
submitted the file to the project the KWrite developers added the priority 
setting to avoid the clash with Fortran.

The only thing I can see is that KWrite allows you to configure the file 
extensions and priorities for the installed syntax files via the GUI. 
Therefore perhaps it is just a case of the priority determines the default 
language for a particular file extension, but the user can override this by 
changing the priority values as required.

Regards

Mark

[toc] | [prev] | [next] | [standalone]

#26903

In article <2013Nov21.145702@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>This is a list of language supported by ctags:
>>Note how obscure some languages are, and that Forth is missing.
>
>Gforth contains tags.fs for generating vi tags files (and etags.fs for
>generating Emacs TAGS files); these programs use the Forth system,
>which allows to support user-defined defining words automatically,
>which Forth modes for ctags and etags cannot do easily; the drawback
>of this method is that the Forth program must be compilable.

I looked at it, and no offense, but it is very limited.
I can only look up words that I've loaded.
I want to have a tags file that loads a file in my editor that was
not before, and certainly not be restricted to a successful load.
I personally find it not strange to want to look up a c-function, while
I'm editing a Forth file.

>
>In any case, we don't use ctags for generating tags files, so it's no
>wonder that ctags does not know about Forth.

You don't use it, so ctags doesn't know about Forth. Who are "you", and
why ctags cares about you?

>
>>No file extension related to the language Forth is known to `make' rules
>>either.
>
>What kind of rules do you imagine make to use for Forth source files?
>
>I don't define pattern rules involving Forth source files in my own
>Makefiles, so I certainly don't expect any standard pattern rules for
>Forth.

Again that is a very restricted view. I certainly love to make programs
(apps are they called nowadays, I believe) using my favorite language.

>
>>1. Add Forth language detection to ctags on the .frt extensions.
>>(ctags is flexible, you can remap to other extensions if you're happy
>>with using ctags, but want to used .fs).
>>With this added to virtually all editors, .frt will become the
>>de facto extension for Forth source files under Linux which is
>>important since Linux has attained world domination.
>
>Given that .fs is the standard extension for source files in Gforth, I
>have my doubts about

Outside of gforth under linux, I've seen it only in the gvim configurations.
Again, with respect,we don't want a standard extension for Gforth files,
we want a standard extension for Forth files.
Different c-compilers do not come with a different convention for
file extensions. If we must agree on .fs, that is fine with me.

>
>>2. With the leverage resulting from 1, I'm gonna claim the
>>extension .frt also in the makefile system.
>>A .frt file is turned into an executable by the rule
>>--------
>>%: %.frt
>>#  commands to execute (built-in):
>>        $(FORTH) -c $^
>>--------
>
>In Gforth, the undocumented -c option is an alias for
>--clear-dictionary (by default, the dictionary is not initialized).
>It certainly does not generate a file x from x.frt.  IYO what should x
>contain?

A binary that can be run on an other machine, preferably without need to
install a forth interpreter.
A good thing that the -c option is not yet cast in stone, so you can
reserve the -c option for when you want a compilation option.

>
>>This is just standardizing the ciforth way of making an executable.
>>This will promote lina.
>
>Ah, ok, world domination for lina.

That would be bad. lina may be a trailblazer, but it is not for one
person to maintain a standard Forth.

>
>- anton
>--

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#26897

"Albert van der Horst"  wrote in message 
news:528e0962$0$26909$e4fe514c@dreader37.news.xs4all.nl...

>On a related note.
>To my surprise gedit does a reasonable job of syntax coloring
>sources with .frt extension, gvim does so for .fs extensions.
>It turns out that the reva guys have claimed the .frt extension
>in gvim.

I have produced ANS  Forth syntax highlighters for kate/kdevelop and gedit. 
I am currently working on one for UltraEdit. I think that having a single, 
common (and preferably unique) file extension would make it much easier to 
integrate Forth support into other packages.

>With this added to virtually all editors, .frt will become the
>de facto extension for Forth source files under Linux which is
>important since Linux has attained world domination.

Personally I have always quite liked .4th as being suitably descriptive and 
to the point.

Regards

Mark 

[toc] | [prev] | [next] | [standalone]

#26899

Mark wrote:
> Personally I have always quite liked .4th as being suitably descriptive
> and to the point.

As Microsoft took hostage of .fs (for f#, which for obvious reasons can't 
have an .f# extension, especially not in Makefiles), it's probably the least 
controversive extension: Nobody else has claimed it, and it is suitable 
descriptive.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#26904

Mark wrote:
> Albert van der Horst wrote:
> > With this added to virtually all editors, .frt will become the de
> > facto extension for Forth source files under Linux which is
> > important since Linux has attained world domination.
> Personally I have always quite liked .4th as being suitably
> descriptive and to the point.

These Forth file extensions are used on GitHub, ordered from most
popular to least:

1. fs
2. fth
3. f
4. 4th
5. fr
6. frt
7. forth
8. 4

I have attempted to avoid false positives from e.g. F# files.

[toc] | [prev] | [next] | [standalone]

#26905

On Friday, November 22, 2013 8:19:49 AM UTC+1, Lars Brinkhoff wrote:
> These Forth file extensions are used on GitHub, ordered from most 
> popular to least: 1. fs 2. fth 3. f 4. 4th 5. fr 6. frt 7. forth 
> 8. 4 
> I have attempted to avoid false positives from e.g. F# files.

So why not use .forth ? Everybody will be inconvienced to the same 
degree and how much clearer can we get? (The .forth extension is 
used for the problem/example files on the SF pages).

-marcel

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.forth

csiph-web