[bug #66103] manpage-10n project: issues in man pages

Follow-up Comment #4, bug #66103 (group groff): >> Man page: soelim.1 >> Issue 1: I<\\%soelim> → B<\\%soelim> >> Issue 2: I<\\%troff> → .MR \\%troff 1 >> >> "I<\\%soelim> is I required for I<\\%troff> to source files." > As this is the very next sentence, another cross reference here would be

[bug #64772] [hdtbl] consider deprecating

Follow-up Comment #6, bug #64772 (project groff): [comment #5 comment #5:] > which implies his previously quoted characterization of the package as "buggy as hell" is speculative based on code inspection, rather than empirical based on testing. Note that code review and black-box testing are bot

[bug #64619] [mdoc] allow distros to maintain mdoc strings

Follow-up Comment #4, bug #64619 (project groff): Not sure why you interpret https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273903 as being mad. That's merely a list of things FreeBSD needs to deal with when upgrading to groff-1.23, and it happens to be public. It's normal that a major vers

[bug #64619] [mdoc] allow distros to maintain mdoc strings

Follow-up Comment #2, bug #64619 (project groff): This is a bad idea. It would cause manual pages to become non-portable. FWIW, i agree with Branden that the string system is among the more poorly designed parts of the mdoc(7) language. Not all of that can be fixed. In particular, the existing

[bug #64594] [troff] "warning: cannot select font 'C'"

Follow-up Comment #2, bug #64594 (project groff): Let me provide a shorter answer to supplement what gbranden@ said: With that kind of low-quality non-portable input poking deeply into implementation details of the formatter instead of using man(7) macros like a manual page should, it's not surpr

[bug #64502] [mdoc] macros should inhibit word breaking where sensible

Follow-up Comment #3, bug #64502 (project groff): FYI: how mandoc(1) does this. 1) mandoc(1) never hyphenates anything - obviously, groff(1) does not want to emulate *this* aspect. 2) Even at existing hyphens, mandoc(1) only breaks output lines if the word containing the hyphen is on a text input

[bug #63958] [mdoc] decide how to set up hanging indent in Synopsis sections

Follow-up Comment #18, bug #63958 (project groff): To re-iterate, right now, i don't see a need to change anything with respect to the topic of this ticket. Unless i'm unaware of some arcane corner cases, i modeled the hanging indents in mandoc(1) to match how groff(1) does them. Ragarding the v

[bug #64018] [man, mdoc] decide on a common base paragraph indentation

Follow-up Comment #22, bug #64018 (project groff): [comment #15 comment #15:] > > > > We cannot, obviously, have three-letter requests. > > > Nope. Like I said, there's room for `Cq`, `Co`, and `Cc`. > > > > Indeed, I see only Co used grepping through all tmacs: > > tmac.doc.old has it as macro

[bug #64018] [man, mdoc] decide on a common base paragraph indentation

Follow-up Comment #21, bug #64018 (project groff): Regarding editing manual page source code in such a way as to avoid particularly ugly line breaks in standard-width 80 column terminal windows: [comment #12 comment #12:] > Possibly, _mdoc_(7) page authors knew this and carefully edited the ones

[bug #64018] [man, mdoc] decide on a common base paragraph indentation

Follow-up Comment #3, bug #64018 (project groff): I see no reason why the standard indentation of running text from the left margin of the paper and the default indentation inside a tagged paragraph need to be related in any way. In fact, in 1990 Kernighan troff, the former was \n(IN and the latt

[bug #64018] [man, mdoc] decide on a common base paragraph indentation

Follow-up Comment #1, bug #64018 (project groff): The setting ".nr IN 7.2n" is present since the beginning of the groff repository, i.e. groff-1.06, Sep 1 12:28:08 1992, file tmac/tmac.an . The groff-1.01 released by James Clark on Mar 13 12:49:40 1991 and declared as a "beta-test version" that i

[bug #63958] [mdoc] decide how to set up hanging indent in Synopsis sections

Follow-up Comment #8, bug #63958 (project groff): re comment #5: re bug #63046: We both know that i dislike excessive, gratuitious configurability like that - it add complexity without any benefit, no need to discuss that over and over again. I can live with it as long as the defaults are sane,

[bug #63958] [mdoc] decide how to set up hanging indent in Synopsis sections

Follow-up Comment #6, bug #63958 (project groff): re comment #4: Yes, i believe it must have been a widget-clicking goof on my part, and i didn't even notice it when the "status" changed. Sorry for that. I don't like interactive web interfaces except those that are strictly read-only, and it se

[bug #63958] [mdoc] decide how to set up hanging indent in Synopsis sections

Update of bug #63958 (project groff): Status:None => Duplicate ___ Follow-up Comment #3: Your comment #2 seems fair enough in general, but note that i'm not guaranteed to be the happiest

[bug #63958] [mdoc] decide how to set up hanging indent in Synopsis sections

Follow-up Comment #1, bug #63958 (project groff): 1. mandoc(1) uses 4n, presumably for compatibility with groff. 2. That's only because mandoc(1) does not support mixed-case section names yet. Apply s/Synopsis/SYNOPSIS/ and mandoc(1) works as expected. Yes, this will be fixed in mandoc(1), hopef

[bug #63076] Adding Russian language to groff

Update of bug #63076 (project groff): Severity: 3 - Normal => 1 - Wish Item Group:None => Feature change ___ Follow-up Comment #2: Someone has to do the

[bug #49390] last line of boxed tables overprinted on nroff devices

Follow-up Comment #7, bug #49390 (project groff): Fix merged to mandoc in https://cvsweb.bsd.lv/mandoc/tbl_term.c#rev1.79 https://marc.info/?l=mandoc-source&m=166168405927772 ___ Reply to this item at:

[bug #62841] [man] stop forcing vertical space before tbl(1) tables

Follow-up Comment #3, bug #62841 (project groff): Merged to mandoc in: https://cvsweb.bsd.lv/mandoc/man_term.c#rev1.241 https://marc.info/?l=mandoc-source&m=166168038326866 ___ Reply to this item at:

[bug #62841] [man] stop forcing vertical space before tbl(1) tables

Update of bug #62841 (project groff): Severity: 3 - Normal => 4 - Important Item Group: Rendering/Cosmetics => Feature change ___ Follow-up Comment #2: This is an incompatib

[bug #62926] [mdoc] align styling of titles and man page cross references with man(7)

Follow-up Comment #6, bug #62926 (project groff): It seems CS, CT, D, HY, LL, LT, and S are GNU only, but cR already appeared in 4.4BSD. So indeed, the horse is barely in sight of the barn any longer, let alone inside of it. No, i wasn't aware of that. In this situation, while MF does add even m

[bug #62926] [mdoc] align styling of titles and man page cross references with man(7)

Follow-up Comment #3, bug #62926 (project groff): [comment #2 comment #2:] > It should surprise no one that my idea is to support the `MF` string in _mdoc_(7) just as is already done in _man_(7). Yikes. Are you aware that the mdoc(7) language API does not contain a single user-visible register

[bug #62926] [mdoc] align styling of headers and man page cross references with man(7)

Follow-up Comment #1, bug #62926 (project groff): No comment on the first sentence because it is not very specific. I do not object to the rest of the original submission. But i strongly disagree with the summary. mdoc(7) has always consistently styled .Xr as \fR for terminal output whereas man

[bug #62918] Wrong GhostScript version reported during build

Follow-up Comment #2, bug #62918 (project groff): [comment #1 comment #1:] > I will be adding a new program, pdfmake, Please don't. Adding yet another program for each afterthought forgotten in the original UI design ruins an API by adding more and more complexity and accumulating more and more

[bug #62814] consolidate or distinguish tty.tmac and tty-char.tmac

Follow-up Comment #5, bug #62814 (project groff): [comment #4 comment #4:] > While not as often a problem in practice these days, the troffrc file is not editable by ordinary users, only by root. As documented in the GNU troff(1) manual, that's trivial to solve for advanced users: Copy troffrc t

[bug #62776] [troff] add optional diagnostic for sentences ending mid-input line

Follow-up Comment #3, bug #62776 (project groff): Not an objection, just for your consideration. We already have a method for enabling, disabling, and selecting diagnostic messages. Please remember that organizing diagnostic messages is among those areas most prone to code sprawl and over-enginee

[bug #62814] consolidate or distinguish tty.tmac and tty-char.tmac

Follow-up Comment #3, bug #62814 (project groff): Please don't overengineer it by defining registers and adding .if statements and the like. tty.tmac is called from troffrc. One simple idea would be to just call tty-char.tmac from the same place. So power users who don't want it by default can si

[bug #62814] consolidate or distinguish tty.tmac and tty-char.tmac

Follow-up Comment #1, bug #62814 (project groff): Arguably, the definitions in tty.tmac are of such a high quality that any user of terminal output wants to use term unconditionally, and warnings about characters in the input document that need any of these fallbacks would make little sense. Most

[bug #40720] [UPGRADE] improve Unicode support

Follow-up Comment #4, bug #40720 (project groff): [comment #3 comment #3:] > Back in '04, Werner posted an overview of how to start tackling this: http://lists.gnu.org/r/groff/2004-05/msg00074.html That's not really an overview but merely a single, partial idea with no context. Essentially, Werne

[bug #62494] [grotty] Remap ~ and ^ to their ASCII equivalents

Follow-up Comment #6, bug #62494 (project groff): I should like to retract my comments #1 and #3. They were wrong because the mappings i quoted were never device-independent. For example, in PDF output, the five input characters in question never mapped to ASCII output characters, so using them

[bug #62494] [grotty] Remap ~ and ^ to their ASCII equivalents

Follow-up Comment #3, bug #62494 (project groff): I had almost given up hope, but maybe we can still get these particular changes for these five input glyphs reverted? It looks like they are more controversial than people thought, and John's suspicion that the number of complaints will only grow

[bug #62494] [grotty] Remap ~ and ^ to their ASCII equivalents

Follow-up Comment #1, bug #62494 (project groff): Indeed. I said before, and will say again in this context, that i would prefer keeping these mappings in manual pages (i won't type any punctuation characters here for fear that the weird Savannah web interface might mangle stuff): input -> outpu

Re: Build error

Hi Branden, G. Branden Robinson wrote on Thu, Mar 24, 2022 at 10:28:22PM +1100: > To reproduce it, I had to do an in-source-tree build. The problem > arises in the "install" target. I _always_ build in a separate "build" > subdirectory, and apparently "make distcheck" always does too, and that

[bug #55789] [PATCH] [mdoc] want .St -susv1 and -susv4

Update of bug #55789 (project groff): Status: Confirmed => Fixed Open/Closed:Open => Closed Summary: [PATCH] [mdoc] want more abbreviations => [PATCH] [mdoc] want .St -susv1 and -su

[bug #55789] [PATCH] tmac/doc-syms-u: Some abbreviations are missing.

Follow-up Comment #5, bug #55789 (project groff): Are people ignoring my comment #1 for some unstated reason and posting patches adding the spurious -xsh4.2 anyway? My preference would be to add -susv1 and -susv4 but to delete -xsh4.2, but i would appreciate a second opinion before doing that. I

Re: [bug #61315] Several groff source files don't include first

Hi Werner and Paul, Werner LEMBERG wrote: > However, I have the feeling that it is moot to discuss this further. > It seems to me part of the eternal GNU vs. BSD philosophy clash. This appears to be independent of the BSD vs. GNU clash, which is a question of licensing, and a question of what "

Re: [bug #61315] Several groff source files don't include first

Hi Werner, [ I'm not Cc:ing the ticket because this is not directly related to the ticket, but i still want to answer your questions. ] Werner LEMBERG wrote on Sat, Oct 09, 2021 at 04:27:23PM +: >> I still think it would be better to just get rid of gnulib. > That's a bad idea IMHO. Yes,

[bug #61315] Several groff source files don't include first

Follow-up Comment #2, bug #61315 (project groff): In ticket #59276 and commit fe121eea, i only fixed those files that actually did require fixing at the time of the commit. The groff codebase still contains lots of files that do not include config.h. My rationale for doing the bare minimum was t

[bug #44018] [PATCH] gtroff hangs in environment::possibly_break_line with -mja

Follow-up Comment #5, bug #44018 (project groff): Looking at that code, i conclude that *is* already coded very defensively. What "int width = 24; int w = wcwidth(get_code(g)); if (w > 1) width *= w;" does is this: * If and only if the C library is sure that the character is double width, reserv

[bug #61167] "make man" does not generate manpages, as it should

Follow-up Comment #6, bug #61167 (project groff): Right now, let me refrain from lobbying for the deletion of a target that already exists, even if i doubt its importance; i think more important cleanup work exists, and the bar for deleting an existing feature is likely a bit higher than the bar f

[bug #44018] [PATCH] gtroff hangs in environment::possibly_break_line with -mja

Follow-up Comment #3, bug #44018 (project groff): Re comment #2: I sense a possible contradiction in this comment: "returning zero" is not the same as "negative character widths". Regarding the first sentence, for wcwidth(3), a zero return value means the character takes up no horizontal space.

[bug #61167] "make man" does not generate manpages, as it should

Follow-up Comment #3, bug #61167 (project groff): Dave dixit: > the red-headed stepchildren of documentation Maybe, but i don't consider this an indication. Well-designed manual pages simply don't need to be built, just installed. So i don't see a problem with including them in the "install" t

[bug #61104] [PATCH] .At 32v should say "[Version 7] AT&T UNIX/32V", not "Version 32V AT&T UNIX"

Follow-up Comment #5, bug #61104 (project groff): Forgot to mention that the same change was applied to portable mandoc and to OpenBSD: https://marc.info/?l=mandoc-source&m=16307876699 https://cvsweb.bsd.lv/mandoc/att.c https://marc.info/?l=openbsd-cvs&m=163078709826654 https://cvsweb.openbs

[bug #61104] [PATCH] .At 32v should say "[Version 7] AT&T UNIX/32V", not "Version 32V AT&T UNIX"

Update of bug #61104 (project groff): Severity: 3 - Normal => 2 - Minor Item Group: Incorrect behaviour => Build/Installation Status:None => Fixed Assigned to:

[bug #61014] [man] should support refer(1)

Follow-up Comment #1, bug #61014 (project groff): You did not yet explain what the advantage of implementing this feature would be, for authors or users. As far as i understand, the point of refer(1) is that authors writing many academic papers can keep the papers they cite repeatedly in a databa

[bug #61002] [an.tmac]: old macro "an-trap" is used in some manuals

Update of bug #61002 (project groff): Severity: 3 - Normal => 1 - Wish ___ Follow-up Comment #1: I advise against this. If people use undocumented internal features of a system that are not part

[bug #60828] [locale][mm][ms] [me] Add an Italian locale

Follow-up Comment #2, bug #60828 (project groff): Edmond Orignac just confirmed in private mail to me that he is indeed the author of the it.tmac file submitted yesterday. He simply modified the fr.tmac file changing French sentences into Italian. He also confirmed that he wishes to have the file

[bug #60828] [locale][mm][ms] [me] Add an Italian locale

Update of bug #60828 (project groff): Category: Macro - mm => Macro - others Severity: 3 - Normal => 1 - Wish Status:None => Confirmed

[bug #57720] mandoc.tmac: Missing definition of some strings

Follow-up Comment #2, bug #57720 (project groff): Bjarni wrote: > troff: :730: warning: macro 'R' not defined Cannot reproduce either. Then, even if it were reproducible, it would totally be a non-issue because the context these user-defined strings are expanded in is explaining that their port

[bug #60639] src/utils/addftinfo/addftinfo.cpp:119: double increment ?

Follow-up Comment #4, bug #60639 (project groff): [comment #3 comment #3:] > I think i += 2 in the last part of the for loop specifier > might make the programmer's original intent more clear. Purely a matter of style, there are arguments both ways. The existing code puts each increment close to

[bug #60639] src/utils/addftinfo/addftinfo.cpp:119: double increment ?

Update of bug #60639 (project groff): Severity: 3 - Normal => 1 - Wish Item Group:None => Warning/Suspicious behaviour Status: Need Info => Invalid Open/Closed

[bug #59753] src/roff/grog/subs.pl: Add file extensions "posix" and "tcl"

Update of bug #59753 (project groff): Category:Core => None Severity: 3 - Normal => 1 - Wish ___ Follow-up Comment #1: I object. If we were

[bug #59425] [man, ms, mm]: drop compatibility wrapper feature

Follow-up Comment #3, bug #59425 (project groff): Re: comment #2 >> nobody in their right mind would want to use non-groff macro packages with groff. > In principle, they should work find in compatibility mode. The question is not so much whether they would work but why anybody would want to d

[bug #59442] [PATCH] groff.cpp: move soelim before preconv in constructed pipeline

Update of bug #59442 (project groff): Category:Core => Preprocessor preconv Item Group: Incorrect behaviour => New feature ___ Follow-up Comment #2: Quick answer without

[bug #59425] [man, ms]: man pages are not compatibility-wrapper aware

Follow-up Comment #1, bug #59425 (project groff): Changing the names of macro packages to avoid conflicts only makes sense as long as you have a concept of portable macro packages *and* you desire alternative implementations of standard macro packages to work with the same roff implementation. Bu

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

Follow-up Comment #7, bug #57218 (project groff): To clarify: 1. I do not object to reproducible build support as far as it is easy to implement and has no downsides. 2. In particular, i do not object to cjwatson@'s patch #50208 that gbranden@ puts forward in comment #6. I did not test the patch,

[bug #59415] tmac/groff_mdoc.7.man: Warnings from "mandoc -T lint"

Update of bug #59415 (project groff): Severity: 3 - Normal => 1 - Wish Status:None => Invalid Open/Closed:Open => Closed

[bug #59276] [PATCH] #include "config.h" before

Follow-up Comment #7, bug #59276 (project groff): Re: comment #6 Thanks, Dave, for noting that. I decided to not waste my time replying to gnulib because: 1. They did not reply to the observation that their tests are wrong because they assume that __restrict, if available, is the same as "restr

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

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 even detrimental feature, but because of privacy concerns. That would also solve this so-called "pr

[bug #55335] [PATCH] preconv produces CR CR LF end-of-line on MS-Windows

Follow-up Comment #3, bug #55335 (project groff): I don't see a risk here. If i read src/include/nonposix.h correctly, SET_BINARY() is a NOOP on any sane system. So given that Eli tested it extensively on Windows, i think no further testing is needed. Any developer who understands in principle

[bug #55334] preconv fails when build with libuchardet on MS-Windows

Follow-up Comment #15, bug #55334 (project groff): Re comment #14: All makes sense to me. Branden, do you want to write the required patch to avoid guessing from the filename and instead use fseek(3) and check for errors, as i suggested? And test it? I don't really want to work on it because i

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

Hi Carsten, Carsten Kunze hat am 21. Oktober 2020 um 21:23 geschrieben: > How about at first using pathconf(3) with the constant _PC_NAME_MAX > to determine the file name length (for a specfific path) and using > the constants only when pathconf returns -1? The file already does that, if pathcon

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

Update of bug #55449 (project groff): Status: Need Info => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #6: Pushed in 9c5f9a862a7

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

Update of bug #55449 (project groff): Assigned to:None => schwarze Planned Release:None => 1.23 ___ Follow-up Comment #4: The patch #45943 is n

[bug #59276] [PATCH] #include "config.h" before

Update of bug #59276 (project groff): Status: Need Info => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #5: Fortunately, nothing

[bug #59276] [PATCH] #include "config.h" before

Update of bug #59276 (project groff): Status: Fixed => Need Info Open/Closed: Closed => Open ___ Follow-up Comment #3: re comment #2: This

[bug #59290] ms: add register to enable backtraces on diagnostics

Follow-up Comment #3, bug #59290 (project groff): Re comment #2: These are all fair points, so probably you are right that a register makes sense here. Another aspect to consider: the task is generic, not specific to ms. So ideally, the naming would harmonize with the naming schemes of *all* ma

[bug #59276] [PATCH] #include "config.h" before

Update of bug #59276 (project groff): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Fixed in fe121eeacd53

[bug #59290] ms: add register to enable backtraces on diagnostics

Follow-up Comment #1, bug #59290 (project groff): >From a user perspective, this should be a command line option, not a register. Registers make sense for properties of the document itself, set on a source line inside the document file itself. They are well-suited to properties that are the same

[bug #55334] preconv fails when build with libuchardet on MS-Windows

Follow-up Comment #13, bug #55334 (project groff): Thanks for fixing this! I would like to raise a minor concern, maybe you can tweak your solution. Comparing the filename to "-" seems fragile. There may be other ways to get a non-seekable file descriptor, for example someone passing "/dev/stdi

[bug #59270] [PATCH] node.h: avoid C++11 feature (non-const init in class)

Update of bug #59270 (project groff): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: fixed in 5b34d465c97a

[bug #59276] [PATCH] #include "config.h" before

Update of bug #59276 (project groff): Planned Release:None => 1.23 ___ Reply to this item at: ___ Mess

[bug #59276] [PATCH] #include "config.h" before

URL: Summary: [PATCH] #include "config.h" before Project: GNU troff Submitted by: schwarze Submitted on: Thu 15 Oct 2020 01:27:04 PM UTC Category: Core Severity: 3 -

[bug #59268] [PATCH] tmac.am: non-portable $< syntax

Update of bug #59268 (project groff): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #2: Fixed in 997b6b3c4582

[bug #59270] [PATCH] node.h: avoid C++11 feature (non-const init in class)

Update of bug #59270 (project groff): Planned Release:None => 1.23 ___ Reply to this item at: ___ Mess

[bug #59270] [PATCH] node.h: avoid C++11 feature (non-const init in class)

URL: Summary: [PATCH] node.h: avoid C++11 feature (non-const init in class) Project: GNU troff Submitted by: schwarze Submitted on: Wed 14 Oct 2020 01:34:45 PM UTC Category: Core

[bug #59268] [PATCH] tmac.am: non-portable $< syntax

Update of bug #59268 (project groff): Planned Release:None => 1.23 ___ Reply to this item at: ___ Mess

[bug #59268] [PATCH] tmac.am: non-portable $< syntax

URL: Summary: [PATCH] tmac.am: non-portable $< syntax Project: GNU troff Submitted by: schwarze Submitted on: Wed 14 Oct 2020 11:56:23 AM UTC Category: Macro - man Sev

[bug #55297] [PATCH] "groff -v -j" hangs

Update of bug #55297 (project groff): Status:None => Fixed Assigned to:None => schwarze Open/Closed:Open => Closed Planned Release:

[bug #55091] [PATCH] stop stripping comments and spaces from installed macro packages

Update of bug #55091 (project groff): Planned Release:1.23 => None ___ Follow-up Comment #2: I think this should be done, but most definitely not shortly before release because there is a ris

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

Update of bug #45034 (project groff): Severity: 3 - Normal => 1 - Wish Status:None => Wont Fix Open/Closed:Open => Closed

[bug #44289] [PATCH] nroff script -E option

Update of bug #44289 (project groff): Category:None => Device - others Status:None => In Progress Assigned to:None => schwarze Planned Release:

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

Update of bug #43541 (project groff): Status:None => Wont Fix Open/Closed:Open => Closed ___ Follow-up Comment #2: Patch retracted by au

Re: [bug #59251] fix an example in groff_tmac(5)

Hi, i'm no longer posting to the bugtracker because this is no longer relevant to the ticket. ivan tkachenko wrote on Mon, Oct 12, 2020 at 06:05:43PM -0400: > Follow-up Comment #4, bug #59251 (project groff): > I pulled master branch -- and there it is, already in the upstream. Well, admittedly

[bug #59251] fix an example in groff_tmac(5)

Update of bug #59251 (project groff): Status: Need Info => Fixed Assigned to:None => schwarze Open/Closed:Open => Closed Planned Release:

[bug #59251] So anyways, how do I contribute?

Update of bug #59251 (project groff): Severity: 3 - Normal => 2 - Minor Status:None => Need Info ___ Follow-up Comment #1: Just attach your patc

Re: [PATCH] Fix typos

Hi, Samanta Navarro wrote on Sun, Oct 04, 2020 at 11:42:21AM +: > contrib/hdtbl/groff_hdtbl.7.man | 2 +- > src/roff/grog/grog.1.man| 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) Pushed, thanks. Ingo > diff --git a/contrib/hdtbl/groff_hdtbl.7.man b/contrib/hdtbl/grof

[bug #59030] some warnings [errors] still emitted with -Ww

Follow-up Comment #9, bug #59030 (project groff): gbranden wrote: > I'm fairly militant about diagnostic messages always including their diagnostic level. I like that, and i think it makes a lot of sense in multiple levels. > I'm undecided as to whether it should. I think it is very good that

[bug #59031] the \[Im] and \[Re] escapes are wrong

Update of bug #59031 (project groff): Item Group: Incorrect behaviour => Documentation Status: Need Info => In Progress ___ Follow-up Comment #6: Sorry, setting back t

[bug #59031] the \[Im] and \[Re] escapes are wrong

Update of bug #59031 (project groff): Item Group: Documentation => Incorrect behaviour Status: In Progress => Need Info ___ Follow-up Comment #4: You were explicitly t

[bug #59031] the \[Im] and \[Re] escapes are wrong

Follow-up Comment #1, bug #59031 (project groff): This report appears to be invalid. \(Re and \(Im represent the functions "real part" and "imaginary part". Both functions are surjective, but not injective funtions taking a complex argument and delivering a real result. \(Re is also idempotent,

[bug #58796] preconv: want option to write traditional [g|t]roff special characters where possible

Follow-up Comment #4, bug #58796 (project groff): Regarding note #3 (it's all a bit tangential to this ticket): I meant requiring iconv(3) at compile time, not iconv(1) at run-time. The former would be horrible, the latter almost harmless. I neither think that groff is really C++, it is more li

[bug #58796] preconv: want option to write traditional [g|t]roff special characters where possible

Follow-up Comment #2, bug #58796 (project groff): Hi Dave, > a bit of a hack Not so much, actually. Making good use of pipes is among the design principles of the whole roff ecosystem, to harmonize with the overall UNIX design philosophy that every tool should solve one task only, but solve it

[bug #43532] [PATCH] man: put titles on separate lines when parts too wide, instead of overlapping them

Follow-up Comment #3, bug #43532 (project groff): For comparison, here is what mandoc does: $ mandoc .TH CosNotifyChannelAdmin_StructuredProxyPushSupplier 3erl "cosNotification 1.1.18" "Ericsson AB" "Erlang Module Definition" CosNotifyChannelAdmin_StructuredProxyPushSupplier(3erl)

[bug #51362] [PATCH]: Add a synonym for the font "CW"

Follow-up Comment #4, bug #51362 (project groff): The bad practice of requesting \f(CW or .ft CW in man(7) pages is widespread enough that mandoc(1) has been supporting it for backward compatibility for many years. In practice, \f(CW is clearly used more often than the more logical \f(CR (which m

[bug #58653] Please add back in the mdoc(7) manual

Follow-up Comment #7, bug #58653 (project groff): > I had thought you were linking to the mdoc documentation that comes with BSD. mandoc is portable software. It is included and used by default in these systems (chronological order by first official use): OpenBSD, NetBSD, Illumos, Void Linux, Fr

[bug #58653] Please add back in the mdoc(7) manual

Follow-up Comment #5, bug #58653 (project groff): > Good documentation lets people know right away what the > cost of learning will be and what the benefits are. Right, that's usually the first one to three sentences in a manual page. No need for a separate document. In groff_mdoc(7), the first

[bug #58653] Please add back in the mdoc(7) manual

Follow-up Comment #3, bug #58653 (project groff): You say "i wish you had mentioned this before". Granted, it would have been helpful, and i wanted to. But there isn't time to answer all questions i could usefully respond to, so it fell through the cracks. I estimate roughly 80% fall through th

[bug #58653] Please add back in the mdoc(7) manual

Update of bug #58653 (project groff): Severity: 3 - Normal => 1 - Wish Assigned to:None => schwarze ___ Follow-up Comment #1: I *VERY* strongly opp

[bug #58016] Add an option "--label=" to show an origin of diagnostics

Follow-up Comment #3, bug #58016 (project groff): Which, as we just noted in another thread on the mailing list, is the most common case (even if admittedly not universal, as e.g. Ralph observed). But i really think we should not add weird, non-essential options bloating the user interface - mere

[bug #58314] [PATCH] preconv.cpp: Add block delimiters for an if-clause

Update of bug #58314 (project groff): Category:Core => Preprocessor preconv Severity: 3 - Normal => 1 - Wish Status: Need Info => Invalid Open/Closed:

  1   2   3   >