help-texinfo
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loss of search facility in info in newer releases of Texinfo


From: Alan Mackenzie
Subject: Re: Loss of search facility in info in newer releases of Texinfo
Date: Sun, 10 Oct 2021 10:18:39 +0000

Hello, Jacob.

On Sat, Oct 09, 2021 at 21:50:08 -0500, Jacob Bachmeyer wrote:
> Eli Zaretskii wrote:
> >> Date: Sat, 9 Oct 2021 15:43:14 +0000
> >> From: Alan Mackenzie <acm@muc.de>

> >>     C-s ` f o o '

> >> ..

> >> This no longer works for me in current Texinfo because what used to be
> >> ASCII punctuation characters in info, ` and ', have been replaced by
> >> Unicode curly quotes, which don't exist on my keyboard.  Thus I cannot
> >> search for `foo' in any reasonable way in Emacs.

> >> Also, the display of these Unicode punctuation characters is awkward and
> >> ugly on my Linux console.

> >> The Emacs maintainer, Eli Zaretskii, has expressed his opposition to
> >> implementing a workaround inside Emacs.


> > To clarify: I'm opposed to changing the characters present in Info
> > files into some other characters when reading the files into Emacs,
> > because replacing the Unicode characters generated by makeinfo with
> > ASCII will generally interfere with file offsets recorded in the Info
> > tag tables.  I do NOT oppose to changing the visual display of the
> > Unicode characters so as to allow them to be seen on terminals that
> > cannot display the original Unicode characters (similarly to what the
> > stand-alone Info reader does), but Alan isn't satisfied with that.

>  From my viewpoint, it seems that Alan wants some kind of equivalence 
> table, such that ASCII backtick and single quote will match the Unicode 
> curly quotes when typed into an I-search.

No, I really don't want these Unicode punctuation characters in my info
files.  Each time I look at an info file, I experience strong negative
feelings because of them.  The problems with isearch are just one example
of why I don't like them.  Their display on my Linux console is also ugly
and distracting.  For example.

> This might be a generally useful feature, particularly if it is
> implemented as a variable that can be made mode-local or buffer-local,
> with a global default customizable by the user, as it would enable
> searching for characters not actually on the user's keyboard.

Eli has pointed out that we have this feature in Emacs anyway, which I
admit I didn't know about.

Anyway, I started looking at the texi2any source code in Texinfo-6.8 last
night, and found the lines in Plaintext.pm which direct the conversion to
Unicode (most of it, anyway), and commented them out.  This gave me more
or less what I want.

(Part of) the enhancement to Texinfo I'm asking for would look something
like this:


--- tp/Texinfo/Convert/Plaintext.pm.orig        2021-07-03 09:18:25.000000000 
+0000
+++ tp/Texinfo/Convert/Plaintext.pm     2021-10-10 09:26:48.914917160 +0000
@@ -420,12 +420,14 @@
       # if '@documentencoding UTF-8' is not given.
       $self->{'convert_text_options'}->{'no_extra_unicode'} = 1;
     } else {
-      foreach my $quoted_command (@quoted_commands) {
-        # Directed single quotes
-        $self->{'style_map'}->{$quoted_command} = ["\x{2018}", "\x{2019}"];
+      if ($self->get_conf('ENABLE_UTF8_PUNCTUATION')) {
+        foreach my $quoted_command (@quoted_commands) {
+          # Directed single quotes
+          $self->{'style_map'}->{$quoted_command} = ["\x{2018}", "\x{2019}"];
+        }
+        # Directed double quotes
+        $self->{'style_map'}->{'dfn'} = ["\x{201C}", "\x{201D}"];
       }
-      # Directed double quotes
-      $self->{'style_map'}->{'dfn'} = ["\x{201C}", "\x{201D}"];
     }
   }
   if (defined($self->get_conf('OPEN_QUOTE_SYMBOL'))) {

I have not yet figured out how to add a new command line option.  I
envisage the new option being called --enable-utf8-punctuation, with a
default value of ON.

So, my question.  Are the maintainers of Texinfo, in principle, willing
to accept such an enhancement and to include it in future release
versions?

> -- Jacob

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]