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> wrote:

>no problem - I see what's going on now. The reason it's been working for
>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 stuff ;)

I have to use to-do lists to remind me what I'm working on.
wc -l says this:

  10649 /users/tom/NOTES/ncurses
  10705 /users/tom/NOTES/other
   6543 /users/tom/NOTES/xterm
  27897 total

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 if
>      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 tom
>tags:            v9_8s6
>   allow tags (read from a tags file) to be any graphic character.  It
>turns out
>   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))
>            break;
>        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 case -- if one uses ctags `--regex' for handling of some language unknown to ctagss
- 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 most
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[1]: `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 side, but after a preceding `make clean' it simply isn't there? this sure is innocuous but should the warning not better be silenced (or tested for existence of
`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 :-)

right. :)

Using Opera's revolutionary email client: http://www.opera.com/mail/

vile mailing list

Reply via email to