bug#31544: Emacs 26.1 rc-1 Texinfo View fails to italicize all 6 lines in paragraph

bug#31544: Emacs 26.1 rc-1 Texinfo View fails to italicize all 6 lines in paragraph

[Van L]

Hello.

In the quotation, the second paragraph should italicize all 6 lines.

That is, the paragraph: ``When I get to the end of a paragraph,…''

The Texinfo View on file emacs-lisp-intro.texi italicizes 2 of 6 lines.

  #+NAME: emacs-lisp-intro.texi
  #+BEGIN_SRC texi -n 827

    An expert programmer who reviewed this text said to me:

    @quotation
    @i{I prefer to learn from reference manuals.  I ``dive into'' each
    paragraph, and ``come up for air'' between paragraphs.}

    @i{When I get to the end of a paragraph, I assume that subject is
    done, finished, that I know everything I need (with the
    possible exception of the case when the next paragraph starts talking
    about it in more detail).  I expect that a well written reference manual
    will not have a lot of redundancy, and that it will have excellent
    pointers to the (one) place where the information I want is.}
    @end quotation

    This introduction is not written for this person!

  #+END_SRC

bug#31544: Emacs 26.1 rc-1 Texinfo View fails to italicize all 6 lines in paragraph

[Eli Zaretskii]

> From: Van L <van@scratch.space>
> Date: Mon, 21 May 2018 21:18:57 +1000
> 
> In the quotation, the second paragraph should italicize all 6 lines.

And it is all in italics in this version:

  https://www.gnu.org/software/emacs/manual/pdf/eintr.pdf

Or maybe I misunderstand your report?

> That is, the paragraph: ``When I get to the end of a paragraph,…''

Not sure I understand this part.

> The Texinfo View on file emacs-lisp-intro.texi italicizes 2 of 6 lines.

What is "Texinfo View"?  If I visit the Texinfo source in Emacs, I
also see the entire quotation italicized.  If that's what you meant by
"Texinfo View", then maybe you are using a version of Emacs other than
26.1-RC1?

Thanks.

bug#31544: Emacs 26.1 rc-1 Texinfo View fails to italicize all 6 lines in paragraph

[Van L]

> Eli Zaretskii writes:
> 
> Or maybe I misunderstand your report?
> 
>> That is, the paragraph: ``When I get to the end of a paragraph,…''
> 
> Not sure I understand this part.
> 
>> The Texinfo View on file emacs-lisp-intro.texi italicizes 2 of 6 lines.
> 
> What is "Texinfo View"?  If I visit the Texinfo source in Emacs, I
> also see the entire quotation italicized.  If that's what you meant by
> "Texinfo View", then maybe you are using a version of Emacs other than
> 26.1-RC1?

The line in `list-buffers’ refers to the file, as follows:

: %  emacs-lisp-intro....  765330 Texinfo          /Volumes/2018-s/Sources/GNU/emacs/doc/lispintro/emacs-lisp-intro.texi

if I close the file then see the [(Dired by name)] view of lispintro directory and press `v’ for view over the file `emacs-lisp-intro.texi’ it has [(Texinfo View)] and I use `s-l’ for goto-line 823 and this time only 1 of 6 lines is italicized.

Note, however, if I search down for the leading line to the paragraph instead of goto-line then the whole paragraph is italicized as expected.

See: 

http://emacs.scratch.space/public/.splash-plus-elisp-intro-texi_m.jpg

Screenshot confirms Emacs 26.1 version and inadequate italicization.

bug#31544: Emacs 26.1 rc-1 Texinfo View fails to italicize all 6 lines in paragraph

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

      > @i{When I get to the end of a paragraph, I assume that subject is
      > done, finished, that I know everything I need (with the
      > possible exception of the case when the next paragraph starts talking
      > about it in more detail).

I think that is not a bug.
We don't follow a rule to write that way.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#31544: Emacs 26.1 rc-1 Texinfo View fails to italicize all 6 lines in paragraph

[Van L]

> Richard Stallman writes:
> 
>> about it in more detail).
> 
> I think that is not a bug.
> We don't follow a rule to write that way.

The bug surfaces to occasionally cause the failure to present the content as all italicized within texi file's @i{} block.

bug#31544: Emacs 26.1 rc-1 Texinfo View fails to italicize all 6 lines in paragraph

[Eli Zaretskii]

On May 22, 2018 5:40:18 AM GMT+03:00, Van L <van@scratch.space> wrote:
> 
> > Richard Stallman writes:
> > 
> >> about it in more detail).
> > 
> > I think that is not a bug.
> > We don't follow a rule to write that way.
> 
> The bug surfaces to occasionally cause the failure to present the
> content as all italicized within texi file's @i{} block.

Thanks, this is unrelated to the manual.  It's some subtle problem with
JIT font-lock in that place.

Off Topic (was: bug#31544)

[Van L]

> Eli Zaretskii writes:
> 
> Van L writes:
>> 
>>> Richard Stallman writes:
>>> 
>>>> about it in more detail).
>>> 
>>> I think that is not a bug.
>>> We don't follow a rule to write that way.
>> 
>> The bug surfaces to occasionally cause the failure to present the
>> content as all italicized within texi file's @i{} embrace.
> 
> It's some subtle problem with
> JIT font-lock in that place.

Thanks.

If a voice-recognition module is workable and Emacs has the skill to compose raw regexps from less terse human friendly natural language statements, with marks and point at data, would it be easy to marry the two?

Re: Off Topic (was: bug#31544)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > If a voice-recognition module is workable and Emacs has the skill
  > to compose raw regexps from less terse human friendly natural
  > language statements, with marks and point at data, would it be
  > easy to marry the two?

We don't have adequate free software for voice recognition, as far as
I know, and we should not add Emacs support for any such nonfree
program.

Compiling a clearer syntax into regexps is feasible.
We have such things but we haven't adopted any of them in Emacs itself.
Perhaps they are not really convenient.  It would be good to figure out
why not, and make one that is convenient to use, and then use it.

Perhaps the inconvenience has to do with combining the complex
parts of the regexp with the simple strings to match.  Is that so?


-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Off Topic (was: bug#31544)

[Van L]

> Richard Stallman writes:
> 
> We don't have adequate free software for voice recognition, as far as
> I know, and we should not add Emacs support for any such nonfree
> program.

I get the demand to be free.

> Perhaps the inconvenience has to do with combining the complex
> parts of the regexp with the simple strings to match.  Is that so?

Imagine this. The scene is one of a room full of twenty Agile Programmers (who may not be any good at all). There are two Scrum Masters and the Agile Coach. They are across realtime data tracking 150,000 objects, such as, people.

In a different world. There is free software voice-recognition (after a long slog to transition from nonfree). The secretaries from the 1980s interact with Emacs on data of equal size and complexity (and there are no charlatans at Theranos which is showing signs of success after a long slog :-).

Re: Off Topic (was: bug#31544)

[Noam Postavsky]

On 22 May 2018 at 23:24, Richard Stallman <rms@gnu.org> wrote:

> Compiling a clearer syntax into regexps is feasible.
> We have such things but we haven't adopted any of them in Emacs itself.

Doesn't rx.el qualify?

Re: Off Topic (was: bug#31544)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > We have such things but we haven't adopted any of them in Emacs itself.

  > Doesn't rx.el qualify?

It's an example of what I said.  We have it, but we don't actually use it
much if at all.  This suggests to me that it has drawbacks which prevent
it from being clearly superior.

If someone comes up with a replacement syntax that reduces the drawbacks,
we might start using it all the time.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Off Topic

[Robert Pluim]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > We have such things but we haven't adopted any of them in Emacs itself.
>
>   > Doesn't rx.el qualify?
>
> It's an example of what I said.  We have it, but we don't actually use it
> much if at all.  This suggests to me that it has drawbacks which prevent
> it from being clearly superior.
>

Iʼve never used rx.el because I didnʼt know it existed. Itʼs not
described in the regular expression chapter of the emacs lisp
reference manual, nor in the emacs user manual.

> If someone comes up with a replacement syntax that reduces the drawbacks,
> we might start using it all the time.

Documenting rx.el would be a more productive use of time, I think,
especially since Iʼve now noticed via reading rx.el that we already
have sregex as well. Let's pick one rather than inventing a third
syntax.

Robert

Re: Off Topic

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Noam Postavsky <npostavs@gmail.com>,  van@scratch.space,  eliz@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 24 May 2018 11:03:33 +0200
> 
> Documenting rx.el would be a more productive use of time, I think,
> especially since Iʼve now noticed via reading rx.el that we already
> have sregex as well. Let's pick one rather than inventing a third
> syntax.

I'm all for more documentation, but in this case what would you add to
the doc string that already is very long and very detailed?

Re: Off Topic

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Noam Postavsky <npostavs@gmail.com>,  van@scratch.space,  eliz@gnu.org,  emacs-devel@gnu.org
>> Date: Thu, 24 May 2018 11:03:33 +0200
>> 
>> Documenting rx.el would be a more productive use of time, I think,
>> especially since Iʼve now noticed via reading rx.el that we already
>> have sregex as well. Let's pick one rather than inventing a third
>> syntax.
>
> I'm all for more documentation, but in this case what would you add to
> the doc string that already is very long and very detailed?

I meant documentation of its existence, something like:

diff --git i/doc/emacs/search.texi w/doc/emacs/search.texi
index 263c4c5dcc..fd65cf3b38 100644
--- i/doc/emacs/search.texi
+++ w/doc/emacs/search.texi
@@ -802,7 +802,8 @@ Regexps
   This section (and this manual in general) describes regular
 expression features that users typically use.  @xref{Regular
 Expressions,,, elisp, The Emacs Lisp Reference Manual}, for additional
-features used mainly in Lisp programs.
+features used mainly in Lisp programs.  For an alternative and more
+verbose syntax, see the @code{rx} package.
 
   Regular expressions have a syntax in which a few characters are
 special constructs and the rest are @dfn{ordinary}.  An ordinary

Re: Off Topic

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 24 May 2018 17:41:04 +0200
> 
> > I'm all for more documentation, but in this case what would you add to
> > the doc string that already is very long and very detailed?
> 
> I meant documentation of its existence, something like:

I very much doubt this will increase the package's visibility, but
saying that certainly doesn't hurt.

Thanks.

Re: Off Topic

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > -features used mainly in Lisp programs.
  > +features used mainly in Lisp programs.  For an alternative and more
  > +verbose syntax, see the @code{rx} package.

We really should link somehow to documentation of rx.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Off Topic (was: bug#31544)

[Alan Mackenzie]

Hello, Richard.

On Wed, May 23, 2018 at 22:48:59 -0400, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

>   > > We have such things but we haven't adopted any of them in Emacs itself.

>   > Doesn't rx.el qualify?

> It's an example of what I said.  We have it, but we don't actually use it
> much if at all.  This suggests to me that it has drawbacks which prevent
> it from being clearly superior.

rx.el uses a wordy syntax, somewhat analagously to Cobol 50 years ago.
Its premiss is that it's the terse, dense, austere characters which make
a regexp difficult to write and read.  I would suggest that it's more
the abstract concepts which cause beginners difficulties, rather than
the syntax.  This was true of Cobol 50 years ago, and I think it's
always been the case with regexps.

That said, rx.el is used ~72 times in 19 files.el in Emacs, so somebody
likes it.

> If someone comes up with a replacement syntax that reduces the drawbacks,
> we might start using it all the time.

I don't think this will happen.  At least, I hope not.  ;-)

> -- 
> Dr Richard Stallman
> President, Free Software Foundation (https://gnu.org, https://fsf.org)
> Internet Hall-of-Famer (https://internethalloffame.org)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Off Topic (was: bug#31544)

[Yuri Khan]

On Thu, May 24, 2018 at 11:38 PM Alan Mackenzie <acm@muc.de> wrote:

> rx.el uses a wordy syntax, somewhat analagously to Cobol 50 years ago.
> Its premiss is that it's the terse, dense, austere characters which make
> a regexp difficult to write and read.  I would suggest that it's more
> the abstract concepts which cause beginners difficulties, rather than
> the syntax.  This was true of Cobol 50 years ago, and I think it's
> always been the case with regexps.

> That said, rx.el is used ~72 times in 19 files.el in Emacs, so somebody
> likes it.

I like rx.el.

I like it because any reasonably involved rx.el expression will be written
out on multiple lines, indented, and possibly commented; whereas the
equivalent plain regexp will be jumbled up on one long line, or else broken
up into a concat of several arbitrary parts.

I like rx.el because its expressions can be navigated structurally, using
‘backward-up-list’, ‘forward-sexp’, and the like. The same commands work on
regular regular expressions only if they have not been broken up for
readability.

I also like rx.el because it allows me to see fewer backslashes,
double-backslashes, and quadruple-backslashes.

Re: Off Topic (was: bug#31544)

[Alan Mackenzie]

Hello, Yuri.

On Thu, May 24, 2018 at 23:53:52 +0700, Yuri Khan wrote:
> On Thu, May 24, 2018 at 11:38 PM Alan Mackenzie <acm@muc.de> wrote:

> > rx.el uses a wordy syntax, somewhat analagously to Cobol 50 years ago.
> > Its premiss is that it's the terse, dense, austere characters which make
> > a regexp difficult to write and read.  I would suggest that it's more
> > the abstract concepts which cause beginners difficulties, rather than
> > the syntax.  This was true of Cobol 50 years ago, and I think it's
> > always been the case with regexps.

> > That said, rx.el is used ~72 times in 19 files.el in Emacs, so somebody
> > likes it.

> I like rx.el.

:-)

> I like it because any reasonably involved rx.el expression will be written
> out on multiple lines, indented, and possibly commented; whereas the
> equivalent plain regexp will be jumbled up on one long line, or else broken
> up into a concat of several arbitrary parts.

Yes.  But...  rx.el needs to be _learnt_.  You cannot, at least not yet,
learn rx.el as an alternative to normal string regexp syntax, because
the string syntax is so common that it _must_ be learnt.  So rx.el is an
optional extra.  It seems unlikely that its use could spread beyond
Emacs, so the effort learning rx.el is going to yield special purpose
knowledge only.

> I like rx.el because its expressions can be navigated structurally, using
> ‘backward-up-list’, ‘forward-sexp’, and the like. The same commands work on
> regular regular expressions only if they have not been broken up for
> readability.

What would be useful would be a function to turn normal regexps into
rx.el syntax.

> I also like rx.el because it allows me to see fewer backslashes,
> double-backslashes, and quadruple-backslashes.

It's when you start seeing triple backslashes that you need to start
worrying.  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Off Topic (was: bug#31544)

[Noam Postavsky]

On 24 May 2018 at 15:57, Alan Mackenzie <acm@muc.de> wrote:

> What would be useful would be a function to turn normal regexps into
> rx.el syntax.

https://github.com/joddie/pcre2el has some handy commands for that.

Re: Off Topic

[Stefan Monnier]

> Yes.  But...  rx.el needs to be _learnt_.  You cannot, at least not yet,
> learn rx.el as an alternative to normal string regexp syntax, because
> the string syntax is so common that it _must_ be learnt.  So rx.el is an
> optional extra.  It seems unlikely that its use could spread beyond
> Emacs, so the effort learning rx.el is going to yield special purpose
> knowledge only.

Very good point.
For me the problem is just that rx.el regexps are too verbose.

>> I like rx.el because its expressions can be navigated structurally, using
>> ‘backward-up-list’, ‘forward-sexp’, and the like. The same commands work on
>> regular regular expressions only if they have not been broken up for
>> readability.
> What would be useful would be a function to turn normal regexps into
> rx.el syntax.

http://elpa.gnu.org/packages/lex.html provides the function
`lex-parse-re` for that.


        Stefan

Re: Off Topic (was: bug#31544)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > What would be useful would be a function to turn normal regexps into
  > rx.el syntax.

That is a good idea.

In order to truly serve the purpose, it needs to be code
that we can install in Emacs.

I wonder if we can make it easier to see
the regexp that an rx call stands for.
Could we make font lock show this?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Off Topic (was: bug#31544)

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If people are happy with rx.el, maybe our search has ended.

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Off Topic (was: bug#31544)

[Eli Zaretskii]

> Date: Thu, 24 May 2018 16:35:34 +0000
> Cc: Noam Postavsky <npostavs@gmail.com>, van@scratch.space, eliz@gnu.org,
>   emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> rx.el uses a wordy syntax, somewhat analagously to Cobol 50 years ago.
> Its premiss is that it's the terse, dense, austere characters which make
> a regexp difficult to write and read.  I would suggest that it's more
> the abstract concepts which cause beginners difficulties, rather than
> the syntax.  This was true of Cobol 50 years ago, and I think it's
> always been the case with regexps.

I actually agree with the premise: reading an rx spec of a regexp is
much easier than reading the regexp itself.

> That said, rx.el is used ~72 times in 19 files.el in Emacs, so somebody
> likes it.

I certainly do (but I'm not responsible for those uses).

bug#31544: Emacs 26.1 rc-1 Texinfo View fails to italicize all 6 lines in paragraph

[Noam Postavsky]

retitle 31544 texinfo-mode fails to consistently fontify multiline @i{italic text}
severity 31544 minor
tags 31544 + confirmed
quit

Eli Zaretskii <eliz@gnu.org> writes:

> On May 22, 2018 5:40:18 AM GMT+03:00, Van L <van@scratch.space> wrote:
>> 
>> The bug surfaces to occasionally cause the failure to present the
>> content as all italicized within texi file's @i{} block.
>
> Thanks, this is unrelated to the manual.  It's some subtle problem with
> JIT font-lock in that place.

I think the problem is that texinfo-mode doesn't follow the advice in
`(elisp) Multiline Font Lock'.

bug#31544: texinfo-mode fails to consistently fontify multiline @i{italic text}

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

>> Thanks, this is unrelated to the manual.  It's some subtle problem with
>> JIT font-lock in that place.
>
> I think the problem is that texinfo-mode doesn't follow the advice in
> `(elisp) Multiline Font Lock'.

Hm...  I seem to be unable to reproduce the problem, but perhaps it is
intermittent?  Or has it been fixed in the years since it was reported?
(I don't see anything obvious in the texinfo-mode vc logs...)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no