On Sun, 11 Mar 2018 21:55:12 +0100, Thomas Dickey <dic...@his.com> wrote:
On Sun, Mar 11, 2018 at 09:38:09PM +0100, j. van den hoff wrote:
On Sun, 11 Mar 2018 18:40:26 +0100, Thomas Dickey <dic...@his.com>
>no problem - I see what's going on now. The reason it's been working
>me was that (I'd forgotten of course) one of my fixes from last year
of course. good to see that I am not the only one forgetting about
I have to use to-do lists to remind me what I'm working on.
wc -l says this:
ok. I see :)
(I've recently stumbled about `http://taskwarrior.org' and gave it a try.
for me, it seems it is one step forward from my TODO lists despite a
somewhat quirky parser/ui)
>dots in the names.
> 20170820 (t)
> > Tom Dickey:
> + modify character class assumed for tags, to check for graphic
> characters. Previously that used qident (cf: 9.7g), which did not
> allow for dots in filenames which could be present in a ctags file
> it were generated using "ctags --extra=+f *" (Savannah #51774).
>The actual change is small:
>REV:1.150 tags.c 2017/08/20 23:08:32
> allow tags (read from a tags file) to be any graphic character. It
> that Hiebert's ctags can point to filenames vs identifiers.
>--- tags.c 2013/09/20 23:00:36 1.149
>+++ tags.c 2017/08/20 23:08:32 1.150
>@@ -212,7 +212,7 @@
> return; /* ignore super-long identifiers */
> c = lgetc(lp, got);
>- if (!isqident(c))
>+ if (!isGraph(c))
> my_name[got] = (char) c;
indeed... with this patch it is working perfectly. really thanks a lot!
regarding your changelog comment: in fact it (the appearance of `.' or
whatever in the tagnames) can also occur more generally -- as in my
if one uses ctags `--regex' for handling of some language unknown to
- such as `R'...
yes - I suppose I should make the command-line and screen-mode tags
closer together. The screen-mode function is shared with the search
command, which may not be the right thing.
>I've been working on lynx for the past few weeks,
>thinking to get vile up to date after that's done.
that would be great. as far as I am concerned `vile' remains by far the
likeable `vi' look-alike around. --
sounds good. I was working on lynx and vile last year to update the
Windows port (for 64-bit support), but got distracted with a pile of
work in ncurses/xterm. That's stable, but I got behind somewhat on
the other large programs.
FYI, I've just noted that at the end of the `make' run the output reads
make: `libvlflt.a' is up to date.
mv vile ovile
mv: rename vile to ovile: No such file or directory
make: [vile] Error 1 (ignored)
that's a detail that was leftover from Paul Fox's makefile, that
I never thought important enough to change. I could fix that...
well, considering the `wc' above, this is maybe not that pressing ;)
it seems the Makefile tries to mv a previously build binary to the
after a preceding `make clean' it simply isn't there? this sure is
but should the warning not better be silenced (or tested for existence
`vile' before trying to mv it)?
I could do "mv -f" (which may quiet things).
sorrily, it does not. it only changes the error message somewhat it seems
That wasn't standard 20 years ago :-)
Using Opera's revolutionary email client: http://www.opera.com/mail/
vile mailing list