* X font completion is buggy @ 2015-07-24 21:49 Vincent Lefevre 2015-07-24 22:50 ` Oliver Kiddle 2015-07-24 23:07 ` Bart Schaefer 0 siblings, 2 replies; 14+ messages in thread From: Vincent Lefevre @ 2015-07-24 21:49 UTC (permalink / raw) To: zsh-workers 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-24 21:49 X font completion is buggy Vincent Lefevre @ 2015-07-24 22:50 ` Oliver Kiddle 2015-07-24 23:31 ` Bart Schaefer 2015-07-25 1:28 ` Vincent Lefevre 2015-07-24 23:07 ` Bart Schaefer 1 sibling, 2 replies; 14+ messages in thread From: Oliver Kiddle @ 2015-07-24 22:50 UTC (permalink / raw) To: zsh-workers 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 \ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-24 22:50 ` Oliver Kiddle @ 2015-07-24 23:31 ` Bart Schaefer 2015-07-25 8:30 ` Oliver Kiddle 2015-07-25 1:28 ` Vincent Lefevre 1 sibling, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2015-07-24 23:31 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-24 23:31 ` Bart Schaefer @ 2015-07-25 8:30 ` Oliver Kiddle 2015-07-26 21:10 ` Vincent Lefevre 0 siblings, 1 reply; 14+ messages in thread From: Oliver Kiddle @ 2015-07-25 8:30 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-25 8:30 ` Oliver Kiddle @ 2015-07-26 21:10 ` Vincent Lefevre 2015-07-26 21:41 ` Bart Schaefer 0 siblings, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2015-07-26 21:10 UTC (permalink / raw) To: zsh-workers 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-26 21:10 ` Vincent Lefevre @ 2015-07-26 21:41 ` Bart Schaefer 2015-07-26 22:29 ` Mikael Magnusson 2015-07-26 23:01 ` Vincent Lefevre 0 siblings, 2 replies; 14+ messages in thread From: Bart Schaefer @ 2015-07-26 21:41 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-26 21:41 ` Bart Schaefer @ 2015-07-26 22:29 ` Mikael Magnusson 2015-07-26 23:01 ` Vincent Lefevre 1 sibling, 0 replies; 14+ messages in thread From: Mikael Magnusson @ 2015-07-26 22:29 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh workers 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-26 21:41 ` Bart Schaefer 2015-07-26 22:29 ` Mikael Magnusson @ 2015-07-26 23:01 ` Vincent Lefevre 2015-07-27 3:19 ` Bart Schaefer 1 sibling, 1 reply; 14+ messages in thread From: Vincent Lefevre @ 2015-07-26 23:01 UTC (permalink / raw) To: zsh-workers 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-26 23:01 ` Vincent Lefevre @ 2015-07-27 3:19 ` Bart Schaefer 2015-07-27 5:11 ` Mikael Magnusson 0 siblings, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2015-07-27 3:19 UTC (permalink / raw) To: zsh-workers 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-27 3:19 ` Bart Schaefer @ 2015-07-27 5:11 ` Mikael Magnusson 2015-07-27 15:40 ` Bart Schaefer 0 siblings, 1 reply; 14+ messages in thread From: Mikael Magnusson @ 2015-07-27 5:11 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh workers 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-27 5:11 ` Mikael Magnusson @ 2015-07-27 15:40 ` Bart Schaefer 0 siblings, 0 replies; 14+ messages in thread From: Bart Schaefer @ 2015-07-27 15:40 UTC (permalink / raw) To: zsh workers 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-24 22:50 ` Oliver Kiddle 2015-07-24 23:31 ` Bart Schaefer @ 2015-07-25 1:28 ` Vincent Lefevre 1 sibling, 0 replies; 14+ messages in thread From: Vincent Lefevre @ 2015-07-25 1:28 UTC (permalink / raw) To: zsh-workers 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-24 21:49 X font completion is buggy Vincent Lefevre 2015-07-24 22:50 ` Oliver Kiddle @ 2015-07-24 23:07 ` Bart Schaefer 2015-07-25 0:47 ` Vincent Lefevre 1 sibling, 1 reply; 14+ messages in thread From: Bart Schaefer @ 2015-07-24 23:07 UTC (permalink / raw) To: zsh-workers 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 \ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: X font completion is buggy 2015-07-24 23:07 ` Bart Schaefer @ 2015-07-25 0:47 ` Vincent Lefevre 0 siblings, 0 replies; 14+ messages in thread From: Vincent Lefevre @ 2015-07-25 0:47 UTC (permalink / raw) To: zsh-workers 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) ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-07-27 15:40 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-07-24 21:49 X font completion is buggy Vincent Lefevre 2015-07-24 22:50 ` Oliver Kiddle 2015-07-24 23:31 ` Bart Schaefer 2015-07-25 8:30 ` Oliver Kiddle 2015-07-26 21:10 ` Vincent Lefevre 2015-07-26 21:41 ` Bart Schaefer 2015-07-26 22:29 ` Mikael Magnusson 2015-07-26 23:01 ` Vincent Lefevre 2015-07-27 3:19 ` Bart Schaefer 2015-07-27 5:11 ` Mikael Magnusson 2015-07-27 15:40 ` Bart Schaefer 2015-07-25 1:28 ` Vincent Lefevre 2015-07-24 23:07 ` Bart Schaefer 2015-07-25 0:47 ` Vincent Lefevre
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).