Re: [vile] How to use map! to enter 'special' UTF8 characters?

[Brendan O'Dea]

On 17 March 2017 at 19:55, Chris Green  wrote:
>> Try mapping it to ^Vu2714.  That worked for me.
>>
> That's *exactly* what I have done, it shows correctly (as above) in
> .vilerc but when I hit F4 in insert mode while editing I see the
> string â\u009C\0094.  I can insert a ✔ by typing CTRL/V + u + 27 + 14
> though, it displays OK in vile.

Don't map it to the *value* of ^Vu2714, map it to that sequence of
characters.  i.e. your .vilerc should contain a ^V and the following
characters, *not* the tick character.  Obviously you need to type
"map! # ^V^Vu2714" when editing .vilerc to get that single literal ^V.

--bod

___
vile mailing list
vile@nongnu.org
https://lists.nongnu.org/mailman/listinfo/vile

Re: [vile] auto-filtered text?

[Brendan O'Dea]

On 1 July 2017 at 01:30,   wrote:
> Let's say I input 10 lines of text, and then I need to filter that text
> through a specific command.  So I go to the top line and do this
>
> :,+9!command
>
> Is there a way that I can save a step -- some kind of special "i" or "o"
> command that will run a filter on each line of text as I enter it?

I can't think of a way offhand to do that, but you can map a character
to apply the filter at the end of each line.  For example:

  map! ^X^M ^[!!tr A-Z a-z^Mo

Note that those need to be literal control characters (see attached).

In this trivial example, I've mapped ^X-RET to exit insert mode,
filter the line through tr to down case the letters, then open a new
line.  So if you were to source the attached file, then enter the
sequence:

  ABC
  DEF

and end each line with ^X-RET (rather than just RET), then the buffer
will contain

  abc
  def

and you should see each line changing case as you move to the next line.

Note (and a question for Tom), for some reason this doesn't work quite
as I would expect when the cursor is on the first line of the window:
the new line is scrolled off the top of the window as opposed to just
hitting RET, which leaves the new line as the first line of the window
and advances the cursor.

--bod


foo.rc
Description: Binary data
___
vile mailing list
vile@nongnu.org
https://lists.nongnu.org/mailman/listinfo/vile

Re: [vile] Possible locations for vile.keywords

[Brendan O'Dea]

Tracing the execution of opening a file in cmode via "vile @filters.rc
foo.c" shows that the following files are attempted in order:

  ./.vile.keywords
  ~/.vile.keywords
  ~/.vile/vile.keywords
  /usr/share/vile/vile.keywords
  ./.c.keywords
  ~/.c.keywords
  ~/.vile/c.keywords
  /usr/share/vile/c.keywords

so ~/.vile.keywords should work.  Does it not?
On Wed, 1 Aug 2018 at 11:20, Chris Green  wrote:
>
> Currently I keep a copy of my customised vile.keywords in /usr/share/vile :-
>
> -rw-r--r-- 1 root root311 Jun 27 22:15 /usr/share/vile/vile.keywords
> -rw-r--r-- 1 root root311 Sep 29  2014 
> /usr/share/vile/vile.keywords.mine
> -rw-r--r-- 1 root root328 Sep 29  2014 
> /usr/share/vile/vile.keywords.original
>
> As I have vile installed on half a dozen or more systems it can become
> a bit of a pain repeatedly copying vile.keywords.mine back over
> vile.keywords whenever vile gets updated.
>
> So, is it possible to have a local copy of vile.keywords that will get
> used in preference to the one at /usr/share/vile/vile.keywords?
>
> E.g. if I have ~/.vile/vile.keywords will that get used?  Or maybe
> even ~/.vile.keywords would get used?
>
> --
> Chris Green
>
> ___
> vile mailing list
> vile@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/vile

___
vile mailing list
vile@nongnu.org
https://lists.nongnu.org/mailman/listinfo/vile

Re: iclower

[Brendan O'Dea]

On Wed, Dec 18, 2019 at 05:55:25PM -0500, Thomas Dickey wrote:
>On Wed, Dec 18, 2019 at 11:00:44AM -0800, Marc Simpson wrote:
>> One nice nvi feature that I miss in vile is the `iclower' setting:
>> 
>> iclower [off]
>>   The iclower edit option makes all Regular Expressions
>>   case-insensitive, as long as an uppercase letter does not
>>   appear in the search string.
[...]
>> Out of curiosity: Would anyone else find this functionality useful
>> in vile?
>
>maybe - it doesn't seem like a large change, since the existing
>comparison is done in one place in regexp.c:
>
>#define SAME(a,b) (ignorecase ? nocase_eq(a,b) : (CharOf(a) == CharOf(b)))

I looked at this today and it is certainly doable, but ends up being a bit
more invasive than expected due to the requirement to toggle the behaviour
based on the search string, which is somewhat further up the stack than where
the match is performed.

A patch to 9.8t is attached which implements "smartmatch", which is a similar
feature that vim supports.  Very lightly tested.

--bod
diff --git a/basic.c b/basic.c
index 2d31f45..7bca596 100644
--- a/basic.c
+++ b/basic.c
@@ -980,7 +980,7 @@ gotoeosent(int f, int n)
 exp = b_val_rexp(curbp, VAL_SENTENCES)->reg;
 /* if we're on the end of a sentence now, don't bother scanning
further, or we'll miss the immediately following sentence */
-if (!(lregexec(exp, DOT.l, DOT.o, llength(DOT.l)) &&
+if (!(lregexec(exp, DOT.l, DOT.o, llength(DOT.l), FALSE) &&
 	  exp->startp[0] - lvalue(DOT.l) == DOT.o)) {
 	if (findpat(f, n, exp, FORWARD) != TRUE) {
 	DOT = curbp->b_line;
diff --git a/buffer.c b/buffer.c
index 06c7932..d921fbd 100644
--- a/buffer.c
+++ b/buffer.c
@@ -1187,7 +1187,7 @@ found_modeline(LINE *lp, int *first, int *last)
 
 for (n = 0; n < TABLESIZE(mls_patterns); ++n) {
 	regexp *prog = mls_regcomp((int) n);
-	if (lregexec(prog, lp, 0, limit)) {
+	if (lregexec(prog, lp, 0, limit, FALSE)) {
 	int j = mls_patterns[n].mark;
 	*first = (int) (prog->startp[j] - prog->startp[0]);
 	*last = (int) (prog->endp[j] - prog->startp[0]);
@@ -1564,11 +1564,9 @@ int
 has_C_suffix(BUFFER *bp)
 {
 int s;
-int save = ignorecase;
-ignorecase = global_g_val(GMDFILENAME_IC);
 s = nregexec(global_g_val_rexp(GVAL_CSUFFIXES)->reg,
-		 bp->b_fname, (char *) 0, 0, -1);
-ignorecase = save;
+		 bp->b_fname, (char *) 0, 0, -1,
+		 global_g_val(GMDFILENAME_IC));
 return s;
 }
 #endif
@@ -1642,7 +1640,7 @@ make_buffer_list(char *bufn)
 
 	if ((exp = regcomp(bufn, strlen(bufn), TRUE)) != 0) {
 		for_each_buffer(bp) {
-		if (nregexec(exp, bp->b_bname, (char *) 0, 0, -1)) {
+		if (nregexec(exp, bp->b_bname, (char *) 0, 0, -1, FALSE)) {
 			result[count++] = strmalloc(bp->b_bname);
 		}
 		}
diff --git a/doc/vile-hlp.html b/doc/vile-hlp.html
index 21a26fc..c40a22a 100644
--- a/doc/vile-hlp.html
+++ b/doc/vile-hlp.html
@@ -3279,6 +3279,12 @@ set-rs-crlf or set-dos-mode
 If your keyboard repeats really fast and you have smoothscroll
 enabled, it may take a while for vile to catch up. (U)
 
+smartcase
+(scs)
+
+Overrides the setting of ignorecase
+when the pattern contains uppercase characters. (B)
+
 spaces-after-sentence
 (sas)
diff --git a/eightbit.c b/eightbit.c
index 04c59bd..9830cc4 100644
--- a/eightbit.c
+++ b/eightbit.c
@@ -297,7 +297,7 @@ vl_narrowed(const char *wide)
 	if ((result = malloc(strlen(wide) + 2 + strlen(on_right))) != 0) {
 		strcpy(result, wide);
 		for (n = 0; n < len; ++n) {
-		found = regexec(exp, result, result + len, n, len);
+		found = regexec(exp, result, result + len, n, len, FALSE);
 		if (found)
 			break;
 		}
@@ -587,7 +587,7 @@ vl_get_encoding(char **target, const char *locale)
 	exp = regcomp(tb_values(latin1_expr),
 			  (size_t) tb_length0(latin1_expr), TRUE);
 	if (exp != 0) {
-		if (nregexec(exp, mylocale, (char *) 0, 0, -1)) {
+		if (nregexec(exp, mylocale, (char *) 0, 0, -1, FALSE)) {
 		TRACE(("... found match in $latin1-expr\n"));
 		result = iso_latin1;
 		}
diff --git a/eval.c b/eval.c
index 58bcedd..4a5487d 100644
--- a/eval.c
+++ b/eval.c
@@ -294,7 +294,7 @@ match_charclass_regexp(int ch, REGEXVAL * exp)
 char temp[2];
 temp[0] = (char) ch;
 
-return nregexec(exp->reg, temp, temp + 1, 0, 0);
+return nregexec(exp->reg, temp, temp + 1, 0, 0, FALSE);
 }
 
 static int
@@ -1469,15 +1469,12 @@ run_func(int fnum)
 	break;
 case UFCMATCH:
 	if ((exp = new_regexval(arg[0], TRUE)) != 0) {
-	int save_flag = ignorecase;
-	ignorecase = TRUE;
-	value = nregexec(exp->reg, arg[1], (char *) 0, 0, -1);
-	ignorecase = save_flag;
+	value = nregexec(exp->reg, arg[1], (char *) 0, 0, -1, TRUE);
 	}
 	break;
 case UFMATCH:
 	if ((exp = new_regexval(arg[0], TRUE)) != 0)
-	value = nregexec(exp->reg, arg[1], (char *) 0, 0, -1);
+	value = nregexec(exp->reg, arg[1], (char *) 0, 0, -1, FALSE);
 	break;
 case UFRANDOM:	

Re: set bcolor to grey85?

[Brendan O'Dea]

On Sun, 15 Mar 2020 at 14:55, Steven Lembark  wrote:
> Catch: ";set bcolor grey85" (or "gray85") gives me nada, it won't
> take the argument. Similarly #f0f0f0 doesn't give me anything.

For vile in the terminal, colours are set with escape codes.
Historically most terminals supported a limited number (if any) of
colors, typically 8 or 16.  Terminal emulators such as xterm allow
Xresources to be used to set the values of these colours (see the
color0-color15 resources in the xterm manual page).

In vile, the command "show-colors" will show what those 16 colours
look like.  See also:

  :show-help
  /^Color basics

--bod

Re: Fonts for xvile in linux - where to find some nice ones?

[Brendan O'Dea]

There is quite a bit of difference in how traditional X11 bitmap fonts
and freetype fonts are selected and rendered
(https://utcc.utoronto.ca/~cks/space/blog/unix/XFontTypes gives a
reasonable summation) but the main thing is that from the API level
they are not interchangeable.  XTerm has specific code to handle
rendering of fonts selected via -fn (server bitmap) vs -fa (client
rendered scalable).  I don't believe that xvile has handling for the
latter, so is limited to traditional server provided bitmap fonts.

On Thu, 7 May 2020 at 00:48, Chris Green  wrote:
>
> On Wed, May 06, 2020 at 07:32:21AM -0400, Paul Fox wrote:
> > chris wrote:
> >  > On Tue, May 05, 2020 at 06:54:48PM -0400, Thomas Dickey wrote:
> >  > > On Tue, May 05, 2020 at 10:43:47PM +0100, Chris Green wrote:
> >  > > > I am always hitting this issue, the current fonts available by 
> > default
> >  > > > in standard Linux repositories for xvile are generally horrible.  
> > Does
> >  > > > anyone here have any nice ones, or can anyone point me at some nice
> >  > > > ones.
> >  > >
> >  > > There's two sets of fonts in the default menu for xvile.
> >  > > The first looks like the bitmap fonts used for xterm,
> >  > > while the other is b lucidatypewriter --
> >  > >
> >  > > you might find this as
> >  > >  bitmap-lucida-typewriter-fonts
> >  > > or
> >  > >  xfonts-100dpi
> >  > >  xfonts-75dpi
> >  > >
> >  > Yes, I have all of those, I was just hoping/wondering if anyone has
> >  > created different/better bitmap fonts.  They're OK[ish] on my desktop
> >  > machine but I can't find anything that is really comfortable to use on
> >  > my laptop.
> >
> > I haven't thought about fonts in a long time.  Is it the case that
> > xvile can't use the same fonts that xterm uses?  I don't use xvile,
> > but I'm pretty happy with my fixed xterm fonts.
> >
> xvile is stuck with the old and rarely renewed/maintained fixed bitmap
> fonts in /etc/X11/fonts whereas vile can use all of the standard
> terminal fonts to be found in /usr/share/fonts.  I'm not sure if xterm
> can use the 'ordinary' system fonts in the same way that other
> terminal emulators can, I use the default xfce4-terminal that comes
> with the xubuntu distribution that I use and that shows me dozens (if
> not hundreds) of different fonts to choose from.
>
> --
> Chris Green
>

Re: The vileget calling code in .vilerc

[Brendan O'Dea]

On Mon, 8 Feb 2021 at 02:45, Chris Green  wrote:
> In my .vilerc that I use on several systems I have the following
> towards the end:-
[snip]

> I only looked at this just recently because I got an unexpected
> vileget running on a little Beaglebone SBC where it took a noticeable
> amount of time to do things.  I couldn't make it start unexpectedly
> again though, I'm a bit non-plussed by the whole thing! :-)

The syntax looks fine to me, and pasted directly into a file and
loaded with "vile @chris.rc" it appears to work fine, with indents as
given.

I can't test dir.pl, which I don't have, but vileget works as
expected: opening the given file in the running vile instance.

I wasn't entirely clear by what you meant by "an unexpected vileget" though...

--bod

Re: Further to the perl/vileget/vileserv saga

[Brendan O'Dea]

On Mon, Feb 08, 2021 at 01:46:11PM -0600, J. Chris Coppick wrote:
>Do not think the "use Vileserv" replaces those other lines.  It does ring a
>bell.  I'd have to dig up the docs and code to check what was required for
>what.

It does, you can pretty easily test it:

  $ echo 'perl "use Vileserv"' >~/vilerc.tmp
  $ vile @~/vilerc.tmp
  :!vileget /etc/passwd

at which point you should have a buffer containing /etc/passwd.

If you're interested in the gory details, the `use Vileserv;' statment in Perl
is equivalent to:

  BEGIN { require Vileserv; Vileserv->import() }

You can ignore the BEGIN block which just changes the evaluation order (not
relevant given that this evaluation context contains only that statement), the
important part here is the invocation of the `import' method, which in the
case of Vileserv does this:

  https://salsa.debian.org/debian/vile/-/blob/master/perl/Vileserv.pm#L80-83

it first calls `Vile::Exporter::import', which is the magic by which every key
in `%REGISTRY' is mapped to a command using `Vile::register':

  https://salsa.debian.org/debian/vile/-/blob/master/perl/Vileserv.pm#L33-38

it then starts the server.  The `END' block arranges to stop the server on
exit:

  https://salsa.debian.org/debian/vile/-/blob/master/perl/Vileserv.pm#L76-78

--bod

Re: Further to the perl/vileget/vileserv saga

[Brendan O'Dea]

On Mon, Feb 08, 2021 at 01:29:13PM +, Chris Green wrote:
>I *think* I'm beginning to understand all this, I suspect there's some
>bits of very old history of mine (and of vile) in all this.
>
>Firstly I don't quite know from where I got the following code (which is in
>my .vilerc):-
>
>perl "Vile::register 'dir', 'dir', 'Dir Browser', 'dir.pl'"
>
>perl "Vile::register 'startserv', 'Vileserv::start', \
>'Start Edit Server', 'Vileserv.pm'"
>perl "Vile::register 'stopserv', 'Vileserv::stop', \
>'Stop Edit Server', 'Vileserv.pm'"
>startserv
>
>store-procedure exitproc
>stopserv
>~endm
>set-variable $exit-hook exitproc
>setv %vileserv-accept-commands true
>

[snip]

>However, while digging into all this I have come across a couple of
>little oddities, mostly in the documentation.
>
>1 - The are references (e.g. in the vileget man page) to a vileserv(3)
>man page.  There isn't a vileserv(3) man page, at least not on any of
>my several systems there isn't.  I do have a vileget man page though.
>(I know I can generate the vileserv manual page using pod2man)

Indeed, the docs are a little messy.  I'll take a look shortly to see what
needs cleaning up and send Tom a patch.

The vileserv manual page is not currently installed.  In the Debian packages,
it is documented under /usr/share/doc/vile/perl/Vileserv.doc, and a command is
registered to display that from vile as `:vileserv-help'.

>2 - I don't know where I got the dir.pl bit above, it seems as if it
>should actually be directory.pm.  Is there any significance in the
>different suffices .pl and .pm for perl extensions?  There is one
>reference to dir.pl in directory.doc which presumably needs changing.

That is another confusion.  There is a doc installed to
/usr/share/doc/vile/dir.doc, and one to
/usr/share/doc/vile/perl/directory.doc.  As noted above, I'll see what I can
do to clean that up.

The difference in `.pl' vs `.pm' is that Perl will use the latter as a default
when `require' is given a bare work (as opposed to a quoted string).  That is
the following two lines are equivalent:

  require "foo.pm";
  require foo;

files with a `.pl' suffix must always be quoted.

  require "foo.pl";

>3 - In Vileserv.doc it says all you need to have in .vilerc is:-
>perl "use Vileserv"
>Does this completely replace the lines above I have in my .vilerc?

Yes.  This may have been in flux at the time that you initially added the
lines to your init file.  It works as-is, just slightly differently.

The Vile::register function registers a command with a Perl implementation,
and optionally specifies the file to load it from (deferred until the first
time it is called).  This is described in vile-perl-api.doc (typically
installed under /usr/share/doc/vile).

So the first line:

  perl "Vile::register 'startserv', 'Vileserv::start', \
   'Start Edit Server', 'Vileserv.pm'"
  startserv

says that the command `:startserv' is implemented by the Perl subroutine
`Vileserv::start', which may be loaded from `Vileserv.pm', and the second line
immediately starts the server.

You also registered `:stopserv', then added a macro and a hook to run that on
exit from vile:

  store-procedure exitproc
   stopserv
  ~endm
  set-variable $exit-hook exitproc

In Perl, the `use' keyword adds the ability to run some implicit
initialisation code when a module is loaded.  At some point (presumably after
you added that stuff to your init file), I added `Vile::Exporter' which
allowed those register commands to be run automatically.  If you look at the
top of Vileserv.pm you will see a %REGISTRY mapping which includes the list of
commands to register automatically when the module is loaded.  This means
that:

  perl "use Vileserv"

implicitly binds `startserv', `stopserv' and some other commands.  It
additionally uses some magic in the import method to start the server on load,
and in the END method to stop the server at shutdown.

In short, you can replace all of the snippet quoted above with the following:

  perl "use directory"
  perl "use Vileserv"
  setv %vileserv-accept-commands true

Of course if you don't use `:directory' or ever run /usr/bin/vileget, you can
simply remove the lot.

--bod

Re: Further to the perl/vileget/vileserv saga

[Brendan O'Dea]

On Tue, 9 Feb 2021 at 10:09, Brendan O'Dea  wrote:
> The difference in `.pl' vs `.pm' is that Perl will use the latter as a default
> when `require' is given a bare work (as opposed to a quoted string).  [...]

That would be "bare *word*", damnit.

--bod

Re: scrolling/paging question

[Brendan O'Dea]

On Tue, Mar 02, 2021 at 07:00:04PM -0500, Thomas Dickey wrote:
>On Tue, Mar 02, 2021 at 04:28:33PM +, Wayne wrote:
>> I can use move-window-down/move-window-up with a count but it still
>> seems in some cases, which I don't quite fully understand yet, the
>> cursor is positioned back at the start of the line.
>
>That's done in getgoal -- offhand, I think the cursor lands on
>a short/empty line, which overrides the initial goal.

I'd be curious to see a case where that happened.  It seems to pretty
tenaciously hang onto the goal column in my tests.

For example: 9.8u, the sequence

  :help
  /scroll through

will place the cursor at 6,29.

Holding down ^E will scroll the window, sticking to column 29 on any line with
at least that many columns.  The cursor moves to the left for shorter lines,
but returns to the goal column in longer lines.

This seemed to work fine using multiple combinations of ^E and ^Y, j and k,
with or without prefix arguments.

--bod

[PATCH 2/2] Perl6 is now known as raku.

[Brendan O'Dea]

Update modes and filters to use "raku" over "perl6".  Extensions as per:

  
https://github.com/Raku/problem-solving/blob/master/solutions/language/Path-to-Raku.md#extensions

are matched, as are the previous ".p6", ".pl6", etc.

Note renames:

  mv filters/pl6filt.c filters/raku-filt.c
  mv filters/perl6.key filters/raku.key
---
 filters/genmake.mak|  4 ++--
 filters/{pl6filt.c => raku-filt.c} |  8 
 filters/{perl6.key => raku.key}|  0
 macros/modes.rc| 10 +-
 4 files changed, 11 insertions(+), 11 deletions(-)
 rename filters/{pl6filt.c => raku-filt.c} (99%)
 rename filters/{perl6.key => raku.key} (100%)

diff --git a/filters/genmake.mak b/filters/genmake.mak
index 2258246..dd9118a 100644
--- a/filters/genmake.mak
+++ b/filters/genmake.mak
@@ -1,4 +1,4 @@
-# $Id: genmake.mak,v 1.49 2020/05/09 09:27:50 tom Exp $
+# $Id$
 # This is a list of filter root names and whether .c or .l files define the
 # filter.  Except for vile-crypt and vile-manfilt (which do not correspond to
 # majormodes), the filter names are constructed as vile-{root}-filt.
@@ -7,7 +7,7 @@ c   c-filt  c
 keykey-filtc
 m4 m4-filt c
 perl   pl-filt c
-perl6  pl6filt c
+raku   raku-filt   c
 ruby   rubyfiltc
 sedsed-filtc
 tags   tagsfiltc
diff --git a/filters/pl6filt.c b/filters/raku-filt.c
similarity index 99%
rename from filters/pl6filt.c
rename to filters/raku-filt.c
index 7cd5580..c451cea 100644
--- a/filters/pl6filt.c
+++ b/filters/raku-filt.c
@@ -1,16 +1,16 @@
 /*
- * $Id: pl6filt.c,v 1.1 2019/07/21 17:42:30 tom Exp $
+ * $Id: raku-filt.c,v 1.1 2019/07/21 17:42:30 tom Exp $
  *
- * Filter to add vile "attribution" sequences to perl6 scripts.
+ * Filter to add vile "attribution" sequences to raku (formerly perl6) scripts.
  * This is a clone of "pl-filt.c", to handle differences from perl5.
  */
 
 #include 
 
 #ifdef DEBUG
-DefineOptFilter(perl6, "d");
+DefineOptFilter(raku, "d");
 #else
-DefineFilter(perl6);
+DefineFilter(raku);
 #endif
 
 /*
diff --git a/filters/perl6.key b/filters/raku.key
similarity index 100%
rename from filters/perl6.key
rename to filters/raku.key
diff --git a/macros/modes.rc b/macros/modes.rc
index a082d1f..4a3c7ca 100644
--- a/macros/modes.rc
+++ b/macros/modes.rc
@@ -706,11 +706,11 @@ define-mode perl
 ;  fence-fi   '^\s*}'
 ~endwith
 
-define-mode perl6
-~with define-submode perl6
-   preamble
'^\(#!\s*\(\/[^\\]*\)\?\\)\|\(\s*use\s\+v6\s*;\)'
-   suffixes'\.\(pl6\|rakudo\)$'
-   mode-pathname   '^.*perl6.*\.t$'
+define-mode raku
+~with define-submode raku
+   preamble
'^\(#!\s*\(\/[^\\]*\)\?\<\(perl6\|rakudo\)\>\)\|\(\s*use\s\+v6\s*;\)'
+   suffixes'\.\(pl\?6\|pm6\|raku\(\|mod\|test\)\)$'
+   mode-pathname   '^.*rakudo.*\.t$'
after   "perl"
cindent
cindent-chars   ':' $fences
-- 
2.34.1

[PATCH 1/2] Apply some changes from pl-filt.c to pl6filt.c

[Brendan O'Dea]

It appears that a leak of `marker' was fixed in the former which didn't make
it to the latter.
---
 filters/pl6filt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/filters/pl6filt.c b/filters/pl6filt.c
index 7148eb3..7cd5580 100644
--- a/filters/pl6filt.c
+++ b/filters/pl6filt.c
@@ -1548,8 +1548,10 @@ do_filter(FILE *input GCC_UNUSED)
state = eHERE;
mark_len = 0;
try_mark = do_alloc(0, (size_t) 2, _len);
-   if (try_mark != 0)
+   if (try_mark != 0) {
+   free(marker);
marker = strcpy(try_mark, ".");
+   }
}
save = s[ok];
s[ok] = 0;
@@ -1659,6 +1661,7 @@ do_filter(FILE *input GCC_UNUSED)
}
free(the_file);
 }
+free(marker);
 }
 
 #if NO_LEAKS
-- 
2.34.1

Re: How to access vile variables in : command?

[Brendan O'Dea]

Not sure about variables in general, but you should be able to use %
for the current filename here (and # for the alternate filename).

On Thu, 9 Nov 2023 at 02:52, Chris Green  wrote:
>
> I'm sure this should be obvious but at the moment it's not obvious to
> me! :-)
>
> I want to do something like the following:-
>
> map #9 :e `pdf $cfilname`^M
>
> However the above doesn't work, $cfilname is null in the above
> context. How can I get the current file's name in this sort of place?
>
>
> --
> Chris Green
>

[PATCH] Fix build failure with Perl 5.36

[Brendan O'Dea]

Fix a build failure for Perl 5.36 caused by a namespace conflict of
the symbol `regexp' (http://bugs.debian.org/1014289).

diff --git a/perl.xs b/perl.xs
index 86c04e3..ee658d2 100644
--- a/perl.xs
+++ b/perl.xs
@@ -118,20 +118,20 @@
 
 /* for vile */
 #define MARK vile_MARK
+#define regexp vile_regexp
 #include "estruct.h"
 #include "edef.h"
 #include "api.h"
 #undef MARK
+#undef regexp
 #undef ABORT
 
 /* for perl */
 #define main perl_main
-#define regexp perl_regexp
 #include 
 #include 
 #include 
 #undef main
-#undef regexp
 #undef dofile
 
 #ifdef __GNUC__

[PATCH] Remove obsolete gcc pragma

[Brendan O'Dea]

Remove a pragma from perl.xs which gcc no longer recognises.

This pragma was meant to reduce noise, but now adds more.  Compiling
with gcc 11 produces:

  ../../perl.xs:24:32: warning: unknown option after ‘#pragma GCC diagnostic’ 
kind [-Wpragmas]
 24 | #pragma GCC diagnostic ignored "-Wcompound-token-split-by-macro"
|^

diff --git a/perl.xs b/perl.xs
index 646f2ed..86c04e3 100644
--- a/perl.xs
+++ b/perl.xs
@@ -21,7 +21,6 @@
  */
 #ifdef __GNUC__
 #pragma GCC diagnostic ignored "-Wcast-qual"
-#pragma GCC diagnostic ignored "-Wcompound-token-split-by-macro"
 #pragma GCC diagnostic ignored "-Wconversion"
 #pragma GCC diagnostic ignored "-Wnested-externs"
 #pragma GCC diagnostic ignored "-Wshadow"

Re: UTF8 has stopped working in vile after OS upgrade

[Brendan O'Dea]

Testing the vile 9.8v-2 package on my Debian machine I get some decidedly
odd behaviour:

The following sequence:

  l- e' c,

is rendered in vile as:

  \?A3\?E9\?E7

outside of vile, in the same terminal that appears fine:

  £éç

which would suggest that vile doesn't handle UTF-8 at all, although as
Chris noted, entering those three characters using C-v x  works fine,
and renders in vile correctly.

Even more odd, *other* characters work fine with compose in vile:

  ## <" e,

for example input fine, and appear in vile as expected:

  ♯“ę

xvile is similarly odd, and launched as:

  xvile -xrm '*font:
-misc-fixed-medium-r-normal--13-120-75-75-c-80-iso10646-1'

behaves in the same way: using compose, ♯“ę works, but £éç does not.
Similarly, the latter does work using C-v x .

Things are more screwy with the Debian shipped app-defaults (hence the -xrm
flag), which uses "8x13" that turns out to be an alias for the 8859-1
variety of that misc font, not the unicode one.  That however is my fault,
and I'll fix that in an upload shortly.

On Fri, 29 Jul 2022 at 07:27, Chris Green  wrote:

> ... and further, no compose key sequences work in vile 9.8v whereas
> they do work in vile 9.8u.
>
> E.g. I can't enter accented characters using COMPOSE + e + ' (for e
> with acute accent) or COMPOSE + c + , (for c with a cedilla).
>
> --
> Chris Green
>
>

[PATCH] fix uxvile font, and update xvile to match

[Brendan O'Dea]

The font specification in /etc/X11/app-defaults/UXVile is being
overridden by the one in XVile.  Additionally update the xvile font to
use the Latin-1 equivalent (9x18 instead of 8x13).

Pushed to salsa.debian.org/debian/vile as 52d1fe2a and 18f244bc respectively.

diff --git a/macros/UXVile.ad b/macros/UXVile.ad
index 6f91fc4..956ad81 100644
--- a/macros/UXVile.ad
+++ b/macros/UXVile.ad
@@ -1,5 +1,5 @@
 ! $Id: UXVile.ad,v 1.2 2009/10/07 10:53:26 tom Exp $
 
-*font: -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1
-
 #include "XVile"
+
+*font: -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso10646-1

diff --git a/macros/XVile.ad b/macros/XVile.ad
index aab6539..8cb72c5 100644
--- a/macros/XVile.ad
+++ b/macros/XVile.ad
@@ -3,7 +3,7 @@
 ! "white" on "black" main window
 *background: grey5
 *foreground: grey95
-*font: 8x13
+*font: -misc-fixed-medium-r-normal--18-120-100-100-c-90-iso8859-1
 *cursor.background: yellow
 *cursor.foreground: grey5
 

Re: UTF8 has stopped working in vile after OS upgrade

[Brendan O'Dea]

OK, so this appears to have been caused by the change:

  "modify lins_chars() to handle a case where a script inserts a UTF-8
character (report by Thomas Dupond)."

lins_chars is being invoked with wide=0, and is working for codepoints >=
256 (which is why ę works, and £ does not).

I've pushed a rollback of that change to Debian as 0d1f060a.  Relevant
patch attached.

--bod

On Sat, 30 Jul 2022 at 00:00, Chris Green  wrote:

> On Fri, Jul 29, 2022 at 04:27:05AM -0400, Thomas Dickey wrote:
> > On Fri, Jul 29, 2022 at 03:40:12PM +1000, Brendan O'Dea wrote:
> > > Testing the vile 9.8v-2 package on my Debian machine I get some
> decidedly
> > > odd behaviour:
> > >
> > > The following sequence:
> > >
> > >   l- e' c,
> > >
> > > is rendered in vile as:
> > >
> > >   \?A3\?E9\?E7
> > >
> > > outside of vile, in the same terminal that appears fine:
> > >
> > >   Łéç
> > >
> > > which would suggest that vile doesn't handle UTF-8 at all, although as
> > > Chris noted, entering those three characters using C-v x  works
> fine,
> > > and renders in vile correctly.
> >
> > hmm - with some time, I can bisect to pinpoint the problem.
> >
> > (pasting outside of 0..255 seems ok)
> >
> Weirdly I find that using the vile defined 'compose' key *does* work
> for accented characters, but using the default 'compose' key (as
> defined in .Xmodmap) it doesn't work.
>
> I.e. I have "source digraphs.rc" in my .vilerc file as follows:-
>
> ;
> ;
> ; Set up ^K as 'compose' key for accented characters
> ;
> source digraphs.rc
>
> ... and, rather to my surprise, when I entered ^ke' I got an e with an
> accute accent.  I rarely (if ever) use this in vile, I'd really
> forgotten it was there.  It doesn't work for a pound sign though (^kl=).
>
> --
> Chris Green
>
>
diff --git a/insert.c b/insert.c
index 645c05d..158ad0e 100644
--- a/insert.c
+++ b/insert.c
@@ -446,7 +446,7 @@ replacechar(int f, int n)
if (isbackspace(c)) {   /* vi beeps here */
s = TRUE;   /* replaced with nothing */
} else {
-   t = s = lins_chars(n, c, FALSE);
+   t = s = lins_chars(n, c);
}
}
}
@@ -981,11 +981,11 @@ inschar(int c, int *backsp_limit_p)
rc = inspound();
} else {
autoindented = -1;
-   rc = lins_chars(1, c, FALSE);
+   rc = lins_chars(1, c);
}
} else {
autoindented = -1;
-   rc = lins_chars(1, c, FALSE);
+   rc = lins_chars(1, c);
}
 }
 return rc;
@@ -1515,7 +1515,7 @@ quote_next(int f, int n)
s = lnewline();
} while ((s == TRUE) && (--n != 0));
} else {
-   s = lins_chars(n, c, TRUE);
+   s = lins_chars(n, c);
}
 }
 return s;
diff --git a/line.c b/line.c
index d56a6f6..bd5b8a5 100644
--- a/line.c
+++ b/line.c
@@ -534,7 +534,7 @@ lins_bytes(int n, int c)
  * or in insert-mode.
  */
 int
-lins_chars(int n, int c, int wide)
+lins_chars(int n, int c)
 {
 int rc = FALSE;
 UCHAR target[10];
@@ -542,7 +542,7 @@ lins_chars(int n, int c, int wide)
 int nn;
 int mapped;
 
-if (wide && (c > 127) && b_is_utfXX(curbp)) {
+if ((c > 127) && b_is_utfXX(curbp)) {
nbytes = vl_conv_to_utf8(target, (UINT) c, sizeof(target));
 } else if (okCTYPE2(vl_wide_enc) && !vl_mb_is_8bit(c)) {
nbytes = 1;
diff --git a/proto.h b/proto.h
index 4c8198f..77ab7e0 100644
--- a/proto.h
+++ b/proto.h
@@ -873,10 +873,10 @@ extern int lrepl_regex (REGEXVAL *expr, const char 
*iline, int ilen);
 
 #if OPT_MULTIBYTE
 extern int ldel_chars (B_COUNT n, int kflag);
-extern int lins_chars (int n, int c, int wide);
+extern int lins_chars (int n, int c);
 #else
 #define ldel_chars(n, kflag) ldel_bytes(n, kflag)
-#define lins_chars(n, c, wide)  lins_bytes(n, c)
+#define lins_chars(n, c)  lins_bytes(n, c)
 #endif
 
 #if OPT_REGS_CMPL

Re: Vileserv on macOS issue

[Brendan O'Dea]

On Wed, 21 Dec 2022 at 09:33, Robert Sturrock  wrote:
> read(0x4, "/Users/rns/tmp/fortune-cookie.txt\n\n\0", 0x2000) = 35 > 0
> write(0x1, "/Users/rns/tmp/fortune-cookie.txt\n\n\n\0", 0x24)= 36 > 0

That looks pretty much what I would expect vileserv to do: it reads
from the socket, and writes to stdout, which is a pipe to the running
vile instance.

> Any clues as to where the issue might be or how I might be better debug this? 
>  I suspect I’m missing some obvious here!

Not quite sure what's going on.  You could also trace the vile
process, where you should see a corresponding read from the pipe.

In addition to that, I'd start putting some print statements into the
readfiles subroutine in Vileserv.pm.  Anything sent to stdout there
should appear in the messages buffer.  Make sure to ":set pm" first to
cause that buffer to popup.

Then just put lines in to see what's going wrong, say adding:

  print "Entering readfiles\n";

at the start of that subroutine (line 171), then:

  print "Got file $fileName\n";

after the "chomp $fileName;" statement.  Keep adding statements until
you find what is not working as expected.

About the only thing which springs to mind that may be a problem is
that the code uses newlines to delimit lines, and Macs at some point
used carriage returns.  Probably not the case since OS X though.

One unrelated, and slightly annoying thing that I noticed is that
printing to the minibuffer now elicits a warning.  Must look into what
changed in more recent Perl versions.

  :perl use warnings; print "foo\n";

for example produces a warning about an uninitialised value, almost
certainly in the guts of perl.xs.  I'll maybe poke at that over
Christmas.

--bod

Re: Build errors at link time - what am I missing?

[Brendan O'Dea]

On Thu, 1 Dec 2022 at 07:26, Chris Green  wrote:
> > However, later on in configure I get:-
> > configure: WARNING: Cannot find -ltermlib, -lcurses, or -ltermcap
> > and then at link time there are loads of undefined references to
> > tputs, tgoto, and a lot of other tx symbols.
> >
> > So presumably I need to build one of those libraries, or is there
> > something simpler I can do?

If you don't have permission to install packages, then you will need
to build some of the dependencies in your home directory.

> The system does have libncurses, it's in /usr/lib/x86_64-linux-gnu. Is
> it possible that directory isn't on the cc/linker search path?  How do
> I add it?

Debian splits libraries into runtime and development components: the
runtime package contains just the versioned shared library such as
libncurses.so.6, and the development package contains the symlink to
the appropriate version of the shared library (e.g. libncurses.so ->
libncurses.so.6), and the header files.

So even if libncurses.so.6 is installed, that is not enough to build
with.  If you're building in your home directory, you can probably
just get:

  https://invisible-island.net/ncurses/ncurses.html

and build that with --prefix=$HOME.  I think that this will provide an
appropriate flex:

  https://invisible-island.net/reflex/reflex.html

The only other things that I build the Debian package with are Perl
and Xaw, which you can skip if you don't fancy building Perl, and
don't care about X.

--bod

Re: Can one build a static vile easily?

[Brendan O'Dea]

On Wed, 12 Jul 2023 at 19:44, Chris Green  wrote:
> Is there any way to build a 'static' version of vile fairly easily?

This is a pretty easy one to answer: easily?  no.

Part of this is because the current configure is not set up for it, so
you would need to muck about with the generated makefile; the other
part is that glibc doesn't really support static linking.  That second
one is a bit complicated, hence the "really" part: in order to support
nsswitch, glibc loads some dynamic components, even when linked
statically.  Additionally, there are a bunch of dependent files for
locale support, which wouldn't be included in a statically linked
binary.

> ... or a way to create something like an appimage?

I've not had much experience with appimage/snap/flatpak/whatever, but
the main reason that I looked for a replacement for Slackware (which
is the distro that I started with), and ended up with Debian, was that
I wanted to be able to support distribution of software to multiple
machines, and wanted some kind of packaging that wasn't a manually
created tarball.

I'm assuming that you have a bunch of machines that you need to
manage, and that you don't want to build vile individually on all of
them.  Assuming that there is a small number of target platforms, I'd
suggest building packages for those platforms.  The vile source has
packaging options for a number of platforms in the `package`
subdirectory.

--bod

Re: Weird problem in xvile - I can't enter a '>' character

[Brendan O'Dea]

On Tue, 12 Mar 2024 at 02:28, Chris Green  wrote:
>
> If I comment out the line:-
>
> keysym period = period rightcaret U25B6 NoSymbol
>
> then the > key works again in xvile.  However I really don't see why
> the above line breaks xvile, no other programs (or none I can find
> anyway) are affected in the same way.  The U25B6 character works in
> xvile as does 'period' (I'd really miss that one!).

Maybe try :

keysym period = period greater U25B6 NoSymbol

On my machine, where I haven't remapped that key I get this:

  % xmodmap -pk | fgrep period
 600x002e (period) 0x003e (greater) 0x002e (period) 0x003e (greater)

--bod

Re: macro question

[Brendan O'Dea]

On Fri, 5 Apr 2024 at 16:09, david sowerby  wrote:
> Hi, in Vim/Neovim I can save a copy of the file when I exit. The copy is 
> renamed file-$(date +%s).bak. This gives me a file with an increasing number 
> plus .bak. It looks like "date+%s" and  "" do the same thing. Is this 
> possible in vile? I know I can save a file as file.bak but I like to save a 
> series of changed files, not just one.

I vaguely recall dealing with operating systems which did this (VMS?
MVS?).  Every file save added a new version, and you had to
periodically run `PURGE` to recover disk space.

An alternative is to stash each write in a version control system.
In a previous job (more than a decade ago, before git existed), all of
our production servers had the attached script installed as both `viw`
(update file and send diff), and a link as `vis` (silently update
file).  This logged changes to any production files (typically in
/etc), and stashed them in version control so you could easily revert
a problem change; see the difference b/w versions, etc.

Note that this script will prompt for a description of the file on
first commit, and a reason for the change in subsequent updates.

This worked pretty well for us at the time, and didn't version every
file, just the ones we cared about.

--bod


viw
Description: Binary data