X font completion is buggy

X font completion is buggy

[Vincent Lefevre]

With zsh 5.0.8 under Debian:

zira:~> xterm -fn fix[TAB]

is completed to:

zira:~> xterm -fn fixed--

which gives an error when I want to open an xterm menu:

Warning: Cannot convert string "fixed--" to type FontStruct

zira:~> xlsfonts | grep '^fix'
fixed
fixed

So, it should have been "fixed".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: X font completion is buggy

[Oliver Kiddle]

Vincent Lefevre wrote:
> 
> zira:~> xterm -fn fixed--

Trying to fix this without understanding what _x_font is doing would lead me
to the following patch. 
But this will still result in stuff like:
Warning: Cannot convert string "-adobe-courier-bold-o-normal--" to type FontStruct

Anyone know what might be special about two dashes or was it just an
attempt to reduce the number of matches?. It is also passing -S ''
to compadd which backs up that theory: it only makes sense with the
incomplete fonts. The line is little changed since it was added in 7480
(Aug 1999).

These days, xft fonts tend to be more useful so you might instead want to try
the -fa option to xterm. e.g: xterm -fa Inconsolata

Oliver

diff --git a/Completion/X/Type/_x_font b/Completion/X/Type/_x_font
index a363b27..368b6a6 100644
--- a/Completion/X/Type/_x_font
+++ b/Completion/X/Type/_x_font
@@ -9,7 +9,7 @@ _tags fonts || return 1
 if (( ! $+_font_cache )); then
   typeset -gU _font_cache
 
- _font_cache=( "${(@)^${(@f)$(_call_program fonts xlsfonts 2> /dev/null)}%%--*}--" )
+ _font_cache=( ${${(f)"$(_call_program fonts xlsfonts)"}/--*/--} )
 fi
 
 _wanted fonts expl font \

Re: X font completion is buggy

[Bart Schaefer]

On Jul 24, 11:49pm, Vincent Lefevre wrote:
}
} zira:~> xterm -fn fix[TAB]
} 
} is completed to:
} 
} zira:~> xterm -fn fixed--
} 
} zira:~> xlsfonts | grep '^fix'
} fixed
} fixed
} 
} So, it should have been "fixed".

Try this patch, although I'm not sure why _font_cache is trimming out
a bunch of size and character set variations in the first place:

diff --git a/Completion/X/Type/_x_font b/Completion/X/Type/_x_font
index a363b27..d4da6c8 100644
--- a/Completion/X/Type/_x_font
+++ b/Completion/X/Type/_x_font
@@ -9,7 +9,7 @@ _tags fonts || return 1
 if (( ! $+_font_cache )); then
   typeset -gU _font_cache
 
- _font_cache=( "${(@)^${(@f)$(_call_program fonts xlsfonts 2> /dev/null)}%%--*}--" )
+ _font_cache=( "${(@)^${(@f)$(_call_program fonts xlsfonts 2> /dev/null)}/%--*/--}" )
 fi
 
 _wanted fonts expl font \

Re: X font completion is buggy

[Bart Schaefer]

On Jul 25, 12:50am, Oliver Kiddle wrote:
}
} Anyone know what might be special about two dashes or was it just an
} attempt to reduce the number of matches?

Normally the typeface modifier e.g. "sans" would appear between those
dashes (the default apparently being "serif").  Following the dashes
are size variations.  It's entirely possible that in 1999 and before,
there were not enough different fonts for that information to make
any difference.

Also this predates menu-selection so insanely long completion listings
were more of a problem.

I think we could safely do away with that filter.

} + _font_cache=( ${${(f)"$(_call_program fonts xlsfonts)"}/--*/--} )

So my nearly-identical patch uses /%--*/-- which anchors --* to the end
of the string, because %%--* works that way.  Maybe that doesn't make
any difference in practice.  If we discard the filter entirely, this
question is rhetorical.

Re: X font completion is buggy

[Vincent Lefevre]

On 2015-07-24 16:07:37 -0700, Bart Schaefer wrote:
> Try this patch, although I'm not sure why _font_cache is trimming out
> a bunch of size and character set variations in the first place:
> 
> diff --git a/Completion/X/Type/_x_font b/Completion/X/Type/_x_font
> index a363b27..d4da6c8 100644
> --- a/Completion/X/Type/_x_font
> +++ b/Completion/X/Type/_x_font
> @@ -9,7 +9,7 @@ _tags fonts || return 1
>  if (( ! $+_font_cache )); then
>    typeset -gU _font_cache
>  
> - _font_cache=( "${(@)^${(@f)$(_call_program fonts xlsfonts 2> /dev/null)}%%--*}--" )
> + _font_cache=( "${(@)^${(@f)$(_call_program fonts xlsfonts 2> /dev/null)}/%--*/--}" )
>  fi
>  
>  _wanted fonts expl font \

This doesn't work: with another font, I end up with:

zira:~> xterm -fn -adobe-helvetica-bold-r-normal--

with no longer any completion possibility, while the fonts are:

-adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-1
-adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-15
-adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-2

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: X font completion is buggy

[Vincent Lefevre]

On 2015-07-25 00:50:19 +0200, Oliver Kiddle wrote:
> These days, xft fonts tend to be more useful so you might instead
> want to try the -fa option to xterm. e.g: xterm -fa Inconsolata

The "xterm -fn ..." was just a test of zsh completion and comparison
with xpdf, which also gives me an error, and I wanted to understand
why. I initially got an error for -adobe-helvetica-bold-r-normal--
so that I tried something simpler with "xpdf -fn fix[TAB]" and noticed
the obvious completion bug "fixed--". Then I tried "xpdf -fn fixed",
and got again an error, so that I was wondering whether the -fn xpdf
option was something special. Thus I tried xterm. But I eventually
found that this was a bug in the Debian xpdf wrapper, which I've just
reported:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793552

Now, the -fa option is useless since what I'm trying to do is to
increase the font size of the *UI* (for xterm, these are the menus),
and -fa has no effect on it. If you have a solution better than
"-fn" or "XTerm*font:" (which does not accept Xft fonts either):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793295

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: X font completion is buggy

[Oliver Kiddle]

Bart wrote:
> 
> Also this predates menu-selection so insanely long completion listings
> were more of a problem.
> 
> I think we could safely do away with that filter.

That's perhaps best. Vincent's follow-up indicates that no filtering
would match his expectations.

There's ways this could be improved if old style X fonts were something
worth caring about: separating out aliases, indications of what
component you're on, handling * wildcards.

Oliver

diff --git a/Completion/X/Type/_x_font b/Completion/X/Type/_x_font
index a363b27..1202d82 100644
--- a/Completion/X/Type/_x_font
+++ b/Completion/X/Type/_x_font
@@ -9,8 +9,8 @@ _tags fonts || return 1
 if (( ! $+_font_cache )); then
   typeset -gU _font_cache
 
- _font_cache=( "${(@)^${(@f)$(_call_program fonts xlsfonts 2> /dev/null)}%%--*}--" )
+ _font_cache=( ${(f)"$(_call_program fonts xlsfonts)"} )
 fi
 
 _wanted fonts expl font \
-    compadd -M 'r:|-=* r:|=*' "$@" -S '' -a - _font_cache
+    compadd -M 'r:|-=* r:|=*' "$@" -a - _font_cache

Re: X font completion is buggy

[Vincent Lefevre]

On 2015-07-25 10:30:31 +0200, Oliver Kiddle wrote:
> diff --git a/Completion/X/Type/_x_font b/Completion/X/Type/_x_font
> index a363b27..1202d82 100644
> --- a/Completion/X/Type/_x_font
> +++ b/Completion/X/Type/_x_font
> @@ -9,8 +9,8 @@ _tags fonts || return 1
>  if (( ! $+_font_cache )); then
>    typeset -gU _font_cache
>  
> - _font_cache=( "${(@)^${(@f)$(_call_program fonts xlsfonts 2> /dev/null)}%%--*}--" )
> + _font_cache=( ${(f)"$(_call_program fonts xlsfonts)"} )
>  fi
>  
>  _wanted fonts expl font \
> -    compadd -M 'r:|-=* r:|=*' "$@" -S '' -a - _font_cache
> +    compadd -M 'r:|-=* r:|=*' "$@" -a - _font_cache

It behaves in a strange way:

$ xterm -fn -ad[TAB]

gives:

$ xterm -fn -adobe-[]

Then h[TAB] gives:

$ xterm -fn -adobe-helvetica-[]--n--0-0-0-0-p-0-iso8859

Another [TAB] gives:

$ xterm -fn -adobe-helvetica-[]--n--0-0-0-0-p-0-iso8859-

Another [TAB] gives the list:

Completing font
-adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-1   
-adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-2   
-adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-15  
-adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-1   
-adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-2   
-adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-15  
-adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-1   
-adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-2   
-adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-15  
-adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-1   
-adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-2   
-adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-15  
-adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-1   
-adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-2   
-adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-15  
-adobe-helvetica-medium-i-normal--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-medium-i-normal--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-medium-i-normal--0-0-0-0-p-0-iso8859-15
-adobe-helvetica-medium-o-narrow--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-medium-o-narrow--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-medium-o-narrow--0-0-0-0-p-0-iso8859-15
-adobe-helvetica-medium-o-normal--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-medium-o-normal--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-medium-o-normal--0-0-0-0-p-0-iso8859-15
-adobe-helvetica-medium-r-narrow--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-medium-r-narrow--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-medium-r-narrow--0-0-0-0-p-0-iso8859-15
-adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-medium-r-normal--0-0-0-0-p-0-iso8859-15

Now, b[TAB] gives:

$ xterm -fn -adobe-helvetica-bold--n--0-0-0-0-p-0-iso8859-[]

but the cursor shouldn't be at the end because after "bold-",
there should be i, o or r. If I type [TAB], I get:

$ xterm -fn -adobe-helvetica-bold--n--0-0-0-0-p-0-iso8859-[]
Completing font
-adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-15
-adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-15
-adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-15
-adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-15
-adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-1 
-adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-2 
-adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-15

I can type "1" and cycle, but I would expect the cursor after "bold-".

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: X font completion is buggy

[Bart Schaefer]

On Jul 26, 11:10pm, Vincent Lefevre wrote:
}
} $ xterm -fn -adobe-helvetica-bold--n--0-0-0-0-p-0-iso8859-[]
} 
} but the cursor shouldn't be at the end because after "bold-",
} there should be i, o or r. If I type [TAB], I get:

If you look at this list, there are three different ways to disambiguate:

} -adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-1 
} -adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-2 
} -adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-15
} -adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-1 
} -adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-2 
} -adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-15
} -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-1 
} -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-2 
} -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-15
} -adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-1 
} -adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-2 
} -adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-15
} -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-1 
} -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-2 
} -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-15

You can add i/o/r after "bold-" to choose to one of the font styles,
or you can type a/o after "n" to choose the width, or you can type
1 or 2 after "59-" to narrow the character sets.

I believe completion always chooses the point of disambiguation with
the longest common prefix (common to the partial completions, not
common to the full list of matches).  If you then type "2" and hit
TAB, that's no longer ambiguous so the cursor moves back to the "n"
because that is still ambiguous, and then if you type "o" and hit
TAB it moves back yet again.

I think you'll find completion always behaves this way, but it's not
usually the case to have this many positions of ambiguity.

Re: X font completion is buggy

[Mikael Magnusson]

On Sun, Jul 26, 2015 at 11:41 PM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Jul 26, 11:10pm, Vincent Lefevre wrote:
> }
> } $ xterm -fn -adobe-helvetica-bold--n--0-0-0-0-p-0-iso8859-[]
> }
> } but the cursor shouldn't be at the end because after "bold-",
> } there should be i, o or r. If I type [TAB], I get:
>
> If you look at this list, there are three different ways to disambiguate:
>
> } -adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-1
> } -adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-2
> } -adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-15
> } -adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-1
> } -adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-2
> } -adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-15
> } -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-1
> } -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-2
> } -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-15
> } -adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-1
> } -adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-2
> } -adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-15
> } -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-1
> } -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-2
> } -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-15
>
> You can add i/o/r after "bold-" to choose to one of the font styles,
> or you can type a/o after "n" to choose the width, or you can type
> 1 or 2 after "59-" to narrow the character sets.
>
> I believe completion always chooses the point of disambiguation with
> the longest common prefix (common to the partial completions, not
> common to the full list of matches).  If you then type "2" and hit
> TAB, that's no longer ambiguous so the cursor moves back to the "n"
> because that is still ambiguous, and then if you type "o" and hit
> TAB it moves back yet again.
>
> I think you'll find completion always behaves this way, but it's not
> usually the case to have this many positions of ambiguity.

The way mine is set up, zsh only ever inserts the unambiguous prefix
on the command line and asks me for the disambiguation at that point,
and never puts the cursor in the middle. I find this to be much less
confusing overall.

-- 
Mikael Magnusson

Re: X font completion is buggy

[Vincent Lefevre]

On 2015-07-26 14:41:46 -0700, Bart Schaefer wrote:
> On Jul 26, 11:10pm, Vincent Lefevre wrote:
> }
> } $ xterm -fn -adobe-helvetica-bold--n--0-0-0-0-p-0-iso8859-[]
> } 
> } but the cursor shouldn't be at the end because after "bold-",
> } there should be i, o or r. If I type [TAB], I get:
> 
> If you look at this list, there are three different ways to disambiguate:
> 
> } -adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-1 
> } -adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-2 
> } -adobe-helvetica-bold-i-normal--0-0-0-0-p-0-iso8859-15
> } -adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-1 
> } -adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-2 
> } -adobe-helvetica-bold-o-narrow--0-0-0-0-p-0-iso8859-15
> } -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-1 
> } -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-2 
> } -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-15
> } -adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-1 
> } -adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-2 
> } -adobe-helvetica-bold-r-narrow--0-0-0-0-p-0-iso8859-15
> } -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-1 
> } -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-2 
> } -adobe-helvetica-bold-r-normal--0-0-0-0-p-0-iso8859-15
> 
> You can add i/o/r after "bold-" to choose to one of the font styles,
> or you can type a/o after "n" to choose the width, or you can type
> 1 or 2 after "59-" to narrow the character sets.
> 
> I believe completion always chooses the point of disambiguation with
> the longest common prefix (common to the partial completions, not
> common to the full list of matches).  If you then type "2" and hit
> TAB, that's no longer ambiguous so the cursor moves back to the "n"
> because that is still ambiguous, and then if you type "o" and hit
> TAB it moves back yet again.

But if I type "1", how can I disambiguate between -1 and -15 so that
the cursor moves back to the "n"?

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: X font completion is buggy

[Bart Schaefer]

On Jul 27,  1:01am, Vincent Lefevre wrote:
}
} But if I type "1", how can I disambiguate between -1 and -15 so that
} the cursor moves back to the "n"?

A reasonable question, but not one that is specific to _x_fonts.

As usual for Sven-era code the abbreviations are impenetrable, so it's
very difficult to find where compstate[unambiguous_cursor] is being
calculated, but it's always set to the position just beyond the largest
value in compstate[unambiguous_positions].

Theoretically someone could puzzle out how to set it based on the
smallest unambiguous position, but I'm just not that interested.

Re: X font completion is buggy

[Mikael Magnusson]

On Mon, Jul 27, 2015 at 5:19 AM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Jul 27,  1:01am, Vincent Lefevre wrote:
> }
> } But if I type "1", how can I disambiguate between -1 and -15 so that
> } the cursor moves back to the "n"?
>
> A reasonable question, but not one that is specific to _x_fonts.
>
> As usual for Sven-era code the abbreviations are impenetrable, so it's
> very difficult to find where compstate[unambiguous_cursor] is being
> calculated, but it's always set to the position just beyond the largest
> value in compstate[unambiguous_positions].
>
> Theoretically someone could puzzle out how to set it based on the
> smallest unambiguous position, but I'm just not that interested.

There is this widget, which might do something useful here?

cycle-completion-positions
After inserting an unambiguous string into the command line, the new
function based completion system may know about multiple places in
this string where characters are missing or differ from at least one
of the possible matches. It will then place the cursor on the posi‐
tion it considers to be the most interesting one, i.e. the one where
one can disambiguate between as many matches as possible with as lit‐
tle typing as possible. This widget allows the cursor to be easily
moved to the other inter‐ esting spots. It can be invoked repeatedly
to cycle between all posi‐ tions reported by the completion system.

-- 
Mikael Magnusson

Re: X font completion is buggy

[Bart Schaefer]

On Jul 27,  7:11am, Mikael Magnusson wrote:
} Subject: Re: X font completion is buggy
}
} On Mon, Jul 27, 2015 at 5:19 AM, Bart Schaefer
} <schaefer@brasslantern.com> wrote:
} > On Jul 27,  1:01am, Vincent Lefevre wrote:
} > }
} > } But if I type "1", how can I disambiguate between -1 and -15 so that
} > } the cursor moves back to the "n"?
} >
} > A reasonable question, but not one that is specific to _x_fonts.
} 
} There is this widget, which might do something useful here?
} 
} cycle-completion-positions
} After inserting an unambiguous string into the command line
} [...] This widget allows the cursor to be easily
} moved to the other inter- esting spots.

Yes, if Vincent were willing to invoke that widget instead of using
TAB repeatedly, it would help.

Unfortuntately there's no way to build that into the completion funcs
themselves, because CURSOR et al. are read-only during completion.