[bug #65763] strictly compare strings in macro packages

[Dave]

Update of bug #65763 (group groff):

Severity:  3 - Normal => 2 - Minor  


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65763] strictly compare strings in macro packages

[Dave]

Update of bug #65763 (group groff):

Severity:   2 - Minor => 3 - Normal 

___

Follow-up Comment #3:

("cc" bug that affects this ticket (and probably others) reported in
http://savannah.nongnu.org/support/?111079)


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65763] strictly compare strings in macro packages

[Dave]

Update of bug #65763 (group groff):

Severity:  3 - Normal => 2 - Minor  

___

Follow-up Comment #2:

[comment #1 comment #1:]
> I suspect this may be low priority,

I agree.

> perhaps so low that it's not worth doing, because _as deployed_,
> all of _groff_'s full-service macro packages are prepared to
> format documents using the basic Latin character set.

Although documents in languages using Latin alphabets are likely groff's
biggest use, I think it's hard to justify declining to fix (as opposed to
deferring fixing) known bugs when it's used for non-Latin-alphabet languages,
especially as groff moves toward supporting such languages in other ways (the
fixed bug #63076, the pending bug #62830).

> I'm also still a bit undecided whether we should have a
> syntactically sweeter way of doing string comparisons.

Like you, I dislike the idea of adding basic language constructs to do
something the language can already do, and also find the way the language
already does this rather ugly.  So I'm no help in deciding.

> It grabs the symbol '~' for use as an operator in a conditional
> expression

This breaks back compatibility with ~'s current use as a synonym (along with
myriad other characters) for the ' conditional operator.  That doesn't
disqualify it, IMHO, but it is another strike against it.

> I suggest that nothing about it is a priority for 1.24.

I agree with this too.  Lowered the severity to reflect this.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[bug #65763] strictly compare strings in macro packages

[G. Branden Robinson]

Update of bug #65763 (group groff):

 Summary: Do actual string comparisons in macro packages =>
strictly compare strings in macro packages

___

Follow-up Comment #1:

I suspect this may be low priority, perhaps so low that it's not worth doing,
because _as deployed_, all of _groff_'s full-service macro packages are
prepared to format documents using the basic Latin character set.

I'm also still a bit undecided whether we should have a syntactically sweeter
way of doing string comparisons.

Here's a proof of concept I did back when discussing this issue with Deri.

It's pretty simple.  It grabs the symbol '~' for use as an operator in a
conditional expression and then uses the same infrastructure that's already in
place to handle `\?`.


$ git stash show -p 1
diff --git a/src/roff/troff/input.cpp b/src/roff/troff/input.cpp
index 8d828a01e..7288f31c5 100644
--- a/src/roff/troff/input.cpp
+++ b/src/roff/troff/input.cpp
@@ -6002,6 +6002,25 @@ static bool do_if_request()
 }
 result = is_abstract_style(nm);
   }
+  else if (c == '~') {
+tok.next();
+symbol nm1 = get_name(true /* required */);
+symbol nm2 = get_name(true /* required */);
+if ((nm1.is_null() || nm2.is_null())) {
+  skip_branch();
+  return false;
+}
+macro *rm1 = static_cast(request_dictionary.lookup(nm1));
+macro *rm2 = static_cast(request_dictionary.lookup(nm2));
+macro *m1 = rm1->to_macro();
+macro *m2 = rm2->to_macro();
+if ((0 /* nullptr */ == m1) || (0 /* nullptr */ == m2)) {
+  error("cannot perform equality comparison on a request");
+  skip_branch();
+  return false;
+}
+result = (*m1 == *m2);
+  }
   else if (tok.is_space())
 result = false;
   else if (tok.is_usable_as_delimiter()) {


Not sure what the best way forward is.  I suggest that nothing about it is a
priority for 1.24.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/