Faces for strong, emph and friends in Info?

Faces for strong, emph and friends in Info?

[T.V Raman]

At present Info renders:
  - @emph{foo} as _foo_
  - @strong{foo} as *foo*

    Would be nice if it could use faces, would save me having to listen
    to "star bold star" -- and would likely look nicer to those looking
    at the screen.

    info.el defines faces for various structural contructs but there
    appears to be no info-strong and info-emph -- is that intentional or
    just a lay-over from the time we didn't have font faces?
-- 

Re: Faces for strong, emph and friends in Info?

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Date: Mon, 08 Apr 2024 07:49:10 -0700
> 
> At present Info renders:
>   - @emph{foo} as _foo_
>   - @strong{foo} as *foo*

That's inaccurate.  It's makeinfo that produces these "renderings",
info.el just shows them as they are in the Info file.

>     Would be nice if it could use faces, would save me having to listen
>     to "star bold star" -- and would likely look nicer to those looking
>     at the screen.
> 
>     info.el defines faces for various structural contructs but there
>     appears to be no info-strong and info-emph -- is that intentional or
>     just a lay-over from the time we didn't have font faces?

I think it's just that no one has written the code to show *foo* and
_foo_ as italics and bold (and hide the _ and * characters).  Of
course, this will cause some lines be shorter or longer than they are
supposed to be, but maybe this is a worthwhile price to pay.

Patches welcome.

Re: Faces for strong, emph and friends in Info?

[Robert Pluim]

>>>>> On Mon, 08 Apr 2024 17:59:20 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> info.el defines faces for various structural contructs but there
    >> appears to be no info-strong and info-emph -- is that intentional or
    >> just a lay-over from the time we didn't have font faces?

    Eli> I think it's just that no one has written the code to show *foo* and
    Eli> _foo_ as italics and bold (and hide the _ and * characters).  Of
    Eli> course, this will cause some lines be shorter or longer than they are
    Eli> supposed to be, but maybe this is a worthwhile price to pay.

    Eli> Patches welcome.

How robust do you want this to be? (I took a quick look at using
font-lock for this, but I donʼt think that supports hiding stuff)

Probably needs (yet another) config variable as well.


diff --git a/lisp/info.el b/lisp/info.el
index 176bc9c0033..14ed026a568 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -4491,6 +4491,16 @@ Info-quoted
   '((t :inherit fixed-pitch-serif))
   "Face used for quoted elements.")
 
+(defface Info-strong
+  '((t :inherit bold))
+  "Face used for *strong* elements."
+  :version "30.1")
+
+(defface Info-emphasis
+  '((t :inherit italic))
+  "Face used for _emphasis_ elements."
+  :version "30.1")
+
 ;; We deliberately fontify only ‘..’ quoting, and not `..', because
 ;; the former can be done much more reliably, i.e. without risking
 ;; false positives.
@@ -5134,6 +5144,20 @@ Info-fontify-node
                 (push (set-marker (make-marker) start)
                       paragraph-markers))))))
 
+      ;; Font-lock *foo* and _foo_ and hide the marker characters.
+      (goto-char (point-min))
+      (while (re-search-forward "\\([*_]\\)\\([^*_\n]+\\)\\([*_]\\)" nil t)
+        (when (string= (match-string 1) (match-string 3))
+          (add-text-properties (match-beginning 1) (match-end 1)
+                               '(invisible t front-sticky nil rear-nonsticky t))
+          (add-text-properties (match-beginning 3) (match-end 3)
+                               '(invisible t front-sticky nil rear-nonsticky t))
+          (put-text-property (match-beginning 2) (match-end 2)
+                             'font-lock-face
+                             (if (string= (match-string 1) "*")
+                                 'Info-strong
+                               'Info-emphasis))))
+
       ;; Refill paragraphs (experimental feature)
       (when (and not-fontified-p
                  Info-refill-paragraphs


Robert
-- 

Re: Faces for strong, emph and friends in Info?

[T.V Raman]

Personally I'd just be happy for faces vs _emph_ and *bold*.

-- 

RE: [External] : Re: Faces for strong, emph and friends in Info?

[Drew Adams]

FWIW, info+.el does this (since 2016).  It
does it only for _..._, not also for *...*.

There are these things:

1. Face `info-emphasis'.

2. Options `Info-fontify-emphasis-flag' and
   `Info-emphasis-regexp'.

3. Commands `Info-toggle-fontify-emphasis'
   and `Info-toggle-fontify-local-emphasis'.
   
   The global one toggles the Boolean option.
   The local one toggles the regexp option
   for the current manual only.

4. Non-option var `Info-fontify-emphasis'.

If the Boolean option is non-nil then _..._ is
highlighted (and the underscores are hidden).

(But if internal var `info-fontify-emphasis'
is nil then there's no such highlighting, and
that Boolean option has no effect.)

The default value of `Info-emphasis-regexp' is
"_\\(\\sw+\\)_".  `C-h v' says this about it:
____

 Regexp to match text enclosed in underscore (`_') characters.
 It must have at least one regexp group.  Regexp group #1 gets
 highlighted with face `info-emphasis'.  The enclosing underscore chars
 are made invisible.

 The default value matches the following (enclosed in underscores):
 word, punctuation, and whitespace characters, plus hyphens, with at
 least one word character.  Hyphen is included explicitly because it
 generally has symbol syntax in Info.

 Some possible values include:

 _\(\sw+\)_		  (single words)

 _\(\sw+\(\s-+\sw+\)*\)_	  (single words, maybe whitespace-separated)

 _\([^_\n]+\)_		  (anything except underscore and newline chars)

 _\([^_]+\)_		  (anything except underscore chars)

 _\(\(\s-\|\sw\|\s.\)+\)_ (word, punctuation, whitespace)

 _\(\(\sw\(\s-\|\sw\|\s.\)*\)\|\(\(\s-\|\sw\|\s.\)\sw*\)\)_

 _\(\(\sw\(\s-\|\sw\|\s.\|\s(\|\s)\)*\)\|
 \(\(\s-\|\sw\|\s.\|\s(\|\s)\)\sw*\)\)_ (but joined, with no newline)
   (like previous, but also open and close delimiters, such as ()[])

 Note that any value can be problematic for some Info text - see
 `Info-fontify-emphasis-flag'.
____

`C-h v Info-fontify-emphasis-flag says this:
____

 Non-nil means `info' fontifies text between underscores (`_').
 The text that is highlighted matches the value of option
 `Info-emphasis-regexp'.

 Note 1:
 This fontification hides the underscores that surround text that is
 emphasized.  Because this fontification is not 100% reliable (see Note
 2), in cases where it is inappropriate or unhelpful you might want to
 see the hidden underscore characters.  You can toggle showing all
 hidden text (not just hidden underscores) using `M-x visible-mode'.
 See (info) `Help-Inv' for more information about this.

 Note 2:
 This fontification can never be 100% reliable.  It aims to be useful
 in most Info texts, but it can occasionally result in fontification
 that you might not expect.  This is not a bug; it is part of the
 design to be able to appropriately fontify a great variety of texts.
 Set this flag to nil if you do not find this fontification useful.
 You can use command `Info-toggle-fontify-emphasis' to toggle the
 option value.

 Note 3:
 If internal variable `info-fontify-emphasis' is `nil' then emphasis is
 never highlighted, and this option has no effect.  This gives you a
 way to turn off all matching of `Info-emphasis-regexp'.
____

`C-h f Info-toggle-fontify-local-emphasis' says this:
____

 Toggle `Info-emphasis-regexp' for the current Info manual.
 With a prefix arg, read a new value for it instead.

 NOTE: The regexp must match the surrounding underscore chars (`_'),
       and it must have at least one regexp group.  Regexp group #1
       gets highlighted with face `info-emphasis'.  The enclosing
       underscore chars are made invisible.

 When reading a new value, You can use `$-' as the regexp, to NOT do
 any such local highlighting, that is, to override any such global
 highlighting.  (`$-' is a regexp that cannot match anything.)
____

There are 19 Info-toggle-fontify* commands and
2 Info-cycle-fontify* commands.  The latter
cycle user options among different values.  E.g., 
`Info-fontify-quotations' cycles among these 3
states: off (nil), multiline (symbol `multiline'),
and same line (other non-nil value).

Command `Info-toggle-fontify-all' turns all of
these options off (sets them to nil), if any of
them is on, and it turns them all on, if any is off:

 Info-fontify-angle-bracketed-flag
 Info-fontify-bookmarked-xrefs-flag (if defined)
 Info-fontify-emphasis-flag
 Info-fontify-glossary-words
 Info-fontify-isolated-quote-flag
 Info-fontify-quotations
 Info-fontify-reference-items-flag
 Info-fontify-visited-nodes
____

This is the code in `Info-fontify-node' that
does the highlighting:
____

;; Fontify EMPHASIS: _..._
;;
;; Do this first because it can remove existing highlighting.
;; Wrap stuff with `ignore-errors' in case the regexp is faulty.
;; This is a special case, because we use text property `invisible',
;; not just font-lock.
(when info-fontify-emphasis
  (goto-char (point-min))
  (when (and font-lock-mode  not-fontified-p)
    (let ((regexp  (Info-emphasis-regexp)))
      (unless (eq info-nomatch regexp)
        (while (ignore-errors (re-search-forward regexp nil t))
          (ignore-errors
            (let ((fn  (if Info-fontify-emphasis-flag
                           #'add-text-properties
                         #'remove-text-properties)))
              (funcall fn (match-beginning 0) (1+ (match-beginning 0))
                       '(invisible t front-sticky nil rear-nonsticky t))
              (funcall fn (1- (match-end 0)) (match-end 0)
                       '(invisible t front-sticky nil rear-nonsticky t))
              (funcall fn (match-beginning 1) (match-end 1)
                       '(font-lock-face info-emphasis)))))))))
____

HTH.  The code is here:

https://www.emacswiki.org/emacs/download/info%2b.el

Re: Faces for strong, emph and friends in Info?

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: "T.V Raman" <raman@google.com>,  emacs-devel@gnu.org
> Date: Mon, 08 Apr 2024 18:57:10 +0200
> 
>     Eli> I think it's just that no one has written the code to show *foo* and
>     Eli> _foo_ as italics and bold (and hide the _ and * characters).  Of
>     Eli> course, this will cause some lines be shorter or longer than they are
>     Eli> supposed to be, but maybe this is a worthwhile price to pay.
> 
>     Eli> Patches welcome.
> 
> How robust do you want this to be?

As robust as possible, of course.

> +(defface Info-strong
> +  '((t :inherit bold))
> +  "Face used for *strong* elements."
> +  :version "30.1")

We need fallback for terminals that don't support bold.  Some
stand-out color, perhaps?

Also, the doc string should mention Info mode.

> +      (while (re-search-forward "\\([*_]\\)\\([^*_\n]+\\)\\([*_]\\)" nil t)

This is too fragile, I think.  It matches stuff like "*Note foo_",
which can happen in cross-references, for example.  Also, what if
@emph or @strong spans a newline?

Thanks.

RE: [External] : Re: Faces for strong, emph and friends in Info?

[Drew Adams]

> > +      (while (re-search-forward "\\([*_]\\)\\([^*_\n]+\\)\\([*_]\\)"
> nil t)
> 
> This is too fragile, I think.  It matches stuff like "*Note foo_",
> which can happen in cross-references, for example.  Also, what if
> @emph or @strong spans a newline?

See my mail about this.
___

I think it's good to let users decide
how tight/loose they want matching to
be - user option(s) for the regexp(s).
___

IMO, _..._ and *...* should be handled
separately.

Definitely don't let _...* and *..._ be
taken as emphasis of any kind.

And maybe you need to decide whether you
intend to allow combining the two: *_..._*
or _*...*_.  (Does texinfo allow/produce
such combinations?)

Re: Faces for strong, emph and friends in Info?

[T.V Raman]

Applied your patch, works like a charm!

Wish I had asked for this  a long time ago -- it's a huge time-saver
when using speech output.


Robert Pluim writes:
 > >>>>> On Mon, 08 Apr 2024 17:59:20 +0300, Eli Zaretskii <eliz@gnu.org> said:
 >     >> info.el defines faces for various structural contructs but there
 >     >> appears to be no info-strong and info-emph -- is that intentional or
 >     >> just a lay-over from the time we didn't have font faces?
 > 
 >     Eli> I think it's just that no one has written the code to show *foo* and
 >     Eli> _foo_ as italics and bold (and hide the _ and * characters).  Of
 >     Eli> course, this will cause some lines be shorter or longer than they are
 >     Eli> supposed to be, but maybe this is a worthwhile price to pay.
 > 
 >     Eli> Patches welcome.
 > 
 > How robust do you want this to be? (I took a quick look at using
 > font-lock for this, but I donʼt think that supports hiding stuff)
 > 
 > Probably needs (yet another) config variable as well.
 > 
 > 
 > diff --git a/lisp/info.el b/lisp/info.el
 > index 176bc9c0033..14ed026a568 100644
 > --- a/lisp/info.el
 > +++ b/lisp/info.el
 > @@ -4491,6 +4491,16 @@ Info-quoted
 >    '((t :inherit fixed-pitch-serif))
 >    "Face used for quoted elements.")
 >  
 > +(defface Info-strong
 > +  '((t :inherit bold))
 > +  "Face used for *strong* elements."
 > +  :version "30.1")
 > +
 > +(defface Info-emphasis
 > +  '((t :inherit italic))
 > +  "Face used for _emphasis_ elements."
 > +  :version "30.1")
 > +
 >  ;; We deliberately fontify only ‘..’ quoting, and not `..', because
 >  ;; the former can be done much more reliably, i.e. without risking
 >  ;; false positives.
 > @@ -5134,6 +5144,20 @@ Info-fontify-node
 >                  (push (set-marker (make-marker) start)
 >                        paragraph-markers))))))
 >  
 > +      ;; Font-lock *foo* and _foo_ and hide the marker characters.
 > +      (goto-char (point-min))
 > +      (while (re-search-forward "\\([*_]\\)\\([^*_\n]+\\)\\([*_]\\)" nil t)
 > +        (when (string= (match-string 1) (match-string 3))
 > +          (add-text-properties (match-beginning 1) (match-end 1)
 > +                               '(invisible t front-sticky nil rear-nonsticky t))
 > +          (add-text-properties (match-beginning 3) (match-end 3)
 > +                               '(invisible t front-sticky nil rear-nonsticky t))
 > +          (put-text-property (match-beginning 2) (match-end 2)
 > +                             'font-lock-face
 > +                             (if (string= (match-string 1) "*")
 > +                                 'Info-strong
 > +                               'Info-emphasis))))
 > +
 >        ;; Refill paragraphs (experimental feature)
 >        (when (and not-fontified-p
 >                   Info-refill-paragraphs
 > 
 > 
 > Robert
 > -- 

-- 

--

Re: Faces for strong, emph and friends in Info?

[T.V Raman]

After  applying the patch, @strong is turning bold, but @emph is still
showing up with '_'.

As an example in node on dabbrevs:
File: emacs.info,  Node: Dabbrev Customization,  Prev: Dynamic Abbrevs,  Up: Abbrevs



<cite>
   Normally, dynamic abbrev expansion preserves the case pattern _of the

</cite>

Robert Pluim writes:
 > >>>>> On Mon, 08 Apr 2024 17:59:20 +0300, Eli Zaretskii <eliz@gnu.org> said:
 >     >> info.el defines faces for various structural contructs but there
 >     >> appears to be no info-strong and info-emph -- is that intentional or
 >     >> just a lay-over from the time we didn't have font faces?
 > 
 >     Eli> I think it's just that no one has written the code to show *foo* and
 >     Eli> _foo_ as italics and bold (and hide the _ and * characters).  Of
 >     Eli> course, this will cause some lines be shorter or longer than they are
 >     Eli> supposed to be, but maybe this is a worthwhile price to pay.
 > 
 >     Eli> Patches welcome.
 > 
 > How robust do you want this to be? (I took a quick look at using
 > font-lock for this, but I donʼt think that supports hiding stuff)
 > 
 > Probably needs (yet another) config variable as well.
 > 
 > 
 > diff --git a/lisp/info.el b/lisp/info.el
 > index 176bc9c0033..14ed026a568 100644
 > --- a/lisp/info.el
 > +++ b/lisp/info.el
 > @@ -4491,6 +4491,16 @@ Info-quoted
 >    '((t :inherit fixed-pitch-serif))
 >    "Face used for quoted elements.")
 >  
 > +(defface Info-strong
 > +  '((t :inherit bold))
 > +  "Face used for *strong* elements."
 > +  :version "30.1")
 > +
 > +(defface Info-emphasis
 > +  '((t :inherit italic))
 > +  "Face used for _emphasis_ elements."
 > +  :version "30.1")
 > +
 >  ;; We deliberately fontify only ‘..’ quoting, and not `..', because
 >  ;; the former can be done much more reliably, i.e. without risking
 >  ;; false positives.
 > @@ -5134,6 +5144,20 @@ Info-fontify-node
 >                  (push (set-marker (make-marker) start)
 >                        paragraph-markers))))))
 >  
 > +      ;; Font-lock *foo* and _foo_ and hide the marker characters.
 > +      (goto-char (point-min))
 > +      (while (re-search-forward "\\([*_]\\)\\([^*_\n]+\\)\\([*_]\\)" nil t)
 > +        (when (string= (match-string 1) (match-string 3))
 > +          (add-text-properties (match-beginning 1) (match-end 1)
 > +                               '(invisible t front-sticky nil rear-nonsticky t))
 > +          (add-text-properties (match-beginning 3) (match-end 3)
 > +                               '(invisible t front-sticky nil rear-nonsticky t))
 > +          (put-text-property (match-beginning 2) (match-end 2)
 > +                             'font-lock-face
 > +                             (if (string= (match-string 1) "*")
 > +                                 'Info-strong
 > +                               'Info-emphasis))))
 > +
 >        ;; Refill paragraphs (experimental feature)
 >        (when (and not-fontified-p
 >                   Info-refill-paragraphs
 > 
 > 
 > Robert
 > -- 

-- 

--

Re: Faces for strong, emph and friends in Info?

[T.V Raman]

I took a more careful look, and @emph is failing if:

1. The argument to @emph{} contains spaces,
2. E.G.: @emph{this is a test}
3. Which turns into this_is_a_test
4. And then fails to pass the regex test.

   Independent of fontification, the spaces in an italicized phrase
   turning into '_' feels like a bug in its own right.

Robert Pluim writes:
 > >>>>> On Mon, 08 Apr 2024 17:59:20 +0300, Eli Zaretskii <eliz@gnu.org> said:
 >     >> info.el defines faces for various structural contructs but there
 >     >> appears to be no info-strong and info-emph -- is that intentional or
 >     >> just a lay-over from the time we didn't have font faces?
 > 
 >     Eli> I think it's just that no one has written the code to show *foo* and
 >     Eli> _foo_ as italics and bold (and hide the _ and * characters).  Of
 >     Eli> course, this will cause some lines be shorter or longer than they are
 >     Eli> supposed to be, but maybe this is a worthwhile price to pay.
 > 
 >     Eli> Patches welcome.
 > 
 > How robust do you want this to be? (I took a quick look at using
 > font-lock for this, but I donʼt think that supports hiding stuff)
 > 
 > Probably needs (yet another) config variable as well.
 > 
 > 
 > diff --git a/lisp/info.el b/lisp/info.el
 > index 176bc9c0033..14ed026a568 100644
 > --- a/lisp/info.el
 > +++ b/lisp/info.el
 > @@ -4491,6 +4491,16 @@ Info-quoted
 >    '((t :inherit fixed-pitch-serif))
 >    "Face used for quoted elements.")
 >  
 > +(defface Info-strong
 > +  '((t :inherit bold))
 > +  "Face used for *strong* elements."
 > +  :version "30.1")
 > +
 > +(defface Info-emphasis
 > +  '((t :inherit italic))
 > +  "Face used for _emphasis_ elements."
 > +  :version "30.1")
 > +
 >  ;; We deliberately fontify only ‘..’ quoting, and not `..', because
 >  ;; the former can be done much more reliably, i.e. without risking
 >  ;; false positives.
 > @@ -5134,6 +5144,20 @@ Info-fontify-node
 >                  (push (set-marker (make-marker) start)
 >                        paragraph-markers))))))
 >  
 > +      ;; Font-lock *foo* and _foo_ and hide the marker characters.
 > +      (goto-char (point-min))
 > +      (while (re-search-forward "\\([*_]\\)\\([^*_\n]+\\)\\([*_]\\)" nil t)
 > +        (when (string= (match-string 1) (match-string 3))
 > +          (add-text-properties (match-beginning 1) (match-end 1)
 > +                               '(invisible t front-sticky nil rear-nonsticky t))
 > +          (add-text-properties (match-beginning 3) (match-end 3)
 > +                               '(invisible t front-sticky nil rear-nonsticky t))
 > +          (put-text-property (match-beginning 2) (match-end 2)
 > +                             'font-lock-face
 > +                             (if (string= (match-string 1) "*")
 > +                                 'Info-strong
 > +                               'Info-emphasis))))
 > +
 >        ;; Refill paragraphs (experimental feature)
 >        (when (and not-fontified-p
 >                   Info-refill-paragraphs
 > 
 > 
 > Robert
 > -- 

-- 

--

RE: [External] : Re: Faces for strong, emph and friends in Info?

[Drew Adams]

> After  applying the patch, @strong is turning bold,
> but @emph is still showing up with '_'.
> As an example in node on dabbrevs:

That contains a newline char.  See what I
wrote in my previous mail.

With info+.el, using the default value of
option `Info-emphasis-regexp' ("_\(\sw+\)_"),
that text is also not highlighted.

But if you change the option value to this
one (mentioned in the doc string) then the
text is highlighted as you'd expect:
"_\(\sw+\(\s-+\sw+\)*\)_".

However, with that regexp you'll encounter
problems with other occurrences of `_'.

There's no single silver bullet for this.
That's why my approach was to try to make
it easy for users to tailor the behavior
to what they want, and to easily change it
any time. 

My suggestion is to try a given regexp value
and then peruse a manual (different manuals
can present different challenges).  (I've
visited zillions of nodes in Emacs and Elisp
manuals, to see the effects.)

Re: [External] : Re: Faces for strong, emph and friends in Info?

[T.V Raman]

Thanks.

All I was trying to say is that in info.el, spaces within emph turning
into '_' is in itself somewhat strange.

-- 

Re: Faces for strong, emph and friends in Info?

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Date: Mon, 8 Apr 2024 18:35:54 -0700
> Cc: eliz@gnu.org,
>     raman@google.com,
>     emacs-devel@gnu.org
> 
> 
> I took a more careful look, and @emph is failing if:
> 
> 1. The argument to @emph{} contains spaces,
> 2. E.G.: @emph{this is a test}
> 3. Which turns into this_is_a_test
> 4. And then fails to pass the regex test.
> 
>    Independent of fontification, the spaces in an italicized phrase
>    turning into '_' feels like a bug in its own right.

I don't see this here.  On my system @emph{foo bar baz} produces
_foo bar baz_, with underscores only at the beginning and the end; the
spaces are left alone.

Which version of Texinfo are you using, and in what manual did you see
spaces converted to underscores?

In any case, if this is what you see in the Info file, it's a Texinfo
problem, not an Emacs problem.

Re: [External] : Re: Faces for strong, emph and friends in Info?

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Cc: "rpluim@gmail.com" <rpluim@gmail.com>,  "eliz@gnu.org" <eliz@gnu.org>,
>   "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Mon, 08 Apr 2024 19:23:54 -0700
> 
> All I was trying to say is that in info.el, spaces within emph turning
> into '_' is in itself somewhat strange.

They aren't, at least not on my system.

Re: Faces for strong, emph and friends in Info?

[Robert Pluim]

>>>>> On Mon, 08 Apr 2024 21:27:43 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: "T.V Raman" <raman@google.com>,  emacs-devel@gnu.org
    >> Date: Mon, 08 Apr 2024 18:57:10 +0200
    >> 
    Eli> I think it's just that no one has written the code to show *foo* and
    Eli> _foo_ as italics and bold (and hide the _ and * characters).  Of
    Eli> course, this will cause some lines be shorter or longer than they are
    Eli> supposed to be, but maybe this is a worthwhile price to pay.
    >> 
    Eli> Patches welcome.
    >> 
    >> How robust do you want this to be?

    Eli> As robust as possible, of course.

    >> +(defface Info-strong
    >> +  '((t :inherit bold))
    >> +  "Face used for *strong* elements."
    >> +  :version "30.1")

    Eli> We need fallback for terminals that don't support bold.  Some
    Eli> stand-out color, perhaps?

I guess. Let me see if I can plagiarize^W seek inspiration from eg
Gnus, that has all sorts of angry fruit salad stuff

    Eli> Also, the doc string should mention Info mode.

    >> +      (while (re-search-forward "\\([*_]\\)\\([^*_\n]+\\)\\([*_]\\)" nil t)

    Eli> This is too fragile, I think.  It matches stuff like "*Note foo_",
    Eli> which can happen in cross-references, for example.  Also, what if
    Eli> @emph or @strong spans a newline?

Yes, would need fixing. I donʼt think emacs regexp search supports
backreferences, so it will be less elegant.

Regarding newlines, do you have an example? It could be added, but Iʼm
not sure if we want to pay the price of excessive searching (although
this code is run only once per node).

Robert
-- 

Re: Faces for strong, emph and friends in Info?

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: raman@google.com,  emacs-devel@gnu.org
> Date: Tue, 09 Apr 2024 11:01:49 +0200
> 
> Regarding newlines, do you have an example? It could be added, but Iʼm
> not sure if we want to pay the price of excessive searching (although
> this code is run only once per node).

Here's the first hit I found:

  ‘woman-use-topic-at-point’
       A boolean value that defaults to ‘nil’.  If non-‘nil’ then the
       ‘woman’ command uses the word at point as the topic, _without
       interactive confirmation_, if it exists as a topic.

We never wrap @emph and @strong in @w, so it's small wonder this
happens quite a lot.

Re: Faces for strong, emph and friends in Info?

[T.V Raman]

I mispoke badly -- I was trying to say that it should become
_foo_ _bar_ _baz_ --- otherwise when the above line-wraps, even
visually the effect of @emph gets lost.

Eli Zaretskii writes:
 > > From: "T.V Raman" <raman@google.com>
 > > Date: Mon, 8 Apr 2024 18:35:54 -0700
 > > Cc: eliz@gnu.org,
 > >     raman@google.com,
 > >     emacs-devel@gnu.org
 > > 
 > > 
 > > I took a more careful look, and @emph is failing if:
 > > 
 > > 1. The argument to @emph{} contains spaces,
 > > 2. E.G.: @emph{this is a test}
 > > 3. Which turns into this_is_a_test
 > > 4. And then fails to pass the regex test.
 > > 
 > >    Independent of fontification, the spaces in an italicized phrase
 > >    turning into '_' feels like a bug in its own right.
 > 
 > I don't see this here.  On my system @emph{foo bar baz} produces
 > _foo bar baz_, with underscores only at the beginning and the end; the
 > spaces are left alone.
 > 
 > Which version of Texinfo are you using, and in what manual did you see
 > spaces converted to underscores?
 > 
 > In any case, if this is what you see in the Info file, it's a Texinfo
 > problem, not an Emacs problem.

-- 

Re: Faces for strong, emph and friends in Info?

[Robert Pluim]

>>>>> On Tue, 09 Apr 2024 12:56:43 +0300, Eli Zaretskii <eliz@gnu.org> said:

    Eli> Here's the first hit I found:

    Eli>   ‘woman-use-topic-at-point’
    Eli>        A boolean value that defaults to ‘nil’.  If non-‘nil’ then the
    Eli>        ‘woman’ command uses the word at point as the topic, _without
    Eli>        interactive confirmation_, if it exists as a topic.

    Eli> We never wrap @emph and @strong in @w, so it's small wonder this
    Eli> happens quite a lot.

In the original texi "without interactive confirmation" is all on the
same line, so this one is understandable.

And thereʼs indentation in the resulting info file, which means when
we use '_' to simulate italics, the indentation does not look good. So
hereʼs what needs deciding:

- what do we fontify? There are instances of eg @strong{Warning:}
where I could argue that the ':' should be outside the @strong{}. So
we either match ?: (and ?.) as well, or move those chars outside the
{}

- do we match across newlines? (in fact, in info buffers, we have to
make an effort to not match across newlines, since newline has
whitespace syntax there, so [[:space:]] matches it.

- if we match across newlines, do we go around wraping @w around all
the multiword @emph and @strong? (could we persuade the texinfo
project to do this for us or emit a warning?)

- how configurable does this need to be? Iʼd say a single toggle is
enough, but Drew might disagree. I guess adding a defcustom for the
matching regexp is easy enough as well.

Robert

PS "This looks like a nice simple change, I have a small amount of
time" always seems to turn into something much bigger with Emacs :)
-- 

Re: Faces for strong, emph and friends in Info?

[T.V Raman]

My  suggestion would be to do the 80% case then progressively handle
the corner cases; 
-- 

Re: Faces for strong, emph and friends in Info?

[Robert Pluim]

>>>>> On Wed, 10 Apr 2024 09:17:31 -0700, "T.V Raman" <raman@google.com> said:

    TVR> My  suggestion would be to do the 80% case then progressively handle
    TVR> the corner cases; 

Yes, but my engineering nature demands perfection :-)

'*' and '_', on the same line, with multiple words in between, is
probably close to 80%

Robert
-- 

Re: Faces for strong, emph and friends in Info?

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: raman@google.com,  emacs-devel@gnu.org
> Date: Wed, 10 Apr 2024 18:11:25 +0200
> 
> >>>>> On Tue, 09 Apr 2024 12:56:43 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     Eli> Here's the first hit I found:
> 
>     Eli>   ‘woman-use-topic-at-point’
>     Eli>        A boolean value that defaults to ‘nil’.  If non-‘nil’ then the
>     Eli>        ‘woman’ command uses the word at point as the topic, _without
>     Eli>        interactive confirmation_, if it exists as a topic.
> 
>     Eli> We never wrap @emph and @strong in @w, so it's small wonder this
>     Eli> happens quite a lot.
> 
> In the original texi "without interactive confirmation" is all on the
> same line, so this one is understandable.

This can happen in Texinfo anywhere, and there's nothing we can do to
avoid this, in general.

> And thereʼs indentation in the resulting info file, which means when
> we use '_' to simulate italics, the indentation does not look good. So
> hereʼs what needs deciding:

Forgive me, but I think you are trying to solve too many loosely
related problems at once, so you take a simple problem and conclude
that it's almost unsolvable.  Let me try to simplify things:

> - what do we fontify? There are instances of eg @strong{Warning:}
> where I could argue that the ':' should be outside the @strong{}. So
> we either match ?: (and ?.) as well, or move those chars outside the
> {}

We match whatever the Texinfo source produced.  In the above case, the
colon will be included, and if the author doesn't like the results,
they need to say @strong{Warning}: instead.  (But since this produces
bold in the printed version, I guess including the colon is actually
perfectly okay.)

> - do we match across newlines?

Yes, we do.

> - if we match across newlines, do we go around wraping @w around all
> the multiword @emph and @strong? (could we persuade the texinfo
> project to do this for us or emit a warning?)

Not a problem for this feature to solve.  If people dislike what it
will produce, they will either turn off this feature (which must be
optional, btw) or go back and wrap in @w what they want.  We do that
already with the likes of @code and @kbd, where it matters, so how are
these markups different?

> - how configurable does this need to be? Iʼd say a single toggle is
> enough, but Drew might disagree. I guess adding a defcustom for the
> matching regexp is easy enough as well.

A single toggle is enough.

Re: Faces for strong, emph and friends in Info?

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: eliz@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 10 Apr 2024 18:27:44 +0200
> 
> >>>>> On Wed, 10 Apr 2024 09:17:31 -0700, "T.V Raman" <raman@google.com> said:
> 
>     TVR> My  suggestion would be to do the 80% case then progressively handle
>     TVR> the corner cases; 
> 
> Yes, but my engineering nature demands perfection :-)

Then I guess we learned two very different flavors of engineering.  To
me, engineering is all about compromises: you do what is necessary,
and leave the rest for Mk.II or for well-paying customer.

Re: Faces for strong, emph and friends in Info?

[Robert Pluim]

>>>>> On Wed, 10 Apr 2024 19:53:22 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: eliz@gnu.org,  emacs-devel@gnu.org
    >> Date: Wed, 10 Apr 2024 18:27:44 +0200
    >> 
    >> >>>>> On Wed, 10 Apr 2024 09:17:31 -0700, "T.V Raman" <raman@google.com> said:
    >> 
    TVR> My  suggestion would be to do the 80% case then progressively handle
    TVR> the corner cases; 
    >> 
    >> Yes, but my engineering nature demands perfection :-)

    Eli> Then I guess we learned two very different flavors of engineering.  To
    Eli> me, engineering is all about compromises: you do what is necessary,
    Eli> and leave the rest for Mk.II or for well-paying customer.

Note to self: written communication is very bad at transmitting humour

Robert
-- 

Re: Faces for strong, emph and friends in Info?

[T.V Raman]

Robert Pluim <rpluim@gmail.com> writes:

Agreed re humor and email; have fallen into that hole often, so I
feel your pain

>>>>>> On Wed, 10 Apr 2024 19:53:22 +0300, Eli Zaretskii <eliz@gnu.org> said:
>
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Cc: eliz@gnu.org,  emacs-devel@gnu.org
>     >> Date: Wed, 10 Apr 2024 18:27:44 +0200
>     >> 
>     >> >>>>> On Wed, 10 Apr 2024 09:17:31 -0700, "T.V Raman" <raman@google.com> said:
>     >> 
>     TVR> My  suggestion would be to do the 80% case then progressively handle
>     TVR> the corner cases; 
>     >> 
>     >> Yes, but my engineering nature demands perfection :-)
>
>     Eli> Then I guess we learned two very different flavors of engineering.  To
>     Eli> me, engineering is all about compromises: you do what is necessary,
>     Eli> and leave the rest for Mk.II or for well-paying customer.
>
> Note to self: written communication is very bad at transmitting humour
>
> Robert

--