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.--
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?
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 ;)
