On Tue, Aug 19, 2025 at 12:43:08PM +0200, joerg van den hoff wrote: > it seems I only replied to you rather than the mailing list, too. so I Cc the > list now again... > > On 16.08.25 18:29, Thomas Dickey wrote: > > On Sat, Aug 16, 2025 at 12:05:34PM +0200, joerg van den hoff wrote: > > > > > > > > > On 15.08.25 22:04, Thomas Dickey wrote: > > > > On Fri, Aug 15, 2025 at 09:46:42PM +0200, joerg van den hoff wrote: > > > > > > > > > > > > > > > On 15.08.25 20:56, Thomas Dickey wrote: > > > > > > On Fri, Aug 15, 2025 at 05:16:55PM +0200, joerg van den hoff wrote: > > > > > > > just downloaded the source from > > > > > > > https://invisible-island.net/vile/ and tried > > > > > > > to build on OSX 15.4.1. build fails with the message: > > > > > > > > > > > > you might be using > > > > > > > > > > > > https://invisible-island.net/datafiles/release/vile.tar.gz > > > > > > > > > > guilty as charged... :| > > > > > > > > > > > > > > > > > which is kind of old - > > > > > > > > > > > > https://invisible-island.net/datafiles/current/vile.tar.gz > > > > > > > > > > > > ...is currently 9.8za > > > > > > > > > > understood. may bad. sorry for the noise. > > > > > > > > > > > > > > > > > https://github.com/macports/macports-ports/blob/master/editors/vile/Portfile > > > > > > https://github.com/Homebrew/homebrew-core/blob/master/Formula/v/vile.rb > > > > > > > > > > > > https://invisible-island.net/archives/vile/current/vile-9.8za.tgz > > > > > > > > > > > > > > > > > > > > echo "#include <flt_defs.h>" > spellflt.c > > > > > > > flex -t spellflt.l >> spellflt.c > > > > > > > gcc -c -I. -I.. -I../filters -I.. -DHAVE_CONFIG_H > > > > > > > -D_DARWIN_C_SOURCE -g -O2 spellflt.c > > > > > > > spellflt.l:137:19: error: call to undeclared function 'umask'; > > > > > > > ISO C99 and > > > > > > > later do not support implicit function declarations > > > > > > > [-Wimplicit-function-declaration] > > > > > > > 137 | int oldmask = umask(0077); > > > > > > > | ^ > > > > > > > spellflt.l:138:20: warning: 'tmpnam' is deprecated: This function > > > > > > > is > > > > > > > > > > > > current source uses mkstemp, when available :-) > > > > > > > > > > indeed, 9.8za builds just fine. thank you for clarifying! > > > > > > > > > > the actual reason I was downloading the source tree (rather than > > > > > continuing > > > > > to use the macports package for OSX) is that after some 15 years of > > > > > vile > > > > > usage I decided to try and finally address an issue which has grated > > > > > me for > > > > > years: the missing syntax highlighting filter for the R language, > > > > > https://www.r-project.org, (which I use a _lot_). so far I had to > > > > > live w/o > > > > > highlighting or restrict myself to defining an "R mode" which simply > > > > > was > > > > > using vile-awk-filt as a very rough approximation of what actually > > > > > would be > > > > > needed. > > > > > > > > > > since I have no clue about flex syntax and how to describe the R > > > > > semantics correctly with it, I today > > > > > tried to somehow convince assorted LLMs (gemini, claude, chat) to > > > > > produce > > > > > some template r-filt.l file that might be a starting point for > > > > > "try+error" > > > > > tweaking. I finally got a file which at least was processed by `make > > > > > r-filt' > > > > > in the filters directory and generated an r-filt binary. putting that > > > > > file > > > > > into the canonical location for such filters in an existing 9.8za > > > > > installation and telling the define-mode macro in my .vilerc to use > > > > > it, > > > > > however leads to this behaviour when editing some R file: > > > > > > > > > > * vile loads the source file and sets major mode to "Rmode" (so it > > > > > understands the define-mode macro in my .vilerc, it seems) > > > > > > > > > > * no syntax highlighting is taking place > > > > > > > > > > * `:show-majormodes' does _not_ include an entry "rmode". > > > > > > > > > > feeding the `vile-r-filt' executable manually with some input at > > > > > least does > > > > > produce some ascii output (whether really sensible and correct I do > > > > > not > > > > > know, yet). so my questions right now: > > > > > > > > some guesses - > > > > > > > > vile has three configurations for filters (external - default, built-in > > > > and loadable - the last won't work for me on MacOS). If you have the > > > > built-in (or loadable) flavor, that shows up in > > > > :show-variables > > > > > > > > e.g., > > > > > > > > $filter-list = c key m4 perl raku ruby sed tags ada as asm au3 awk > > > > basic bat bnf cfg conf css cweb dcl def diff ecl erl esql est fdl hs > > > > html imake info ini iss json latex lex lisp lua mail mailcap make mcrl > > > > md midl mms nmake nr pas php pot ps ps1 py rc rcs rexx rpm rtf rust > > > > sccs scheme sh sml spell sql tbl tc tcl texi ti tpu txt vile vlog wbt > > > > xml xq xres xs yacc yaml > > > > > > > > The external filters won't show up there, and are supposedly easy to > > > > just > > > > add another executable. You _might_ have builtin filters, though as I > > > > mention it, it seems that I did allow for a mixture - but not overriding > > > > a given name. > > > > > 1. am I simply doing something wrong from the outset which would > > > > > explain why > > > > > the new filter seemingly is ignored completely? does it need to be > > > > > included > > > > > in the full build process from the beginning (I would not expect the > > > > > latter > > > > > to be the case)? > > > > > > > > I have a half-dozen modes in my .vilerc, such as this: > > > > > > > > define-mode map > > > > ~with define-submode map > > > > suf '\(\.\(map\)$\)' > > > > comment-prefix '^\s*[#]' > > > > comments '^\s*[#]\s*$' > > > > filtername 'vile-conf-filt' > > > > ~endwith > > > > > > > > That shows up in > > > > :show-majormodes > > > > > > > > like this: > > > > > > > > --- "map" majormode settings > > > > ---------------------------------------(68:121)---- > > > > Qualifier: > > > > qualifiers=any suffixes=\(\.\(map\)$\) > > > > > > > > Buffer: > > > > comment-prefix=^\s*[#] comments=^\s*[#]\s*$ > > > > > > > > filtername=vile-conf-filt > > > > > > > > so I'd expect that if the suffix matches, and the filtername is set, > > > > then that would work. > > > > > > understood. thanks a lot for bothering. > > > > > > for the record: my "majormode does not show up in :show-majormode output" > > > problem was a false alarm due to stupid oversight on my side (so sorry for > > > the previous noise!): I was not aware that "define-mode R" (which I > > > capitalized for the sole reason that R lang uses upper case .R file > > > extension by default...) is in fact case-sensitive regarding the chosen > > > name > > > and that ":show-majormode" does not simply downcase and report that as > > > "rmode" (which was the location where I was looking in the alphabetical > > > sorting). I only now saw the uppercase entry "Rmode" right at the > > > beginning > > > of the listing (before RCSmode)... > > > > > > > > > > > If the suffix doesn't match, I'd force it by > > > > > > > > :set-h map > > > > > > > > for example > > > > > > > > > 2. presuming vile-r-filt does in fact produce invalid output (quite > > > > > likely I > > > > > guess...), what would vile do: erroring out or silently ignoring the > > > > > buggy > > > > > filter (and not showing it under :majormodes) and reverting to > > > > > no-highlight? > > > > > > > > if it doesn't see the ^A-formatting stuff, there's nothing for this to > > > > grab onto: > > > > > > > > "attribute-cntl_a-sequences-til" ^A-A > > > > > > > > offhand, I'd expect garbage on the screen in that case, because it's > > > > treated > > > > like an overlay. > > > > > > I see. thanks for clarifying. looking at the output of the LLM-generated > > > vile-r-filt filter, it is obviously completely broken, spewing out text > > > looking like > > > > > > 4 dat > > > 5 <- > > > 4 matrix > > > 4 unlist > > > > > > (one word per line preceded by blank-separated integer) where input > > > contained a line starting with "dat <- matrix(unlist" > > > > > > so that's completely messed up. it remains a mystery to me, though, why > > > vile still presents the > > > edited file sanely (just w/o syntax highlighting) as if simply ignoring > > > that dysfunctional filter. > > > > vile doesn't see anything to apply. It uses the filter to change things, > > but there's no valid change presented. > > > > Looking in select.c, at attribute_from_filter, I see this: > > > > DOT.o = b_left_margin(curbp); > > for (n = 0; n < nbytes; n++) { > > if (fflinebuf[n] == CONTROL_A) { > > done = decode_attribute(fflinebuf, nbytes, n, &skip); > > if (done) { > > n = ((size_t) done - 1); > > set_mark_after(skip, 1); > > if (apply_attribute()) > > (void) attributeregion(); > > } > > } else { > > DOT.o += BytesAt(DOT.l, DOT.o); > > } > > } > > > > so vile just walks through the buffer, not seeing anything to use. > > > back to square no. one, then: how to construct a rudimentary r-filt.l for > > > R, sigh ... :). > > > > > > apart from the tough syntax-highlighting approach (tough for me, anyway) > > > vile remains my favourite vi(-like) incarnation by a large margin. thanks > > > for all the work that has gone into it over the years. > > > > For debugging syntax filters, it can help to turn on the debug option > > of flex. That makes some (usually useful) information go to stderr. > > Since the filter writes to stdout, it's easy to redirect them (and > > with a suitable script and macro, it's easy to read the filtered > > file into a buffer and apply the attributes, to see the colored version). > > > > When I'm working on filters, I collect a bunch of examples, and > > add/use a script to diff successive runs, to check for unwanted changes. > > understood, thanks for the advice. problem for me is: zero knowledge of flex. > so that will be tough. > but I might give it a serious try. question: are there any more pointers > beyond what can be found in vile's help and further documents in the > "./docs" of the vile distribution regarding how exactly to write such a > filter? if doable a a step-by-step walked-through example would be really > good.--
sorry, no - I agree it would be nice to have (since filterio.[ch] is pretty
stable).
But... there are about 80 examples (75 lex, several C).
For learning, I'd start by looking at the simplest filter, e.g.,
bnf-filt.l, and seeing
#include <filters.h>
DefineFilter(bnf);
the latter defines a unique name matching the majormode -- and has to be
distinct for built-in filters. There are a few sections marked off with
"%{", "%}", "%%" (C, non-C, non-C, C), with pattern definitions in the
first non-C section, such as
IDENT [@$%&]*[[:alpha:]_][[:alnum:]_-]*
and rules in the next non-C section, e.g.,
{IDENT} { WriteToken(get_keyword_attr(yytext)); }
The purpose of the WriteToken* macros is to write marked-up stuff for vile
to read. This is the simplest one, using the yytext and yyleng (text and
length) defined by lex/flex, and getting the keyword attribute (e.g., from
bnf.key) to use for coloring:
#define WriteToken(attr) flt_puts(yytext, yyleng, attr)
Most of the filters define variables to hold attribute information (e.g.,
color, underlining, etc). The names for the classes are used lots of
places:
Action_attr = class_attr(NAME_ACTION);
The regular expressions used in lex/flex are pretty standard (I'm aware
that "new" flex allows brace expressions such as foo{3,4}, but that's
actually an external library, which doesn't help with portability).
> for the time being I have reverted to trying something simpler namely a
> naive regexp pattern-matching approach using awk just to better understand
> what is going on.
>
> so I now have a filter file "vile-r-filt" (pure awk code) put in the
> canonical location of a vile installation. for q&d testing I again just used
> some auto-generated code (gemini LLM) to have a starting point (awk at least
> I do know and will be able to adust if this is viable at all...). so the
> current version does not quite do the right thing but it does _some_ sort of
> highlighting by inserting the expected ^AnCi: sequences.
>
> what I do _not_ understand:
>
> editing some R-code via "vile test.R" does recognize the newly defined
> "Rmode" and the associated filter (as listed by :show-majormodes) but does
> show different highlighting from what I get when doing
>
> "vile-r-filt < test.R > markedup; vile markedup" and issuing ^A-AG from
> within vile.
>
> should I expect such differences? what am I missing?
If you send a diff, I can take a look.
> > > best,
> > > joerg
> > >
> > > >
> > > > > best regards,
> > > > > joerg
> > > > >
> > > > > ps: and of course, if someone does know of a working filter for the R
> > > > > language, please let me know ;)
just looking at the language, I don't see anything complicated in the
quoting, etc.
https://cran.r-project.org/doc/manuals/R-lang.pdf
> > > > >
> > > >
> > >
> > >
> >
>
>
--
Thomas E. Dickey <[email protected]>
https://invisible-island.net
signature.asc
Description: PGP signature
