Loading ...
Sorry, an error occurred while loading the content.

Re: vim56-33: GUI multibyte patch (doc patch)

Expand Messages
  • K.Nagano
    On Thu, Apr 06, 2000 at 09:42, (Bram) wrote in SUBJ: vim56-33: GUI multibyte patch (doc patch) ... On technically, it is not so problem. I
    Message 1 of 3 , Apr 6, 2000
    • 0 Attachment
      On Thu, Apr 06, 2000 at 09:42, <Bram@...>(Bram) wrote
      in SUBJ:"vim56-33: GUI multibyte patch (doc patch)"

      >
      > Katsuhito Nagano wrote:
      >
      > > IMO, if you think we should make vim more user friendly, we should delete
      > > guifontset option, and integrate it to guifont....
      > >
      > > Can we do this ?
      >
      > If it's possible to do this with one option instead of two, that looks like a
      > good solution. Would be easier for the user, right? But perhaps there is a
      > reason why it is not possible? Is there a situation where both 'guifont' and
      > 'guifontset' are required?

      On technically, it is not so problem. I have seen many i18n/l10n patches in
      other program do like this.

      However since, at now, vim supports many platform and environment, I'm afraid
      that deleting option affects to code for them.(in addition, the changes may
      have to do at once.)
      At least, I can not do that for all platform/environment.
      This is only problem of coding power.

      regards,
      ------------------------------------------------------------------------------
      ADVANTEST CORPORATION OFFICE: nagano@...
      Katsuhito Nagano PRIVATE: GCD02476@...
      ------------------------------------------------------------------------------
    • Bram Moolenaar
      ... Well, we could keep both guifont and guifontset , and make them point to the same variable. Sort of an alias. Thus the option that was set last will
      Message 2 of 3 , Apr 6, 2000
      • 0 Attachment
        Katsuhito Nagano wrote:

        > > > IMO, if you think we should make vim more user friendly, we should
        > > > delete guifontset option, and integrate it to guifont....
        > > >
        > > > Can we do this ?
        > >
        > > If it's possible to do this with one option instead of two, that looks
        > > like a good solution. Would be easier for the user, right? But perhaps
        > > there is a reason why it is not possible? Is there a situation where both
        > > 'guifont' and 'guifontset' are required?
        >
        > On technically, it is not so problem. I have seen many i18n/l10n patches in
        > other program do like this.
        >
        > However since, at now, vim supports many platform and environment, I'm afraid
        > that deleting option affects to code for them.(in addition, the changes may
        > have to do at once.)
        > At least, I can not do that for all platform/environment.
        > This is only problem of coding power.

        Well, we could keep both 'guifont' and 'guifontset', and make them point to
        the same variable. Sort of an alias. Thus the option that was set last will
        be used. I tried quickly going through the code to see if this doesn't
        conflict with how it works now, but it's too complicated to tell if this
        doesn't cause any backwards compatibility problems.

        Is it true that when 'guifontset' is set, 'guifont' isn't used? Then it
        should be possible to make 'guifontset' an alias for 'guifont, and use a
        detection mechanism (checking for a comma) to see if it's a fontset.

        --
        BLACK KNIGHT: The Black Knight always triumphs. Have at you!
        ARTHUR takes his last leg off. The BLACK KNIGHT's body lands upright.
        BLACK KNIGHT: All right, we'll call it a draw.
        "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

        /-/-- Bram Moolenaar --- Bram@... --- http://www.moolenaar.net --\-\
        \-\-- Vim: http://www.vim.org ---- ICCF Holland: http://www.vim.org/iccf --/-/
      Your message has been successfully submitted and would be delivered to recipients shortly.