| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 51:26:52 |
| Calls: | 422 |
| Files: | 1,025 |
| Messages: | 90,551 |
Urs Janssen <urs@buil.tin.org> wrote:
meanwhile you might be able to use something like (depends on your $SHELL) >>editor_format=%E +$((%N - 1)) %F
Thank you, I can adapt this to my shell. I am not sure, however,
it will work with follow-ups, because they are OK as is. At least,
I can simply ignore the error and be glad that you fixed the bug
upsteam.
Joerg Mertens <joerg-mertens@t-online.de> wrote:
Anton Shepelev <anton.txt@gmail.moc> wrote:
Urs Janssen <urs@buil.tin.org> wrote:
meanwhile you might be able to use something like (depends on your $SHELL) >>>>editor_format=%E +$((%N - 1)) %F
Thank you, I can adapt this to my shell. I am not sure, however,
it will work with follow-ups, because they are OK as is. At least,
I can simply ignore the error and be glad that you fixed the bug
upsteam.
You can also tell nvi to jump to the last line with
# vi +'$' file
or
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
Anton Shepelev <anton.txt@gmail.moc> wrote:
Urs Janssen <urs@buil.tin.org> wrote:
meanwhile you might be able to use something like (depends on your $SHELL) >>>editor_format=%E +$((%N - 1)) %F
Thank you, I can adapt this to my shell. I am not sure, however,
it will work with follow-ups, because they are OK as is. At least,
I can simply ignore the error and be glad that you fixed the bug
upsteam.
You can also tell nvi to jump to the last line with
# vi +'$' file
or
# vi -c'$' file
So you can just ignore the %N.
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
Joerg Mertens <joerg-mertens@t-online.de> wrote:
Joerg Mertens <joerg-mertens@t-online.de> wrote:
You can also tell nvi to jump to the last line with
# vi +'$' file
or
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
I love this noise and am glad to meet a vi user online. Have you
noticed that its -c option is documented as if accepting the command
after a space: -c <cmd> ? This form does not work for me, and I
have to use it without the inervening space: -c<cmd> . Is it an
error in the man page, or I am missing someting?
Anton Shepelev <anton.txt@gmail.moc> wrote:
I love this noise and am glad to meet a vi user online. Have you
noticed that its -c option is documented as if accepting the command
after a space: -c <cmd> ? This form does not work for me, and I
have to use it without the inervening space: -c<cmd> . Is it an
error in the man page, or I am missing someting?
It works here with both the system nvi (OpenBSD) and the nvi from ports.
The former is version 1.79 and the ports nvi is 2.2.1.
For example:
# vi -c '/^$/' file
starts on the first blank line of the file,
Joerg Mertens wrote:
# vi -c'$' file
So you can just ignore the %N.
... wich also won't work with followups, by the way.
Sorry for the noise.
vim -c":silent! +%N" %F
should work for vim/nvi
Anton Shepelev wrote:
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed
intentionally?
kinda, just tested it with an editor which doesn't complain _and_ jumps
one line _past_ the last line if called with +N > lines_in_file (e.g.
nano, joe, ...). I'll revert that change (= adding an additional
\n to the stub):
Somewhat related to this problem, is another, when Tin passes 0 for
%N, whereas the lines are numbered from unity (1). Consequently,
nvi complains that an address of zero is wrong.
Anton Shepelev wrote:
Somewhat related to this problem, is another, when Tin passes 0 for
%N, whereas the lines are numbered from unity (1). Consequently,
nvi complains that an address of zero is wrong.
%N should always >= 1, can you state how to reproduce this?
Anton Shepelev wrote:
Yes. When when I invoke a postponed article by ^O, tin invokes:
vi +0 /home/ant/.tin_dir/.article.2109
oic, I forgot that we didn't bother to check where the body starts
for postponed articles. quick fix: adjust the last arg. of post_loop()
in post.c:post_postponed_article() from 0 to 1.
I'll calculate to correct offset to the fist line in the body for
the next release.
Yes. When when I invoke a postponed article by ^O, tin invokes:
vi +0 /home/ant/.tin_dir/.article.2109
Anton Shepelev wrote:
Yes. When when I invoke a postponed article by ^O, tin invokes:
vi +0 /home/ant/.tin_dir/.article.2109
oic, I forgot that we didn't bother to check where the body starts
for postponed articles. quick fix: adjust the last arg. of post_loop()
in post.c:post_postponed_article() from 0 to 1.
I'll calculate to correct offset to the fist line in the body for
the next release.
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
it in my editor (nvi) with `+7', which complains:
-c option, 1: illegal address: only 6 lines in the file
And indeed, there are only six lines in the generated file:
--------------------------------- Cut ---------------------------------- From: Anton Shepelev <anton.txt@gmail.moc>
Subject: Russian encodings KOI8-RU and KOI8-R
Newsgroups: misc.test
Summary:
Keywords:
--------------------------------- Cut ----------------------------------
whereas I think there should be seven, because one empty line
separates the headers from the body, and one begins the body. It
is rather unlikely that the error should be in Tin, but perhaps
something is wrong in my environment preventing the second empty
line in the generated stubs?
I used the following primitive wrapper script to log the process:
--------------------------------- Cut ----------------------------------
echo $* >> ~/invoke.txt
cp $2 ~/art.txt
vi $*
--------------------------------- Cut ----------------------------------
Anton Shepelev <anton.txt@gmail.moc> wrote:
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
it in my editor (nvi) with `+7', which complains:
-c option, 1: illegal address: only 6 lines in the file
And indeed, there are only six lines in the generated file:
--------------------------------- Cut ----------------------------------
From: Anton Shepelev <anton.txt@gmail.moc>
Subject: Russian encodings KOI8-RU and KOI8-R
Newsgroups: misc.test
Summary:
Keywords:
--------------------------------- Cut ----------------------------------
whereas I think there should be seven, because one empty line
separates the headers from the body, and one begins the body. It
is rather unlikely that the error should be in Tin, but perhaps
something is wrong in my environment preventing the second empty
line in the generated stubs?
I used the following primitive wrapper script to log the process:
--------------------------------- Cut ----------------------------------
echo $* >> ~/invoke.txt
cp $2 ~/art.txt
vi $*
--------------------------------- Cut ----------------------------------
Haven't been a *NIX user for decades,
but you sure the error is generated by tin, and not by nvi?
You say tin opens the editor, and then you see the error which makes
it appear the editor issues the error.
Tried getting tin to switch to vim as the editor?
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
it in my editor (nvi) with `+7', which complains:
-c option, 1: illegal address: only 6 lines in the file
And indeed, there are only six lines in the generated file:
Anton Shepelev <anton.txt@gmail.moc> wrote:
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
it in my editor (nvi) with `+7', which complains:
-c option, 1: illegal address: only 6 lines in the file
And indeed, there are only six lines in the generated file:
Very odd. What is VISUAL set to ?
Do you have an empty ~/.signature File ? Maybe that is why.
Try creating a ~/.signature with 1 'real' line and see what
happens. Or maybe delete file ~/.signature
Also check ~/.tin/tinrc and see if there is simething odd in
that.
VanguardLH <V@nguard.lh> wrote:
Anton Shepelev <anton.txt@gmail.moc> wrote:
When I post a new message in Tin 2.6.3, after I enter the subject
and press Enter, Tin generates the "stub" of a new article and opens
it in my editor (nvi) with `+7', which complains:
-c option, 1: illegal address: only 6 lines in the file
And indeed, there are only six lines in the generated file:
--------------------------------- Cut ---------------------------------- >>> From: Anton Shepelev <anton.txt@gmail.moc>
Subject: Russian encodings KOI8-RU and KOI8-R
Newsgroups: misc.test
Summary:
Keywords:
--------------------------------- Cut ---------------------------------- >>>
whereas I think there should be seven, because one empty line
separates the headers from the body, and one begins the body. It
is rather unlikely that the error should be in Tin, but perhaps
something is wrong in my environment preventing the second empty
line in the generated stubs?
I used the following primitive wrapper script to log the process:
--------------------------------- Cut ---------------------------------- >>> echo $* >> ~/invoke.txt
cp $2 ~/art.txt
vi $*
--------------------------------- Cut ----------------------------------
Haven't been a *NIX user for decades,
Well, both `tin' and `vim' are available on Windows and Mac OS X.
but you sure the error is generated by tin, and not by nvi?
I wrote that the error message quoted above is from `nvi', but it
indicates that `tin' may be invokig it incorrectly /or/ generating
an incorrect stub for the article.
You say tin opens the editor, and then you see the error which makes
it appear the editor issues the error.
It does, and I have reproduced the error by calling
>nvi +7 6l.txt
where 6l.txt is a file with six lines.
Tried getting tin to switch to vim as the editor?
The classic `vi' is the standard editor on my system, but I have
installed vim and tested with it, and there is no error message.
`tin', however, inokes the configured editor with +7 even though
the pre-generated file has only six lines. Both the editors move
the cursor to the last (sixsth) line of the file, but `nvi'
additionally issues an error message, whereas `vim' stays quiet.
I think `nvi' is correct here, because it is asked to position the
cursor on the senventh line in a six-line file.
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed intentionally?
Anton Shepelev <anton.txt@gmail.moc> wrote:
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed
intentionally?
Look at the file with a hex editor. Could the 7th line just be a
newline? I don't know if nvi has a mode to show non-printable chars.
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed intentionally?
Anton Shepelev wrote:
It is not a bug in the editor, because regarless of the editor `tin'
2.6.3 on FreeBSD 14.1 pre-generates an article with /only one/ empty
line at the end instead of two. `tin' 2.6.2 (on a remote system I
use) pre-genenerates articles with two empty lines at the end. I
think it is an error in `tin' 2.6.3. Or can this have been changed
intentionally?
kinda, just tested it with an editor which doesn't complain _and_ jumps
one line _past_ the last line if called with +N > lines_in_file (e.g.
nano, joe, ...). I'll revert that change (= adding an additional
\n to the stub):
=== modified file 'src/post.c'
--- old/src/post.c 2024-09-17 13:26:24 +0000
+++ new/src/post.c 2024-09-21 09:52:00 +0000
@@ -2895,6 +2895,7 @@
start_line_offset = msg_write_headers(fp) + 1;
msg_free_headers();
+ fprintf(fp, "\n"); /* add a newline to keep vi from bitching */
meanwhile you might be able to use something like (depends on your $SHELL) >editor_format=%E +$((%N - 1)) %F
+ fprintf(fp, "\n"); /* add a newline to keep vi from bitching */
Yeah, but the comment
positioning the cursor on a non-existant line in the file.