On 22/11/14 10:47, Werner LEMBERG wrote:
>
>> Out of curiosity, why did you prefer this:
>>
>> +#if defined(__MSDOS__) || (defined(_WIN32) && !defined(__CYGWIN__))
>> +void normalize_for_lf (string &fn)
>> +{
>> + int fnlen = fn.length();
>> + for (int i = 0; i < fnlen; i++) {
>> +
> Date: Sat, 22 Nov 2014 11:47:12 +0100 (CET)
> Cc: groff@gnu.org
> From: Werner LEMBERG
>
> With your version, I get a warning about an unused variable `fn' if
> not compiling for MS.
Got it, thanks.
> Out of curiosity, why did you prefer this:
>
> +#if defined(__MSDOS__) || (defined(_WIN32) && !defined(__CYGWIN__))
> +void normalize_for_lf (string &fn)
> +{
> + int fnlen = fn.length();
> + for (int i = 0; i < fnlen; i++) {
> +if (fn[i] == '\\')
> + fn[i] = '/';
> +
> Date: Thu, 20 Nov 2014 19:47:19 +0100 (CET)
> Cc: groff@gnu.org
> From: Werner LEMBERG
>
> >> Sorry for the delayed answer. Your patch looks fine, and I'm going
> >> to apply it soon. Thanks a lot.
> >
> > Great, thanks. Now I can publish the binary with that patch and
> > claim that it was
On Fri, Nov 21, 2014 at 01:24:36PM +, Ralph Corderoy wrote:
> :
> > Indeed, this is true for (almost) all groff header files. For some
> > reason, Clark decided to code it that way, not providing guards
> > against loading header files multiple times. I haven't changed that.
>
> Gets
Ralph Corderoy writes:
>
> Gets my vote. :-) It's a Bell Labs style of programming seen widely in
> Plan 9. Rob Pike has also written about it since the 1980s. Header
> files should not be #include'd multiple times; nor should they #include
> others. They should state their needs and be #inc
Hi Werner,
> > It's IMO a Groff problem that is not specific to MinGW:
> > stringclass.h is not idempotent.
>
> Indeed, this is true for (almost) all groff header files. For some
> reason, Clark decided to code it that way, not providing guards
> against loading header files multiple times. I h
>> Out of curiosity, Eli, why did you find it necessary to move
>> stringclass.h to an earlier position in the include order? Is it
>> not a symptom of either a flawed design, or an implementation
>> fault, if that matters? Is there a MinGW issue which may need
>> investigation? Or is it simply
> Date: Thu, 20 Nov 2014 19:33:58 +
> From: Keith Marshall
> CC: groff@gnu.org
>
> Out of curiosity, Eli, why did you find it necessary to move
> stringclass.h to an earlier position in the include order? Is it not a
> symptom of either a flawed design, or an implementation fault, if that
>
On 20/11/14 18:47, Werner LEMBERG wrote:
>>> Sorry for the delayed answer. Your patch looks fine, and I'm going
>>> to apply it soon. Thanks a lot.
>>
>> Great, thanks. Now I can publish the binary with that patch and
>> claim that it was accepted upstream.
>
> Now committed, with minor fixes.
>> Sorry for the delayed answer. Your patch looks fine, and I'm going
>> to apply it soon. Thanks a lot.
>
> Great, thanks. Now I can publish the binary with that patch and
> claim that it was accepted upstream.
Now committed, with minor fixes.
Werner
> Date: Wed, 19 Nov 2014 07:37:45 +0100 (CET)
> Cc: groff@gnu.org
> From: Werner LEMBERG
>
> Sorry for the delayed answer. Your patch looks fine, and I'm going to
> apply it soon. Thanks a lot.
Great, thanks. Now I can publish the binary with that patch and claim
that it was accepted upstream
> Ping!
Sorry for the delayed answer. Your patch looks fine, and I'm going to
apply it soon. Thanks a lot.
Werner
Ping!
> Date: Mon, 10 Nov 2014 17:08:21 +0200
> From: Eli Zaretskii
> Cc: groff@gnu.org
>
> > Date: Sun, 09 Nov 2014 08:46:21 +0100 (CET)
> > Cc: groff@gnu.org
> > From: Werner LEMBERG
> >
> >
> > >> I was imagining something primitive, e.g. a working equivalent to
> > >>
> > >> #if define
Eli Zaretskii wrote:
|> Date: Tue, 11 Nov 2014 13:50:48 +0100
|> From: Steffen Nurpmeso
|>
|> Doug McIlroy wrote:
|>|* For a ludicrous example, when I type my own name,
|>| M. Douglas McIlroy
|>|at the beginning of a line--as for a signature or author line--
|>|Open Office thinks that I
> cc: Eli Zaretskii
> Date: Tue, 11 Nov 2014 20:12:13 +
> From: Ralph Corderoy
>
> Hi Keith,
>
> > > Hmm, does that mean the argv[] processing in groff's code is a place
> > > to transliterate when it's known to be a filename?
> >
> > How can that possibly be known? When argv[] processing
> Date: Tue, 11 Nov 2014 19:46:22 +
> From: Keith Marshall
> CC: groff@gnu.org
>
> Perhaps Eli's explanation is overly simplistic. In reality, cmd.exe
> doesn't process those directory separators, no matter whether they are
> specified as slashes, (as POSIX and $DEITY mandate), or reversed
>
> cc: groff@gnu.org
> Date: Tue, 11 Nov 2014 19:20:19 +
> From: Ralph Corderoy
>
> > > and so wrappers around the code that's cooking up the a\b\c in the
> > > first place could transliterate there without caring where the a/b/c
> > > is later to be used?
> >
> > The problem with this approa
Hi Keith,
> > Hmm, does that mean the argv[] processing in groff's code is a place
> > to transliterate when it's known to be a filename?
>
> How can that possibly be known? When argv[] processing is performed,
> all we see is a sequence of strings; they have no semantic meaning.
At some point,
On 11/11/14 19:20, Ralph Corderoy wrote:
> Hi Eli,
>
> Thanks for the explanation.
>
>>> Am I right in thinking that Windows' API is as happy with a/b/c as
>>> a\b\c
>>
>> That's correct.
>>
>>> and so wrappers around the code that's cooking up the a\b\c in the
>>> first place could transliterate
Hi Eli,
Thanks for the explanation.
> > Am I right in thinking that Windows' API is as happy with a/b/c as
> > a\b\c
>
> That's correct.
>
> > and so wrappers around the code that's cooking up the a\b\c in the
> > first place could transliterate there without caring where the a/b/c
> > is later
> Date: Tue, 11 Nov 2014 13:50:48 +0100
> From: Steffen Nurpmeso
>
> Doug McIlroy wrote:
> |* For a ludicrous example, when I type my own name,
> | M. Douglas McIlroy
> |at the beginning of a line--as for a signature or author line--
> |Open Office thinks that I've begun a paragraph numbered
> Date: Mon, 10 Nov 2014 19:08:00 +
> From: Ralph Corderoy
>
> One thing I think I've missed: why has this come to light now?
Because I make a point of investigating any strange messages from the
program, while those who came before me didn't?
To put this in context, I bumped into this whe
> From: Doug McIlroy
> Date: Sun, 09 Nov 2014 11:54:51 -0500
Sorry to reply only now, but I don't subscribe to the list, so I don't
receive messages unless I'm explicitly CC'ed.
> It is safe to convert backslashes to slashes only when it is
> known that the literal string is indeed a file name.
Doug McIlroy wrote:
|* For a ludicrous example, when I type my own name,
| M. Douglas McIlroy
|at the beginning of a line--as for a signature or author line--
|Open Office thinks that I've begun a paragraph numbered with
|a Roman numeral, and proceeds to tack "MI." onto the beginning
|of th
Hi Eli,
> +void normalize_for_lf (string &fn)
> +{
> +#if defined(__MSDOS__) || (defined(_WIN32) && !defined(__CYGWIN__))
> + int fnlen = fn.length();
> + for (int i = 0; i < fnlen; i++)
> +{
> + if (fn[i] == '\\')
> + fn[i] = '/';
> +}
> +#endif
> +}
One thing I think I've mis
> Date: Sun, 09 Nov 2014 08:46:21 +0100 (CET)
> Cc: groff@gnu.org
> From: Werner LEMBERG
>
>
> >> I was imagining something primitive, e.g. a working equivalent to
> >>
> >> #if defined(__MSDOS__) || (defined(_WIN32) && !defined(__CYGWIN__))
> >> # define DOS2UNIX_FILENAME(f) dos2unix_filen
> It is safe to convert backslashes to slashes only when it is known
> that the literal string is indeed a file name. This condition holds
> for command arguments, but not for groff input text. "Fixing" .lf
> commands is of a piece with the maddening AI of Microsoft Word and
> Open Office, which t
It is safe to convert backslashes to slashes only when it is
known that the literal string is indeed a file name. This
condition holds for command arguments, but not for groff
input text. "Fixing" .lf commands is of a piece with the
maddening AI of Microsoft Word and Open Office, which think
that t
>> 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
> 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
> 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
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
> 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
> 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
> 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 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
> 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
>> > 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 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
> 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 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
> 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'
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
44 matches
Mail list logo
