--without-xim is ignored.

--without-xim is ignored.

[Kenichi Handa]

It seems that the configure option --without-xim is ignored
in the latest HEAD.  Is it intentional?
  % configure --help
still tells that this option has an effect.

---
Ken'ichi HANDA
handa@m17n.org

Re: --without-xim is ignored.

[Dave Love]

Kenichi Handa <handa@m17n.org> writes:

> It seems that the configure option --without-xim is ignored
> in the latest HEAD.  Is it intentional?

I guess not, now that it's a runtime option.  What was the intention
of that configure option?  If it's still required, perhaps it should
just disable HAVE_X_I18N?  Does that macro indicate anything else
useful?

Re: --without-xim is ignored.

[Kenichi Handa]

In article <rzqr857tgx3.fsf@albion.dl.ac.uk>, Dave Love <d.love@dl.ac.uk> writes:
> Kenichi Handa <handa@m17n.org> writes:
>>  It seems that the configure option --without-xim is ignored
>>  in the latest HEAD.  Is it intentional?

> I guess not, now that it's a runtime option.  What was the intention
> of that configure option?  

I don't know.  But I got a bug report from a person who
always built Emacs with that option.  He doensn't want XIM
on Emacs because C-\ is eaten by XIM in his environment.

As this option has been there from 21.1, it should not be
ignored.

> If it's still required, perhaps it should just disable
> HAVE_X_I18N?  Does that macro indicate anything else
> useful?

I don't know.

---
Ken'ichi HANDA
handa@m17n.org

Re: --without-xim is ignored.

[Richard Stallman]

    I guess not, now that it's a runtime option.  What was the intention
    of that configure option?

I don't see a need for a build-time option if we have a run-time option.

Re: --without-xim is ignored.

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I guess not, now that it's a runtime option.  What was the intention
>     of that configure option?
> 
> I don't see a need for a build-time option if we have a run-time option.

We explicitly mention it as one of the options to use to improve
response-time when using emacs over slow WAN links, so I would think
that quite a number of people is using it -- so removing it could
probably be confusing.

What about making --without-xim control the default run-time setting
of XIM, i.e. default is on, but --without-xim turns it off?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: --without-xim is ignored.

[Stephen J. Turnbull]

>>>>> "Kim" == Kim F Storm <storm@cua.dk> writes:

    Kim> What about making --without-xim control the default run-time
    Kim> setting of XIM, i.e. default is on, but --without-xim turns
    Kim> it off?

How about making --without-xim control a configure-time error (to be
converted to a warning after a suitable "burn-in" period), which
explains that this feature is now controlled at run-time by a certain
variable, and recommend that site admins consider turning it off in
site-start or default.el?



-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: --without-xim is ignored.

[Richard Stallman]

    What about making --without-xim control the default run-time setting
    of XIM, i.e. default is on, but --without-xim turns it off?

That is ok.

Re: --without-xim is ignored.

[Dave Love]

Kenichi Handa <handa@m17n.org> writes:

> As this option has been there from 21.1, it should not be
> ignored.

I don't really see why it can't be ignored.  Does the NEWS item which
mentions the run-time configuration need improving?

[The sort of problem here may be solvable with xmodmap anyway, without
turning off input methods.  There's a PROBLEMS entry for that sort of
thing on Tru64.]

Re: --without-xim is ignored.

[Dave Love]

Richard Stallman <rms@gnu.org> writes:

>     I guess not, now that it's a runtime option.  What was the intention
>     of that configure option?
>
> I don't see a need for a build-time option if we have a run-time option.

Indeed.  What I meant, was to ask why exactly that option was added
originally, e.g. was it for build errors or crashes under some
circumstance?

Re: --without-xim is ignored.

[Dave Love]

storm@cua.dk (Kim F. Storm) writes:

> We explicitly mention it as one of the options to use to improve
> response-time when using emacs over slow WAN links,

Where?  I thought I removed that.

> What about making --without-xim control the default run-time setting
> of XIM, i.e. default is on, but --without-xim turns it off?

I tend to think that would cause extra confusion.

Re: --without-xim is ignored.

[Kim F. Storm]

Dave Love <d.love@dl.ac.uk> writes:

> storm@cua.dk (Kim F. Storm) writes:
> 
> > We explicitly mention it as one of the options to use to improve
> > response-time when using emacs over slow WAN links,
> 
> Where?  I thought I removed that.

Sorry, I didn't notice that.

In any case, IMHO, fiddling with X resources isn't for the average user.

A compile time option is much easier to describe and understand IMO...

So I would recommend to still mention --without-xim as an alternative
to useXIM in PROBLEMS.

> 
> > What about making --without-xim control the default run-time setting
> > of XIM, i.e. default is on, but --without-xim turns it off?
> 
> I tend to think that would cause extra confusion.

Maybe.  But I just installed changes to do just that (following RMS'
approval).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: --without-xim is ignored.

[Stefan Monnier]

> A compile time option is much easier to describe and understand IMO...

I'd expect that most users don't compile their Emacs.


	Stefan

Re: --without-xim is ignored.

[Richard Stallman]

    In any case, IMHO, fiddling with X resources isn't for the average user.

    A compile time option is much easier to describe and understand IMO...

On the contrary, a compile time option is useless for the ordinary
user, but setting a flag in various ways is easy.  We document
many Lisp variables and env vars in the Emacs manual.

Re: --without-xim is ignored.

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     In any case, IMHO, fiddling with X resources isn't for the average user.
> 
>     A compile time option is much easier to describe and understand IMO...
> 
> On the contrary, a compile time option is useless for the ordinary
> user, but setting a flag in various ways is easy.  We document
> many Lisp variables and env vars in the Emacs manual.

But this is neiher a lisp var or env var...

What other "flags" do we currently have in Emacs which

a) could be controlled via a lisp variable or function, but
b) can only be controlled via X resources, and
c) cannot be turned on again, once it has been turned off.

In my experience, very few users are familiar with X resources.
So at least we should include an example how to do this at the
proper place in PROBLEMS, e.g.

For example, you can use the option ``-xrm "useXIM: false"'' when
you start emacs.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: --without-xim is ignored.

[Richard Stallman]

    What other "flags" do we currently have in Emacs which

    a) could be controlled via a lisp variable or function, but
    b) can only be controlled via X resources, and
    c) cannot be turned on again, once it has been turned off.

We should have a frame parameter to control this.  Then it will
be like other frame parameters, or mostly so.  It won't be exactly
like them, since the first frame on a display will control what
happens on that display.  We will have to document that as a wrinkle.

Re: --without-xim is ignored.

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     What other "flags" do we currently have in Emacs which
> 
>     a) could be controlled via a lisp variable or function, but
>     b) can only be controlled via X resources, and
>     c) cannot be turned on again, once it has been turned off.
> 
> We should have a frame parameter to control this.  Then it will
> be like other frame parameters, or mostly so.  It won't be exactly
> like them, since the first frame on a display will control what
> happens on that display.  We will have to document that as a wrinkle.

I agree, and hope that someone will do this.

Just for the record: If useXIM had already been a user option (that
could be toggled at run-time from inside emacs), I would not have
proposed (and implemented) the new meaning of --without-xim.

I'll remove --without-xim entirely once that is done.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: --without-xim is ignored.

[Dave Love]

storm@cua.dk (Kim F. Storm) writes:

> In any case, IMHO, fiddling with X resources isn't for the average
> user.

Well, that's the way you configure X applications.  The average user
probably doesn't actually have a call for that resource,

> A compile time option is much easier to describe and understand IMO...

Recompilation is definitely not a valid way to configure Emacs.

Re: --without-xim is ignored.

[Dave Love]

storm@cua.dk (Kim F. Storm) writes:

> What other "flags" do we currently have in Emacs which
>
> a) could be controlled via a lisp variable or function, but

It can't be controlled via Lisp if you want it to apply initially,
like for toolbar and menu.

> b) can only be controlled via X resources, and
> c) cannot be turned on again, once it has been turned off.

If you know exactly what makes sense as far as turning it on and off,
you've found better XIM documentation than I have, and I'd be
interested in a pointer.

> In my experience, very few users are familiar with X resources.
> So at least we should include an example how to do this at the
> proper place in PROBLEMS, e.g.
>
> For example, you can use the option ``-xrm "useXIM: false"'' when
> you start emacs.

If the doc on X resources in the manual isn't sufficiently easy to
find or understand, I think that's what needs fixing.

Re: --without-xim is ignored.

[Kevin Rodgers]

Dave Love wrote:

> storm@cua.dk (Kim F. Storm) writes:
>>A compile time option is much easier to describe and understand IMO...
> 
> Recompilation is definitely not a valid way to configure Emacs.

Sure it is.  But it's not a valid way to customize Emacs, which I'm

sure is what you meant.

-- 
Kevin Rodgers