[bug #65108] [troff] support construction of general file name request arguments

Update of bug #65108 (group groff): Status:None => Postponed ___ Follow-up Comment #19: Post-1.24. ___ Reply to this item at:

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #18, bug #65108 (group groff): [comment #17 comment #17:] > Which emails notifications I receive seems to be pretty erratic. Savannah seems to be under a lot of churn lately--which is overall a good thing, as useful features are being added. But yeah, I did notice http://savann

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #17, bug #65108 (group groff): [comment #16 comment #16:] > [comment #8 comment #8:] >> A. what to do about `\ ` in GNU _soelim_ and _troff_. > > The soelim part is now covered by bug #66027. ...and the _troff_ part by bug #66434, where the answer is basically "nothing"; I re

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #16, bug #65108 (group groff): [comment #8 comment #8:] > A. what to do about `\ ` in GNU _soelim_ and _troff_. The soelim part is now covered by bug #66027. (This bug was modified to depend on 66027 the same day comment #8 and comment #9 were posted, but if there was an email

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #15, bug #65108 (group groff): [comment #14 comment #14:] > So, ideally, we want GNU _troff_ requests to be able to refer > unambiguously to either one. Yes. And even _more_ ideally, groff would look at its environment and make an educated guess of how to encode any non-ASCII c

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #14, bug #65108 (group groff): [comment #13 comment #13:] > [comment #12 comment #12:] > > I feel like we're saying the same thing, or compatible things. > > Quite possibly. > > > A file named "résumé1.ms" might be stored on the file system > > using either character encoding,

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #13, bug #65108 (group groff): [comment #12 comment #12:] > I feel like we're saying the same thing, or compatible things. Quite possibly. > A file named "résumé1.ms" might be stored on the file system > using either character encoding, ...or, as my example attempted to illust

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #12, bug #65108 (group groff): [comment #11 comment #11:] > [comment #0 original submission:] > > we have no way of knowing what the file system's character encoding is. > > Might be ISO 8859-1, UTF-8, UTF-16BE/LE, or something else entirely. > > I'm not sure now if that's a mea

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #11, bug #65108 (group groff): [comment #0 original submission:] > we have no way of knowing what the file system's character encoding is. > Might be ISO 8859-1, UTF-8, UTF-16BE/LE, or something else entirely. I'm not sure now if that's a meaningful question. The file system se

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #10, bug #65108 (group groff): [comment #8 comment #8:] > [comment #7 comment #7:] > > One additional comment on the proposal: > > > > [comment #3 comment #3:] > > > Only codes in the range 00-1F and 80-FF are accepted in > > > [`\[u00XX]`] syntax; those in the range 20-7F are i

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #9, bug #65108 (group groff): [comment #5 comment #5:] > So I'm not sure whether or not you advocate retaining soelim's current escape mechanism. Maybe you're not yet either. It's a question that tempts me to dither. > My suggestion in comment #2 that support for soelim's es

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #8, bug #65108 (group groff): [comment #7 comment #7:] > One additional comment on the proposal: > > [comment #3 comment #3:] > > Only codes in the range 00-1F and 80-FF are accepted in > > [`\[u00XX]`] syntax; those in the range 20-7F are ignored with a > > diagnostic advising

[bug #65108] [troff] support construction of general file name request arguments

Update of bug #65108 (group groff): Status: Need Info => None Assigned to:barx => None ___ Follow-up Comment #7: One additional comment

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #6, bug #65108 (group groff): [comment #1 comment #1:] > It would seem that AT&T _troff_ users (and _groff_ users to date) > have been pretty conservative about the file names they pass to > these requests. In my experience, users who work a lot at the command line (which I bet

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #5, bug #65108 (group groff): Your plan looks solid! I do have one question about two lines at opposite ends of comment #3 that seem to be in opposition. > let's rough out a syntax that would work both for existing uses > of `so` as _soelim_(1) understands it and for formatter

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #4, bug #65108 (group groff): I forgot case #1 for Solaris 10 _troff soelim_. printf '.so foo bar file.troff\n' | soelim foo: No such file or directory .so foo bar file.troff So just no space-in-file-name support of any kind. Also, I cheated here with an example that I don't

[bug #65108] [troff] support construction of general file name request arguments

Update of bug #65108 (group groff): Status:None => Need Info Assigned to:None => barx ___ Follow-up Comment #3: Well, let's rough out a

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #2, bug #65108 (group groff): [comment #1 comment #1:] > Decide what to do about spaces and tabs. One can argue about tabs > being reasonable in file names, but spaces are a fact of life. > > As it happens, all requests that take _file_ arguments > always do so as the their *la

[bug #65108] [troff] support construction of general file name request arguments

Follow-up Comment #1, bug #65108 (group groff): This would affect the `\O` escape sequence and the `cf`, `fp`, `hpf`, `hpfa`, `mso`, `msoquiet`, `nx`, `open`, `opena`, `psbb`, `so`, `soquiet`, and `trf` requests. Right now at least some of these use the internal function `get_long_name()`, which

[bug #65108] [troff] support construction of general file name request arguments

URL: Summary: [troff] support construction of general file name request arguments Group: GNU roff Submitter: gbranden Submitted: Tue 02 Jan 2024 10:59:42 PM UTC Category: Core