Re: Tilde (~) in bash(1) is typeset incorrectly as Unicode character

Chet Ramey wrote in <2fd2ed52-3272-3433-6179-164bc5122...@case.edu>: ... |> At 2023-07-26T10:47:05+0200, Thomas ten Cate wrote: |>> In the bash manual page (`man bash`), the ASCII tilde character '~' |>> (0x7e) is replaced by the Unicode character '˜' (U+02DC SMALL TILDE): |>> |>> $

Re: Tilde (~) in bash(1) is typeset incorrectly as Unicode character

Steffen Nurpmeso wrote in <20230729002703.lasps%stef...@sdaoden.eu>: |Chet Ramey wrote in | <2fd2ed52-3272-3433-6179-164bc5122...@case.edu>: | ... ||> At 2023-07-26T10:47:05+0200, Thomas ten Cate wrote: ||>> In the bash manual page (`man bash`), the ASCII tilde char

Re: Viewing PDFs. (Was: Happy new Sun)

G. Branden Robinson wrote in <20221227232513.6zeaunnqaywtrxvw@illithid>: ... |I haven't looked at it Buddy, it is where you got your _idea_ from. So do not mind i unsubscribe to stop you spamming my inbox with your shit, Mr. infinitely scaling intellectual. When s-roff will ever spring into

Re: Viewing PDFs. (Was: Happy new Sun)

Ralph Corderoy wrote in <2022122714.845141f...@orac.inputplus.co.uk>: |Hi Steffen, ... |Deri means you. Dunno, Ralph. Thanks, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks

Re: Viewing PDFs. (Was: Happy new Sun)

G. Branden Robinson wrote in <20221227095728.c7oo2iolmg6hl4nw@illithid>: |At 2022-12-24T23:39:07+, Deri wrote: |>> "o" for the former. |>> 'That said, https://ftp.sdaoden.eu/code-mailx-1.pdf (beware: |>> 1MB!), realized with newest minor of mdocmx on groff |>> 1.23.0.rc1.2915-c6d7, |

Re: Viewing PDFs. (Was: Happy new Sun)

Ralph Corderoy wrote in <20221224090607.7dbb222...@orac.inputplus.co.uk>: |Hi Deri, | |> You may need to open the outline pane on the left, which acts like a |> table of contents. | |Is it mandatory that a PDF viewer must supply this mechanism to be |worthy of the name? Off-hand, I don't

Re: Nils-Peter Nelson, sqtroff, and groff history

G. Branden Robinson wrote in <20221214002919.gy56muresenofizt@illithid>: |Some people might find the following messages, first from Nils-Peter |Nelson and then Liam R. E. Quin, of interest. They're posts from 1996 |to the comp.text USENET group. (Je me souviens, DejaNews!) Thanks for

Re: [RFC] input.cpp: Remove use of strncat(3)

Alejandro Colomar wrote in <20221205223936.8290-1-...@kernel.org>: ... |--- a/src/roff/troff/input.cpp |+++ b/src/roff/troff/input.cpp |@@ -7892,7 +7892,7 @@ void do_macro_source(bool quietly) |MACRO_POSTFIX, sizeof(MACRO_POSTFIX) - 1) == 0) { |char *s = new char[fnlen +

Re: Doubts about a typo fix

G. Branden Robinson wrote in <20221126035253.pli53qzgfx6tbax5@illithid>: |At 2022-11-25T18:18:46-0800, Paul Eggert wrote: ... |> If we did that, Groff would set a source string like "\*-\*-help" as |> "−−help", with two instances of U+2212 MINUS SIGN instead of U+002D |> HYPHEN-MINUS.

Re: 1.23: UTF-8 device: more display oddities

DJ Chase wrote in : |On Sat Sep 17, 2022 at 3:30 PM EDT, Steffen Nurpmeso wrote: |> P.S.: with the help from people of IRC i have now tested LuxiMono, |> IBMPlexMono, and NotoMono, and only LuxiMono gets it somehow right |> (but looks terrible as a monospace font imho). ... |JetBr

Re: 1.23: UTF-8 device: more display oddities

Steffen Nurpmeso wrote in <20220917165637.pmpud%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20220917162423.trkch%stef...@sdaoden.eu>: ||Steffen Nurpmeso wrote in || <20220917152906.uhdto%stef...@sdaoden.eu>: |||Ralph Corderoy wrote in ||| <2

Re: 1.23: UTF-8 device: more display oddities

Steffen Nurpmeso wrote in <20220917162423.trkch%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20220917152906.uhdto%stef...@sdaoden.eu>: ||Ralph Corderoy wrote in || <20220917105400.a3f1121...@orac.inputplus.co.uk>: |||> ` U+0060, GRAVE ACCENT, "backtick

Re: 1.23: UTF-8 device: more display oddities

Steffen Nurpmeso wrote in <20220917152906.uhdto%stef...@sdaoden.eu>: |Ralph Corderoy wrote in | <20220917105400.a3f1121...@orac.inputplus.co.uk>: ||> ` U+0060, GRAVE ACCENT, "backtick" ||> ||> is displayed as ||> ||> ‘ U+2018, LEFT SINGLE QUOTATI

Re: 1.23: UTF-8 device: more display oddities

Steffen Nurpmeso wrote in <20220917155426.f4zgu%stef...@sdaoden.eu>: ... |I am out. Well a bit harsh. But other than that, not. I see people using copy+paste with code examples and, even worse, configuration examples, and getting lots of trouble because of character mappings which

Re: 1.23: UTF-8 device: more display oddities

G. Branden Robinson wrote in <20220917005135.3sy2ri22dhvlnvq5@illithid>: |At 2022-09-17T01:00:26+0200, Steffen Nurpmeso wrote: |> G. Branden Robinson wrote in |> <20220916223236.lmkf3brdwotdn2fd@illithid>: |>|At 2022-09-16T23:56:58+0200, Steffen Nurpmeso wrote: |>|

Re: 1.23: UTF-8 device: more display oddities

Hello Ralph. Ralph Corderoy wrote in <20220917105400.a3f1121...@orac.inputplus.co.uk>: |> ` U+0060, GRAVE ACCENT, "backtick" |> |> is displayed as |> |> ‘ U+2018, LEFT SINGLE QUOTATION MARK |> |> which in Liberation Mono (at least!) this reverses the direction of |> the tick. |

Re: 1.23: UTF-8 device: more display oddities

G. Branden Robinson wrote in <20220916223236.lmkf3brdwotdn2fd@illithid>: |At 2022-09-16T23:56:58+0200, Steffen Nurpmeso wrote: .. |> i=`echo '~/home^run'` |> |> becomes |> |> i=‘‘echo ’˜/homeˆrun’‘’ |> |> How is anyone supposed to document a sh(1)ell-s

Re: 1.23: UTF-8 device: more display oddities

Steffen Nurpmeso wrote in <20220916213112.5dabw%stef...@sdaoden.eu>: |Hello. | |Letting aside the hyphen-minus -> hyphen thing that i fixed for me |locally, there is also the problem that | | ` U+0060, GRAVE ACCENT, "backtick" | |is displayed as | | ‘ U+2018, LE

1.23: UTF-8 device: more display oddities

Hello. Letting aside the hyphen-minus -> hyphen thing that i fixed for me locally, there is also the problem that ` U+0060, GRAVE ACCENT, "backtick" is displayed as ‘ U+2018, LEFT SINGLE QUOTATION MARK which in Liberation Mono (at least!) this reverses the direction of the tick. I was

Re: 1.23: UTF-8 device produces mysterious characters

Ralph Corderoy wrote in <20220914071616.2e89021...@orac.inputplus.co.uk>: |Hi Steffen, | |>>> En dash would look nice, i could imagine. |>> |>> Those ASCII ‘-’ above should be rendered as a hyphen in nicely |>> typeset output. An en-dash is far too big. Oh, there's another |>> one!

Re: 1.23: UTF-8 device produces mysterious characters

Dave Kemper wrote in : How about [12066c659ea454a663483a12181a0c33cf416b22]. This looks promising. Thank you. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert

Re: 1.23: UTF-8 device produces mysterious characters

Ralph Corderoy wrote in <20220913084152.0211621...@orac.inputplus.co.uk>: |Hi Steffen, | |> Hyphen is good at the end of line when a word is hyphenated, otherwise |> it is misplaced. | |Not in English. A hyphen may be used to join compound adjectives, as a |two-minute Google would show.

Re: 1.23: UTF-8 device produces mysterious characters

G. Branden Robinson wrote in <20220913053400.7lmdp2qpxb6zweei@illithid>: |At 2022-09-12T23:41:34+0200, Steffen Nurpmeso wrote: |> This is not a hyphenated word. |[rearranging this a bit] |> En dash would look nice, i could imagine. | |Then use en dashes in your input. | | on\

Re: 1.23: UTF-8 device produces mysterious characters

Dave Kemper wrote in : |On 9/12/22, Steffen Nurpmeso wrote: ... |Groff has converted an input U+002D to a proper hyphen in typeset |output for decades. It has done so in UTF-8 output since at least |groff 1.19.2. ... This is not true. I never have seen anything but hyphen-minus on my

Re: 1.23: UTF-8 device produces mysterious characters

Hello Branden. G. Branden Robinson wrote in <20220912144641.q2r65kkfpiej4u2u@illithid>: |At 2022-09-12T15:43:00+0200, Steffen Nurpmeso wrote: |> I have problems with the UTF-8 device, it shows |> |> on‐main‐loop‐tick |> instead of |> on-main-loop-tock |>

1.23: UTF-8 device produces mysterious characters

Hello! I have problems with the UTF-8 device, it shows on‐main‐loop‐tick instead of on-main-loop-tock ie U+2010 instead of hyphen-minus U+002D. The above does not feel right, and searching is impossible! I would expect U+2010 HYPHEN in hyphenation, but not as a regular combiner aka

[bug #63042] Enhancement: mdocmx(7) extension to mdoc(7)

Follow-up Comment #1, bug #63042 (project groff): 630 42. Why not. ___ Reply to this item at: ___ Message sent via Savannah https://savannah.gnu.org/

[bug #63042] Enhancement: mdocmx(7) extension to mdoc(7)

: None ___ Follow-up Comments: --- Date: Fri 09 Sep 2022 10:14:30 PM UTC By: Steffen Nurpmeso Hello. Another try to establish the mdocmx(7) reference+ extension at groff(1)'s mdoc(7), after the failed attempt in 2015, which, granted, was

Re: 1.23: troff register names broken?

Eh sorry folks. Steffen Nurpmeso wrote in <20220909164816.rzev-%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20220909163015.7zdu0%stef...@sdaoden.eu>: | ... ||so it seems to me .nr registers can no longer contain a "#" in ||their name! That would totally b

Re: 1.23: troff register names broken?

Steffen Nurpmeso wrote in <20220909163015.7zdu0%stef...@sdaoden.eu>: ... |so it seems to me .nr registers can no longer contain a "#" in |their name! That would totally boom my macro package(s)! Is not However, i also have . nr mx#t-d#n1 0 . while (\n[mx#t-

1.23: troff register names broken?

Hello. During testing (still not done because i massively improved the less pull request, not yet pushed, but now even ^O^N and ^O^P work totally graceful regarding repaints and _every_ move around) i stumbled over certain number registers i use do not work no more like they should, so if i

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

Hello Branden, ..again, and sorry, for the noise.. Steffen Nurpmeso wrote in <20220907210913.drf4v%stef...@sdaoden.eu>: |P.S.: ... |||(Actually my less(1) pull request will not find the IDs my mdocmx ... |I updated the pull request with an additional fix commit that ... |I would

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

P.S.: Steffen Nurpmeso wrote in <20220906232237.izz2i%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20220906231824.-4way%stef...@sdaoden.eu>: ... ||(Actually my less(1) pull request will not find the IDs my mdocmx ... I updated the pull request with an additional fix commi

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

Steffen Nurpmeso wrote in <20220906231824.-4way%stef...@sdaoden.eu>: ... |(Actually my less(1) pull request will not find the IDs my mdocmx |produces via your grotty thing because of it. Hm. Well, we break |out if we cannot find the = in the K=V, and ;: is an empty |parameter. Si

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

Oh! Steffen Nurpmeso wrote in <20220906224118.jh2ju%stef...@sdaoden.eu>: |G. Branden Robinson wrote in | <20220906205844.xbo54jzk2v7jscvf@illithid>: ||At 2022-09-06T16:22:42+0200, Steffen Nurpmeso wrote: ... |It would be _tremendous_ if \X'tty: link' would get the Actually i t

Re: [e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

Hello Branden. G. Branden Robinson wrote in <20220906205844.xbo54jzk2v7jscvf@illithid>: |At 2022-09-06T16:22:42+0200, Steffen Nurpmeso wrote: ... |Thanks, Steffen. I have applied this to my working copy. It would be _tremendous_ if \X'tty: link' would get the possibility to create I

[e9e92ee00811f7d0fcbde415346f7f4f7be14528] missed one

P.S.: i overtook this name change to my roff clone, shall that ever spring into real existance. You have a credit, please complain if you do not want to be named in THANKS. diff --git a/tmac/mdoc/doc-common b/tmac/mdoc/doc-common index 6c9093a876..29ee7f8c7b 100644 --- a/tmac/mdoc/doc-common +++

Re: .man file extension

Alejandro Colomar wrote in : |Hi Branden, | |I see that you use .7.man or .1.man internally in the groff(1) source |repository. But then those extensions are presumably removed during the |installation, since man(1) doesn't like them. What are they for? Surely automake sausage. As like

Re: 1.23.0.rc1.2875-9c30-dirty: does not prefer its own same-version subprograms?

Dave Kemper wrote in : |On 9/3/22, Steffen Nurpmeso wrote: |> Letting aside that --with[out]-doc was blindly removed | |This was not done blindly: Ingo posted a lengthy rationale to this |list (http://lists.gnu.org/r/groff/2022-04/msg9.html), and invited |comment from anyone who wan

1.23.0.rc1.2875-9c30-dirty: does not prefer its own same-version subprograms?

Hello. Gratulations for maintainership, Branden Robinson! I am in the process of porting mdocmx to groff 1.23. (That is to say: automake issues, after gnulib issues, git gc --aggressive is killed by that ChangeLog which is nothing but a duplicate of git log but prepends at the top instead of

Re: man(7) .TH font change, was: groff man(7) `B` macro...

Ingo Schwarze wrote in : |Steffen Nurpmeso wrote on Mon, Jun 20, 2022 at 02:23:58PM +0200: | |> Just to mention that since 2014 my .Mx mdoc(7) extension is |> distributed for the things i use, and i never have heard about an | |Just in case people aren't aware, even

Re: man(7) .TH font change, was: groff man(7) `B` macro...

Ingo Schwarze wrote in : |Alejandro Colomar wrote on Sun, Jun 19, 2022 at 04:11:49PM +0200: |> On 6/19/22 16:00, Ralph Corderoy wrote: ... |That makes compatibility in man(7) significantly more of a concern |than in mdoc(7). All the same, i would certainly not consider |adding anything as

Re: lots of fatal build system bugs on OpenBSD

Ingo Schwarze wrote in : |Douglas McIlroy wrote on Tue, Mar 22, 2022 at 08:58:19AM -0400: |> Tangential comment: |> I have always recoiled from git. | |I agree to some extent. Git does get a number of things right, but |there are also many aspects of its user interface and design that make

Re: memccpy(3) and stpcpy(3) status in C2x (was: stpecpy(): A better string copy function)

Martin Sebor wrote in : |On 2/13/22 13:32, Alejandro Colomar (man-pages) wrote: |> On 2/13/22 19:29, Alejandro Colomar (man-pages) wrote: .. |>>> I expect/hope stpcpy to become the new norm for string copying, though |>>> it will require overcoming much inertia and many dusty old books.

Re: PROPOSED: Kill \X'tty: sgr'

G. Branden Robinson wrote in <20211125171302.ubixfedm3xtssc5m@localhost.localdomain>: |I'm proposing a feature deletion. | |https://savannah.gnu.org/bugs/index.php?61561 | |Have I overlooked something? It is the counterpart to the environment variable *_NO_SGR, and controls the same

Re: Find a char in string

Wim Stockman wrote in : |Is there a function in groff to find the position of a char in a string. |So I can split a string into more than one. |I found the substring function that can cut based on length. If I could my |marker in the string I could cut it there. Loop over the string and use

Re: WAYTO: indexed man pages

Ingo Schwarze wrote in <20210602223746.ga92...@athene.usta.de>: ... |Then again, i feel that's a problem of relatively little urgency. That is because you use that mutilated less. The original can. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he

Re: getting more out of man pages with less(1)

Hey. Steffen Nurpmeso wrote in <20210523212903.58vrh%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in | <20210523004836.gta8l%stef...@sdaoden.eu>: | ... |||> Good idea. I've further changed the Subject: to reflect the flow \ |||> of the |||> discussion. || ..

Re: getting more out of man pages with less(1)

Good evening and Hello. Steffen Nurpmeso wrote in <20210523004836.gta8l%stef...@sdaoden.eu>: ... ||> Good idea. I've further changed the Subject: to reflect the flow of the ||> discussion. | ... ||> I also wonder if the pager wars are basically over and less(1) won them

Re: getting more out of man pages with less(1)

Steffen Nurpmeso wrote in <20210523212903.58vrh%stef...@sdaoden.eu>: |Good evening and Hello. And thanks to Mario Blättermann, replying to the mail unrevealed a bug that is present in the MUA i maintain since at least 2003 (nail 10.05)! A nice Monday i wish. (And happy 80th birthda

Re: getting more out of man pages with less(1)

Hello. |> Good idea. I've further changed the Subject: to reflect the flow of the |> discussion. ... |> I also wonder if the pager wars are basically over and less(1) won them. | |That's certainly what I thought... .. Ever since less(1) started supporting OSC 8 "Hyperlinks in Terminal

Re: man-intro

Ulrich Lauther wrote in <20210522214249.GA20730@starlite>: |On Sat, May 22, 2021 at 08:18:41PM +0200, Oliver Corff wrote: |> |> "man cd", on the other hand, opens the bash built-in command *man page*, |> which, at least on my system is a plethora of text to read (and digest). |> |on my

Re: Question about Unicode Greek

Hello. Robert Goulding wrote in : |I've been away from groff for a long time; I think the last time I used it, |there was no Unicode support at all. Now I'm interested in using it as a |filter from markdown, through pandoc to groff to pdf. | |This is working well for me, except for a

Re: How to make groff use local timezone?

Colin Watson wrote in <20201214154336.ga32...@riva.ucam.org>: |On Mon, Dec 14, 2020 at 02:12:28PM +1100, G. Branden Robinson wrote: |> At 2020-12-12T21:19:38-0800, Jim Avera wrote: |>> I suspect groff is always in UTC (but haven't confirmed).   |> |> No, that is not true, at least not in

Re: pdfmark not working

Timothy Groves wrote in : |Any attempt to use the pdfmark macro package causes exactly nothing to |happen - no error messages, but also no metadata being added to my PDF.  |I've followed the instructions that come with pdfmark slavishly, |including testing in the most minimal document

Re: [bug #59461] smoke-test_html_device.sh: make the test more independent of locale

Bjarni Ingi Gislason wrote in <20201113-180249.sv93188.62...@savannah.gnu.org>: |URL: | ... |locale -a | grep -F -q UTF-8 || exit 77 # skip That will not do, at least not portably and if you care for older systems. At minimum you must test utf8 and

Re: [DRAFT] Revised groff ms manual for review

Tadziu Hoffmann wrote in <20201108120208.gd2...@usm.uni-muenchen.de>: | |> When you say points are '(about 1/72")', it probably |> doesn't hurt to go the extra mile (!) in precision and |> say '(1/72.27")'. It's shorter (no need for 'about') |> and more correct. | |Historically, the size

Re: Unable to get GROFF_ENCODING to seep through to sourced subfiles

Dorai Sitaram wrote in <1129728531.3387046.1604937518...@mail.yahoo.com>: |I have GROFF_ENCODING set to utf8, but this only works for the main \ |file processed by groff, not to any subfiles that are sourced via .so . |Giving the -s option to groff to force a soelim doesn't work either.  

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

G. Branden Robinson wrote in <20201101042024.gfw4dqth3qlfxxw2@localhost.localdomain>: |At 2020-10-21T15:18:29+0200, Steffen Nurpmeso wrote: |>> Steffen has withdrawn most/all of his other patches and even after |>> reading |> |> I do not know what this has to do

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

Hello, and sorry for the late reply. G. Branden Robinson wrote in <20201101035740.2azpyoxgyrd6ozdl@localhost.localdomain>: |Hi, Steffen. Coming back to an old item of business. | |At 2020-09-29T19:12:00+1000, G. Branden Robinson wrote: |> At 2020-09-28T22:57:37+0200, Steffen Nurpm

Re: [bug #57218] [PATCH] Reproducible builds support is broken and embeds timezone

Hu-hu! Ingo Schwarze wrote in <20201022-173721.sv97361.91...@savannah.gnu.org>: |Follow-up Comment #4, bug #57218 (project groff): | |I think groff should not write %%CreationDate into PostScript files it |creates. Not because of reproducible builds, which i consider a useless \ |and

Re: [bug #55449] [PATCH] Use FILENAME_MAX in maxfilename.cpp

Ingo Schwarze wrote in <20201021231159.ge12...@athene.usta.de>: ... |Now, arguably, if pathconf(3) fails, which can easily happen if the |input argument is garbage, the function should not return (size_t)-1, |which is a large value. ... |Anyone willing to fix this particular bug? I have

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

|Steffen has withdrawn most/all of his other patches and even after reading I do not know what this has to do with this bug. |this report a few times I'm not clear on what exactly the problem is supposed |to be. | |The "solution", "drop gnulib", is not likely, especially not during an RC

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

|Steffen has withdrawn most/all of his other patches and even after reading I do not know what this has to do with this bug. |this report a few times I'm not clear on what exactly the problem is supposed |to be. | |The "solution", "drop gnulib", is not likely, especially not during an RC

Re: Learning troff - where to start?

Morten Bo Johansen wrote in : |On 2020-10-14 Peter Schaffter wrote: | |> What difficulties do you have entering UTF8 directly into the |> source? I've produced groff documents in most of the Western |> European and Scandinavian languages | |I thought we Scandinavians were also considered

Re: Learning troff - where to start?

Greg 'groggy' Lehey wrote in <20201013232627.gb24...@eureka.lemis.com>: |On Tuesday, 13 October 2020 at 22:49:03 +0200, J.-J. wrote: |> Le mardi 13 octobre 2020 à 14:41 +0200, Johann Höchtl a écrit : |>> * What would be a good starting point (tutorial) into troff and its |>> core principles?

Re: [bug #45034] [PATCH] mdoc(7): add support for the mdocmx(7) reference extension

Dave wrote in <20201013-025534.sv93119.11...@savannah.gnu.org>: |Update of bug #45034 (project groff): | | Summary: mdoc(7): add support for the mdocmx(7) reference |extension => [PATCH] mdoc(7): add support for the mdocmx(7) reference |extension Likewise, i am not going to

Re: [bug #45034] [PATCH] mdoc(7): add support for the mdocmx(7) reference extension

Dave wrote in <20201013-025534.sv93119.11...@savannah.gnu.org>: |Update of bug #45034 (project groff): | | Summary: mdoc(7): add support for the mdocmx(7) reference |extension => [PATCH] mdoc(7): add support for the mdocmx(7) reference |extension Likewise, i am not going to

Re: [bug #43541] [PATCH] FILE* encapsulation via class; compression support for input files

Dave wrote in <20201013-025522.sv93119.18...@savannah.gnu.org>: |Update of bug #43541 (project groff): | | Summary: FILE* encapsulation via class; compression \ | support |for input files => [PATCH] FILE* encapsulation via class; compression \ |support |for

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

Dave wrote in <20201013-025509.sv93119.83...@savannah.gnu.org>: |Update of bug #42233 (project groff): | | Summary: wcwidth(3) used on UCS4/UTF-32 codepoints \ | => [PATCH] |wcwidth(3) used on UCS4/UTF-32 codepoints My patch is based on old groff and even

Re: [bug #42233] [PATCH] wcwidth(3) used on UCS4/UTF-32 codepoints

Dave wrote in <20201013-025509.sv93119.83...@savannah.gnu.org>: |Update of bug #42233 (project groff): | | Summary: wcwidth(3) used on UCS4/UTF-32 codepoints \ | => [PATCH] |wcwidth(3) used on UCS4/UTF-32 codepoints My patch is based on old groff and even

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

G. Branden Robinson wrote in <20200927063701.vj6bg474km3ofpfh@localhost.localdomain>: |At 2020-09-16T01:21:14+0200, Steffen Nurpmeso wrote: |> C64 had no login. And DMR would not have used it. |> I am all with Tadziu Hoffmann in this thread. | |Did Tadziu comment on this thre

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

G. Branden Robinson wrote in <20200915183356.3xt3ywitpzifixm2@localhost.localdomain>: |At 2020-09-15T13:59:04+0200, Steffen Nurpmeso wrote: |> Just out of interest: why do you change an omnipresent idiom that |> is in use for standard section headers in Unix manual pages since

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

Hallo Ingo. Ingo Schwarze wrote in <20200915133505.gi1...@athene.usta.de>: |Hi Steffen, | |Steffen Nurpmeso wrote on Tue, Sep 15, 2020 at 01:59:04PM +0200: | |> Just out of interest: why do you change an omnipresent idiom that |> is in use for standard section headers in Unix

Re: [groff] 01/08: mdoc: Accept mixed-case section headings.

G. Branden Robinson wrote in <20200915110201.e2d1820...@vcs0.savannah.gnu.org>: ... |commit 0438b1b905ebe9ac5fc678af06db911d25c3a030 |Author: G. Branden Robinson |AuthorDate: Mon Sep 14 21:18:02 2020 +1000 | |mdoc: Accept mixed-case section headings. | |*

Re: manlint?

Sergiusz Pawlowicz wrote in : |Hi, |is there anything like "manlint"? |A tool which verifies the syntax of a man file and eventually points \ |to errors? Use "mandoc -Tlint". It has flaws but is the best i know. You can also use FreeBSD's igor, it is meant for mdoc macros but nonetheless

Re: Plan 9 man added a new macro for man page references

G. Branden Robinson wrote in <20200815112655.xow4f3d4dcdaiaui@localhost.localdomain>: |[CCing Russ Cox out of the blue; Russ, I work on GNU roff] | |Plan 9 went and did an interesting thing[1]. They implemented a macro |just for man page cross-references. ... |[1]

Re: Groff macro to make .UR and .UE links clickable in PDF?

Michael Pirkola wrote in <20200717123254.3aff0148@walrus>: |On Sat, 11 Jul 2020 09:28:45 +0100 |Colin Watson wrote: | |> On Fri, Jul 10, 2020 at 11:26:46AM -0400, Steve Izma wrote: |>> I think it's an abomination that a man page extends it's line |>> length to fit the width of the terminal;

Re: .Xr mdoc(7) from groff_mdoc(7)?

I am off-topic. Ingo Schwarze wrote in <20200625214812.gf90...@athene.usta.de>: |given that two authoritative manual pages for the mdoc language |exist that describe exactly the same language, but in a somewhat ... | The manual page groff_mdoc(7): https://man.voidlinux.org/groff_mdoc |

Fwd: Re: Groff macro to make .UR and .UE links clickable in PDF?

--- Forwarded from B 9 --- Date: Fri, 19 Jun 2020 13:55:30 -0700 From: B 9 To: Steffen Nurpmeso Subject: Re: Groff macro to make .UR and .UE links clickable in PDF? Message-ID: <20200619205530.n0y90%hacke...@member.fsf.org> Steffen Nurpmeso wrote: > Yes i am reading this lis

Re: Groff macro to make .UR and .UE links clickable in PDF?

B 9 wrote in <20200619061008.okwcr%hacke...@member.fsf.org>: |Since mdoc is a "semantic markup language", I presumed it would have |some way to specify a hyperlink in running text that won't (to the |best of mdoc's abilities) interfere with the flow of the text. The |exact implementation would

Re: man Macro Package and pdfmark

Ingo Schwarze wrote in <20200214184532.gj92...@athene.usta.de>: |Hi Jeff, | |Jeff Conrad wrote on Thu, Feb 13, 2020 at 03:45:10PM -0800: | |> A major drawback to manual pages formatted using the man macros is the |> lack of bookmarks in a PDF file. A quick and dirty way to get bookmarks |>

Re: man Macro Package and pdfmark

Jeff Conrad wrote in : |A major drawback to manual pages formatted using the man macros is the |lack of bookmarks in a PDF file. A quick and dirty way to get bookmarks |appears to be adding | |.am SH |.pdfbookmark 1 "\&\\$*" |.. |.am SS |.pdfbookmark 2 "\&\\$*" |.. Why quick and dirty?

Re: [bug #57592] [PATCH] tmac/: Add a warning

Bjarni Ingi Gislason wrote in <20200113-183655.sv93188.51...@savannah.gn\ u.org>: |URL: | .. |From: Bjarni Ingi Gislason |Date: Mon, 13 Jan 2020 18:10:39 + |To: bug-groff@gnu.org |Subject: [PATCH] tmac/: Add a warning | | Some macro files have

Re: pic anomalies

Ingo Schwarze wrote in <20191227212705.gi66...@athene.usta.de>: |Hi Doug, | |Steffen Nurpmeso wrote on Fri, Dec 27, 2019 at 06:45:23PM +0100: | |> Should be handled by [...] | |I believe the first patch that got sent to the list is incorrect. | |The parser in src/pre-pic/pic.

Re: pic anomalies

Doug McIlroy wrote in <201912271608.xbrg84jr128...@tahoe.cs.dartmouth.edu>: |The description of sprintf in the man page pic(1) does not |reveal that only a few format codes are permitted. | |Eric Raymond's "Making Pictures With GNU PIC" says only |%,%e,%f,%g are permitted. But what does a

Re: [bug #57485] [PATCH] accept any number of arguments for .Dd in the groff_mdoc(7) macros

Ingo Schwarze wrote in <20191226222825.ga23...@athene.usta.de>: |I'm not posting these answers into the bugtracker because these |points are not relevant for evaluating the patch; i'm merely sending |this mail to avoid that people get confused by the misleading |statements. | |S

Re: [bug #57485] [PATCH] accept any number of arguments for .Dd in the groff_mdoc(7) macros

Hi Ingo. Ingo Schwarze wrote in <20191226-172201.sv97361.20...@savannah.gnu.org>: |Follow-up Comment #1, bug #57485 (project groff): | |I'd like to stress that this patch indeed fixes a bug. In 4.4BSD, |it was *not* documented that .Dd requires exactly three arguments |and prints the

Re: [bug #57485] [PATCH] accept any number of arguments for .Dd in the groff_mdoc(7) macros

Ingo Schwarze wrote in <20191226-144637.sv97361.2...@savannah.gnu.org>: |URL: | | | Summary: [PATCH] accept any number of arguments for .Dd in |the groff_mdoc(7) macros | Project: GNU troff |Submitted by:

Re: FAMILY-dependent apostrophe behaviour with -mom

Hello. Deri wrote in <2403810.z0MjTcnAeh@pip>: |On Monday, 2 December 2019 16:22:34 GMT Marc Simpson wrote: | |> Hi Dale, | |> | |> Thanks for your reply. Sorry for jumping into your thread and being off-topic, but may i ask what mailer you use? It produces the most terrible HTML that i

Re: [groff] Table of content for UTP in groff format

Andrea D'Amore wrote in : |Hello, |I got the "UNIX Text Processing" book in groff format, link "groff and |PostScript files--Beta" at [1] and built the default "utp_book.ps" |target. |The resulting PostScript file and its conversion to PDF via ps2pdf |have no outline. | |I see the Makefile

Re: [groff] Table of content for UTP in groff format

Andrea D'Amore wrote in : |On Thu, 24 Oct 2019 at 17:11, Andrea D'Amore wrote: |> link "groff and PostScript files--Beta" at [1] and built the default \ |> "utp_book.ps" target. |[…] |> [1]: https://www.oreilly.com/openbook/utp/ | |While [1] is active the mentioned link points to a

Re: [groff] MacTeX (was: groff and pipes)

Douglas Johnson wrote in <20190807133230.ga25...@panix.com>: |On Aug 07, 2019, at 08:40, John Gardner wrote: | |>Installing TeX on macOS also requires a 3.9 GB download of the full |>MacTeX distribution, whereas Groff's source tree doesn't even consume |>that much space... | |Installing

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

Steffen Nurpmeso wrote in <20190704202830.ds7rz%stef...@sdaoden.eu>: |James K. Lowden wrote in <20190703140438.a516b5af83532af9d7aa883b@schema\ |mania.org>: ||On Wed, 3 Jul 2019 07:08:44 +1000 ||John Gardner wrote: || ||> Really? That's interesting. What did do? On the term

Re: [groff] [PATCH] new requests to case-transform string register values

G. Branden Robinson wrote in <20190703154957.27lxnueucvu2cr5v@localhost.\ localdomain>: |A recurring theme in my man page clean-up work has been my violent |antipathy for shouting capitals in their texts. While I don't _like_ |being shouted at for reasons other than true emergency, the real

Re: [groff] 04/05: {g, n}roff.1.man: Give assistance to pager users.

James K. Lowden wrote in <20190703140438.a516b5af83532af9d7aa883b@schema\ mania.org>: |On Wed, 3 Jul 2019 07:08:44 +1000 |John Gardner wrote: | |> Really? That's interesting. What did do? On the terminal |> emulators I have on hand at the moment, none of them are responding |> or behaving

Re: [groff] no header in Japanese manpages

KUBO Koichi wrote in <51db73de-bc1a-e930-1be6-b5b04e432...@obuk.org>: |On 4/21/19 2:22 AM, Steffen Nurpmeso wrote: |> KUBO Koichi wrote in <51fe9714-c2f9-5351-e4d5-aacc92fa0...@obuk.org>: |>|I am using groff-1.22.4 on FreeBSD. |>|After updating groff, I realized th

Re: [groff] no header in Japanese manpages

Hello. KUBO Koichi wrote in <51fe9714-c2f9-5351-e4d5-aacc92fa0...@obuk.org>: |I am using groff-1.22.4 on FreeBSD. |After updating groff, I realized that there is no header in Japanese |manpages using mdoc.tmac. So I added the following line to |mdoc.local: | |.if ((\n[.x]\n[.y] >= 122) &

Re: Possible bug with utf8 encoded files, when sourced via .so

Paul Ito wrote in : |Very new to this list, so please be gentle. | |I have the following issue: | |I want to include a utf8-encoded file "text.txt" (with lots of german \ |umlauts in my case) into a groff file "include.roff", |that would then be processed with the -ms macro along with the

Re: [bug #55449] Use FILENAME_MAX in maxfilename.cpp

Steffen Nurpmeso wrote in <20190112142048.2xfrg%stef...@sdaoden.eu>: |Steffen Nurpmeso wrote in <20190112141035.ao9y8%stef...@sdaoden.eu>: ||Eli Zaretskii wrote in <838szqf00l@gnu.org>: |||> Date: Sat, 12 Jan 2019 14:42:31 +0100 |||> From: Steffen Nurpmeso ||

  1   2   3   4   >