Re: move/copy question
On Thu, Jun 06, 2024 at 01:50:48PM +, david sowerby wrote:
> Thanks for the quick reply. I can live without "co" and "m", it was mostly
> curiosity on my part. Maybe the "show-commands" should have "not implemented
> yet" added? and thanks for all the work :-)
agreed. When I switch back to vile, I'll probably do that, as well as
making some notes on why it's not done -- perhaps "only" the syntax,
which would require some work to permit the address adjacent to the
command-name -- unlike all of the other commands.
>
> ==
> Inertia is the most powerful force in the Universe.
>
>
> On Thursday, June 6, 2024 at 01:09:57 AM PDT, Thomas Dickey
> wrote:
>
> On Thu, Jun 06, 2024 at 05:05:30AM +, david sowerby wrote:
> > According to the O'Reilly book Vile doesn't have the vi 'move' command (or
> > the 'copy' one either?) But checking through Vile's "show-commands" they are
> > both described -- 'move-til' and 'copy-til'. But they don't work :-(
> > ...or am I doing something wrong? A search in the Archives gives no
> > result. Another month another question.
>
> They are in the symbol table for completeness, but as the message says,
> not implemented. The reason for the omission is that (without a lot of
> work, of course), the vi-compatible syntax wouldn't work with the way
> vile's ":" line is parsed:
>
> + vi works by reading the whole line all at once, and picking out what
> it needs.
>
> + vile works by accepting the line in steps which allow for
> name-completion and scrolling through the history.
>
> The basic scheme of parsing in steps dates from the early 1990s.
> Later in the 1990s, I did a lot of the name-completion and
> history mechanism.
>
> While _that_ has some quirks (which I've gotten used to, and
> overlook), getting that to work well took a lot of time :-)
>
> The archives don't go back that far, of course (looks like that began in
> January 2006). Paul Fox used to run a mailing list on his machine.
> I'm not aware of an archive for that, and don't have a complete set.
>
> There was some occasional discussion of the above points, and I probably
> have some relevant mail, but digging it out would take some work :-(
>
> The code in its current form dates from 1996, with some reformatting in 2001:
>
> 1.277 (pgf 01-May-96): /* ARGSUSED */
> 1.277 (pgf 01-May-96): int
> 1.290 (tom 15-Mar-97): unimpl(int f GCC_UNUSED, int n GCC_UNUSED)
> 1.277 (pgf 01-May-96): {
> 1.453 (tom 21-Aug-01): mlwarn("[Sorry, that vi command is
> unimplemented in vile ]");
> 1.453 (tom 21-Aug-01): return FALSE;
> 1.277 (pgf 01-May-96): }
> 1.277 (pgf 01-May-96):
> 1.277 (pgf 01-May-96): int
> 1.277 (pgf 01-May-96): opercopy(int f, int n)
> 1.277 (pgf 01-May-96): {
> 1.453 (tom 21-Aug-01): return unimpl(f, n);
> 1.277 (pgf 01-May-96): }
> 1.277 (pgf 01-May-96):
> 1.277 (pgf 01-May-96): int
> 1.277 (pgf 01-May-96): opermove(int f, int n)
> 1.277 (pgf 01-May-96): {
> 1.453 (tom 21-Aug-01): return unimpl(f, n);
> 1.277 (pgf 01-May-96): }
>
> but the unimpl and related functions date from 1991:
>
> REV:1.6 main.c 1991/05/31 11:12:19 pgf
>
> changed args to execute(), and
> added linespec character class, and
> added unimplemented ex functions
>
> All of this is in RCS, but I've exported stuff to git -
>
> https://invisible-island.net/personal/git-exports.html
> https://github.com/ThomasDickey/vile-snapshots
> https://github.com/ThomasDickey/pgf-vile-snapshots
>
> --
> Thomas E. Dickey
> https://invisible-island.net
>
--
Thomas E. Dickey
https://invisible-island.net
signature.asc
Description: PGP signature
Re: move/copy question
On Thu, Jun 06, 2024 at 05:05:30AM +, david sowerby wrote:
> According to the O'Reilly book Vile doesn't have the vi 'move' command (or
> the 'copy' one either?) But checking through Vile's "show-commands" they are
> both described -- 'move-til' and 'copy-til'. But they don't work :-(
> ...or am I doing something wrong? A search in the Archives gives no
> result. Another month another question.
They are in the symbol table for completeness, but as the message says,
not implemented. The reason for the omission is that (without a lot of
work, of course), the vi-compatible syntax wouldn't work with the way
vile's ":" line is parsed:
+ vi works by reading the whole line all at once, and picking out what
it needs.
+ vile works by accepting the line in steps which allow for
name-completion and scrolling through the history.
The basic scheme of parsing in steps dates from the early 1990s.
Later in the 1990s, I did a lot of the name-completion and
history mechanism.
While _that_ has some quirks (which I've gotten used to, and
overlook), getting that to work well took a lot of time :-)
The archives don't go back that far, of course (looks like that began in
January 2006). Paul Fox used to run a mailing list on his machine.
I'm not aware of an archive for that, and don't have a complete set.
There was some occasional discussion of the above points, and I probably
have some relevant mail, but digging it out would take some work :-(
The code in its current form dates from 1996, with some reformatting in 2001:
1.277(pgf 01-May-96): /* ARGSUSED */
1.277(pgf 01-May-96): int
1.290(tom 15-Mar-97): unimpl(int f GCC_UNUSED, int n GCC_UNUSED)
1.277(pgf 01-May-96): {
1.453(tom 21-Aug-01): mlwarn("[Sorry, that vi command is
unimplemented in vile ]");
1.453(tom 21-Aug-01): return FALSE;
1.277(pgf 01-May-96): }
1.277(pgf 01-May-96):
1.277(pgf 01-May-96): int
1.277(pgf 01-May-96): opercopy(int f, int n)
1.277(pgf 01-May-96): {
1.453(tom 21-Aug-01): return unimpl(f, n);
1.277(pgf 01-May-96): }
1.277(pgf 01-May-96):
1.277(pgf 01-May-96): int
1.277(pgf 01-May-96): opermove(int f, int n)
1.277(pgf 01-May-96): {
1.453(tom 21-Aug-01): return unimpl(f, n);
1.277(pgf 01-May-96): }
but the unimpl and related functions date from 1991:
REV:1.6 main.c 1991/05/31 11:12:19 pgf
changed args to execute(), and
added linespec character class, and
added unimplemented ex functions
All of this is in RCS, but I've exported stuff to git -
https://invisible-island.net/personal/git-exports.html
https://github.com/ThomasDickey/vile-snapshots
https://github.com/ThomasDickey/pgf-vile-snapshots
--
Thomas E. Dickey
https://invisible-island.net
signature.asc
Description: PGP signature
Re: macro question
On Sat, Apr 06, 2024 at 07:21:33PM +1100, Brendan O'Dea wrote: > 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. VMS (DEC) is what you're thinking of. MVS (IBM) is different... I wrote a file-manager for VMS in 1984-1985, which implements a command language with "purge": https://invisible-island.net/flist/flist.html https://github.com/ThomasDickey/flist-snapshots/blob/1eeef2322704c5efe0f98b1b287c16a896657f0b/doc/flist.mem#L64 and during the initial development was able to generate a series of versions for the executable that passed 1200. > 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. VMS had a versioning system also - "CMS", which I encountered in 1989. Its archive files looked like SCCS (interleaved deltas), except that the magic character was "*" rather than control/A. With some work, one could determine when it was introduced: http://www.bitsavers.org/pdf/dec/vax/vms/ It's mentioned in the master index for 5.0 (1988). http://www.bitsavers.org/pdf/dec/vax/vms/5.0/ (VMS DEC/CMS is unrelated to IBM VM/CMS) Nowadays, I generally review changes in vile (showing diff's in a buffer). That's usually with RCS, with Git for special cases (and snapshots). https://invisible-island.net/ded/cm_tools.html https://invisible-island.net/personal/git-exports.html (There are of course graphical diff's - sometimes helpful, sometimes not) > 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 -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: macro question
On Thu, Apr 04, 2024 at 08:01:01PM +, 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. > So a macro that saves a copy and I then call that macro with write-hook. > Thanks. write-hook is called before a file is written (so I don't think it would work just like the suggested order). But you could have a macro which decides what the filename should be, and writes to that. The macro should save and restore $cfilname, otherwise $cfilname will get updated to point to the most recently written file. -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: searching for ascii/non-ascii
On Fri, Mar 29, 2024 at 12:07:16PM -0400, Paul Fox wrote: > I often want to clean up the residue you sometimes get when copying > text from a web page -- bits of unicode, or special characters, like > the "\?B0" my screen uses to show the "degrees" symbols in this line: > Start Totality 01:33 pm67.2? 178.0? > > I think that long, long, ago, I could find those characters using \P, > but that was before the vile's shorthand search notations were brought > into line with the X/Open classes. With that change, the TAB character > lost its "printable" status, so \P finds tabs as well as true non-printables. > > What I think I want is a shorthand for [:ascii:] (meaning "8th bit clear"). > Is this available in some way that I'm missing? > > Would it be possible to add this, perhaps bound to \y or \z? Even if > it weren't bound to a shorthand, if [[:ascii:]] were available as > part of a search string, that would be useful enough. it sounds simple. I generally just type in [^ -~^I] to find non-printable bytes (where the "^I" is the tab character). For zapping Unicode as well, :setl fk=8bit Oddly, perlre doesn't list anything appropriate, though \z and \Z have useful meanings. I don't see \y or \Y (except the latter as something that one might customize). > > (Oddly, if I search for "[[:ascii:]]" today, it finds instances of ":]". > Not sure why.) > > > Current classes and shorthands: >\i \I [:alnum:] >\a \A [:alpha:] >\b \B [:blank:] >\c \C [:cntrl:] >\d \D [:digit:] >\f \F [:file:] >\g \G [:graph:] >\w \W [:ident:], alphanumeric (plus '_') >\l \L [:lower:] >\o \O [:octal:] >\p \P [:print:], printable (note that space is printable) >\q \Q [:punct:] >\s \S [:space:] >\u \U [:upper:] >\x \X [:xdigit:] > > > =-- > paul fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 40.1 degrees) > > -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Weird problem in xvile - I can't enter a '>' character
On Tue, Mar 12, 2024 at 09:11:32AM +, Chris Green wrote:
> On Tue, Mar 12, 2024 at 02:25:59PM +1100, Brendan O'Dea wrote:
> > 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)
> >
> Yes, brilliant! Thank you. It now works.
>
> I don't know where I got rightcaret from. It's always the most
> difficult bit when playing with character mapping, finding the right
> names.
xmodmap uses the names defined in the X keyboard map files.
Those start with a grid location, i.e., the "AB09" in this chunk:
key { [ comma, less, ccedilla, Ccedilla ] };
key { [period,greater, dead_abovedot, dead_caron ] };
key { [ slash, question, questiondown,dead_hook ] };
key { [ backslash,bar, notsign,brokenbar ] };
The symbols match up with /usr/include/X11/keysymdef.h, which has a bunch
of non-character codes, plus ISO-8859-1 and its friends. There's a nice
comment in the file which explains how it relates to Unicode.
Locations that didn't right nicely into a uniform grid have special names such
as "BKSL".
The names can differ according to the keyboard map. You can get some insight
by seeing how they're used, e.g., in /usr/share/X11/xkb (Debian):
Looking for rightcaret, I see only a few references:
symbols/my:98:key { [Arabic_comma, rightcaret] };
symbols/in:1581:key { [ U002E, U0C19,
rightcaret ] }; // . ఙ >
symbols/us:83:key {[ leftcaret,rightcaret ] };
The last is plausible, but see its definition:
partial alphanumeric_keys
xkb_symbols "ibm238l" {
include "us(basic)"
name[Group1]= "English (US, IBM Arabic 238_L)";
key {[ comma,comma ] };
key {[period,period ] };
key {[ quoteleft,asciitilde ] };
key {[ backslash,bar] };
key {[ leftcaret,rightcaret ] };
};
That "ibm238l" looks odd - that's used in a few places:
rules/base.extras.xml:463:ibm238l
rules/evdev.extras.xml:463:ibm238l
symbols/sun_vndr/us:63: xkb_symbols "ibm238l" {
symbols/sun_vndr/us:64: include "us(ibm238l)"
symbols/us:74:xkb_symbols "ibm238l" {
and none of those seem plausible. Perhaps this used a customized keyboard
map which was wiped out by an upgrade.
"greater" is easier to follow, there are more than 300 references, e.g.,
symbols/us:53:key { [period,greater ] };
symbols/us:138:key { [period,greater, dead_abovedot,
dead_caron ] };
symbols/us:194: key { [ period, greater, dead_abovedot,
dead_circumflex ] };
symbols/us:224:key { [ period, greater, dead_abovedot,
periodcentered ] };
symbols/us:288:key { [period,greater, dead_abovedot,
dead_caron ] };
symbols/us:352:key { [period, greater, ecircumflex,
periodcentered ] };
symbols/us:403:key { [ period, greater ] };
symbols/us:454:key { [ period, greater ] };
When you use xmodmap, you're basically telling it to reinterpret one of those
table entries. So... when you're puzzled, finding the relevant table can
help.
For amusement:
https://invisible-island.net/xterm/modified-keys.html
--
Thomas E. Dickey
https://invisible-island.net
signature.asc
Description: PGP signature
Re: Weird problem in xvile - I can't enter a '>' character
On Mon, Mar 11, 2024 at 10:16:08AM -0400, Paul Fox wrote: > chris wrote: > > I don't use xvile all that much, I use vile in a terminal window most > > of the time, however I do sometimes find I need to use xvile. > > > > I've just found that the > character doesn't work in xvile. This > > seems to be the same on both version 9.8v and 9.8y running on two > > different xubuntu systems. > > > > The > character works fine everwhere else, in vile, in the terminal > > window, in browser windows, etc. > > > > I've tried changing font selection but that didn't help. > > > > I *can* enter a > by typing x3e. > > > > Any ideas how to diagnose this? > > Perhaps not much help, but: works for me, 9.8v on Ubuntu. same here. I'd suspect locale-related problems (e.g., the keyboard configuration). Some environments tend to switch my keyboard settings to UK - perhaps you have the complementary problem of switching to US? -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: .ini files and DOS line endings
On Wed, Mar 06, 2024 at 09:58:26AM -0500, Paul Fox wrote: > Never mind. I figured it out. > > I copied the "ini" mode definition from modes.rc into my .vilerc, and > changed it to remove the ".ini" file suffix from its list. The file > now comes up in conf mode. that works. I'd have just done something like this in .vilerc: define-mode ini ~with define-submode ini nodos ~endwith or (assuming "define-mode ini" was already executed): define-submode ini nodos possibly with a comparing $cwd to the places where I preferred using that combination. > paul > > I wrote: > > A .ini file is edited in [inimode]. It's also edited with DOS line > > endings, i.e. [inimode crlf]. > > > > Normally when a file is in "crlf" mode, you can do "set nodos" before > > writing it out to eliminate the DOS line endings. > > > > But if the file is also in inimode, that doesn't work. > > > > So I have a .ini file, on linux, which keeps getting CRNL line endings > > every time I edit and write it. Frustrating, since the program that reads > > it warns about this when it starts. > > > > Is there a way to prevent the INI filter (if that's what's doing it) from > > changing the file's line endings? > > > > Barring that, how do I disable an editing mode -- how can I tell vile > > that a .ini file isn't special at all. delete-mode inimode -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Slackbuild URL
On Mon, Mar 04, 2024 at 06:00:24PM -0500, lists-vile--- via discussions concerning the vile text editor wrote: > Thomas Dickey wrote: > > On Mon, Mar 04, 2024 at 11:08:11AM -0500, lists-vile--- via discussions > > concerning the vile text editor wrote: > > > Thomas, > > > > > > On the mail vile page, https://www.invisible-island.net/vile/vile.html, > > > the > > > Slackbuild that is referenced is out of date. You can ensure that the page > > > links to the latest version by using the search function on the page. > > > > > > https://slackbuilds.org/result/?search=vile > > that works, though not elegant: > > it gives me both vile and xvile -- and bubblewrap > > > > It would be nice if there were a "current" alias at the top of the tree, > > so that one could make a better search. > > > I can kind of understand why xvile is there but I've never been able to > figure out why bubblewrap is mixed in. And if the search key is just xvile, > that is all that is returned. The search functionality could definitely be > improved. "vile" is a substring of "unprivileged", which appears in the description of bubblewrap. (I use symbolic links on my website; a "current" on slackbuilds.org would help) -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Slackbuild URL
On Mon, Mar 04, 2024 at 11:08:11AM -0500, lists-vile--- via discussions concerning the vile text editor wrote: > Thomas, > > On the mail vile page, https://www.invisible-island.net/vile/vile.html, the > Slackbuild that is referenced is out of date. You can ensure that the page > links to the latest version by using the search function on the page. > > https://slackbuilds.org/result/?search=vile that works, though not elegant: it gives me both vile and xvile -- and bubblewrap It would be nice if there were a "current" alias at the top of the tree, so that one could make a better search. -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
ANN: vile-9.8z
Files: https://invisible-island.net/archives/vile/current/vile-9.8z.tgz https://invisible-island.net/archives/vile/current/vile-9.8z.tgz.asc https://invisible-island.net/archives/vile/patches/MD5sums https://invisible-island.net/archives/vile/patches/vile-9.8z.patch.gz https://invisible-island.net/archives/vile/patches/vile-9.8z.patch.gz.asc https://invisible-island.net/archives/vile/patches/vile-9.8z.patch.gz patch by Thomas E. Dickey created Sun Jan 21 23:46:42 UTC 2024 -- CHANGES | 24 MANIFEST |2 aclocal.m4 | 353 +- bind.c |4 builtflt.c | 15 charsets.c |8 config.guess | 63 config.sub | 222 + configure| 6187 +++-- configure.in | 20 curses.c | 114 display.c| 22 doc/vile-hlp.html|4 doc/vile-man.html|2 doc/vile-toc.html|4 eightbit.c | 42 estruct.h|7 eval.c |4 filters/ini-filt.l |4 filters/key-filt.c | 41 filters/makefile.in |4 filters/manfilt.c|4 filters/md-filt.l|7 filters/nmakeflt.l |4 main.c | 149 - makefile.in |4 ntwinio.c|4 package/convile.nsi |8 package/debian/changelog |6 package/minvile.nsi |8 package/vile.spec| 19 package/winvile.iss |4 package/winvile.nsi |6 patchlev.h |4 proto.h | 14 revlist | 88 tcap.c | 32 tcap.h | 12 trace.c | 24 vile.1 | 12 vile.hlp |7 w32info.rc | 12 wcwidth.c| 675 xftplain.c |4 44 files changed, 4712 insertions(+), 3541 deletions(-) -- 20240121 (z) > Tom Dickey: + modify configure script to check validity of $IMAKE_LOADFLAGS + modify curses driver to work around configurations of ncurses where the SIGWINCH handler has been disabled. + modify vl_get_encoding() to allow for nl_langinfo(CODESET) returning an empty string, recover from this error using checks on the locale variable (report by David Snyder). + updated wcwidth.c, from xterm #389 + modify spec-file to work around a bug in make 4.4.1 + reduce compiler-warnings in configure script checks. + disallow newline in quoted string in ini filter. + adjust dlsym lookup to account for special case of define_key, to avoid conflict with ncurses. + fix mandoc warnings in vile.1 + fix a use-after-free in parse_nondirective() due to free() in the actual_color() function of key-filt.c + change VIDEO_TEXT type to "unsigned", allowing display of Unicode values past BMP for drivers which support this. + modify curses configuration to handle ncurses KEY_RESIZE (prompted by discussion with Sebastian Neuper). + fix typo in cross-compile check in CF_KILLPG macro (Debian #1029956) + update config.guess, config.sub -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Build errors on Centos Stream Release 9
On Wed, Dec 27, 2023 at 11:32:15AM -0500, Brian O'Shea wrote: > Has anybody successfully built on Centos 9? actually I hadn't done anything with Centos 9 (had looked at upgrading a Centos 8 Stream to Centos 9 early this year, but -- on VirtualBox 6 -- found that didn't work). however... a new install of Centos 9 (with VirtualBox 7...) and checking on the build - nothing "unusual". But I built from current source, which includes fixes for the compiler warning "improvements" introduced this year, which break configure scripts. https://github.com/ThomasDickey/vile-snapshots doing that, I was able to build rpms with the perl extension. > Any pointers you can share? > > I haven’t spent much time other than to run config and make, when that > didn’t work immediately I had to put it on the back burner until I have > more time. > > Thanks! -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Encoding translation error on macOS Sonoma 14.2
On Fri, Dec 15, 2023 at 05:41:10PM -0700, David Snyder wrote:
> Not the correct solution, but I was able to get vile to work on macOS
> Sonoma with this change:
>
> $ git diff
> diff --git a/eightbit.c b/eightbit.c
> index f5b0b158..24e9f617 100644
> --- a/eightbit.c
> +++ b/eightbit.c
> @@ -616,6 +616,7 @@ vl_get_encoding(char **target, const char *locale)
> } else {
> #ifdef HAVE_LANGINFO_CODESET
> result = nl_langinfo(CODESET);
> + result = utf_eight;
> #else
> if (vl_is_utf8_encoding(locale)) {
> result = utf_eight;
>
> For some reason, nl_langinfo(CODESET) returns an empty string when locale
> is "en_US"
"en_US" would be ISO-8859-1
Actually I'd expect "en_US.UTF-8", since that's what locale shows me on
a command-line (in Ventura). If Apple removed the data for non-Unicode
locales, I suppose it could return an empty string.
I dimly recall some long-ago discussion of how Apple sets the locale,
but in the settings I see only "English (US) -- Primary" for the
Language & Region
This still applies to Ventura (perhaps your problem):
https://blog.remibergsma.com/2012/07/10/setting-locales-correctly-on-mac-osx-terminal-application/
or it may be in your /etc/profile (I don't see it there):
https://stackoverflow.com/questions/7165108/in-os-x-lion-lang-is-not-set-to-utf-8-how-to-fix-it
> * thread #1, queue = 'com.apple.main-thread', stop reason = step over
> frame #0: 0x00010007ecd4
> vile`vl_get_encoding(target=0x0001000cc1c8, locale="en_US") at
> eightbit.c:618:11 [opt]
>615 endofDisplay();
>616} else {
>617 #ifdef HAVE_LANGINFO_CODESET
> -> 618 result = nl_langinfo(CODESET);
>619 result = utf_eight;
>620 #else
>621 if (vl_is_utf8_encoding(locale)) {
> Target 0: (vile) stopped.
> (lldb) p (char *) nl_langinfo(0)
> (char *) 0x00018b435db8 ""
>
> Hope this helps you work out a proper solution.
>
>
> On Fri, Dec 15, 2023 at 4:15 PM David Snyder wrote:
>
> > Not surprisingly, installing vile via Homebrew produces the same results.
> >
> > ==> Downloading https://ghcr.io/v2/homebrew/core/vile/manifests/9.8y
> > #
> > 100.0%
> > ==> Fetching vile
> > ==> Downloading
> > https://ghcr.io/v2/homebrew/core/vile/blobs/sha256:9c04feee9958f
> > #
> > 100.0%
> > ==> Pouring vile--9.8y.arm64_sonoma.bottle.tar.gz
> > /opt/homebrew/Cellar/vile/9.8y: 223 files, 7.9MB
> > ==> Running `brew cleanup vile`...
> > Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
> > Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
> > $ vile
> > Cannot setup translation from to UTF-8
> >
> > On Fri, Dec 15, 2023 at 9:24 AM David Snyder
> > wrote:
> >
> >> Hi Thomas,
> >>
> >> Thanks for your reply. I was hoping that would work, but no luck so far:
> >>
> >> $ LC_ALL=en_US.UTF-8 vile
> >> Cannot setup translation from to UTF-8
> >>
> >> It seems odd that vl_narrow_enc.encoding is *empty* in the error message
> >> above.
> >>
> >> For locale, I see the same as you:
> >>
> >> $ locale -a | wc -l
> >> 203
> >>
> >> Output of locale:
> >>
> >> $ locale
> >> LANG="en_US.UTF-8"
> >> LC_COLLATE="en_US.UTF-8"
> >> LC_CTYPE="en_US.UTF-8"
> >> LC_MESSAGES="en_US.UTF-8"
> >> LC_MONETARY="en_US.UTF-8"
> >> LC_NUMERIC="en_US.UTF-8"
> >> LC_TIME="en_US.UTF-8"
> >> LC_ALL=
> >>
> >> However, as I showed above, even explicitly setting LC_ALL has no effect:
> >>
> >> $ export LC_ALL="en_US.UTF-8"
> >> $ locale
> >> LANG="en_US.UTF-8"
> >> LC_COLLATE="en_US.UTF-8"
> >> LC_CTYPE="en_US.UTF-8"
> >> LC_MESSAGES="en_US.UTF-8"
> >> LC_MONETARY="en_US.UTF-8"
> >> LC_NUMERIC="en_US.UTF-8"
> >> LC_TIME="en_US.UTF-8"
> >> LC_ALL="en_US.UTF-8"
> >>
> >> $ vile
> >> Cannot setup translation from to UTF-8
> >>
> >>
> >> On Thu, Dec 14, 2023 at 6:44 PM Thomas Dickey wrote:
> >>
> >>> - Original Message -
> >>> | From: "David Snyder"
> >>> | To: "Vile mai
Re: Encoding translation error on macOS Sonoma 14.2
- Original Message -
| From: "David Snyder"
| To: "Vile mailing list"
| Sent: Thursday, December 14, 2023 7:51:46 PM
| Subject: Encoding translation error on macOS Sonoma 14.2
| After upgrading to macOS Sonoma 14.2 (MacBook Pro with Apple M1 Pro
| processor), I can't seem to get vile to run. Even after a fresh build, I
| see the following error:
hmm - I've 3 macs that I intend upgrading to Sonoma, but as usual put it off.
One is an M2 (the others are Intel). Those are all on Ventura, and locales
work.
"locale -a |wc -l" lists 203 settings.
What does "locale" print for your environment?
The message indicates that there's no locale set.
If Apple's lobotomized locale support, you might just as well set
LC_ALL=en_US.UTF-8
(that would probably even work with something like OpenBSD).
|
| $ vile
| Cannot setup translation from to UTF-8
|
| Looking at the source I see this function in eightbit.c:
|
| static void
| open_encoding(char *from, char *to)
| {
|if (!try_encoding(from, to)) {
|fprintf(stderr, "Cannot setup translation from %s to %s\n", from,
| to);
|tidy_exit(BADEXIT);
|}
| }
|
| I also tried rebuilding using --with-locale:
|
| $ ./configure -v --with-locale
|
| Unfortunately, the same result. Also, this is on an M1 MacBook Pro, so I
| don't have gdb handy.
|
| Compiling using --with-trace, I see these warnings, which look
| disconcerting:
|
| trace.c:488:59: warning: overflow in expression; result is 2147483647 with
| type 'int' [-Winteger-overflow]
|int c = buffer[j] & ((1 << (8 * sizeof(VIDEO_TEXT))) - 1);
| ^
| trace.c:488:30: warning: shift count >= width of type
| [-Wshift-count-overflow]
|int c = buffer[j] & ((1 << (8 * sizeof(VIDEO_TEXT))) - 1);
|^
|
| Hoping someone with better development tools on Apple silicon can reproduce
| this issue and provide more helpful debugging info. Thanks.
|
| -- David
--
Thomas E. Dickey
https://invisible-island.net
Re: How to access vile variables in : command?
On Wed, Nov 08, 2023 at 03:51:37PM +, 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? rather than map, doing a bind (to a stored macro) would work. #9 is treated as function-key 9, and by default is bound to the name execute-macro-9 (seen using describe-key): "execute-macro-9" #-9 untested (does pdf echo the name of the file? - I checked with just "echo"), but to give some idea how to organize it: 9 store-macro " make a buffer to get the output of pdf kill-buffer pdf-output edit-file "!pdf " $pathname rename-buffer pdf-output " cursor is at the beginning of the line; open that file find-file $pathname " dispose of the temporary buffer kill-buffer pdf-output ~endm -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Can one build a static vile easily?
On Wed, Jul 12, 2023 at 10:44:09AM +0100, Chris Green wrote: > Is there any way to build a 'static' version of vile fairly easily? > ... or a way to create something like an appimage? a "static" version would include the C runtime (and curses/termcap/whatever), which is a lot of work. Without doing that, I'd configure/build vile on a system with a compatible C runtime, etc., using --with-builtin-filters, and tar/zip the result (with whatever is needed to set the startup-path). -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: What do these entries in 'show-commands' mean?
- Original Message - | From: "Chris Green" | To: "Vile mailing list" | Sent: Saturday, May 13, 2023 5:05:22 AM | Subject: What do these entries in 'show-commands' mean? | In the 'show-commands' output there are entries like the following:- | | "edit-file" ^X-e | or"E" | or"e" | or"find-file" | ( bring given (or under-cursor) file or existing buffer into window ) | | I know that CTRL-X plus e opens the file under the cursor for editing, | but what do the other entries mean? Ah, I think I understand, | "edit-file", "E", "e" and "find-file" are effectively 'synonymns' for | the same action (they can be entered at the : prompt). ^X-e invokes | that command from command mode. | | | Is there an easy way to list all the single character command-mode keys? there's no single command that would do this, but since the display is generated (consistent format), one could write a script to format it differently. -- Thomas E. Dickey https://invisible-island.net
Re: What actually are hypertext commands in vile?
On Sat, May 13, 2023 at 02:01:41PM +0100, Chris Green wrote: > While, just now, mucking about in my .vilerc I saw the hypertext macro > that has been there for ages (copied from help):- > > 22 store-macro > ~force execute-hypertext-command > ~if $status > ~force forward-character-to-eol > ~endif > ~endm > bind-key execute-macro-22 ' ' > > So what does vile understand/see as a hypertext link? I tried a few > possibles (http://, file://) but nothing actually appeared to do > anything. Only file:// would seem to make any sense as a file to go > to and edit. Maybe I'm misunderstanding what it's supposed to do > (very likely!). It's only used for vile's commands (no web browser). "execute-hypertext-command" ^X-z ( run the hypertext command attached to the region under the cursor ) Kevin added that stuff a while back: (kev) 980403 (p) + vile.hlp: Added new sections "Writing your own filters" and "Hypertext". + x11.c (multi_click): Added code to execute hypertext command, when present, on a double click. > Just curious really, I can't think of an application for me at the > moment. > > -- > Chris Green > -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Closing completed files when editing many
On Wed, Mar 22, 2023 at 05:20:06AM +, James Haggerty wrote: > Hi, > > One of the things I usually do with editors is go through a number of > files making related edits. e.g. > > vile a.c b.c c.c > > I would have assumed the natural way to do this in vile would be to > remove the current buffer when I've finished with it, but there appears vi's :n walks through to the "next" buffer. The "autobuffer" mode (see help) controls the order in which "next" will go. > to be no default key binding for this. I'd have to either use * and ^X-k, > or use :ki and name the buffer/file. Is this correct? This makes me > think I'm approaching the problem in the wrong way for vile. you could do :ki *.c or (in the buffer list), use a repeat-count with ^X-k, e.g., putting the cursor on the "0", do 2 ^X k SizeBuffer name Contents --- - 0# 811 a.c ./a.c 1 811 b.c ./b.c 2 968 mutt-prl-debianold-6 /var/tmp/mutt-prl-debianold-64-1001-4271-12414928227669892054 3 811 c.c ./c.c Current dir: /tmp -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Lsp client
On Sun, Mar 19, 2023 at 07:31:50PM +0100, Thomas Gustafsson wrote: > Hi, > > Has anyone developed a Language Server Protocol client in vile? In such a > case, which lsp servers has it been tested against? If not, would it be > possible to develop an lsp client in vile? I'm not aware of anything here - looks like a fair amount of work. https://microsoft.github.io/language-server-protocol/overviews/lsp/overview/ https://microsoft.github.io/language-server-protocol/implementors/servers/ https://microsoft.github.io/language-server-protocol/implementors/tools/ ...aside from NetBeans (not recent), I've had no problems (so far) executing vile/xvile/winvile from an IDE. patches will be duly considered - but see https://invisible-island.net/personal/self-service.html -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Vileserv on macOS issue
On Thu, Jan 12, 2023 at 03:56:13AM -0500, Thomas Dickey wrote: > On Wed, Dec 21, 2022 at 03:08:48PM +1100, Brendan O'Dea wrote: > > 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. fwiw, I can reproduce this. > I haven't gotten to this either - I'm currently investigating Chris Green's > report, expecting to complete that this week (so far, looks like a small > change to map.c which could be applied to 9.8x in Debian). > > Perhaps I'll do something with this as well. I did take a look at this, yesterday, but it "just worked" for me. However, that is on macOS 12.6.2 (Monterey) - a machine that I'll upgrade to Ventura "soon". I'm generally using MacPorts - the initial report here doesn't seem to tell me whether it's only XCode or +MacPorts or +brew. I have a couple of older Macs which stop at High Sierra. Perhaps I can retest on those, e.g., upgrading the MacOS port. Speaking of that, it seems that it might improve things to add a perl variant to the port (to make building this more predictable). https://guide.macports.org/chunked/reference.variants.html However, my ongoing updates to configure scripts have taken a lot of time... -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
ANN: vile-9.8y
Files: https://invisible-island.net/archives/vile/current/vile-9.8y.tgz https://invisible-island.net/archives/vile/current/vile-9.8y.tgz.asc https://invisible-island.net/archives/vile/patches/MD5sums https://invisible-island.net/archives/vile/patches/vile-9.8y.patch.gz https://invisible-island.net/archives/vile/patches/vile-9.8y.patch.gz.asc https://invisible-island.net/archives/vile/patches/vile-9.8y.patch.gz patch by Thomas E. Dickey created Mon Jan 16 01:37:21 UTC 2023 -- CHANGES | 15 MANIFEST |2 aclocal.m4 | 168 - bind.c |6 configure| 5360 ++--- configure.in | 17 display.c|8 doc/vile-hlp.html|4 doc/vile-toc.html|4 fences.c |4 filters/filters.h|5 filters/genmake.sh | 12 glob.c |4 input.c |5 macros/vile-libdir-path | 27 makefile.in |4 map.c| 26 modetbl |6 ntwinio.c|4 package/convile.nsi |8 package/debian/changelog |6 package/debian/rules |2 package/minvile.nsi |8 package/vile.spec|9 package/winvile.iss |4 package/winvile.nsi |6 patchlev.h |4 perl.xs |5 revlist | 70 statevar.c | 10 version.sh | 10 vile.hlp |6 w32info.rc | 12 x11.c| 16 xshell.sh| 10 35 files changed, 3006 insertions(+), 2861 deletions(-) -- 20230115 (y) > Tom Dickey: + build-fixes for --disable-extensions and --disable-shell configure options. + amend fix for 9.8w change to map.c, so that both UTF-8 in scripts as well as interactive insertions of UTF-8 are handled (report by Chris Green). + reduce compiler warnings in configure script checks. + modify CF_RESTARTABLE_PIPEREAD to include , if found, to prototype wait() (Redhat #2158163). + improve configure macros CF_CURSES_TERMCAP, CF_TERMCAP_LIBS, and CF_XOPEN_SOURCE. + fix shellcheck warnings in version.sh and xshell.sh + add pattern to vile-libdir-path to allow for Debian multiarch. -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: However accented characters are still rather broken
On Mon, Jan 02, 2023 at 08:33:05PM -0500, Thomas Dickey wrote:
> On Mon, Jan 02, 2023 at 03:27:20PM -0500, Thomas Dickey wrote:
> > On Mon, Jan 02, 2023 at 11:23:54AM +, Chris Green wrote:
> > > So, after partially understanding the syntax highlighting issue I now
> > > see that entering accented characters is still broken.
> > >
> > > As reported a while ago vile 9.8v gets confused when you try to enter
> > > accented characters (I use a Multi_key, so to enter, for example an e
> > > with an acute accent I hit Multi_key, e, ').
> > >
> > > On vile 9.8u (and earlier, I've checked 9.8t too) entering accented
> > > characters with the Multi_key works perfectly. On 9.8v (as reported)
> > > on entering an accented character an odd backslash sequence is echoed
> > > and it's not the character entered.
> > >
> > > On vile 9.8w (from the Ubuntu repository) entering an accented
> > > character does nothing if you enter just one accented character but if
> > > you enter a second accented character that *does* get added. This
> > > continues, entering a series of accented characters every other one
> > > actually gets inserted.
>
> fwiw, this was introduced at the time that I fixed this bug:
>
> 20220805 (w)
> + revise change for lins_chars() to handle UTF-8 in scripts, as that
> interfered with normal insertions (report by Chris Green).
>
> and the "odd backslash" was from an earlier change to the same code:
>
> + modify lins_chars() to handle a case where a script inserts a UTF-8
> character (report by Thomas Dupond).
>
> I think I'll have time later this week to re-revisit this (and make both
> scripts and interactive editing work at the same time).
see attached (9.8y will have other changes, but this is the small fix)
--
Thomas E. Dickey
https://invisible-island.net
--- vile-9.8x+/map.c 2022-12-23 00:32:02.0 +
+++ vile-9.8y/map.c 2023-01-13 08:51:24.0 +
@@ -923,6 +926,18 @@
}
do {
+ /*
+ * This is a workaround for an ambiguity between the different return
+ * values from mapgetc(), on entry to this function:
+ * - If infloopcount is zero, mapgetc() has just called tgetc(), which
+ * in turn called sysmapped_c(), and then term.getc(). That pointer
+ * is initialized to vl_mb_getch(), which will decode UTF-8 into a
+ * Unicode value.
+ * - If infloopcount is nonzero, the function returns a byte (of UTF-8),
+ * which must be decoded later in this function.
+ */
+ int full_c = (infloopcount == 0); /* tgetc returned full char? */
+
(void) itb_init(, esc_c);
matched = maplookup(c,
@@ -949,7 +966,7 @@
c = mapgetc();
#if OPT_MULTIBYTE
- if (vl_encoding >= enc_UTF8 && b_is_utfXX(curbp)) {
+ if (remap && !full_c && (vl_encoding >= enc_UTF8 && b_is_utfXX(curbp))) {
char save[MAX_UTF8];
int have = 0;
int need = 9;
signature.asc
Description: PGP signature
Re: Vileserv on macOS issue
On Wed, Dec 21, 2022 at 03:08:48PM +1100, Brendan O'Dea wrote: > 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. I haven't gotten to this either - I'm currently investigating Chris Green's report, expecting to complete that this week (so far, looks like a small change to map.c which could be applied to 9.8x in Debian). Perhaps I'll do something with this as well. -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: However accented characters are still rather broken
On Mon, Jan 02, 2023 at 03:27:20PM -0500, Thomas Dickey wrote: > On Mon, Jan 02, 2023 at 11:23:54AM +, Chris Green wrote: > > So, after partially understanding the syntax highlighting issue I now > > see that entering accented characters is still broken. > > > > As reported a while ago vile 9.8v gets confused when you try to enter > > accented characters (I use a Multi_key, so to enter, for example an e > > with an acute accent I hit Multi_key, e, '). > > > > On vile 9.8u (and earlier, I've checked 9.8t too) entering accented > > characters with the Multi_key works perfectly. On 9.8v (as reported) > > on entering an accented character an odd backslash sequence is echoed > > and it's not the character entered. > > > > On vile 9.8w (from the Ubuntu repository) entering an accented > > character does nothing if you enter just one accented character but if > > you enter a second accented character that *does* get added. This > > continues, entering a series of accented characters every other one > > actually gets inserted. fwiw, this was introduced at the time that I fixed this bug: 20220805 (w) + revise change for lins_chars() to handle UTF-8 in scripts, as that interfered with normal insertions (report by Chris Green). and the "odd backslash" was from an earlier change to the same code: + modify lins_chars() to handle a case where a script inserts a UTF-8 character (report by Thomas Dupond). I think I'll have time later this week to re-revisit this (and make both scripts and interactive editing work at the same time). -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Start again with syntax highlighting problem
- Original Message - | From: "Gary Jennejohn" | To: "Vile mailing list" | Sent: Monday, January 2, 2023 3:02:03 PM | Subject: Re: Start again with syntax highlighting problem | On Mon, 2 Jan 2023 14:17:43 -0500 | Thomas Dickey wrote: | |> On Mon, Jan 02, 2023 at 10:45:14AM +, Chris Green wrote: |> > OK, restart, I think I now see a pattern in this. I completely |> > removed and re-installed vile from the Ubuntu repositories on esprimo |> > and it is now working correctly there. I had modified it there |> > because of the issue a while ago with UTF8 characters. So the table |> > is now as follows:- |> > |> > backup xubuntu 22.10 vile 9.8w colour OK, but not right |> > bison Android 11 vile 9.8w colour OK, but not right |> > caracal Debian 10 vile 9.8no colour syntax |> > cheddar Debian 10 vile 9.8t colour OK |> > esprimo xubuntu 22.04 vile 9.8v colour OK |> > isbdUbuntu 20.04vile 9.8t colour OK |> > odinDebian 9vile 9.8s colour OK |> > pimedia Debian 11 vile 9.8u colour OK |> > t470xubuntu 22.10 vile 9.8w colour OK, but not right |> > tsohost very oldvile 9.8no colour syntax |> > |> > |> > This makes *much* more sense! :-) The systems with versions older |> > than vile9.8w do syntax highlighting OK. The two systems where I |> > built vile myself and installed as a user (no root access) don't do |> > syntax highlighting but thati's almost certainly something I have |> > missed out in the build and it's not so important there anyway. |> > |> > So, the question is why the syntax highlighting of vilemode for |> > version 9.8w is messed up. It's not badly wrong, it gets the colour |> |> I made an incorrect bug-fix in 9.8w for vilemode, which is fixed in 9.8x |> |> This was the change (reverting it will fix the bug): |> |> @@ -17,7 +17,7 @@ |> |> #define FLTSTACK_EXTRA int with_state; int with_active; |> #define FltStack_WITH_STATE FLTSTACK_THIS.with_state |> -#define FltStack_WITH_ACTIVE FLTSTACK_THIS.with_state |> +#define FltStack_WITH_ACTIVE FLTSTACK_THIS.with_active |> #include |> |> #if defined(_estruct_h) && !SMALLER |> | | This is peculiar. In my 9.8w code (FreeBSD) this error is not present. The tarballs and patches should match the snapshots that I export to Git: https://github.com/ThomasDickey/vile-snapshots/commit/49e69b2a9c24709e8dc6534842c531f036fc6ef5#diff-2f62c16021dc47a5af4606a274a77fe2684bb704641a215e2c7147e8e7d8c362 |> > of comments right throughout but gets confused about keyword colours |> > and within some 'map' settings. As far as I can see on other file |> > types (shell scripts, python, C) version 9.8w gets the highlighting |> > correct so it does look like just an error in the vilemode |> > highlighting. |> > |> > Has the vile-filt-filt file changed between 9.8v and 9.8w? -- Thomas E. Dickey https://invisible-island.net
Re: However accented characters are still rather broken
On Mon, Jan 02, 2023 at 11:23:54AM +, Chris Green wrote:
> So, after partially understanding the syntax highlighting issue I now
> see that entering accented characters is still broken.
>
> As reported a while ago vile 9.8v gets confused when you try to enter
> accented characters (I use a Multi_key, so to enter, for example an e
> with an acute accent I hit Multi_key, e, ').
>
> On vile 9.8u (and earlier, I've checked 9.8t too) entering accented
> characters with the Multi_key works perfectly. On 9.8v (as reported)
> on entering an accented character an odd backslash sequence is echoed
> and it's not the character entered.
>
> On vile 9.8w (from the Ubuntu repository) entering an accented
> character does nothing if you enter just one accented character but if
> you enter a second accented character that *does* get added. This
> continues, entering a series of accented characters every other one
> actually gets inserted.
I hadn't noticed this, but can reproduce it (with 9.8x, and in a quick
test with empty .vilerc, the same). Attaching a debug trace with 6
keypresses, 3 characters inserted.
--
Thomas E. Dickey
https://invisible-island.net
| old_locale 'en_US.UTF-8'
| called {{ vl_get_encoding(en_US.UTF-8)
| return }} UTF-8
| system getenv LC_ALL=en_US.UTF-8
| Checking for UTF-8 suffix of 'en_US.UTF-8'
| called {{ vl_narrowed(en_US.UTF-8)
| system getenv VILE_LOCALE_MAPPING=
| regparser {/\.\(UTF\|utf\)[-]\?8$//}
| ...regparser {\.\(UTF\|utf\)[-]\?8$}
| regparser {//}
| ...regparser {}
| regcomp("\\.\\(UTF\\|utf\\)[-]\\?8$", magic)
| after regmassage: '\\.(UTF|utf)[-]?8$'
| vl_narrowed match ".UTF-8", replace with ""
| return }} en_US
| called {{ vl_init_8bit(en_US.UTF-8, en_US)
| setup mixed-locale(en_US.UTF-8, en_US)
| called {{ vl_get_encoding(en_US.UTF-8)
| | return }} UTF-8
| called {{ vl_get_encoding(en_US)
| | return }} ISO-8859-1
| ...locale encodings(UTF-8, ISO-8859-1)
| try_encoding(from=ISO-8859-1, to=UTF-8) OK
| fixed-up 0 of 256 8bit/utf8 mappings
| assume 256 Latin1 codes
| return }}
| setlocale(en_US) -> 'en_US'
| called {{ vl_get_encoding(en_US)
| return }} ISO-8859-1
| called {{ vl_ctype_init() lo=0, hi=0
| wide_locale:en_US.UTF-8
| narrow_locale:en_US
| current_locale:en_US
| Forcing printable for [128..min(-1,255)]
| return }}
| called {{ global_val_init()
| regcomp("\\(\\[\\([!]\\?[[:print:]]\\+\\)\\]\\)\\|\\([[:ident:].-]\\+\\)",
magic)
| after regmassage: '(\\[([!]?[[:print:]]+)\\])|([[:ident:].-]+)'
| regcomp("^\\s*\\(\\(\\s*[#*>]\\)\\|\\(///*\\)\\)\\+", magic)
| after regmassage: '^\\s*((\\s*[#*\\>])|(///*))+'
| regcomp("^\\s*/\\?\\(\\s*[#*>/]\\)\\+/\\?\\s*$", magic)
| after regmassage: '^\\s*/?(\\s*[#*\\>/])+/?\\s*$'
| regcomp("/\\*", magic)
| after regmassage: '/\\*'
| regcomp("^\\s*#\\s*elif\\>", magic)
| after regmassage: '^\\s*#\\s*elif>'
| regcomp("^\\s*#\\s*else\\>", magic)
| after regmassage: '^\\s*#\\s*else>'
| regcomp("\\*/", magic)
| after regmassage: '\\*/'
| regcomp("^\\s*#\\s*endif\\>", magic)
| after regmassage: '^\\s*#\\s*endif>'
| regcomp("^\\s*#\\s*if", magic)
| after regmassage: '^\\s*#\\s*if'
| regcomp("\\w\\+", magic)
| after regmassage: '\\w+'
| regcomp("\\(\\.orig\\|~\\)$", magic)
| after regmassage: '(\\.orig|~)$'
|
regcomp("^\\.[ILPQ]P\\>\\|^\\.P\\>\\|^\\.LI\\>\\|^\\.[plinb]p\\>\\|^\\.\\?\\s*$",
magic)
| after regmassage: '^\\.[ILPQ]P>|^\\.P>|^\\.LI>|^\\.[plinb]p>|^\\.?\\s*$'
| regcomp("[[:file:]]\\+", magic)
| after regmassage: '[[:file:]]+'
|
set_buf_fname_expr(\(\(\[\([!]\?[[:print:]]\+\)\]\)\|\([[:ident:].-]\+\)\|[[:file:]]\+\))
|
regcomp("\\(\\(\\[\\([!]\\?[[:print:]]\\+\\)\\]\\)\\|\\([[:ident:].-]\\+\\)\\|[[:file:]]\\+\\)",
magic)
| after regmassage: '((\\[([!]?[[:print:]]+)\\])|([[:ident:].-]+)|[[:file:]]+)'
| regcomp("^[{^L]\\|^\\.[NS]H\\>\\|^\\.HU\\?\\>\\|^\\.[us]h\\>\\|^+c\\>", magic)
| after regmassage: '^[\\{^L]|^\\.[NS]H>|^\\.HU?>|^\\.[us]h>|^\\+c>'
| regcomp("[.!?][])"']* \\?$\\|[.!?][])"']*
\\|^\\.[ILPQ]P\\>\\|^\\.P\\>\\|^\\.LI\\>\\|^\\.[plinb]p\\>\\|^\\.\\?\\s*$",
magic)
| after regmassage: '[.!\\?][]\\)"']* ?$|[.!\\?][]\\)"']*
|^\\.[ILPQ]P>|^\\.P>|^\\.LI>|^\\.[plinb]p>|^\\.?\\s*$'
| set_state_variable(empty-lines,1)
| ...set_state_variable ->1
| set_state_variable(filename-expr,[[:file:]])
| regcomp("[[:file:]]", magic)
| after regmassage: '[[:file:]]'
| ...set_state_variable ->1
| vile getenv VILE_HELP_FILE=
| set_state_variable(helpfile,vile.hlp)
| ...set_state_variable ->1
|
set_state_variable(latin1-expr,^\(aa\|af\|br\|de\|en\|es\|fr\|fi\|ga\|gb\|gl\|gv\|id\|it\|kl\|ms\|nl\|nn\|om\|pt\|so\|sv\|tl\)_[A-Za-z]\+$)
|
regcomp("^\\(aa\\|af\\|br\\|de\\|en\\|es\\|fr\\|fi\\|ga\\|gb\\|gl\\|gv\\|id\\|it\\|kl\\|ms\\|nl\\|nn\\|om\\|pt\\|so\\|sv\\|tl\\)_[A-Za-z]\\+$",
magic)
| after regmassage:
'^(aa|af|br|de|en|es|fr|fi|ga|gb|gl|gv|id|it|kl|ms|nl|nn|om|pt|so|sv|tl)_[A-Za-z]+$'
| called {{ vl_init_8bit(en_US.UTF-8, en_US)
| | setup mixed-locale(en_US.UTF-8, en_US)
| | called {{ vl_get_encoding(en_US.UTF-8)
| | | return
Re: Start again with syntax highlighting problem
On Mon, Jan 02, 2023 at 10:45:14AM +, Chris Green wrote: > OK, restart, I think I now see a pattern in this. I completely > removed and re-installed vile from the Ubuntu repositories on esprimo > and it is now working correctly there. I had modified it there > because of the issue a while ago with UTF8 characters. So the table > is now as follows:- > > backup xubuntu 22.10 vile 9.8w colour OK, but not right > bison Android 11 vile 9.8w colour OK, but not right > caracal Debian 10 vile 9.8no colour syntax > cheddar Debian 10 vile 9.8t colour OK > esprimo xubuntu 22.04 vile 9.8v colour OK > isbdUbuntu 20.04vile 9.8t colour OK > odinDebian 9vile 9.8s colour OK > pimedia Debian 11 vile 9.8u colour OK > t470xubuntu 22.10 vile 9.8w colour OK, but not right > tsohost very oldvile 9.8no colour syntax > > > This makes *much* more sense! :-) The systems with versions older > than vile9.8w do syntax highlighting OK. The two systems where I > built vile myself and installed as a user (no root access) don't do > syntax highlighting but thati's almost certainly something I have > missed out in the build and it's not so important there anyway. > > So, the question is why the syntax highlighting of vilemode for > version 9.8w is messed up. It's not badly wrong, it gets the colour I made an incorrect bug-fix in 9.8w for vilemode, which is fixed in 9.8x This was the change (reverting it will fix the bug): @@ -17,7 +17,7 @@ #define FLTSTACK_EXTRA int with_state; int with_active; #define FltStack_WITH_STATE FLTSTACK_THIS.with_state -#define FltStack_WITH_ACTIVE FLTSTACK_THIS.with_state +#define FltStack_WITH_ACTIVE FLTSTACK_THIS.with_active #include #if defined(_estruct_h) && !SMALLER > of comments right throughout but gets confused about keyword colours > and within some 'map' settings. As far as I can see on other file > types (shell scripts, python, C) version 9.8w gets the highlighting > correct so it does look like just an error in the vilemode > highlighting. > > Has the vile-filt-filt file changed between 9.8v and 9.8w? > > -- > Chris Green > -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
Re: Syntax colour highlighting problem - not working on some of my systems
On Sun, Jan 01, 2023 at 08:02:31PM +, Chris Green wrote: > On Sun, Jan 01, 2023 at 06:13:07PM +, Chris Green wrote: > > The eternal problem > > > > On just *some* of my several Linux systems colour syntax higlighting > > isn't working. It always used to work but I really can't see what I > > might have changed on *some* systems to break it. > > > > The systems and versions and 'working or not' are:- > > > > backup xubuntu 22.10 vile 9.8w colour OK > > bison Android 11 vile 9.8w colour OK > > caracal Debian 10 vile 9.8no colour syntax > > cheddar Debian 10 vile 9.8t colour OK > > esprimo xubuntu 22.04 vile 9.8u no colour syntax > > isbdUbuntu 20.04vile 9.8t colour OK > > odinDebian 9vile 9.8s colour OK > > pimedia Debian 11 vile 9.8u colour OK > > t470xubuntu 22.10 vile 9.8w colour OK > > tsohost very oldvile 9.8no colour syntax > > > > Since esprimo is my main desktop system it's a bit annoying that > > syntax colouring isn't working there. > > > > On all systems 'show-colors' in vile works fine, so they're all > > *capable* of colour. The two systems showing just vile 9.8 are ones > > where I have built vile myself, so they have pretty recent code. > > > > All systems have the same .vilerc and it runs with no errors. So they > > all execute:- > > > > source filters.rc > > setv $autocolor-hook HighlightFilter > > setv $read-hook HighlightFilter > > set autocolor=500 > > set bcolor=default > > > > I'm stumped! Can anyone point me at some way to diagnose what's > > wrong? Could it (possibly) be something to do with built-in or > > external filters? If so, how do I tell whether vile was built with > > 'built-in' or not? > > > Just to add to the fun if I run xvile remotely across an 'ssh -Y' > connection to esprimo the syntax highlighting works OK. (that's > running xvile on esprimo from t470) > > This suggests to me that it's something to do with how vile was built > (it's the version from the repositories). vile's running in a terminal. I'd check if the terminal is configured for color: disregarding hard-coded stuff, the value of $TERM is used to select a terminal description. If it's "vt100" on some machines, that would explain. Running this from the command-line will show colors only if the terminal is configured: #!/bin/sh tput blink tput bold tput setab 1 tput setaf 4 printf "Hello-" tput setaf 1 tput setab 4 echo "world" tput sgr0 read aa -- Thomas E. Dickey https://invisible-island.net signature.asc Description: PGP signature
ANN: vile-9.8x
Files: https://invisible-island.net/archives/vile/current/vile-9.8x.tgz https://invisible-island.net/archives/vile/current/vile-9.8x.tgz.asc https://invisible-island.net/archives/vile/patches/MD5sums https://invisible-island.net/archives/vile/patches/vile-9.8x.patch.gz https://invisible-island.net/archives/vile/patches/vile-9.8x.patch.gz.asc https://invisible-island.net/archives/vile/patches/vile-9.8x.patch.gz patch by Thomas E. Dickey created Tue Dec 27 00:30:42 UTC 2022 -- CHANGES| 48 MANIFEST | 20 README | 18 README.PC |8 aclocal.m4 | 116 api.c |4 basic.c|6 bind.c | 18 cmdtbl |6 config.guess | 50 config.sub | 22 configure | 6063 +-- configure.in | 49 curses.c | 26 doc/macros.doc |6 doc/macros.html| 109 doc/makefile |3 doc/vile-hlp.html | 113 doc/vile-man.html | 121 doc/vile-toc.html |5 edef.h |4 filters/vilefilt.l |6 input.c|9 install-sh | 687 +- macros/uxvile |6 macros/vile-libdir-path|8 macros/vile-pager | 43 main.c | 54 map.c | 95 mktbls.c | 34 modetbl|5 package/convile.nsi|6 package/debian/changelog |6 package/debian/control | 29 package/debian/rules | 261 package/debian/vile-common.examples|1 package/debian/vile-common.files |5 package/debian/vile-filters.files |8 package/debian/vile.postinst |4 package/debian/vile.prerm |4 package/debian/xvile.files |3 package/freebsd/vile/Makefile |6 package/freebsd/vile/distinfo |6 package/freebsd/vile/pkg-plist |6 package/freebsd/xvile/Makefile |7 package/freebsd/xvile/distinfo |6 package/freebsd/xvile/pkg-plist|6 package/minvile.nsi|6 package/pkgsrc/vile/Makefile |9 package/pkgsrc/vile/PLIST |8 package/pkgsrc/vile/distinfo | 10 package/pkgsrc/xvile/Makefile |9 package/pkgsrc/xvile/PLIST |8 package/vile.spec | 11 package/winvile.iss|4 package/winvile.nsi|6 patchlev.h |4 proto.h|8 revlist| 155 statevar.c | 14 tcap.c | 16 trace.c|4 vile-9.8x/icons/pumpkin.ico|binary vile-9.8x/icons/sink.ico |binary vile-9.8x/icons/vile-mini.ico |binary vile-9.8x/icons/vile.ico |binary vile-9.8x/package/debian/vile-common.README.Debian | 11 vile-9.8x/package/openbsd/Makefile | 26 vile-9.8x/package/openbsd/distinfo |2 vile-9.8x/package/openbsd/patches/patch-crypt | 72 vile-9.8x/package/openbsd/pkg/DESCR|9 vile-9.8x/package/openbsd/pkg/PLIST| 138 vile.1 | 12 vile.hlp
Re: Build errors at link time - what am I missing?
- Original Message - | From: "Chris Green" | To: "Vile mailing list" | Sent: Wednesday, November 30, 2022 6:42:39 PM | Subject: Re: Build errors at link time - what am I missing? | On Wed, Nov 30, 2022 at 06:32:59PM -0500, Thomas Dickey wrote: |> On Wed, Nov 30, 2022 at 08:26:07PM +, Chris Green wrote: |> > On Wed, Nov 30, 2022 at 08:20:53PM +, Chris Green wrote: |> > > I'm trying to build vile-9.8 on a Debian system where I have a shared |> > > hosting account with ssh access. |> > > |> > > I'm doing "./configure --prefix=$HOME" and it runs OK but there are |> > > couple of warnings. |> > > |> > > Firstly it can't find a good lex so it says:- |> > > configure: WARNING: disabling build for lex-filters |> > > I don't think this is going to be an issue. |> > > |> > > 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? |> > > |> > 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? |> |> You need the development package. The runtime package has a similarly named |> library file. |> |> For example (Debian/oldstable) |> |> libtinfo6 has |> /usr/lib/x86_64-linux-gnu/libtic.so.6 |> |> libncurses-dev hs |> /usr/lib/x86_64-linux-gnu/libtinfo.so |> |> The plain ".so" is what development packages link with, e.g., -ltinfo |> | There's some .so files buried deep down:- | |chrisisbd@caracal:/usr/lib/x86_64-linux-gnu/zsh/5.7.1$ cd zsh |chrisisbd@caracal:/usr/lib/x86_64-linux-gnu/zsh/5.7.1/zsh$ ls |attr.so complist.so example.so nearcolor.so pcre.so system.so |zleparameter.so |cap.so computil.so files.so net regex.so termcap.so |zprof.so |clone.so curses.so langinfo.so newuser.sorlimits.so terminfo.so |zpty.so |compctl.so datetime.so mapfile.so param sched.sozftp.so |zselect.so |complete.so deltochar.so mathfunc.so parameter.so stat.so zle.so |zutil.so | | Will these allow me to build if I include that directory in the ld search path? | If so, how do I include that directory? | | If not then I guess I'll have to build ncurses as desribed in the E-Mail before. Brendan's advice is the way to go. -- Thomas E. Dickey http://invisible-island.net ftp://ftp.invisible-island.net
Re: Build errors at link time - what am I missing?
On Wed, Nov 30, 2022 at 08:26:07PM +, Chris Green wrote: > On Wed, Nov 30, 2022 at 08:20:53PM +, Chris Green wrote: > > I'm trying to build vile-9.8 on a Debian system where I have a shared > > hosting account with ssh access. > > > > I'm doing "./configure --prefix=$HOME" and it runs OK but there are > > couple of warnings. > > > > Firstly it can't find a good lex so it says:- > > configure: WARNING: disabling build for lex-filters > > I don't think this is going to be an issue. > > > > 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? > > > 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? You need the development package. The runtime package has a similarly named library file. For example (Debian/oldstable) libtinfo6 has /usr/lib/x86_64-linux-gnu/libtic.so.6 libncurses-dev hs /usr/lib/x86_64-linux-gnu/libtinfo.so The plain ".so" is what development packages link with, e.g., -ltinfo -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Always get two windows when using -c
On Sun, Nov 13, 2022 at 09:55:18PM +, Chris Green wrote: > On Sun, Nov 13, 2022 at 03:40:43PM -0500, Thomas Dickey wrote: > > On Sun, Nov 13, 2022 at 08:11:17PM +, Chris Green wrote: > > > On Sun, Nov 13, 2022 at 10:55:07AM -0500, Thomas Dickey wrote: > > > > On Sun, Nov 13, 2022 at 01:57:30PM +, Chris Green wrote: > > > > > This relates to my recent posting about trying to use the '-c' command > > > > > line option. However it's now a more general problem/question. > > > > > > > > > > Whenever I add a '-c command' (or a '+ command', or a '-g NNN') to the > > > > > command line vile opens two windows, the file I want is in the first > > > > > window and the following is in the second (lower) window:- > > > > > > > > > > [Reading /home/chris/.vilerc] > > > > > > > > perhaps your .vilerc doesn't set nopopup-msgs (or sets popup-msgs) > > > > > > > My .vilerc is:- > > > > > > > > ... > > > source digraphs.rc > > > > > > But it's happenning before reading .vilerc isn't it? > > > > no - it's happening because of the warning message: > > > > * If no warning messages were encountered during startup, and the > > popup-msgs > > * mode wasn't enabled, discard the informational messages that are there > > * already. > > > > you could do this > > > > vile -c goto-end-of-file > > > Ah! Thank you, that does what I need. > > However I'm still a little confused, when you say "it's happening > because of the warning message", am I getting a warning message? If > so, what is it? ... and can I stop it? The error message was this - "/home/chris/wiki/data/pages/boating/diary/2011/05/20.txt"] [Not that many lines in buffer: 20] > > Are you saying that "source digraphs.rc" is causing it? no :- > ... I've had a boozy supper just now on my birthday today so apologies > for confused/confusing replies. :-) > > -- > Chris Green > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Always get two windows when using -c
On Sun, Nov 13, 2022 at 08:11:17PM +, Chris Green wrote: > On Sun, Nov 13, 2022 at 10:55:07AM -0500, Thomas Dickey wrote: > > On Sun, Nov 13, 2022 at 01:57:30PM +, Chris Green wrote: > > > This relates to my recent posting about trying to use the '-c' command > > > line option. However it's now a more general problem/question. > > > > > > Whenever I add a '-c command' (or a '+ command', or a '-g NNN') to the > > > command line vile opens two windows, the file I want is in the first > > > window and the following is in the second (lower) window:- > > > > > > [Reading /home/chris/.vilerc] > > > > perhaps your .vilerc doesn't set nopopup-msgs (or sets popup-msgs) > > > My .vilerc is:- > > ... > source digraphs.rc > > But it's happenning before reading .vilerc isn't it? no - it's happening because of the warning message: * If no warning messages were encountered during startup, and the popup-msgs * mode wasn't enabled, discard the informational messages that are there * already. you could do this vile -c goto-end-of-file -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Always get two windows when using -c
On Sun, Nov 13, 2022 at 01:57:30PM +, Chris Green wrote: > This relates to my recent posting about trying to use the '-c' command > line option. However it's now a more general problem/question. > > Whenever I add a '-c command' (or a '+ command', or a '-g NNN') to the > command line vile opens two windows, the file I want is in the first > window and the following is in the second (lower) window:- > > [Reading /home/chris/.vilerc] perhaps your .vilerc doesn't set nopopup-msgs (or sets popup-msgs) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: vile source links
On Sat, Oct 22, 2022 at 01:42:21PM +, Wayne Cuddy via discussions concerning the vile text editor wrote: > On Fri, Oct 21, 2022 at 07:42:01PM -0400, Thomas Dickey wrote: > > On Fri, Oct 21, 2022 at 06:20:40PM +, Wayne Cuddy via discussions > > concerning the vile text editor wrote: > > > On the vile download page: > > > > > > https://www.invisible-island.net/vile/vile.html#download > > > > > > The links for the source downloads: > > > > > > https://www.invisible-island.net/archives/vile/vile.tar.gz > > > > > > https://www.invisible-island.net/datafiles/release/vile.tar.gz > > > > > > These both seem to point to the older 9.8 release instead of 9.8w. Is > > > this intentional? > > > > sort of (the versioning with letter suffixes seems to be acceptable to > > everyone -- though I recall quite a while ago a packager refusing to > > do anything with vile unless it ended ".0" -- and I've seen no real > > need recently for a "stable release"). > > > > "current" is where you should look: > > > > https://invisible-island.net/datafiles/current/vile.tar.gz > > https://invisible-island.net/archives/vile/current/vile.tar.gz > > https://invisible-island.net/archives/vile/current/ > > > > I totally ignored those links for some reason. Perhaps because they are > suffixed with (for installers). > > I'll make a note of that. sounds good (I'm working on several things currently, but one of the threads leads back to vile - will have to think how to better lay out the page). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: vile source links
On Fri, Oct 21, 2022 at 06:20:40PM +, Wayne Cuddy via discussions concerning the vile text editor wrote: > On the vile download page: > > https://www.invisible-island.net/vile/vile.html#download > > The links for the source downloads: > > https://www.invisible-island.net/archives/vile/vile.tar.gz > > https://www.invisible-island.net/datafiles/release/vile.tar.gz > > These both seem to point to the older 9.8 release instead of 9.8w. Is > this intentional? sort of (the versioning with letter suffixes seems to be acceptable to everyone -- though I recall quite a while ago a packager refusing to do anything with vile unless it ended ".0" -- and I've seen no real need recently for a "stable release"). "current" is where you should look: https://invisible-island.net/datafiles/current/vile.tar.gz https://invisible-island.net/archives/vile/current/vile.tar.gz https://invisible-island.net/archives/vile/current/ > Should I be using another link to access to latest source? > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: A somewhat off-topic question about ncurses and wrapping long lines
On Sun, Oct 02, 2022 at 09:22:03AM +0100, Chris Green wrote: > On Sat, Oct 01, 2022 at 06:35:26PM -0400, Thomas Dickey wrote: > > On Sat, Oct 01, 2022 at 10:01:00AM +0100, Chris Green wrote: > > > Well it's not entirely off topic, it's about something that works as > > > I'd expect it to in vile (and less) but doesn't work right in mutt (my > > > E-Mail program of choice). > > > > > > The issue is about how long chunks of text, with no spaces in them, > > > are wrapped when they are too long to fit in the terminal width. The > > > typical case (and the one that is a particular problem in mutt) is > > > that of long URLs. This *isn't* about how these programs manage > > > wrapping normal text made up of 'words' with spaces in between. > > > > > > In less or vile when there is a long piece of text and you have told > > > less/vile to wrap long lines then the long URL (or whatever) is > > > displayed wrapped at the right margin but it is still a single string > > > and you can select it in the terminal by right clicking on it. > > > > > > In mutt (in mutt's internal pager specifically) however, although the > > > URL is displayed the same (i.e. wrapped at the right margin) it's > > > actually broken into one or more lines and you *can't* select it by > > > right clicking on it, you just get the single line that you click on. > > > > > > This has been discussed at length at various times on the mutt mailing > > > list and hasn't been solved. > > > > I'm subscribed to mutt-dev (don't recall it there). > > Perhaps mutt-user... > > Yes, it's mutt-users. > > > > > (none of the mutt development gets very deep into this stuff) > > > > > Is there some specific way of using/calling ncurses which does what we > > > want? ... and/or does ncurses default to breaking the string at the > > > page margin and need some option to prevent it doing this? > > > > It's a special case of xterm (imitated by more than one terminal emulator, > > though probably not _all_). xterm notices when a line is written and > > wraps. Screen updates that simply write to the end of a line (including > > a previously "wrapped" line) make it forget about follow part of a line. > > > I sort of understand. So you're saying that it's the xterm (or > similar) that is inserting the LF after mutt has output a long string > using ncurses. When xterm is asked (by another client that wants to paste the selection) for the selection, it copies from its window the characters for the selected range of columns/lines. As it does that, it checks at the end of each line whether that was wrapped -- and adds a newline in that case. Double-clicking on a line does the same thing -- extending the selection to the entire (wrapped) line. The "wrapped" term in a half-dozen places in xterm's manpage is talking about this... > > less and vile have an advantage over ncurses in deciding if a line is > > wrapped -- ncurses can't tell if an application writes text (using one > > of the wrapping calls such as waddch) intending to construct a long line. > > > So vile and less manage the wrapping themselves whereas xterm does it > for mutt - is that the difference? no - vile and less just happen to work when they write a wrapped line. If they were smarter and only wrote the parts of lines that changed, then they wouldn't trigger the special handling in the terminal emulator that tells _it_ that this is one long line. > I thought vile used ncurses. vile (in a terminal) could be termcap, terminfo or curses :-) fwiw, it's terminfo in Debian, which makes vile doing the screen updates. (ncurses provides terminfo, but that's a low-level feature which is different from the higher-level stuff that mutt is using) > > Actually, long lines in mutt for me have a "+" marking the beginning > > of the following lines (which iirc is configurable). > > > I have "set nomarkers" in my muttrc which turns the + off. At least > one can then manually select the long URL and paste it into a browser > address bar (as long as the browser, correctly, inores the embedded > LF). However right-clicking the URL would be much handier. agreed, but without some planning in the code, curses will just update the places on a screen which have changed, and one you add in scrolling, it's hard to say whether the library should have tweaked its updates to ensure that wrapped lines are pasted together again :-) > > > I'm floundering a bit at understanding this as I'm not really sure > > > it's an ncurses issue but it does seem to be pretty
Re: A somewhat off-topic question about ncurses and wrapping long lines
On Sat, Oct 01, 2022 at 10:01:00AM +0100, Chris Green wrote: > Well it's not entirely off topic, it's about something that works as > I'd expect it to in vile (and less) but doesn't work right in mutt (my > E-Mail program of choice). > > The issue is about how long chunks of text, with no spaces in them, > are wrapped when they are too long to fit in the terminal width. The > typical case (and the one that is a particular problem in mutt) is > that of long URLs. This *isn't* about how these programs manage > wrapping normal text made up of 'words' with spaces in between. > > In less or vile when there is a long piece of text and you have told > less/vile to wrap long lines then the long URL (or whatever) is > displayed wrapped at the right margin but it is still a single string > and you can select it in the terminal by right clicking on it. > > In mutt (in mutt's internal pager specifically) however, although the > URL is displayed the same (i.e. wrapped at the right margin) it's > actually broken into one or more lines and you *can't* select it by > right clicking on it, you just get the single line that you click on. > > This has been discussed at length at various times on the mutt mailing > list and hasn't been solved. I'm subscribed to mutt-dev (don't recall it there). Perhaps mutt-user... (none of the mutt development gets very deep into this stuff) > Is there some specific way of using/calling ncurses which does what we > want? ... and/or does ncurses default to breaking the string at the > page margin and need some option to prevent it doing this? It's a special case of xterm (imitated by more than one terminal emulator, though probably not _all_). xterm notices when a line is written and wraps. Screen updates that simply write to the end of a line (including a previously "wrapped" line) make it forget about follow part of a line. less and vile have an advantage over ncurses in deciding if a line is wrapped -- ncurses can't tell if an application writes text (using one of the wrapping calls such as waddch) intending to construct a long line. Actually, long lines in mutt for me have a "+" marking the beginning of the following lines (which iirc is configurable). > I'm floundering a bit at understanding this as I'm not really sure > it's an ncurses issue but it does seem to be pretty much the same > regardless of other things. I use /usr/bin/xfce4-terminal but the > same happens to lots of other people and I have tried other terminal > emulators and seen no change. > > Can anyone throw any light on this? > > -- > Chris Green > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: package/freebsd/*vile content is for 9.8v rather than for 9.8w
On Mon, Aug 22, 2022 at 04:09:17PM -0400, Thomas Dickey wrote:
> On Mon, Aug 22, 2022 at 01:48:21PM +0200, Gary Jennejohn wrote:
> > I tried to build {,x}vile9.8w for FreeBSD using what's under
> > package/freebsd,
> > but all the files are for 9.8v.
> >
> > This would be trivial to fix, but what's missing are the correct
> > TIMESTAMPs for the distfiles and I'm not sure how to get them.
> >
> > The size is known and SHA256 values I can generate myself.
>
> yes - I know about that, but hadn't found a nicer solution.
>
> I use that particular set of files for testing after an update
> (and to help check if there's some change to the makefile
> that I should account for).
>
> Since they're part of the release tarball, it's not possible to have the
> sha256's match. Generally I update the distinfo using make(whatever) in
> the ports tree, and make packages for myself.
make makesum
(it's hard to remember because different package systems use different
commands)
> > Note that I at one time was the FreeBSD maintainer of vile and xvile,
> > so I know how things should work.
>
> I'm currently the maintainer for those packages - but have to check on
> how moving to Git has changed the procedure :-)
>
> I started updating the MacPorts file this morning (not exactly the maintainer,
> but made the last update).
done...
> Over the next day or so, I'll be updating that stuff (unless someone else
> gets there first).
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265996
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
ANN: vile-9.8w
Files: https://invisible-island.net/archives/vile/current/vile-9.8w.tgz https://invisible-island.net/archives/vile/current/vile-9.8w.tgz.asc https://invisible-island.net/archives/vile/patches/MD5sums https://invisible-island.net/archives/vile/patches/vile-9.8w.patch.gz https://invisible-island.net/archives/vile/patches/vile-9.8w.patch.gz.asc https://invisible-island.net/archives/vile/patches/vile-9.8w.patch.gz patch by Thomas E. Dickey created Mon Aug 22 01:05:58 UTC 2022 -- CHANGES| 30 MANIFEST |8 aclocal.m4 | 42 basic.c|4 configure | 3353 +++ display.c |4 doc/vile-hlp.html |4 doc/vile-toc.html |4 estruct.h |4 eval.c |4 file.c | 12 filters/genmake.mak|5 filters/imakeflt.l |7 filters/makefilt.l |7 filters/manfilt.c | 67 filters/sh-filt.l | 14 filters/spellflt.l | 11 filters/vilefilt.l |4 history.c | 14 input.c|7 insert.c | 51 line.c | 14 macros/UXVile.ad |6 macros/XVile.ad|4 macros/manpage.rc | 13 macros/modes.rc| 21 main.c |4 makefile.in|5 map.c | 56 mktbls.c | 14 ntwinio.c |4 package/convile.nsi|8 package/debian/changelog |6 package/freebsd/vile/Makefile |2 package/freebsd/vile/distinfo |6 package/freebsd/xvile/Makefile |1 package/freebsd/xvile/distinfo |6 package/minvile.nsi|8 package/vile.spec | 10 package/winvile.iss|4 package/winvile.nsi|6 patchlev.h |4 perl.xs|7 plink.sh | 11 proto.h|8 random.c |4 regexp.c | 32 region.c |4 revlist| 118 - tcap.c |8 vile-9.8w/filters/md-filt.l| 616 +++ vile-9.8w/filters/md.key |1 vile-9.8w/filters/raku.key |2 vile-9.8w/filters/rakufilt.c | 1672 +++ vile.hlp |6 w32cbrd.c |4 w32info.rc | 12 w32ole.cpp |6 wvwrap.cpp |6 xterm.c|4 60 files changed, 4466 insertions(+), 1913 deletions(-) -- Please remove the following files before applying this patch. (You can feed this patch to 'sh' to do so.) rm -f filters/perl6.key rm -f filters/pl6filt.c rm -f revlist.bak exit 20220821 (w) > Brendan O'Dea: + the font specification in /etc/X11/app-defaults/UXVile was being overridden by the one in XVile. Additionally update the xvile font to use the Latin-1 equivalent (9x18 instead of 8x13). + apply memory-leak fix from pl-filt.c in 9.8v to pl6filt.c + rename perl6mode and corresponding syntax filter to "raku" (report by Steve Lembark). + update suffix-list for rakumode. > Tom Dickey: + portability-fixes for plink.sh + fixes for regexp.c: + build-fix for test_regexp + add parentheses in non-multibyte is_CLASS() macro to correct a problem with pointer expressions. + add I/i toggle in test_regexp to exercise ignorecase. + revise change for lins_chars() to handle UTF-8 in scripts, as that interfered with normal insertions (report by Chris Green). + fix a check in vile-manfilt, to ensure that stepping into previous lines does not use flushed/discarded rows. + build-fix for perl 5.36 (Debian #1014289) + modify error-message from vile-manfilt to show the program name. + fix a state-transition in sh-filt.l, which left some text uncolored (report by Wayne Cuddy). + add markdown mode (mdmode). + update copyright dates + update package/freebsd/* + fix some issues found with Coverity. + fix a few compiler-warnings. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: [PATCH] Fix build failure with Perl 5.36
On Tue, Aug 09, 2022 at 06:44:58PM -0700, Kevin Buettner wrote: > On Mon, 4 Jul 2022 15:12:27 +1000 > Brendan O'Dea wrote: > > > Fix a build failure for Perl 5.36 caused by a namespace conflict of > > the symbol `regexp' (http://bugs.debian.org/1014289). > > I've tested this fix on my (Fedora) rawhide machine. It works for me. sounds good (same here). I have most of 9.8w done, except for finishing the markdown-highlighter that I began. I might complete that today. See this for other fixes: https://github.com/ThomasDickey/vile-snapshots -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: UTF8 has stopped working in vile after OS upgrade
On Tue, Aug 02, 2022 at 03:23:26PM +1000, Brendan O'Dea wrote:
> 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).
yes... the change can probably be made to work as intended by accounting
for whether lins_chars is called from a script or interactively by adding
the clexec variable to the check, e.g.
if ((!clexec || !global_is_utfXX()) && (c > 127) && b_is_utfXX(curbp)) {
though the code has changed, and that's untested :-)
I'll investigate that over the next day or so.
> 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
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: UTF8 has stopped working in vile after OS upgrade
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.
did that. It's a small change, which I'll have to rethink.
Attaching a diff showing what I changed to get this problem.
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
Index: CHANGES
--- vile/CHANGES 2020-09-09 00:17:55.0 +
+++ vile-bad/CHANGES 2020-11-30 00:56:48.0 +
@@ -1,9 +1,11 @@
Changes for vile 9.9 (released ??? ??? ?? )
- 20200908 (v)
+ 20201129 (v)
> Stephan Schulz:
+ add popup-choices mode (Savannah #58999)
> Tom Dickey:
+ + modify lins_chars() to handle a case where a script inserts a UTF-8
+ character (report by Thomas Dupond).
+ modify configure/makefiles to support ".PHONY" feature.
+ change configure/makefiles to use ARFLAGS rather than AR_OPTS
+ change configure --with-warnings to --enable-warnings for consistency
Index: estruct.h
Prereq: 1.757
--- vile/estruct.h 2020-08-23 19:03:03.0 +
+++ vile-bad/estruct.h 2020-11-29 22:41:44.0 +
@@ -12,7 +12,7 @@
*/
/*
- * $Id: estruct.h,v 1.757 2020/08/23 19:03:03 Stephan.Schulz Exp $
+ * $Id: estruct.h,v 1.758 2020/11/29 22:41:44 tom Exp $
*/
#ifndef _estruct_h
@@ -1316,10 +1316,14 @@
* True if the buffer contents are in UTF-8 (or -16, -32).
*/
#if OPT_MULTIBYTE
+#define global_is_utfXX()((global_b_val(VAL_FILE_ENCODING) >= enc_UTF8) \
+ || (global_b_val(VAL_FILE_ENCODING) == enc_LOCALE \
+ && vl_encoding >= enc_UTF8))
#define b_is_utfXX(bp) ((b_val(bp, VAL_FILE_ENCODING) >= enc_UTF8) \
|| (b_val(bp, VAL_FILE_ENCODING) == enc_LOCALE \
&& vl_encoding >= enc_UTF8))
#else
+#define global_is_utfXX()0
#define b_is_utfXX(bp) 0
#endif
Index: insert.c
Prereq: 1.184
--- vile/insert.c 2015-03-13 10:29:15.0 +
+++ vile-bad/insert.c 2020-11-29 22:44:16.0 +
@@ -4,7 +4,7 @@
* Most code probably by Dan Lawrence or Dave Conroy for MicroEMACS
* Extensions for vile by Paul Fox
*
- * $Header: /tmp/vile/RCS/insert.c,v 1.184 2015/03/13 10:29:15 tom Exp $
+ * $Header: /tmp/vile/RCS/insert.c,v 1.185 2020/11/29 22:44:16 tom Exp $
*/
#include "estruct.h"
@@ -1039,7 +1039,7 @@
while (n--) {
tp = tstring;
while (*tp) {
- if ((status = inschar(*tp++, _limit)) != TRUE) {
+ if ((status = inschar(CharOf(*tp++), _limit)) != TRUE) {
n = 0;
break;
}
Index: line.c
Prereq: 1.235
--- vile/line.c 2019-12-19 09:32:10.0 +
+++ vile-bad/line.c 2020-11-30 00:46:44.0 +
@@ -10,7 +10,7 @@
* editing must be being displayed, which means that "b_nwnd" is non zero,
* which means that the dot and mark values in the buffer headers are nonsense.
*
- * $Id: line.c,v 1.235 2019/12/19 09:32:10 bod Exp $
+ * $Id: line.c,v 1.236 2020/11/30 00:46:44 tom Exp $
*/
/* #define POISON */
@@ -542,7 +542,7 @@
int nn;
int mapped;
-if ((c > 127) && b_is_utfXX(curbp)) {
+if (!global_is_utfXX() && (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;
signature.asc
Description: PGP signature
Re: UTF8 has stopped working in vile after OS upgrade
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) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: UTF8 has stopped working in vile after OS upgrade
On Thu, Jul 28, 2022 at 10:27:05PM +0100, 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). hmm - in a quick check (without getting into keyboard configuration or compose), I can reproduce this in my Ubuntu 22.04 machine, by pasting text selected/copied between xterms(*) and don't see the problem in the older Debian machine that I'm using. So there's something that I can investigate. At the moment, I'm getting ready for a trip (email yes, development no), but am supposing that I can dig into this next week :-) (*) something that I can fix. I've noticed that gnome-terminal is really flakey in Ubuntu 22.04, but _that_ is off-topic. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: UTF8 has stopped working in vile after OS upgrade
On Thu, Jul 28, 2022 at 09:21:52PM +0100, Chris Green wrote: > Further information... > > I've built vile 9.7 on this system and pound signs work correctly, if > I build vile 9.8 with the same build environment pound signs don't work. That's a fairly long timespan, since I started 9.8 in 2010. But you might be able to pinpoint that more closely using https://github.com/ThomasDickey/vile-snapshots (about 250 tags since 2010, or ~8 steps). I have an Ubuntu 20.04 and 22.04 machine for test-compiles; "locale -a" (the easy fix) only shows C.UTF-8 changing to C.utf8 -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: UTF8 has stopped working in vile after OS upgrade
On Thu, Jul 28, 2022 at 11:54:54AM +0100, Chris Green wrote: > I just upgraded my systems from xubuntu 21.10 to xubuntu 22.04. I don't know about "xubuntu", but Ubuntu 22.04 doesn't seem an improvement. > My UTF8 confiuguration in vile and xvile is broken now. > > Well, entering pound sterling signs no longer works, here is one:- > > � > > (That looks a bit like an iso 8859-1 character to me, not sure really) > > vile has been upgraded to version 9.8v, all my locale settings are > unchanged I think, and pound signs seem to be working correctly > everywhere else. Perhaps locale -a would show only UTF-8 encoding (vile is designed to know about a combination of non-UTF-8 and UTF-8, which used to be a problem). I've not changed any of that for quite a while -- locale support is the first place to check. > It's the character *entry* in vile/xvile that's broken, if I create a > file with pound signs in it and then open it with vile then the pound > signs display correctly. > > -- > Chris Green > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: [PATCH] Fix build failure with Perl 5.36
On Mon, Jul 04, 2022 at 03:12:27PM +1000, Brendan O'Dea wrote: > Fix a build failure for Perl 5.36 caused by a namespace conflict of > the symbol `regexp' (http://bugs.debian.org/1014289). ... I suppose I'll have to put out a 9.8w in the next few weeks, once Perl 5.36 becomes more widespread. In February I was investigating a problem in vile-manfilt, but over most of the intervening time I've been busy with xterm and its dependencies. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: [PATCH] Remove obsolete gcc pragma
On Mon, Jul 04, 2022 at 02:20:15PM +1000, Brendan O'Dea wrote: > 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: That's a recent change, from December. My checkin comment says quiet another, used in OpenSUSE and Slackware > ../../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" -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: sh-mode highlight issue
On Mon, Jan 31, 2022 at 03:20:14PM +, Wayne Cuddy via discussions
concerning the vile text editor wrote:
> On Sun, Jan 30, 2022 at 03:45:15PM -0500, Thomas Dickey wrote:
> > On Sat, Jan 29, 2022 at 04:09:09PM -0500, Thomas Dickey wrote:
> > > On Sat, Jan 29, 2022 at 07:51:53PM +, Wayne Cuddy via discussions
> > > concerning the vile text editor wrote:
> > > > I'm not sure if this has been reported before, please forgive me if
> > > > this is repetitious.
> > > >
> > > > I'm running 9.8t and have not had a chance to upgrade to the
> > > > latest/greatest yet but I don't see mention of this issue being
> > > > corrected in the changelog. The closest I could find was comments from
> > > > 9.7y:
> > > >
> > > > + improve vile-sh-filt for these cases:
> > > > + "${number}"
> > > > + "$(commands)"
> > > > + "$((expression))"
> > > > + "${name#value}", etc.
> > > >
> > > >
> > > > The issue concerns $((expression)) expansions in variable assignments,
> > > > but may not be limited to just this case.
> > > >
> > > > var="prefix$((5*5))suffix"
> > >^ string
> > > ^expression
> > > ^ string?
> > > >
> > > > prefix appears correctly highlighted, suffix does not, it seems the
> > > > syntax highlighting terminates after the final ')' character.
> > >
> > > Just looking at the source, the line
> > >
> > > {BACKTIC2_UP}{ handle_backtic2(yytext, yyleng,
> > > LEN_BACKTIC2_DOWN, 0); }
> > >
> > > is probably what should trigger on the "))", which takes it into
> > >
> > > if (FLTSTACK_OK && (which <= 0) && (FLTSTACK_THIS.backtic == test)) {
> > >
> > > and fails there for some reason -- otherwise it would go back to the
> > > string/literal coloring.
> > >
> > > (I'm in the middle of ncurses, but may dig into it tomorrow to get a
> > > better
> > > answer).
> >
> > See attached
> >
> > --
> > Thomas E. Dickey
> > https://invisible-island.net
> > ftp://ftp.invisible-island.net
>
> > --- sh-filt.l 2021/12/12 01:26:53 1.183
> > +++ sh-filt.l 2022/01/30 20:27:01
> > @@ -70,6 +70,7 @@
> > static void handle_backtic2(const char *text, int length, int test, int
> > which);
> > static void handle_backtic1(const char *text, int length, int test, int
> > which);
> > static void handle_parens(const char *text, int length, int test, int
> > which, int state);
> > +static void resume_state(void);
> > static void save_here(const char *text, int length);
> > static void write_vname(const char *text, int length);
> >
> > @@ -198,8 +199,10 @@
> > FLEX_PRINTF((stderr, "cannot pop '$((' level %d\n",
> > stk_level));
> > if (!pop_backtic1(yytext, 1, LEN_BACKTIC1_DOWN)) {
> > FLEX_PRINTF((stderr, "cannot pop '$(' level
> > %d\n", stk_level));
> > - if (FLTSTACK_OK && stk_state[stk_level-1].state
> > == NORMAL)
> > + if (FLTSTACK_OK && stk_state[stk_level-1].state
> > == NORMAL) {
> > pop_state();
> > + resume_state();
> > + }
> > flt_putc(R_PAREN);
> > }
> > unput(R_PAREN);
> > @@ -213,8 +216,10 @@
> > }
> > {BACKTIC1_UP} { if (!pop_backtic1(yytext, yyleng,
> > LEN_BACKTIC1_DOWN)) {
> > FLEX_PRINTF((stderr, "cannot pop '$(' level %d\n",
> > stk_level));
> > - if (FLTSTACK_OK && stk_state[stk_level-1].state ==
> > NORMAL)
> > + if (FLTSTACK_OK && stk_state[stk_level-1].state ==
> > NORMAL) {
> > pop_state();
> > + resume_state();
> > + }
> > ECHO;
> > }
> > }
> > @@ -293,6 +298,7 @@
> > "))" {
> > WriteToken(Action_attr);
> >
Re: sh-mode highlight issue
On Sat, Jan 29, 2022 at 04:09:09PM -0500, Thomas Dickey wrote:
> On Sat, Jan 29, 2022 at 07:51:53PM +, Wayne Cuddy via discussions
> concerning the vile text editor wrote:
> > I'm not sure if this has been reported before, please forgive me if
> > this is repetitious.
> >
> > I'm running 9.8t and have not had a chance to upgrade to the
> > latest/greatest yet but I don't see mention of this issue being
> > corrected in the changelog. The closest I could find was comments from
> > 9.7y:
> >
> > + improve vile-sh-filt for these cases:
> > + "${number}"
> > + "$(commands)"
> > + "$((expression))"
> > + "${name#value}", etc.
> >
> >
> > The issue concerns $((expression)) expansions in variable assignments,
> > but may not be limited to just this case.
> >
> > var="prefix$((5*5))suffix"
>^ string
> ^expression
> ^ string?
> >
> > prefix appears correctly highlighted, suffix does not, it seems the
> > syntax highlighting terminates after the final ')' character.
>
> Just looking at the source, the line
>
> {BACKTIC2_UP}{ handle_backtic2(yytext, yyleng,
> LEN_BACKTIC2_DOWN, 0); }
>
> is probably what should trigger on the "))", which takes it into
>
> if (FLTSTACK_OK && (which <= 0) && (FLTSTACK_THIS.backtic == test)) {
>
> and fails there for some reason -- otherwise it would go back to the
> string/literal coloring.
>
> (I'm in the middle of ncurses, but may dig into it tomorrow to get a better
> answer).
See attached
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
--- sh-filt.l 2021/12/12 01:26:53 1.183
+++ sh-filt.l 2022/01/30 20:27:01
@@ -70,6 +70,7 @@
static void handle_backtic2(const char *text, int length, int test, int which);
static void handle_backtic1(const char *text, int length, int test, int which);
static void handle_parens(const char *text, int length, int test, int which,
int state);
+static void resume_state(void);
static void save_here(const char *text, int length);
static void write_vname(const char *text, int length);
@@ -198,8 +199,10 @@
FLEX_PRINTF((stderr, "cannot pop '$((' level %d\n",
stk_level));
if (!pop_backtic1(yytext, 1, LEN_BACKTIC1_DOWN)) {
FLEX_PRINTF((stderr, "cannot pop '$(' level
%d\n", stk_level));
- if (FLTSTACK_OK && stk_state[stk_level-1].state
== NORMAL)
+ if (FLTSTACK_OK && stk_state[stk_level-1].state
== NORMAL) {
pop_state();
+ resume_state();
+ }
flt_putc(R_PAREN);
}
unput(R_PAREN);
@@ -213,8 +216,10 @@
}
{BACKTIC1_UP} { if (!pop_backtic1(yytext, yyleng, LEN_BACKTIC1_DOWN))
{
FLEX_PRINTF((stderr, "cannot pop '$(' level %d\n",
stk_level));
- if (FLTSTACK_OK && stk_state[stk_level-1].state ==
NORMAL)
+ if (FLTSTACK_OK && stk_state[stk_level-1].state ==
NORMAL) {
pop_state();
+ resume_state();
+ }
ECHO;
}
}
@@ -293,6 +298,7 @@
"))" {
WriteToken(Action_attr);
pop_state();
+ resume_state();
}
{IDENT1} |
{VNAME} { WriteToken(Ident_attr); }
@@ -312,6 +318,7 @@
flt_bfr_append("'", 1);
flt_bfr_finish();
pop_state();
+ resume_state();
}
\\[0-7]{1,3} {
flt_bfr_embed(yytext, 1, Action_attr);
@@ -874,6 +881,7 @@
flt_bfr_append(value + used, length - used);
flt_bfr_finish();
pop_state();
+ resume_state();
FreeAndNull(here_tag);
here_exp = 0;
here_next = 0;
signature.asc
Description: PGP signature
Re: sh-mode highlight issue
On Sat, Jan 29, 2022 at 07:51:53PM +, Wayne Cuddy via discussions
concerning the vile text editor wrote:
> I'm not sure if this has been reported before, please forgive me if
> this is repetitious.
>
> I'm running 9.8t and have not had a chance to upgrade to the
> latest/greatest yet but I don't see mention of this issue being
> corrected in the changelog. The closest I could find was comments from
> 9.7y:
>
> + improve vile-sh-filt for these cases:
> + "${number}"
> + "$(commands)"
> + "$((expression))"
> + "${name#value}", etc.
>
>
> The issue concerns $((expression)) expansions in variable assignments,
> but may not be limited to just this case.
>
> var="prefix$((5*5))suffix"
^ string
^expression
^ string?
>
> prefix appears correctly highlighted, suffix does not, it seems the
> syntax highlighting terminates after the final ')' character.
Just looking at the source, the line
{BACKTIC2_UP}{ handle_backtic2(yytext, yyleng,
LEN_BACKTIC2_DOWN, 0); }
is probably what should trigger on the "))", which takes it into
if (FLTSTACK_OK && (which <= 0) && (FLTSTACK_THIS.backtic == test)) {
and fails there for some reason -- otherwise it would go back to the
string/literal coloring.
(I'm in the middle of ncurses, but may dig into it tomorrow to get a better
answer).
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: [PATCH 2/2] Perl6 is now known as raku.
On Thu, Jan 20, 2022 at 09:46:17PM +1100, Brendan O'Dea wrote: > 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 thanks (will test-build and push in my vile-snapshots, for now) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: 9.8v/shared/vile/perl6.keywords should be "raku.keywords.
On Mon, Jan 17, 2022 at 03:47:48PM -0500, Steven Lembark wrote: > > Simplest fix is probably a symlink in the tarball. I'd just copy/paste the definition for perl6 mode from filters.rc, rename that to rakumode, and add filtername 'vile-perl-filt -k perl6' -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Retaining Vile 'state' over close/open?
On Tue, Jan 04, 2022 at 10:27:39AM -0500, George Eccles wrote: > I am currently using vile 9.7 32-bit. (It does what I need, and 9.81(?) > seemed to change the 'go to mark' in a way that I couldn't figure out, so I > just stuck.) > > Anyway, on my new(er) Win10 PC, the 'hibernate' function is not available, > b/c the SSD is too small. The next best option would be to just 'shutdown' > the PC. Most other programs (eg, Excel, Firefox, etc) that I use all retain > their 'state'(?) when closed: when you resume, they come back to where you > were. Vile (9.7) does not: I need to re-open whatever files I was using, > set new marks, etc. > > So, my question: has this behavior been changed in subsequent versions; or, > is there some way I'm not aware of to preserve the 'state'(?) of Vile over a > close/re-open? no - I've not changed that. For recently-opened files, I use this feature, which lets winvile remember up to 20 files and folders in the registry: * a "Recent Files" menu that lists the last N files opened/created by the editor. Any file selected from this list is immediately opened for editing. This feature is disabled by default, but can be configured via the "recent-files" mode. * a "Recent Folders" menu that lists the last N folders visited via an explicit or implicit cd. Selecting a folder from this list is equivalent to executing ":cd ". This feature is disabled by default, but can be configured via the "recent-folders" mode. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Markdown syntax file
On Tue, Jan 04, 2022 at 11:10:51PM +, Gerard Lally wrote: > On Tue, Jan 04, 2022 at 04:49:42PM -0500, Thomas Dickey wrote: > > On Tue, Jan 04, 2022 at 09:39:12PM +, Gerard Lally wrote: > > > Does anyone have a Markdown syntax file available? Preferably with > > > MultiMarkdown support. > > > > I don't think so. Referring to > > > > https://fletcherpenney.net/multimarkdown/ > > > > it says that's a superset of markdown. vile's "txt" mode can be fooled > > into doing _part_ of markdown, but it's not really that close. > > > > I was using it for that a month or two ago, and concluded that it would > > require yet another syntax filter to do the job, and added that to my > > to-do list (but as usual I'm working on other stuff). > > Thank you, Thomas. I'll see what I can come up with myself in the > meantime. I'm under a little pressure myself, and philosophy, not > hacking, is my area, which is why I tried to pull a fast one by asking! actually syntax highlighters are relatively easy to code -- but I spend all of my time on things that aren't that easy :-( -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Markdown syntax file
On Tue, Jan 04, 2022 at 09:39:12PM +, Gerard Lally wrote: > Does anyone have a Markdown syntax file available? Preferably with > MultiMarkdown support. I don't think so. Referring to https://fletcherpenney.net/multimarkdown/ it says that's a superset of markdown. vile's "txt" mode can be fooled into doing _part_ of markdown, but it's not really that close. I was using it for that a month or two ago, and concluded that it would require yet another syntax filter to do the job, and added that to my to-do list (but as usual I'm working on other stuff). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
ANN: vile-9.8v
The current version of vile is 9.8v It's available at https://invisible-island.net/vile/vile.html ftp://ftp.invisible-island.net/vile/ https://invisible-mirror.net/archives/vile/ Files: ftp://ftp.invisible-island.net/vile/current/vile-9.8v.tgz ftp://ftp.invisible-island.net/vile/current/vile-9.8v.tgz.asc ftp://ftp.invisible-island.net/vile/patches/MD5sums ftp://ftp.invisible-island.net/vile/patches/vile-9.8v.patch.gz ftp://ftp.invisible-island.net/vile/patches/vile-9.8v.patch.gz.asc ftp://ftp.invisible-island.net/vile/patches/vile-9.8v.patch.gz patch by Thomas E. Dickey created Sun Dec 12 23:59:32 UTC 2021 -- CHANGES| 76 INSTALL|2 MANIFEST | 20 README |2 README.PC |2 aclocal.m4 | 1214 +- ansi.c |2 api.h |2 basic.c|6 borland.c |2 buffer.c |4 buglist|2 chgdfunc.h |2 cmdtbl |2 config.guess | 1177 +- config.sub | 647 - config_h.in|2 configure |13645 ++- configure.in | 78 csrch.c|2 curses.c |6 descrip.mms|2 dirstuff.h |2 display.c |6 djhandl.c |2 doc/config.doc |6 doc/config.html|4 doc/make-hlp.pl|4 doc/make-toc.pl|5 doc/makefile |2 doc/vile-hlp.html | 893 - doc/vile-man.sed |2 doc/vile-toc.html |6 dumbterm.c |2 edef.h |2 eightbit.c |4 encrypt.c |2 estruct.h | 18 eval.c |7 externs.c |2 filters/ada-filt.l |2 filters/atr2ansi.c |2 filters/atr2text.c |2 filters/awk-filt.l |2 filters/bnf-filt.l |2 filters/c-filt.c | 97 filters/cfg-filt.l |2 filters/css-filt.l |2 filters/cwebfilt.l |2 filters/dcl-filt.l |2 filters/def-filt.l |2 filters/difffilt.l |2 filters/ecl-filt.l |2 filters/ecrypt.c |2 filters/esqlfilt.l |2 filters/est-filt.l |2 filters/fdl-filt.l |2 filters/filters.c |2 filters/flt_defs.h |2 filters/genmake.c |2 filters/htmlfilt.l |2 filters/imakeflt.l |2 filters/infofilt.l |2 filters/ini-filt.l |2 filters/jsonfilt.l |2 filters/key-filt.c |2 filters/latexflt.l |2 filters/lua-filt.l |2 filters/m4-filt.c |2 filters/mailfilt.l |2 filters/makefile.2nd |4 filters/makefile.djg |4 filters/makefile.emx |2 filters/makefile.icc |2 filters/makefile.in|6 filters/makefilt.l |2 filters/makelist.sh|2 filters/manfilt.c | 28 filters/mc-filt.l |2 filters/mcrlfilt.l |2 filters/midlfilt.l
Re: Dianosing lack of colour highlighting
- Original Message - | From: "Chris Green" | To: "Vile mailing list" | Sent: Thursday, July 29, 2021 5:40:03 PM | Subject: Re: Dianosing lack of colour highlighting | On Thu, Jul 29, 2021 at 10:20:38PM +0100, Chris Green wrote: |> Well I have vile running OK on my phone running termux but I can't get |> colour syntax highlighting to work. |> |> I feel as if I have copied all the required configuration files across |> from my Linux systems where colour highlighting works OK, However, no |> colours. |> |> The terminal can display in colours as dircolors works when running ls. |> |> So how to diagnose this? |> | I've run show-colors and that does show colours so that's a good start. | | Looking at the vile help it says I should be doing:- | |./configure --prefix=$HOME/local --with-builtin-filters | | to get colour. Is that --with-builtin-filters necessary to get syntax | highlighting? If so it might explain my problem! :-) using builtin-filters simplifies the calling interface, eliminates screen hiccups, but whether you get color at all depends on the terminal description (e.g., what's TERM set to?) -- Thomas E. Dickey http://invisible-island.net ftp://ftp.invisible-island.net
Re: Has anyone tried compiling vile in termux?
On Thu, Jul 29, 2021 at 04:17:43PM +0100, Chris Green wrote: > On Thu, Jul 29, 2021 at 04:04:38PM +0100, Chris Green wrote: > > u0_a166@bison$ ./vile > > Bad system call > > > OK, a quick web search has found a solution, it runs OK in a chroot > environment:- > > u0_a166@bison$ termux-chroot ./vile > > I think I now need to rearrange things a bit so I always run termux in > a termux-root[ed] enviroment. > > But anyway that was actually remarkably painless, not a single missing > library and the fixes needed were fairly trivial. I'm now even more > impressed with both termux and vile! :-) sounds good. I recall some older discussion which said that Android only provided some Java emulation of the command-line - either that was mistaken, or termux is newer. just as a sanity-check, searching on "termux ncurses" shows that the latter works - which means that vile ought to (since it uses similar system features). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: xvile as external editor for Joplin
On Sun, Apr 04, 2021 at 11:43:06PM +0100, Gerard Lally wrote: > Thank you, Thomas. > > xvile -fork does the trick. > > So does xterm -e vile. What confused me a little was that I was > entering vile in Joplin's "Text Editor" box where I should have > entered xterm instead. > > -e vile of course goes in the "Arguments" box, not the editor box. > > Thanks again. no problem (report bugs) > Gerard Lally > > On Thu, 1 Apr 2021 at 23:51, Thomas Dickey wrote: > > > > On Thu, Apr 01, 2021 at 04:49:57PM +0100, Gerard Lally wrote: > > > Hi. > > > > > > It is possible to edit notes in the Joplin notes app using an external > > > editor. Unfortunately, xvile freezes when I try to do so. > > > > > > joplinapp dot org > > > > > > No cursor, scrollbar or menus appear either. How to start troubleshooting? > > > > hmm - some library conflict, perhaps. I'd make joplin run a shell script > > which calls the actual binary xvile, using the shell script to run strace > > (to see what files it opens, including the shared libraries). > > > > Making xvile fork on startup might be a workaround: > > > > xvile -fork > > > > > I'm happy to edit using vile + xterm instead, if I know the magic formula! > > > > xterm -e vile whatever > > > > > Tested on Slackware 14.2 and -current, and also on Debian -testing. > > > All fully patched, and vile + xvile installed from Slackbuilds / > > > Debian repos. > > > > > > Gerard Lally > > > > > > > -- > > Thomas E. Dickey > > https://invisible-island.net > > ftp://ftp.invisible-island.net -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: xvile as external editor for Joplin
On Thu, Apr 01, 2021 at 04:49:57PM +0100, Gerard Lally wrote: > Hi. > > It is possible to edit notes in the Joplin notes app using an external > editor. Unfortunately, xvile freezes when I try to do so. > > joplinapp dot org > > No cursor, scrollbar or menus appear either. How to start troubleshooting? hmm - some library conflict, perhaps. I'd make joplin run a shell script which calls the actual binary xvile, using the shell script to run strace (to see what files it opens, including the shared libraries). Making xvile fork on startup might be a workaround: xvile -fork > I'm happy to edit using vile + xterm instead, if I know the magic formula! xterm -e vile whatever > Tested on Slackware 14.2 and -current, and also on Debian -testing. > All fully patched, and vile + xvile installed from Slackbuilds / > Debian repos. > > Gerard Lally > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: scrolling/paging question
On Tue, Mar 02, 2021 at 04:28:33PM +, Wayne wrote: > I'm working with some wide files in vile. 600+ characters-per-line > with nolinewrap enabled. > > If the cursor is positioned several hundred characters into a line I can > use the j/k keys to scroll through the lines without the screen > shifting. However if I use page-up/page-down/ctrl-f/ctrl-b/ctrl-u/ctrl-d > the cursor is re-positioned back to the beginning of the line. yes... vi does that > 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. > Is there a convenient way to page through wide files without the > cursor changing columns? A macro could do this, e.g., binding ^F/^B to macros that do the scrolling and end with goto-column with your preferred column-offset. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: The vileget calling code in .vilerc
On Sun, Feb 07, 2021 at 03:44:40PM +, Chris Green wrote: > In my .vilerc that I use on several systems I have the following > towards the end:- > > ; > ; > ; Add a reStructuredText mode > ; > ; define-mode rst > ; map! ; : > ; map! : ; > ; ~with define-submode rst > ; suf '\.rst$' > ; shiftwidth=2 > ; ~endwith > > 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 The syntax, etc., look ok. Perhaps your installed vile-scripts are missing/altered/whatever. (I don't use the feature, but can troubleshoot it if the source needs fixes) > ; > ; > ; Set up ^K as 'compose' key for accented characters > ; > source digraphs.rc > > > The commented out reStructuredText mode is fine, it's just an > aide-memoire, the ^K bit at the end is OK too. However the bit in > between looks a bit odd, if only because of the indenting. > > Have I lost anything over the years or is it just the indenting is > awry? I know I just slavishly copied the code when I first inserted > it so I'm not really clear how it all works. > > 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! :-) > > -- > Chris Green > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: insert-string garbling characters
On Mon, Dec 21, 2020 at 08:13:23PM +, Thomas Dupond wrote: > Dear Thomas, > > Please excuse my very late response. I applied the patch as I'm late too (have been working on an upgrade to configure scripts...) >>I've attached the test-scripts that I used: >> I is mapped to an insert (using UTF-8) >> J is mapped to an insert using ^Vu >> K sets the buffer to 8bit >> M uses the insert-string command. > you described and I will try to describe concisely what I > observed using your foo?.rc files. > > For foo.rc (é): > > I: inserts \?E9 > J: inserts é > M: inserts \?E9 > K: Turns \?E9 into é and é into é > > After using K; I, J and M insert é correctly. that seems correct: after K, the current buffer is "8bit" (not UTF-8), so that UTF-8 data which was inserted into the buffer will be shown as its 8-bit bytes. Also, inserts using literal strings (as done in a map or the insert-string command) will insert the actual bytes used in those commands. The ^Vu mapping tries to convert the value, so you'll see some difference between I and J. Using ^G in vile (editing this message), I see this information: é -> char is 0xE9 or 0351 ǩ -> char is 0x1E9 or 0751 My "hex" program shows the bytes for those two cases: 0xe9: 233 0351 0xe9 text "\351" utf8 \303\251 0x1E9: 489 0751 0x1e9 text "\001\351" utf8 \307\251 and (showing what those octal values are): 0303: 195 0303 0xc3 text "\303" utf8 \303\203 0251: 169 0251 0xa9 text "\251" utf8 \302\251 0307: 199 0307 0xc7 text "\307" utf8 \303\207 0251: 169 0251 0xa9 text "\251" utf8 \302\251 à -> char is 0xC3 or 0303 © -> char is 0xA9 or 0251 Ç -> char is 0xC7 or 0307 © -> char is 0xA9 or 0251 > For foo2.rc (ǩ): > > I: inserts ǩ > J: inserts ǩ > M: inserts ǩ > K: Turns ǩ into Ç© > > After using K; I and M insert Ç©, J inserts é > > For foo3.rc (⇩) > > I: inserts ⇩ > J: inserts ⇩ > M: inserts ⇩ > K: Turns ⇩ into â\x87© > > After using K; I and M insert â\x87©, J inserts é > > Regards, > Thomas > > ‐‐‐ Original Message ‐‐‐ > Le mercredi, décembre 2, 2020 1:58 AM, Thomas Dickey a écrit > : > > > On Tue, Dec 01, 2020 at 04:18:48AM -0500, Thomas Dickey wrote: > > > > > On Mon, Nov 30, 2020 at 02:06:40PM +, Thomas Dupond wrote: > > > > > > > Thank you very much for your fast reply and this small patch. > > > > I downloaded version 9.8u and applied the patch but now > > > > whenever I try to insert an é interactively I only get : \?E9 > > > > > > ouch - I'll continue investigating a fix for this (thanks) > > > > Here's a followup (apply after the previous patch) which seems to work. > > > > I've attached the test-scripts that I used: > > I is mapped to an insert (using UTF-8) > > J is mapped to an insert using ^Vu > > K sets the buffer to 8bit > > M uses the insert-string command. > > > > > > And this goes for every character like èéêîïôöûù they do not > > > > appear correctly. When I switch to 8bit encoding with > > > > `setl fk=8bit` \?E9 appears correctly as é. > > > > On the bright side, when I use insert-string with UTF-8 > > > > encoding, the characters appear normally in the command prompt > > > > and insert-string works as intended. > > > > > > halfway there :-) > > > > > > > I realised that you use `setl fk=8bit` and with this encoding > > > > everything work as intended, interactive and insert-string. But > > > > I would rather use UTF-8 than ISO-8859. > > > > I'm sorry I cannot be of much help, I have very little > > > > knowledge of C programming. > > > > Regards, > > > > Thomas Dupond > > > > ‐‐‐ Original Message ‐‐‐ > > > > Le lundi, novembre 30, 2020 1:59 AM, Thomas Dickey dic...@his.com a > > > > écrit : > > > > > > > > > On Sun, Nov 29, 2020 at 04:21:24PM +, Thomas Dupond wrote: > > > > > > > > > > > Hello, > > > > > > I'm just starting on exploring vile and I fell on something I > > > > > > cannot solve. I was trying to write a macro and while vile > > > > > > seems to handle UTF8 really well it doesn't seem to work well > > > > > > with the function insert-string. > > > > > > I can insert "é" but when I use "insert-string é" it prints this
Re: insert-string garbling characters
On Tue, Dec 01, 2020 at 04:18:48AM -0500, Thomas Dickey wrote:
> On Mon, Nov 30, 2020 at 02:06:40PM +, Thomas Dupond wrote:
> > Thank you very much for your fast reply and this small patch.
> > I downloaded version 9.8u and applied the patch but now
> > whenever I try to insert an é interactively I only get : \?E9
>
> ouch - I'll continue investigating a fix for this (thanks)
Here's a followup (apply after the previous patch) which seems to work.
I've attached the test-scripts that I used:
I is mapped to an insert (using UTF-8)
J is mapped to an insert using ^Vu
K sets the buffer to 8bit
M uses the insert-string command.
> > And this goes for every character like èéêîïôöûù they do not
> > appear correctly. When I switch to 8bit encoding with
> > `setl fk=8bit` \?E9 appears correctly as é.
> >
> > On the bright side, when I use insert-string with UTF-8
> > encoding, the characters appear normally in the command prompt
> > and insert-string works as intended.
>
> halfway there :-)
>
> > I realised that you use `setl fk=8bit` and with this encoding
> > everything work as intended, interactive and insert-string. But
> > I would rather use UTF-8 than ISO-8859.
> >
> > I'm sorry I cannot be of much help, I have very little
> > knowledge of C programming.
> >
> > Regards,
> > Thomas Dupond
> >
> > ‐‐‐ Original Message ‐‐‐
> > Le lundi, novembre 30, 2020 1:59 AM, Thomas Dickey a écrit
> > :
> >
> > > On Sun, Nov 29, 2020 at 04:21:24PM +, Thomas Dupond wrote:
> > >
> > > > Hello,
> > > > I'm just starting on exploring vile and I fell on something I
> > > > cannot solve. I was trying to write a macro and while vile
> > > > seems to handle UTF8 really well it doesn't seem to work well
> > > > with the function insert-string.
> > > > I can insert "é" but when I use "insert-string é" it prints this
> > > > mess : ￃﾩ
> > >
> > > yes... scripting hasn't been as well-tested as interactive stuff :-(
> > >
> > > > Any idea on how to solve this ?
> > >
> > > Here's a fix for the most common case (it won't handle a special
> > > case where the buffer is non-UTF-8), which should work for you.
> > >
> > > also attaching a script I used for testing, e.g.,
> > > ./configure --enable-trace --with-builtin-filters && make
> > > ./vile @foo.rc makefile
> > >
> > > > My locale is :
> > > > LANG=en_GB.UTF-8
> > > > LANGUAGE=en_GB:en
> > >
> > > ...
> > >
> > > > I'm on debian 4.19 and I compiled vile-9.8 from source with
> > >
> > > 9.8's getting a little stale - 9.8u is current.
> > >
> > > I put snapshots in github (but have too many concurrent things to
> > > polish off 9.8v)
> > >
> > > > ./configure --with-builtin-filters
> > > > And $cfgopts = hypertext,locale,iconv,multibyte,terminfo
> > > > Kind regards,
> > > > Thomas
> > >
> > > --
> > >
> > > Thomas E. Dickey dic...@invisible-island.net
> > > https://invisible-island.net
> > > ftp://ftp.invisible-island.net
> >
> >
>
> --
> Thomas E. Dickey
> https://invisible-island.net
> ftp://ftp.invisible-island.net
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
--- CHANGES 2020/11/30 00:56:48 1.1972
+++ CHANGES 2020/12/01 22:53:53
@@ -1,9 +1,10 @@
Changes for vile 9.9 (released ??? ??? ?? )
- 20201129 (v)
+ 20201201 (v)
> Stephan Schulz:
+ add popup-choices mode (Savannah #58999)
> Tom Dickey:
+ + add check for 'U' in read_quoted() needed to make ^VU work.
+ modify lins_chars() to handle a case where a script inserts a UTF-8
character (report by Thomas Dupond).
+ modify configure/makefiles to support ".PHONY" feature.
--- input.c 2020/08/30 23:46:08 1.371
+++ input.c 2020/12/01 22:47:44
@@ -44,7 +44,7 @@
* tgetc_avail() true if a key is avail from tgetc() or below.
* keystroke_avail() true if a key is avail from keystroke() or below.
*
- * $Id: input.c,v 1.371 2020/08/30 23:46:08 tom Exp $
+ * $Id: input.c,v 1.372 2020/12/01 22:47:44 tom Exp $
*/
#include "estruct.h"
@@ -1852,10 +1852,11 @@
if (count <= 0)
returnCode(c);
-/* accumulate up to 3 digits for a single byte */
+/* accumulate digits for a character */
if (isDigit(c)
#if OPT_MULTIBYTE
|| (c == 'u')
+ || (c == 'U')
#endif
|| (c == 'x')) {
if (!inscreen) {
--- insert.c 2020
Re: insert-string garbling characters
On Mon, Nov 30, 2020 at 02:06:40PM +, Thomas Dupond wrote: > Thank you very much for your fast reply and this small patch. > I downloaded version 9.8u and applied the patch but now > whenever I try to insert an é interactively I only get : \?E9 ouch - I'll continue investigating a fix for this (thanks) > And this goes for every character like èéêîïôöûù they do not > appear correctly. When I switch to 8bit encoding with > `setl fk=8bit` \?E9 appears correctly as é. > > On the bright side, when I use insert-string with UTF-8 > encoding, the characters appear normally in the command prompt > and insert-string works as intended. halfway there :-) > I realised that you use `setl fk=8bit` and with this encoding > everything work as intended, interactive and insert-string. But > I would rather use UTF-8 than ISO-8859. > > I'm sorry I cannot be of much help, I have very little > knowledge of C programming. > > Regards, > Thomas Dupond > > ‐‐‐ Original Message ‐‐‐ > Le lundi, novembre 30, 2020 1:59 AM, Thomas Dickey a écrit : > > > On Sun, Nov 29, 2020 at 04:21:24PM +, Thomas Dupond wrote: > > > > > Hello, > > > I'm just starting on exploring vile and I fell on something I > > > cannot solve. I was trying to write a macro and while vile > > > seems to handle UTF8 really well it doesn't seem to work well > > > with the function insert-string. > > > I can insert "é" but when I use "insert-string é" it prints this > > > mess : ￃﾩ > > > > yes... scripting hasn't been as well-tested as interactive stuff :-( > > > > > Any idea on how to solve this ? > > > > Here's a fix for the most common case (it won't handle a special > > case where the buffer is non-UTF-8), which should work for you. > > > > also attaching a script I used for testing, e.g., > > ./configure --enable-trace --with-builtin-filters && make > > ./vile @foo.rc makefile > > > > > My locale is : > > > LANG=en_GB.UTF-8 > > > LANGUAGE=en_GB:en > > > > ... > > > > > I'm on debian 4.19 and I compiled vile-9.8 from source with > > > > 9.8's getting a little stale - 9.8u is current. > > > > I put snapshots in github (but have too many concurrent things to > > polish off 9.8v) > > > > > ./configure --with-builtin-filters > > > And $cfgopts = hypertext,locale,iconv,multibyte,terminfo > > > Kind regards, > > > Thomas > > > > -- > > > > Thomas E. Dickey dic...@invisible-island.net > > https://invisible-island.net > > ftp://ftp.invisible-island.net > > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: insert-string garbling characters
On Sun, Nov 29, 2020 at 04:21:24PM +, Thomas Dupond wrote:
> Hello,
>
> I'm just starting on exploring vile and I fell on something I
> cannot solve. I was trying to write a macro and while vile
> seems to handle UTF8 really well it doesn't seem to work well
> with the function *insert-string*.
>
> I can insert "é" but when I use "insert-string é" it prints this
> mess : ￃﾩ
yes... scripting hasn't been as well-tested as interactive stuff :-(
> Any idea on how to solve this ?
Here's a fix for the most common case (it won't handle a special
case where the buffer is non-UTF-8), which should work for you.
also attaching a script I used for testing, e.g.,
./configure --enable-trace --with-builtin-filters && make
./vile @foo.rc makefile
> My locale is :
>
> LANG=en_GB.UTF-8
> LANGUAGE=en_GB:en
...
> I'm on debian 4.19 and I compiled vile-9.8 from source with
9.8's getting a little stale - 9.8u is current.
I put snapshots in github (but have too many concurrent things to
polish off 9.8v)
>
> ./configure --with-builtin-filters
>
> And $cfgopts = hypertext,locale,iconv,multibyte,terminfo
>
>
> Kind regards,
>
> Thomas
>
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
--- estruct.h 2020/08/23 19:03:03 1.757
+++ estruct.h 2020/11/29 22:41:44
@@ -1316,10 +1316,14 @@
* True if the buffer contents are in UTF-8 (or -16, -32).
*/
#if OPT_MULTIBYTE
+#define global_is_utfXX()((global_b_val(VAL_FILE_ENCODING) >= enc_UTF8) \
+ || (global_b_val(VAL_FILE_ENCODING) == enc_LOCALE \
+ && vl_encoding >= enc_UTF8))
#define b_is_utfXX(bp) ((b_val(bp, VAL_FILE_ENCODING) >= enc_UTF8) \
|| (b_val(bp, VAL_FILE_ENCODING) == enc_LOCALE \
&& vl_encoding >= enc_UTF8))
#else
+#define global_is_utfXX()0
#define b_is_utfXX(bp) 0
#endif
--- insert.c 2015/03/13 10:29:15 1.184
+++ insert.c 2020/11/29 22:44:16
@@ -1039,7 +1039,7 @@
while (n--) {
tp = tstring;
while (*tp) {
- if ((status = inschar(*tp++, _limit)) != TRUE) {
+ if ((status = inschar(CharOf(*tp++), _limit)) != TRUE) {
n = 0;
break;
}
--- line.c 2019/12/19 09:32:10 1.235
+++ line.c 2020/11/29 22:43:43
@@ -542,7 +542,7 @@
int nn;
int mapped;
-if ((c > 127) && b_is_utfXX(curbp)) {
+if (!global_is_utfXX() && (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;
store-procedure oops
insert-string "é"
~endm
map I ié
map K :setl fk=8bit
map M :oops
signature.asc
Description: PGP signature
Re: Problem building/compiling
On Wed, Jul 01, 2020 at 09:19:03PM +0100, Chris Green wrote: > I am trying to compile vile on a web hosting system where I have a > Linux ssh login account. The C preprocessor is problematic:- > > bash-3.2$ pwd > /var/sites/o/oasis41.co.uk/tmp/vile-9.8 > bash-3.2$ ./configure > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > Configuring for linux-gnu > checking for gcc... gcc > checking for C compiler default output... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for executable suffix... > checking for object suffix... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking how to run the C preprocessor... /lib/cpp > configure: error: C preprocessor "/lib/cpp" fails sanity check > bash-3.2$ I'd be inclined to see why the test failed. config.log shows some information, but getting details requires editing the configure script (since it doesn't show a diff between actual and expected). But seeing config.log would be useful. > Are there any obvious things to try in order to get round this problem? I'd look to see what version of ncurses is used. Of course, if it's busybox, there's not much to be done. If you've got gcc (and ld), you probably have ldd. ldd run on bash is a quick way to see (I'm using Debian at the moment): linux-vdso.so.1 (0x7ffdf8bc8000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f0eb364f000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0eb344b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0eb30ac000) /lib64/ld-linux-x86-64.so.2 (0x7f0eb3879000) "tinfo" is the low-level half of ncurses. I'd compile vile with another machine with the right architecture and version of ncurses (generally ABI 5's are compatible across releases, ABI 6's probably the same but less often encountered on limited accounts). Also - you'll need terminal descriptions. If your remote ssh account has "infocmp", it's probably workable. If you don't have ldd and infocmp, it's more work :-) > Alternatively is there a way to create an executable image which > includes all libraries etc., like appimage format? The system reports > its architecture etc. as:- not easily - there's a lot of platforms, and only half of the ones I use are Linux-based... > bash-3.2$ uname -a > Linux shell3.gridhost.co.uk 2.6.32-754.27.1.el6.x86_64 #1 SMP Tue Jan 28 > 14:11:45 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: ANN: vile-9.8u
On Mon, May 18, 2020 at 10:09:53AM -0700, Marc Simpson wrote: > On Sun, May 17, 2020 at 5:46 PM Thomas Dickey wrote: > > > > Files: > > ftp://ftp.invisible-island.net/vile/current/vile-9.8u.tgz > > ftp://ftp.invisible-island.net/vile/current/vile-9.8u.tgz.asc > > ftp://ftp.invisible-island.net/vile/patches/MD5sums > > ftp://ftp.invisible-island.net/vile/patches/vile-9.8u.patch.gz > > ftp://ftp.invisible-island.net/vile/patches/vile-9.8u.patch.gz.asc > > Great; thanks Tom. > > FWIW, as of this morning MacPorts provides 9.8u. sounds good. I'm working to update the FreeBSD port (a little involved, since I have to upgrade other stuff such as clang...) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
ANN: vile-9.8u
Files: ftp://ftp.invisible-island.net/vile/current/vile-9.8u.tgz ftp://ftp.invisible-island.net/vile/current/vile-9.8u.tgz.asc ftp://ftp.invisible-island.net/vile/patches/MD5sums ftp://ftp.invisible-island.net/vile/patches/vile-9.8u.patch.gz ftp://ftp.invisible-island.net/vile/patches/vile-9.8u.patch.gz.asc ftp://ftp.invisible-island.net/vile/patches/vile-9.8u.patch.gz patch by Thomas E. Dickey created Mon May 18 00:40:24 UTC 2020 -- CHANGES | 85 CHANGES.R3|4 CHANGES.R4| 24 CHANGES.R5| 20 CHANGES.R6|6 CHANGES.R7| 10 CHANGES.R8|2 MANIFEST | 24 README|4 aclocal.m4| 668 + ansi.c|4 api.c |6 api.h |4 basic.c | 31 borland.c |4 buffer.c | 12 buglist | 26 config.guess | 359 config.sub| 1147 +- configure | 7860 +--- configure.in |7 doc/Vileserv.doc |4 doc/Vileserv.html |4 doc/config.doc| 18 doc/config.html | 42 doc/dir.doc |4 doc/dir.html |4 doc/filters.doc | 13 doc/filters.html | 23 doc/macros.doc| 166 doc/macros.html | 749 - doc/make-hlp.pl | 48 doc/make-toc.pl |4 doc/menus.doc |4 doc/menus.html|4 doc/modes.doc |4 doc/modes.html|4 doc/oleauto.doc |4 doc/oleauto.html |4 doc/perl.doc |4 doc/perl.html |4 doc/vile-hlp.html | 1279 +- doc/vile-toc.html |8 doc/visvile.doc |6 doc/visvile.html | 30 edef.h|4 eightbit.c|6 estruct.h | 30 eval.c| 13 exec.c|5 fences.c | 23 filters/as-filt.l | 10 filters/asm-filt.l|6 filters/atr2html.c| 27 filters/au3-filt.l|8 filters/bas-filt.l|8 filters/filterio.c|4 filters/filters.h |4 filters/filters.rc| 19 filters/genmake.mak |5 filters/genmake.sh|4 filters/iss-filt.l|8 filters/manfilt.c | 13 filters/mk-key.awk|6 filters/pl-filt.c |7 filters/pot-filt.l|8 filters/ps.key|6 filters/py-filt.l | 12 filters/rubyfilt.c|4 filters/spellflt.l|7
Re: Fonts for xvile in linux - where to find some nice ones?
On Wed, May 06, 2020 at 11:10:34PM +0100, Chris Green wrote: > On Wed, May 06, 2020 at 03:25:52PM -0400, Thomas Dickey wrote: > > On Thu, May 07, 2020 at 01:11:30AM +1000, Brendan O'Dea wrote: > > > 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. > > > > agreed - the APIs are very different. There was no _technical_ reason > > that they had to be incompatible... > > > > Having both in xterm makes it complicated. If/when I find time to > > do TrueType for xvile, it'll be one or the other at configure/make > > time. > > > That would be OK, what will distributions/repositories do though? s/will/would/ (this is an item from a long to-do list) Assuming that I had done the work, and it worked well enough, I'd probably change the configure-default to the preferred version :-) Most packagers would use whatever I set that to... > > > However, I mostly use vile in xterm, and after _that_, winvile. > > > I mostly use vile in a terminal, it's just that *occasionally* (such > as marking rectangular areas with the mouse) xvile is very handy. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Fonts for xvile in linux - where to find some nice ones?
On Thu, May 07, 2020 at 01:11:30AM +1000, Brendan O'Dea wrote: > 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. agreed - the APIs are very different. There was no _technical_ reason that they had to be incompatible... Having both in xterm makes it complicated. If/when I find time to do TrueType for xvile, it'll be one or the other at configure/make time. However, I mostly use vile in xterm, and after _that_, winvile. I was just starting to review where I was with winvile in Windows 10, which had two gotchas that I want to have out of the way before making new installers. > 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 > > > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Fonts for xvile in linux - where to find some nice ones?
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 > I tend to revert to using vile a lot of the time because I can use the > systems GUI fonts as opposed to the very limited X fonts. However I'm > just doing something again which is much more suited to xvile. > > -- > Chris Green > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Hopefully quick mode question
On Sun, Apr 12, 2020 at 03:04:39PM -0500, Steven Lembark wrote:
>
> When I edit files with '.c' in them I end up in cmode.
> Annoying thing is that this inlcudes "*.conf" files.
>
> To the best of my recollection the only places that should put
> me in C mode are:
>
> set c-suffixes '\.([ch]\|xs)$'
>
> define-majormode c
> remove-submode c cindent
> ~with define-submode c
> suffixes '\.[ch]$'
> notabinsert
> tabstop=4
> shiftwidth=4
> ~endwith
>
> (note that I last looked at this a few decades ago when most of
> my work was in C... recollection is fuzzy).
>
> i.e., edit with C format for strings endin in ".c", ".h", and ".xs"
> a.k.a. m{ [.] ( [ch]|xs ) $}x.
>
> Q: Why would these get caught on "*.conf" basenames?
It shouldn't. But you can (part of) the trace by doing
vile -D *.conf
and looking at the [Trace] buffer.
For instance, running that in /etc (where I've a few .conf files),
I see these lines:
** opened /etc/adduser.conf for read
matched preamble of adduser.conf
...inferred majormode conf
while in another directory, I might see matches by suffix:
** opened /usr/build/vile/vile/perl.xs for read
matched suffix of perl.xs
...inferred majormode xs
(showing all of the comparisons is a different matter - the compile-time
debug trace would show _that_).
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: paste-from-clipboard vs register ;
On Fri, Apr 03, 2020 at 08:27:19PM +0200, Gary Jennejohn wrote: > On Fri, 3 Apr 2020 15:45:42 + > Wayne Cuddy wrote: > > > Using the latest xvile but I don't believe the version makes a > > difference. > > > > I know there is data in the clipboard. > > > > If issue :paste-from-clibpard it works as expected. > > > > Per the help doc. > > > >The register name '.' contains the current selected text in xvile. Also > > in > >xvile, the register name ';' is a synonym for the clipboard. Other > >versions of vile permit use of '.' and ';' as supplemental register > >storage. > > > > However when data is in the clipboard and I do ";p I receive 'nothing > > in register ;]'. > > > > Right, '.'works but ';' does not. So, it's either a bug in xvile or > in the help doc. Partly the latter. Reading the code (x11.c), it seems that the intent was to have a key-binding which would tell xvile to copy from the keyboard, and record that information in the ";' register. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Inserting text of arbitrary length before rectangular region
On Thu, Mar 05, 2020 at 05:05:15PM -0500, Paul Fox wrote: > marc wrote: > > On Thu, Mar 5, 2020 at 1:43 PM Paul Fox wrote: > > > > > > marc wrote: > > > > I'd go the traditional vi route, > > > > > > Yes, clearly in this case, where the insertion is at the start > > > of a line, that's easiest. > > > > Right; I don't have a good solution for inserting between two columns. > > Maybe we really could use a rectangular insert, that works kind of > like the 'c' command except that instead of overwriting a rectangle, > it first opens a rectangle of exactly the right width. > > (Hmmm. I wonder what I did with that compiler. I used to have one > around here somewhere... Heck, I don't think I have a recent vile > source tree.) I do (along with about 90 other source-trees and a few hundred git clones). Not that I'm uninterested (rectangles come up occasionally), but I'm more interested in fixing winvile with Windows 10 :-( At the moment I'm working on xterm, thinking that I might squeeze in some development on winvile before putting out another fire :-) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Python filter: incomplete triple-quoted string support
On Tue, Feb 04, 2020 at 08:55:55PM -0800, Marc Simpson wrote:
> The current filter (py-filt.l) only supports triple-quoted strings
> formed with double quotes; single quote multi-line literals are
> incorrectly highlighted, e.g.
hmm - I overlooked that (when I wrote it in 1999).
> '''
> 'foo'
> bar
> '''
>
> Naive patch: declare QUOTE4, duplicate and adapt the existing QUOTE3
> block:
>
> %s NORMAL QUOTE1 QUOTE2 QUOTE3 QUOTE4
>
> ...
>
> \'\'\' { BeginQuote(QUOTE4, String_attr); }
> \'\'\' { FinishQuote(NORMAL); }
> (\\.|.) { flt_bfr_append(yytext, yyleng); }
> [\n]{ flt_bfr_append(yytext, yyleng); }
>
> (This can surely be simplified.)
Only a little.
The last two lines can be combined with the similar QUOTE3 ones,
like this:
(\\.|.) { flt_bfr_append(yytext, yyleng); }
[\n]{ flt_bfr_append(yytext, yyleng); }
lex doesn't have macros, or something analogous, so the other two
lines in each chunk can't be merged.
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: Crash with unmatched patterns
On Sun, Jan 12, 2020 at 09:53:20AM -0800, Marc Simpson wrote: > On Sun, Jan 12, 2020 at 9:51 AM Thomas Dickey wrote: > > > > - Original Message - > > | From: "Marc Simpson" > > | To: "Thomas Dickey" > > | Cc: "Vile mailing list" > > | Sent: Sunday, January 12, 2020 12:46:28 PM > > | Subject: Re: Crash with unmatched patterns > > > > | On Sun, Jan 12, 2020 at 9:33 AM Thomas Dickey wrote: > > |> > > |> On Sat, Jan 11, 2020 at 09:36:25AM -0800, Marc Simpson wrote: > > |> > Hitting n or N after searching for an unmatched pattern with / or ? > > |> > crashes vile. > > |> > > > |> > To reproduce: > > |> > > |> I've tried this, but am not able to reproduce it :-( > > |> > > |> (it might depend on the platform - I'm using 64-bit Debian 8 - > > |> or it might depend on the .vilerc) > > | > > | Ah, sorry---it's setting specific here too. This combination seems to > > | trigger the crash: > > | > > | set ic scs > > | > > | while 'ic' and 'scs' on their own yield "Not found". > > | > > | Able to reproduce? > > > > yes - thanks :-) > > > > I'll make a fix and push that out (probably today). > > Thanks as always Tom. no problem - that's v9_8t18 -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Crash with unmatched patterns
- Original Message - | From: "Marc Simpson" | To: "Thomas Dickey" | Cc: "Vile mailing list" | Sent: Sunday, January 12, 2020 12:46:28 PM | Subject: Re: Crash with unmatched patterns | On Sun, Jan 12, 2020 at 9:33 AM Thomas Dickey wrote: |> |> On Sat, Jan 11, 2020 at 09:36:25AM -0800, Marc Simpson wrote: |> > Hitting n or N after searching for an unmatched pattern with / or ? |> > crashes vile. |> > |> > To reproduce: |> |> I've tried this, but am not able to reproduce it :-( |> |> (it might depend on the platform - I'm using 64-bit Debian 8 - |> or it might depend on the .vilerc) | | Ah, sorry---it's setting specific here too. This combination seems to | trigger the crash: | | set ic scs | | while 'ic' and 'scs' on their own yield "Not found". | | Able to reproduce? yes - thanks :-) I'll make a fix and push that out (probably today). -- Thomas E. Dickey http://invisible-island.net ftp://ftp.invisible-island.net
Re: Crash with unmatched patterns
On Sat, Jan 11, 2020 at 10:08:56AM -0800, Marc Simpson wrote: > On Sat, Jan 11, 2020 at 9:58 AM Chris Green wrote: > > > > On Sat, Jan 11, 2020 at 09:36:25AM -0800, Marc Simpson wrote: > > > Hitting n or N after searching for an unmatched pattern with / or ? > > > crashes vile. > > > > > > To reproduce: > > > > > > /\( > > > > > > Vile reports > > > > > > [Bad pattern: unmatched () ] > > > > > > which is all well and good. Then hit > > > > > > n > > > > > > to attempt searching again (for the bad pattern); this should > > > reproduce the crash. > > > > > Doesn't happen for me, running version 9.8t on xubuntu. > > > > When I hit n after the unmatched one I just see "Search reached bottom > > without matching patter". > > Thanks for checking Chris. I'm using the latest snapshot here on > macOS and OpenBSD. > > I think the issue might be > > https://github.com/ThomasDickey/vile-snapshots/blob/master/search.c#L819 > > which, in the event of failed compilation, doesn't clear apat (used to > set searchpat in the caller). > > I believe that this means that the pattern exists as far as n and N > are concerned, even though it's failed to compile: > > https://github.com/ThomasDickey/vile-snapshots/blob/master/search.c#L179 maybe - but that variable's used for the initial prompted value when doing another '/' command. I tried reproducing this with my default (package) build on Debian 8, and then using address-sanitizer in a one-off build. With the latter, (or using valgrind), I'd usually manage to see the problem. > I've only had time for a quick look, so this analysis might be completely off. > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Crash with unmatched patterns
On Sat, Jan 11, 2020 at 09:36:25AM -0800, Marc Simpson wrote: > Hitting n or N after searching for an unmatched pattern with / or ? > crashes vile. > > To reproduce: I've tried this, but am not able to reproduce it :-( (it might depend on the platform - I'm using 64-bit Debian 8 - or it might depend on the .vilerc) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Fwd: :show-marks
On Thu, Dec 19, 2019 at 06:00:41PM -0500, Thomas Dickey wrote: > On Thu, Dec 19, 2019 at 10:28:52AM -0800, Marc Simpson wrote: > > On Thu, Dec 19, 2019 at 10:09 AM Paul Fox wrote: > > > > > > marc wrote: > > > > On Thu, Dec 19, 2019 at 9:20 AM Marc Simpson wrote: > > > > > > > > > > It looks like :show-marks (or :marks, :list-marks) erroneously > > > > > displays '(none)' for buffers that have one or more marks. > > > > > > > > I only just noticed the most significant part of this problem: > > > > > > > > Named marks for [Named Marks] > > > > (none) > > > > > > > > i.e., :marks is listing marks for its own buffer, not the buffer that > > > > was being edited. > > > > > > > > > > I think it's because the [Named Marks] buffer is current. If you > > > switch back to your edit buffer, the [Named Marks] buffer updates > > > correctly. > > > > Confirmed here too; thanks Paul. > > > > > So it seems like :show-marks buffer is being made current, > > > when it shouldn't be. > > > > Agreed. > > hmm - I probably should review the various commands which create buffers > to see if there's other stuff to fix (or possibly add a mode to control > the behavior). I read through these, didn't see any obvious to change... > > Sidenote/related: It also looks like marks in the [Named Marks] buffer > > are ignored, even though the "[Mark 'x' set]" is displayed. If this > > is intentional, then perhaps that message should be suppressed or > > changed. > > thanks (on my to-do list) I added that :-) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Fwd: :show-marks
On Thu, Dec 19, 2019 at 10:28:52AM -0800, Marc Simpson wrote: > On Thu, Dec 19, 2019 at 10:09 AM Paul Fox wrote: > > > > marc wrote: > > > On Thu, Dec 19, 2019 at 9:20 AM Marc Simpson wrote: > > > > > > > > It looks like :show-marks (or :marks, :list-marks) erroneously > > > > displays '(none)' for buffers that have one or more marks. > > > > > > I only just noticed the most significant part of this problem: > > > > > > Named marks for [Named Marks] > > > (none) > > > > > > i.e., :marks is listing marks for its own buffer, not the buffer that > > > was being edited. > > > > > > > I think it's because the [Named Marks] buffer is current. If you > > switch back to your edit buffer, the [Named Marks] buffer updates > > correctly. > > Confirmed here too; thanks Paul. > > > So it seems like :show-marks buffer is being made current, > > when it shouldn't be. > > Agreed. hmm - I probably should review the various commands which create buffers to see if there's other stuff to fix (or possibly add a mode to control the behavior). > Sidenote/related: It also looks like marks in the [Named Marks] buffer > are ignored, even though the "[Mark 'x' set]" is displayed. If this > is intentional, then perhaps that message should be suppressed or > changed. thanks (on my to-do list) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: iclower
On Thu, Dec 19, 2019 at 07:48:35PM +1100, Brendan O'Dea wrote: > 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. builds ok (I'm slow on 9.8u since I have two problems with Windows 10) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: iclower
On Wed, Dec 18, 2019 at 11:00:44AM -0800, Marc Simpson wrote:
> Hi all,
>
> [I forget whether this has been discussed before; a preliminary
> search on https://lists.nongnu.org/archive/html/vile/ suggests not:]
I don't recall that, though it reminds me of a couple of things on my to-do
list...
> 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.
>
> where /abc/ matches {'abc', 'Abc', 'ABC', ...} but /Abc/ only matches
> 'Abc'. This is convenient if your typical preference is for case
> insensitive matching but you occasionally need to search for
> uppercased constants, class names or other identifiers where case
> is used contrastively. `ignorecase' typically frustrates this use
> case (at least for short inputs), so toggling case sensitivity
> (`set noic') is typically required to avoid being flooded with false
> positives.
>
> 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)))
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature
Re: vile.hlp typo
- Original Message - | From: "Marc Simpson" | To: "Thomas Dickey" | Cc: "Vile mailing list" | Sent: Wednesday, December 4, 2019 8:33:14 PM | Subject: Re: vile.hlp typo | On Wed, Dec 4, 2019 at 4:23 PM Marc Simpson wrote: |> |> On Wed, Dec 4, 2019 at 3:55 PM Thomas Dickey wrote: |> |> > I'll proofread through that, and make a snapshot with just the various |> > formatting changes (thanks). |> |> Thanks Tom. | | I see that v9_8t12 has been committed and pushed. Not sure whether | you're aware that this only fixes a few of the above issues? For | example, | | https://github.com/ThomasDickey/vile-snapshots/blob/master/vile.hlp#L637 | https://github.com/ThomasDickey/vile-snapshots/blob/master/vile.hlp#L1185 | | are still incorrectly formatted. sorry - I was paying attention to the html, and in that file, those are at the end of a line. -- Thomas E. Dickey http://invisible-island.net ftp://ftp.invisible-island.net
Re: vile.hlp typo
On Wed, Dec 04, 2019 at 09:35:28AM -0800, Marc Simpson wrote: > On Wed, Dec 4, 2019 at 9:06 AM Marc Simpson wrote: > > > > On Wed, Dec 4, 2019 at 9:01 AM Marc Simpson wrote: > > > > > > Very minor typo (looks like hyphenated text that was subsequently joined): > > A couple more (sorry for the incremental suggestions): > > 1185: You can also type a question mark (or the current "test- completions" > 3037: vile will reapply mapping to the result of a system- defined map. System hmm - I see. These date from when I switched from the original vile.hlp to the html version (and generating vile.hlp _from_ vile-hlp.html). Just over ten years ago. So I'll make the fixes to vile-hlp.html However, I see that since I generated this using my Debian 8 machine in April, that the formatting using Debian 9 differs for tables (column-widths and table-widths change). That's going from links 2.8 to 2.14, noting that I started doing this formatting around links 2.3. I'll proofread through that, and make a snapshot with just the various formatting changes (thanks). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: New user question
On Tue, Nov 19, 2019 at 05:18:18PM -0500, Paul Fox wrote: > thomas wrote: > > Hi, > > > > I’m a new user of vile and I really like it. It is fast and the > > mix of emacs and vi is good. I’m coming from emacs keybindings and > > I find vile’s default to be really nice. > > > > I have a question regarding storing sessions and history. Is there > > some way to let vile remeber which files are opened? Furthermore, > > can vile remember the search strings history? > > Not between sessions, that I'm aware of. Search strings are remembered > within a session, of course. winvile (Clark Morgan's contribution here) does remember up to the last 20 files and directories, which I've found useful. But reopening a file at the last place I was editing never seemed useful enough to want to implement it (since I'm _done_ at the previous location). That, and because saving/reloading all of the relevant state would be a performance hit. however (as usual) I'll take into account patches, etc. (at the moment I'm filling in the other 90% on a recent change for byacc) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Xvile command line option -xrm
On Sat, Nov 09, 2019 at 11:17:27PM +1100, Brendan O'Dea wrote: > I don't recall having to use .Xdefaults-`hostname` in the past, but it > certainly behaves that way now. Maybe this is to support NFS mounted > homedirs? In any case, I can't think of a case where I've ever wanted to > change the behaviour of an X program based on which host it was executed > from. The source code in X11 says that the library tries first to get the settings from the X server using $HOME/.Xdefaults, _if_ it had no data previously in the initialization. Then it reads from $HOME/.Xdefaults-`hostname`, if $XENVIRONMENT is not set. The comments in the code refer to getting the resource manager database during opening the X display. I suppose you'd see this behavior if "xrdb -query" shows any (string) properties -- actually I don't see any output (using MacOS). In a Linux "desktop", there's some output. It's done this since X11R4. > Consider using .Xresources rather than .Xdefaults: the former are loaded > into the X server, so are linked to a particular display environment, > whereas the latter are set based on the client. > > In my case, typically I care more about the server than the client for > things like font size: for example, when using my laptop the resources are > configured to suit a 14" screen at a particular resolution, and those same > settings are used when I run xvile either locally, or remotely on my > workstation over ssh. When sitting at my workstation which has a somewhat > larger screen, I want different settings configured in the X server. By > using .Xresources rather than .Xdefaults the same invocation of xvile > behaves appropriately depending on where it is being displayed, rather than > where was invoked from. > > For most desktop environments, ~/.Xresources should be loaded at login. I use those sometimes :-) > Note that if you make changes you will need to run xrdb to pick them up. I don't do that :-) (xrdb interferes with dynamic loading of resources by applications) > See also https://wiki.archlinux.org/index.php/x_resources > > On Sat, 9 Nov 2019 at 10:02, Thomas Dickey wrote: > > > On Fri, Nov 08, 2019 at 12:34:14PM +0100, Gary Jennejohn wrote: > > > Hi, > > > > > > I'm using Xvile 98.t and am trying to create a bash alias using > > > -xrm to set various X resources. > > > > > > I'm doing this because I'm starting Xvile over a ssh login and > > > for some reason the XVile settings in .Xdefaults are not being > > > used by the Xorg server on the computer from which I'm logging > > > in. Using ssh -X does not help. > > > > man X tells me ... -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: Xvile command line option -xrm
On Fri, Nov 08, 2019 at 12:34:14PM +0100, Gary Jennejohn wrote: > Hi, > > I'm using Xvile 98.t and am trying to create a bash alias using > -xrm to set various X resources. > > I'm doing this because I'm starting Xvile over a ssh login and > for some reason the XVile settings in .Xdefaults are not being > used by the Xorg server on the computer from which I'm logging > in. Using ssh -X does not help. man X tells me XENVIRONMENT Any user- and machine-specific resources may be specified by setting the XENVIRONMENT environment variable to the name of a resource file to be loaded by all applications. If this vari‐ able is not defined, a file named $HOME/.Xdefaults-hostname is looked for instead, where hostname is the name of the host where the application is executing. -xrm resourcestring Resources can also be specified from the command line. The resourcestring is a single resource name and value as shown above. Note that if the string contains characters interpreted by the shell (e.g., asterisk), they must be quoted. Any number of -xrm arguments may be given on the command line. Perhaps your ".Xdefaults" isn't linked to ".Xdefaults-hostname" > The target computer has just enough of Xorg installed to allow > Xvile to run. > > Unfortunately, the syntax required for -xrm isn't explained > anywhere in the help file. > > Any examples on how to use -xrm? It's borrowed from xterm, but actually is an X Toolkit option. Here, "appres XVile" gives me a longish list, e.g., *menubar*foreground:black *menubar*borderColor: grey *menubar.hSpace:1 *menubar.vSpace:1 *menubar*background:grey and I could pass each of those as an -xrm option by quoting it, e.g., xterm \ -xrm '*menubar*foreground: black' \ -xrm '*menubar*borderColor: grey' \ -xrm '*menubar.hSpace: 1' \ -xrm '*menubar.vSpace: 1' \ -xrm '*menubar*background: grey' but actually setting XAPPLRESDIR (mentioned just before the chunk I quoted) lets one set up a directory where X will search for the "XVile" file: application-specific files Directories named by the environment variable XUSERFILESEARCH‐ PATH or the environment variable XAPPLRESDIR (which names a single directory and should end with a '/' on POSIX systems), plus directories in a standard place (usually under /usr/share/X11/, but this can be overridden with the XFILE‐ SEARCHPATH environment variable) are searched for for applica‐ tion-specific resources. For example, application default resources are usually kept in /usr/share/X11/app-defaults/. See the X Toolkit Intrinsics - C Language Interface manual for details. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: [vile] spellflt.l: Include UTF-8 code points
On Mon, Jun 24, 2019 at 06:22:00AM +0200, Michael von der Heide wrote:
> > Possibly clearer (ispell on my Debian8 works with this):
> >
> > diff -u -r1.59 filters/spellflt.l
> > --- filters/spellflt.l 2013/12/02 01:32:53 1.59
> > +++ filters/spellflt.l 2019/06/23 20:28:42
> > @@ -157,7 +157,10 @@
> >
> > %}
> >
> > -WORD [[:alpha:]]([[:alnum:]])*
> > +ALPHA [[:alpha:]]
> > +UMLAUT \xc3[\x80-\xbf]
> > +LETTER ({ALPHA}|{UMLAUT})+
> > +WORD {LETTER}({LETTER}|[[:digit:]])*
> >
> > %%
> >
> This one is probably better and works for me too.
sounds good - see
https://github.com/ThomasDickey/vile-snapshots
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: Digital signature
___
vile mailing list
vile@nongnu.org
https://lists.nongnu.org/mailman/listinfo/vile
Re: [vile] spellflt.l: Include UTF-8 code points
On Sun, Jun 23, 2019 at 09:47:18PM +0200, Michael von der Heide wrote:
> It works (hunspell) for me with words like "prüfen" or "Straße". Flex
> generates an 8-bit scanner. UTF-8 should work. Would you mind testing it?
sorry - when you said "code points", I had in mind Unicode.
Applying the term to UTF-8 sequences doesn't seem entirely correct,
though I'm aware people use the two interchangeably. (not to argue,
but a string isn't a point)
lex/flex will allow ranges, and hexadecimal's standard (hence "lex" too):
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/lex.html
> --
> Michael von der Heide
>
>
> Thomas Dickey schrieb am So., 23. Juni 2019, 21:24:
>
> > On Sun, Jun 23, 2019 at 07:42:26PM +0200, Michael von der Heide wrote:
> > > Would it be possible to include UTF-8 code points to check words
> > containing
> > > umlauts?
> > >
> > > WORD ([a-zA-Z]|\xc3[\x80-\xbf])+
for reference, that's the UTF-8 encoding for the Unicode codepoints 192-255:
192: 192 0300 0xc0 text "\300" utf8 \303\200
255: 255 0377 0xff text "\377" utf8 \303\277
and
0303: 195 0303 0xc3 text "\303" utf8 \303\203
0200: 128 0200 0x80 text "\200" utf8 \302\200
0277: 191 0277 0xbf text "\277" utf8 \302\277
Possibly clearer (ispell on my Debian8 works with this):
diff -u -r1.59 filters/spellflt.l
--- filters/spellflt.l 2013/12/02 01:32:53 1.59
+++ filters/spellflt.l 2019/06/23 20:28:42
@@ -157,7 +157,10 @@
%}
-WORD [[:alpha:]]([[:alnum:]])*
+ALPHA [[:alpha:]]
+UMLAUT \xc3[\x80-\xbf]
+LETTER ({ALPHA}|{UMLAUT})+
+WORD {LETTER}({LETTER}|[[:digit:]])*
%%
> > > WORD ([a-zA-Z]|\xc3[\x80-\xbf])+
> >
> > lex/flex doesn't do that :-(
> >
> > They use small (256-entry) tables for the character types.
> >
> > I've seen a (long ago) patch to use big tables (which I've read
> > doesn't work well).
> >
> > on my (too-long) to-do list, I have an idea which could be developed,
> > to provide the feature using character-classes. That is, flex could
> > be modified (perhaps a month's work...)
--
Thomas E. Dickey
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: Digital signature
___
vile mailing list
vile@nongnu.org
https://lists.nongnu.org/mailman/listinfo/vile
Re: [vile] spellflt.l: Include UTF-8 code points
On Sun, Jun 23, 2019 at 07:42:26PM +0200, Michael von der Heide wrote: > Would it be possible to include UTF-8 code points to check words containing > umlauts? > > WORD ([a-zA-Z]|\xc3[\x80-\xbf])+ lex/flex doesn't do that :-( They use small (256-entry) tables for the character types. I've seen a (long ago) patch to use big tables (which I've read doesn't work well). on my (too-long) to-do list, I have an idea which could be developed, to provide the feature using character-classes. That is, flex could be modified (perhaps a month's work...) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature ___ vile mailing list vile@nongnu.org https://lists.nongnu.org/mailman/listinfo/vile
Re: [vile] FTP URL acting strange
On Sun, Apr 07, 2019 at 02:18:22PM -0400, Thomas Dickey wrote: > On Sun, Apr 07, 2019 at 02:03:15PM -0400, Wayne Cuddy wrote: > > On Sun, Apr 07, 2019 at 01:45:10PM -0400, Thomas Dickey wrote: > > > > > > actually the person who pointed out the problem to me was trying > > > to use wget - that didn't work, and nor do any of my browsers. > > > > > > > Should I update the slackbuild with /pub inserted or is this temporary > > > > situation. > > > > > > Using an explicit "/pub" should work for some time :-) > > > > > > -- > > > Thomas E. Dickey > > > https://invisible-island.net > > > ftp://ftp.invisible-island.net > > > > I'll update the Slackbuild.. thank you Tom. > > no problem (report bugs) Revisiting this, I experimented and found that changing the form of the links seems to work around the problem. Before, I had this (for a long time) vile -> pub/vile but changing it to vile -> /pub/vile seems to work. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature ___ vile mailing list vile@nongnu.org https://lists.nongnu.org/mailman/listinfo/vile
Re: [vile] FTP URL acting strange
On Sun, Apr 07, 2019 at 02:03:15PM -0400, Wayne Cuddy wrote: > On Sun, Apr 07, 2019 at 01:45:10PM -0400, Thomas Dickey wrote: > > > > actually the person who pointed out the problem to me was trying > > to use wget - that didn't work, and nor do any of my browsers. > > > > > Should I update the slackbuild with /pub inserted or is this temporary > > > situation. > > > > Using an explicit "/pub" should work for some time :-) > > > > -- > > Thomas E. Dickey > > https://invisible-island.net > > ftp://ftp.invisible-island.net > > I'll update the Slackbuild.. thank you Tom. no problem (report bugs) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature ___ vile mailing list vile@nongnu.org https://lists.nongnu.org/mailman/listinfo/vile
Re: [vile] FTP URL acting strange
On Sun, Apr 07, 2019 at 12:39:23PM -0400, Wayne Cuddy wrote: > I maintain the slackbuild for vile, currently using rev 9.8s. > > It's worked in the past for many years but something has recently > broken the FTP URL source path via curl. > > Here is a build attempt that fails at the download phase: > > root@snow:/tmp# slapt-src -i vile > The following packages will be installed: > vile > Do you want to continue? [y/N] y > Fetching README...Done > Fetching patches/sh-filt.patch...Done > Fetching slack-desc...Done > Fetching vile.SlackBuild...Done > Fetching vile.info...Done > Fetching > ftp://ftp.invisible-island.net/vile/current/vile-9.8s.tgz...Failed yes - something changed with my ISP about two weeks ago and asking them got no useful information other than that they're using ProFTPD. See http://lists.gnu.org/archive/html/bug-ncurses/2019-03/msg00022.html http://lists.gnu.org/archive/html/bug-ncurses/2019-03/msg00025.html This should work: ftp://ftp.invisible-island.net/pub/vile/current/vile-9.8s.tgz...Failed ^^^ It's not handling the symbolic links used to make "/pub/vile" look like "/vile", etc. I added those symlinks at the top-level in 2007 (last rebuilt in 2013) to cover up a previous change they made. > * Connected to ftp.invisible-island.net (216.194.196.78) port 21 (#0) > < 220 ProFTPD Server (ftp.invisible-island.net) [216.194.196.78] :-) > The problem appears to permissions in the intial /vile directory? no - I think the problem is that the way ProFTPD's handling symlinks either changed due to an upgrade, or someone modified the configuration. Perhaps that involves permissions, but only within ProFTPD (the website's still the same). Either way, it's not visible to me: the configuration is outside the container that my website runs in. (On the plus side, I might be able to set up ProFTPD on a local machine and see how they might have broken it, to advise...). > Connected to ftp.invisible-island.net (216.194.196.78). > 220 ProFTPD Server (ftp.invisible-island.net) [216.194.196.78] > Name (ftp.invisible-island.net:wcuddy): anonymous > 331 Anonymous login ok, send your complete email address as your password > Password: > 230 Anonymous access granted, restrictions apply > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> cd /vile > 550 /vile: No such file or directory > ftp> cd /vile/current > 250 CWD command successful > > Looks like curl changes directories one at time but wget performs > the complete CD at once. > > I can get curl to work inserting /pub into the URL: > ftp://ftp.invisible-island.net/pub/vile/current/vile-9.8t.tgz actually the person who pointed out the problem to me was trying to use wget - that didn't work, and nor do any of my browsers. > Should I update the slackbuild with /pub inserted or is this temporary > situation. Using an explicit "/pub" should work for some time :-) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature ___ vile mailing list vile@nongnu.org https://lists.nongnu.org/mailman/listinfo/vile
Re: [vile] multiline abbreviations, is it possible?
On Sun, Jan 20, 2019 at 10:22:21AM -0500, Wayne Cuddy wrote: > > I tried: > > :abb XXX line1^V^Mline2 I use map for this: map #3 oThe current version of vile is 9.8 It's available at https://invisible-island.net/vile/vile.html ftp://ftp.invisible-island.net/vile/ https://invisible-mirror.net/archives/vile/ but don't recall anything about abbreviate > But when I type XXX it simply outputs line1^V^Mline2 without > inserting a new line. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature ___ vile mailing list vile@nongnu.org https://lists.nongnu.org/mailman/listinfo/vile
Re: [vile] Help the poor windows user!
On Wed, Dec 12, 2018 at 12:31:48PM +, Gavin Holt wrote: > Hi > > I am grateful that you take the time to provide a win32 executable ( I > don't have the skills to compile code). Of all the console based editors > vile has the best screen/mouse functionality under Windows, it appears to > have the most customisable UI and it is the fastest to load! > > The macro language and list of all commands offers the opportunity for a > life time of incremental improvements to the practice of text editing. It > is obvious to me that proper editing requires a command line - you can only > have so many nested menus! The web site is helpful and I have tried to > reference the available documentation. > > My problem is that I would like to reassign some keys bindings to match my > CUA / windows muscle memory, but my attempts are not going well. I am using > a standard 101/102-key PC keyboard under windows 7/10. I am obviously doing > something wrong: > > ; --- Modeless key bindings --- > > bind-key goto-line ^G ; how to ask for line number? > bind-key next-buffer ^I ; Works > ;bind-key next-buffer ^TAB ; Fails to load > bind-key write-changed-buffers ^W ; Fails > > > ; --- Insert mode key bindings --- > > bind-insmode-key goto-bol FN-H ; Works > bind-insmode-key goto-eol FN-E ; Works > bind-insmode-key goto-beginning-of-file ctrl+FN-H ; Works > bind-insmode-key goto-end-of-file ctrl+FN-E ; Works > bind-insmode-key search-forward ^F ; Fails > bind-insmode-key undo-change ^Z ; Fails > > ; --- Command mode key bindings --- > > bind-cmdmode-key goto-bol FN-H ; Fails > bind-cmdmode-key goto-eol FN-E ; Fails > bind-cmdmode-key goto-beginning-of-file ctrl+FN-H ; Fails > bind-cmdmode-key goto-end-of-file ctrl+FN-E ; Fails > bind-cmdmode-key edit-file ^O ; Fails > > Although you may recommend abandoning myself to the "vi(le) way", I would > be grateful for pointers to some documentation explaining how to map keys - > written for a windows user used to ctrl/shift/alt modifiers and "normal" > function/navigation key descriptions. I will try multi-key bindings in the > future but only if I can get passed these hurdles. > > Any pointers to examples or a translation table for the key descriptions > would be welcome. Please note I like the console version not winvile. These (same feature) show the predefined keys: show-key-names list-key-names Known keys are internally defined to associate them with "real" keys. But for determining what's a workable binding, I'd use something like one of these commands :bind-key describe-key K :bind-key describe-insmode-key K :bind-key describe-cmdmode-key K :bind-key describe-selmode-key K to temporarily assign "K" to promoting for the keys to verify. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: Digital signature ___ vile mailing list vile@nongnu.org https://lists.nongnu.org/mailman/listinfo/vile
