In some rare cases, Groff 1.22.3 emits strange (and quite cryptic for
this roff-ignorant curmudgeon) messages. Examples:
$ groff -man -t man1/chem.1 > cat1/chem.1
:4: `\c' is not allowed in a name
mann1:550: `\c' is not allowed in a name
$ groff -t -man man1/tbl.1 > cat1/tbl.1
:4: a no
> Date: Sat, 08 Nov 2014 10:54:42 +0200
> From: Eli Zaretskii
>
> In some rare cases, Groff 1.22.3 emits strange (and quite cryptic for
> this roff-ignorant curmudgeon) messages. Examples:
>
> $ groff -man -t man1/chem.1 > cat1/chem.1
> :4: `\c' is not allowed in a name
> mann1:550: `\c'
> Date: Sat, 08 Nov 2014 11:22:58 +0200
> From: Eli Zaretskii
>
> I think I know the reason. This is Windows-specific, as demonstrated
> by using the -V switch:
>
> groff -t -man -V \usr\share\man\man1\chem.1
> tbl '\usr\share\man\man1\chem.1' | troff -man -Tascii | grotty
>
> The problem is
> [...] i stumbled over a interpretation difference (full source
> attached):
>
> source:
> .It Fn at_quick_exit , Fn _atexit
> groff and mandoc agree.
> .It Fn at_quick_exit , _atexit
> Only mandoc gets that right.
>
> mandoc:
> at_quick_exit(), _atexit()
> grof
Hi Grégoire,
> Will it be possible in a while to get the new version on Synaptic?
Ubuntu's package manager? http://packages.ubuntu.com/utopic/groff says
14.10's is currently 1.22.2-8 and that they take Debian's package,
maintained by Colin Watson (who's on this list). That version is what's
in
Hello,
i finally come around to implement my proposed mdoc(7) reference
extension and yesterday i stumbled over a interpretation
difference (full source attached):
source:
.It Fn at_quick_exit , Fn _atexit
groff and mandoc agree.
.It Fn at_quick_exit , _atexit
Only mandoc gets that right.
> groff -t -man man\man1\chem.1 > man\cat1\chem.1
> :4: name expected (got a node): treated as missing
> :0: warning: numeric expression expected (got `a')
> :550: name expected (got a node): treated as missing
> :410: warning: numeric expression expected (got `a')
>
> These come from t
> Date: Sat, 08 Nov 2014 14:36:35 +0100 (CET)
> Cc: groff@gnu.org
> From: Werner LEMBERG
>
> > .lf 1 man\man1\chem.1
>
> This is a feature of GNU troff (and I guess that other troff
> implementations are doing it similarly): Arguments of `.lf' are
> handled the normal troff way, including expa
>> > One possible solution to this is to convert all backslashes to
>> > forward slashes '/' when writing the .lf directive.
>
> Is there a good place to put the function that will do this?
I suggest `libs/libgroff/lf.cpp'.
> Or should I just have it in each place that needs it?
Whatever you th
> Date: Sat, 08 Nov 2014 15:25:17 +0100 (CET)
> Cc: groff@gnu.org
> From: Werner LEMBERG
>
> >> > One possible solution to this is to convert all backslashes to
> >> > forward slashes '/' when writing the .lf directive.
> >
> > Is there a good place to put the function that will do this?
>
> I
Hi Werner,
> upload a unified diff (`diff -u'), from old to new. Your context diff
> is apparently from new to old, which is hard to read.
I agree contributors should prepare unified old-new patches, but you
might like to know about Tim Waugh's patchutils for manipulating
patches, including reve
> Date: Sat, 08 Nov 2014 15:25:17 +0100 (CET)
> Cc: groff@gnu.org
> From: Werner LEMBERG
>
> >> > One possible solution to this is to convert all backslashes to
> >> > forward slashes '/' when writing the .lf directive.
> >
> > Is there a good place to put the function that will do this?
>
> I
> OK, here's the proposed patch and the log entries:
Thanks.
> 2014-11-08 Eli Zaretskii
>
> Fix handling of MS-Windows quoting and file names with backslashes.
> * src/preproc/soelim/soelim.cpp (do_file):
> * src/preproc/refer/refer.cpp (do_file):
> * src/preproc/prec
> Date: Sat, 08 Nov 2014 21:03:29 +0100 (CET)
> Cc: groff@gnu.org
> From: Werner LEMBERG
>
>
> > OK, here's the proposed patch and the log entries:
>
> Thanks.
>
> > 2014-11-08 Eli Zaretskii
> >
> > Fix handling of MS-Windows quoting and file names with backslashes.
> > * src/prepr
> You mean in so many different places?
Yes.
>> Any chance to have some code in `nonposix.h' to avoid this?
>
> Please suggest how. do_file more often than not accepts strings
> given by 'const char *', so it is not possible to modify the string
> itself. What else can I do?
I was imagining s
On 08/11/14 20:43, Eli Zaretskii wrote:
>> Any chance to have some code in `nonposix.h' to avoid this?
> Please suggest how. do_file more often than not accepts strings given
> by 'const char *', so it is not possible to modify the string itself.
> What else can I do?
Maybe make the *implementati
Hi Werner and Steffen,
Werner LEMBERG wrote on Sat, Nov 08, 2014 at 02:19:38PM +0100:
> Steffen Nurpmeso wrote:
>> [...] i stumbled over a interpretation difference (full source
>> attached):
>>
>> source:
>> .It Fn at_quick_exit , Fn _atexit
>> groff and mandoc agree.
>> .It Fn at_quick_e
> Date: Sat, 08 Nov 2014 21:54:27 +0100 (CET)
> Cc: groff@gnu.org
> From: Werner LEMBERG
>
> >> Any chance to have some code in `nonposix.h' to avoid this?
> >
> > Please suggest how. do_file more often than not accepts strings
> > given by 'const char *', so it is not possible to modify the st
> Date: Sat, 08 Nov 2014 21:05:05 +
> From: Keith Marshall
> CC: groff@gnu.org
>
> On 08/11/14 20:43, Eli Zaretskii wrote:
> >> Any chance to have some code in `nonposix.h' to avoid this?
> > Please suggest how. do_file more often than not accepts strings given
> > by 'const char *', so it i
>> I was imagining something primitive, e.g. a working equivalent to
>>
>> #if defined(__MSDOS__) || (defined(_WIN32) && !defined(__CYGWIN__))
>> # define DOS2UNIX_FILENAME(f) dos2unix_filename(f)
>> #else
>> # define DOS2UNIX_FILENAME(f) (f)
>> #endif
>
> But then the non-Windows code
20 matches
Mail list logo
