`xterm-mouse-mode' has a bogus Custom group

`xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

`xterm-mouse-mode' relies on a bogus default :group, chosen by
define-minor-mode, xterm-mouse, that does not have one of the major
groups as an ancestor (in fact, that does not even have a parent
group).  As a result, users can never find it while browsing Custom
using `customize-browse' or similar.  This is bad, since it is an
option many people who have to often run Emacs in an xterm might want
to set.

I believe that we have to choose a valid group for `xterm-mouse-mode'.
Maybe the most logical is 'mouse, as the patch below implements.

Another frustration I had with `xterm-mouse-mode' was finding
appropriate documentation starting from the Custom buffer.

In the Custom buffer, you get the documentation for the variable,
which simply says to read the docstring of the function instead:

See the command `xterm-mouse-mode' for a description of this minor-mode.

If you click on that link, you do not get the doc for the function
yet, but a buffer telling you once more that `xterm-mouse-mode' is
both a variable and a command and also has a plist.  You have to click
on `Command:".  Then we finally get the function docstring, which
barely says anything of substance either.

Everything but the last fact applies to just about any minor mode
defined by define-minor-mode.  The only thing the patch below does
something about is the last fact: it expands the command docstring.
(Most of the new text is based on the Emacs manual documentation.)

I can install the patch below if desired.

===File ~/xt-mouse-diff=====================================
*** xt-mouse.el	17 Jan 2005 10:30:26 -0600	1.24
--- xt-mouse.el	01 Apr 2005 20:55:39 -0600	
***************
*** 155,162 ****
    "Toggle XTerm mouse mode.
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
! Turn it on to use emacs mouse commands, and off to use xterm mouse commands."
!   nil " Mouse" nil :global t
    (if xterm-mouse-mode
        ;; Turn it on
        (unless window-system
--- 155,167 ----
    "Toggle XTerm mouse mode.
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
! Turn it on to use emacs mouse commands, and off to use xterm mouse commands.
! This works in terminal emulators compatible with xterm.  Only single clicks
! are supported.  When turned on, the normal xterm mouse functionality is still
! available by holding down the SHIFT key while pressing the mouse button.
! The Linux console supports this mode if it has support for the mouse enabled,
! for instance using the gpm daemon."
!   nil " Mouse" nil :global t :group 'mouse
    (if xterm-mouse-mode
        ;; Turn it on
        (unless window-system
============================================================

`xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

 > ! The Linux console supports this mode if it has support for the mouse
 > ! enabled, for instance using the gpm daemon."

Is this true? I couldn't get it to work in a Linux console and I can't see how
it could work outside the context of X (xt-mouse knows nothing about gpm).

The original author (Per Abrahamsen) says:

;; The xterm mouse escape codes are supposedly also supported by the
;; Linux console, but I have not been able to verify this.

However, I have updated t-mouse.el for Emacs 22, which does work in a Linux
console. If anyone is in touch with Ian T Zimmermann and can persuade him to
sign papers, then this file can be included in the Emacs distribution.

Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Nick Roberts wrote:
    
    > ! The Linux console supports this mode if it has support for the mouse
    > ! enabled, for instance using the gpm daemon."

   Is this true? I couldn't get it to work in a Linux console and I
   can't see how it could work outside the context of X (xt-mouse
   knows nothing about gpm).

I should have checked this better.  But I took this from the Emacs
manual docs.  (See `(emacs)XTerm Mouse'.)  I will delete it from the
docstring.  But then it should be deleted from the Emacs manual too.
This is strange.  The person writing it in the Emacs manual must have
had some reason to believe it was true.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

>	The GNU/Linux console currently does not appear to support
>	`xterm-mouse-mode'.

I think this should just say Linux console although I don't really understand
where the kernel ends and the operating system begins.

> The normal `xterm' mouse functionality is still available by holding down
> the `SHIFT' key when you press the mouse button.

This seems to be true for mouse-1 but:

C-mouse-1 gives me the Main Options menu
C-mouse-2 gives me the VT Options menu
C-mouse-3 gives me the VT Fonts menu

S-C-mouse-1, S-C-mouse-2, S-C-mouse-3 give me nothing.


Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Nick Roberts wrote:

   >	The GNU/Linux console currently does not appear to support
   >	`xterm-mouse-mode'.

   I think this should just say Linux console although I don't really
   understand where the kernel ends and the operating system begins.

Neither do I, but Richard asked me to refer to it as "GNU/Linux console".

   > The normal `xterm' mouse functionality is still available by holding down
   > the `SHIFT' key when you press the mouse button.

   This seems to be true for mouse-1 but:

   C-mouse-1 gives me the Main Options menu
   C-mouse-2 gives me the VT Options menu
   C-mouse-3 gives me the VT Fonts menu

   S-C-mouse-1, S-C-mouse-2, S-C-mouse-3 give me nothing.

I believe that the following patches should finally get it right:

===File ~/xt-mouse.el-diff==================================
*** xt-mouse.el	03 Apr 2005 19:34:53 -0500	1.25
--- xt-mouse.el	05 Apr 2005 15:42:18 -0500	
***************
*** 156,164 ****
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
  Turn it on to use Emacs mouse commands, and off to use xterm mouse commands.
! This works in terminal emulators compatible with xterm.  Only single clicks
! are supported.  When turned on, the normal xterm mouse functionality is still
! available by holding down the SHIFT key while pressing the mouse button."
    nil " Mouse" nil :global t :group 'mouse
    (if xterm-mouse-mode
        ;; Turn it on
--- 156,165 ----
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
  Turn it on to use Emacs mouse commands, and off to use xterm mouse commands.
! This works in terminal emulators compatible with xterm.  Only
! non-modified single clicks are supported.  When turned on, the
! normal xterm mouse functionality for such clicks is still available
! by holding down the SHIFT key while pressing the mouse button."
    nil " Mouse" nil :global t :group 'mouse
    (if xterm-mouse-mode
        ;; Turn it on
============================================================

===File ~/man-frames.texi-diff==============================
*** frames.texi	04 Apr 2005 16:06:35 -0500	1.77
--- frames.texi	05 Apr 2005 15:39:00 -0500	
***************
*** 1056,1064 ****
  Some terminal emulators under X support mouse clicks in the terminal
  window.  In a terminal emulator which is compatible with @code{xterm},
  you can use @kbd{M-x xterm-mouse-mode} to enable simple use of the
! mouse---only single clicks are supported.  The normal @code{xterm} mouse
! functionality is still available by holding down the @kbd{SHIFT} key
! when you press the mouse button.
  
  @ignore
     arch-tag: 7dcf3a31-a43b-45d4-a900-445b10d77e49
--- 1056,1064 ----
  Some terminal emulators under X support mouse clicks in the terminal
  window.  In a terminal emulator which is compatible with @code{xterm},
  you can use @kbd{M-x xterm-mouse-mode} to enable simple use of the
! mouse---only non-modified single clicks are supported.  The normal
! @code{xterm} mouse functionality for such clicks is still available by
! holding down the @kbd{SHIFT} key when you press the mouse button.
  
  @ignore
     arch-tag: 7dcf3a31-a43b-45d4-a900-445b10d77e49
============================================================

Re: `xterm-mouse-mode' has a bogus Custom group

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Nick Roberts wrote:
>
>    >	The GNU/Linux console currently does not appear to support
>    >	`xterm-mouse-mode'.
>
>    I think this should just say Linux console although I don't
>    really understand where the kernel ends and the operating system
>    begins.
>
> Neither do I, but Richard asked me to refer to it as "GNU/Linux
> console".

The console clearly is exclusively a feature of the kernel.  We render
ourselves ridiculous if we demand that people call the whole operating
system "GNU/Linux" to distinguish it from the kernel "Linux", then
call the console "GNU/Linux".  The whole point about "GNU/Linux" is to
make the distinction in the first place, to give credit where credit
is due.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

 > ! This works in terminal emulators compatible with xterm.  Only
 > ! non-modified single clicks are supported.  When turned on, the
 > ! normal xterm mouse functionality for such clicks is still available
 > ! by holding down the SHIFT key while pressing the mouse button."

Its a bit more quirky than that, mouse-save-then-kill doesn't kill text if you
click with mouse-3 twice (this is not a double-click). Also xterm mouse
functionality is still available for double/triple mouse clicks by holding
down the SHIFT key while pressing the mouse button. Maybe the previous
documentation was deliberately vague for that reason.

Sorry, I've not been very helpful by offering anything better. Perhaps
xt-mouse could be improved further to accept multi-clicks (I might look at
this one day). Although, perhaps it will also become less important when the
multi-tty branch is merged in, as then presumably remote connections which
don't allow X can be displayed with a local X application (?).


Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    >	The GNU/Linux console currently does not appear to support
    >	`xterm-mouse-mode'.

    I think this should just say Linux console although I don't really understand
    where the kernel ends and the operating system begins.

Neither "Linux console" nor "GNU/Linux console" is incorrect.
We want to make people aware that the system is not Linux,
so we say "GNU/Linux console".

Re: `xterm-mouse-mode' has a bogus Custom group

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     >	The GNU/Linux console currently does not appear to support
>     >	`xterm-mouse-mode'.
>
>     I think this should just say Linux console although I don't
>     really understand where the kernel ends and the operating system
>     begins.
>
> Neither "Linux console" nor "GNU/Linux console" is incorrect.
> We want to make people aware that the system is not Linux,
> so we say "GNU/Linux console".

The console is exclusively Linux and has nothing to do with GNU
whatsoever.  Our main argument for the "GNU/Linux" moniker is the
correct attribution of credit and use of terminology, so it undermines
our case if we muddy the distinction ourselves.

If you want to have the choice of words appear more deliberate, this
can be written as:

"The text consoles of the Linux kernel currently do not support..."

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    The console clearly is exclusively a feature of the kernel.

The console is implemented by the kernel, but you use it to log in to
the whole system.  Thus, both "Linux console" and "GNU/Linux console"
are justifiable.

If we call it the "Linux console", everyone who isn't a wizard will
misunderstand and think it refers to the "Linux operating system".
The only way to avoid promoting this misunderstanding is to call
it the "GNU/Linux console".

Neither name is perfectly right, so my decision is to use the one that
doesn't hurt the GNU project.

Re: `xterm-mouse-mode' has a bogus Custom group

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     The console clearly is exclusively a feature of the kernel.
>
> The console is implemented by the kernel, but you use it to log in
> to the whole system.

There are embedded Linux systems that are most definitely not GNU, and
for example the system at <URL:http://www.skarnet.org/poweredby.html>
runs Linux, but not the GNU system.

> Thus, both "Linux console" and "GNU/Linux console" are justifiable.
>
> If we call it the "Linux console", everyone who isn't a wizard will
> misunderstand and think it refers to the "Linux operating system".
> The only way to avoid promoting this misunderstanding is to call it
> the "GNU/Linux console".

We can't demand correctness from others with regard to GNU/Linux that
we are not willing to provide ourselves.

> Neither name is perfectly right, so my decision is to use the one
> that doesn't hurt the GNU project.

In my opinion that should be the one that does not expose us as
hypocrites: that hurts more than anything else could... I already
proposed a wording that would make clear that we are talking about the
kernel here.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Nick Roberts wrote:

   Its a bit more quirky than that, mouse-save-then-kill doesn't kill
   text if you click with mouse-3 twice (this is not a
   double-click). Also xterm mouse functionality is still available
   for double/triple mouse clicks by holding down the SHIFT key while
   pressing the mouse button. Maybe the previous documentation was
   deliberately vague for that reason.

The situation is obviously so messy that going for 100 percent
accurate documentation seems hopeless.  I include patches below whose
main difference docwise is that they include the word basically to
indicate that no 100 percent accuracy is claimed: "Basically, only
non-modified single clicks are supported."

The new patch for xt-mouse includes a more fundamental non-doc change,
which I could, of course, easily leave out if it would be deemed
undesirable: get rid of the "Mouse" which appears in the mode line if
the mode is activated.

The way I understand it, if you want Emacs to handle simple mouse
clicks while running in an xterm, you can simply enable the mode
unconditionally.  While you are using a window system, the mode does
nothing anyway.  Except for putting the confusing "Mouse" in the mode
line.  Also, this is the kind of thing you either enable permanently
or not at all.  It does not seem to be the kind of stuff that you
dis/enable all the time.  Hence, even while running Emacs in an xterm,
the "Mouse" just seems too waste precious space in the mode line.

===File ~/xt-mouse-diff-b===================================
*** xt-mouse.el	03 Apr 2005 19:34:53 -0500	1.25
--- xt-mouse.el	06 Apr 2005 14:47:20 -0500	
***************
*** 156,165 ****
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
  Turn it on to use Emacs mouse commands, and off to use xterm mouse commands.
! This works in terminal emulators compatible with xterm.  Only single clicks
! are supported.  When turned on, the normal xterm mouse functionality is still
! available by holding down the SHIFT key while pressing the mouse button."
!   nil " Mouse" nil :global t :group 'mouse
    (if xterm-mouse-mode
        ;; Turn it on
        (unless window-system
--- 156,167 ----
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
  Turn it on to use Emacs mouse commands, and off to use xterm mouse commands.
! This works in terminal emulators compatible with xterm.  It only
! works for simple uses of the mouse.  Basically, only non-modified
! single clicks are supported.  When turned on, the normal xterm
! mouse functionality for such clicks is still available by holding
! down the SHIFT key while pressing the mouse button."
!   :global t :group 'mouse
    (if xterm-mouse-mode
        ;; Turn it on
        (unless window-system
============================================================

===File ~/man-frames.texi-diff-b============================
*** frames.texi	04 Apr 2005 16:06:35 -0500	1.77
--- frames.texi	06 Apr 2005 14:33:02 -0500	
***************
*** 1056,1064 ****
  Some terminal emulators under X support mouse clicks in the terminal
  window.  In a terminal emulator which is compatible with @code{xterm},
  you can use @kbd{M-x xterm-mouse-mode} to enable simple use of the
! mouse---only single clicks are supported.  The normal @code{xterm} mouse
! functionality is still available by holding down the @kbd{SHIFT} key
! when you press the mouse button.
  
  @ignore
     arch-tag: 7dcf3a31-a43b-45d4-a900-445b10d77e49
--- 1056,1064 ----
  Some terminal emulators under X support mouse clicks in the terminal
  window.  In a terminal emulator which is compatible with @code{xterm},
  you can use @kbd{M-x xterm-mouse-mode} to enable simple use of the
! mouse---basically, only non-modified single clicks are supported.  The normal
! @code{xterm} mouse functionality for such clicks is still available by
! holding down the @kbd{SHIFT} key when you press the mouse button.
  
  @ignore
     arch-tag: 7dcf3a31-a43b-45d4-a900-445b10d77e49
============================================================

Re: `xterm-mouse-mode' has a bogus Custom group

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     The console clearly is exclusively a feature of the kernel.
>>
>> The console is implemented by the kernel, but you use it to log in
>> to the whole system.
>
> There are embedded Linux systems that are most definitely not GNU, and
> for example the system at <URL:http://www.skarnet.org/poweredby.html>
> runs Linux, but not the GNU system.

Does Emacs run on those systems?

The "Linux kernel console" -- as the user sees it on a GNU/Linux system--
is typically just a process started by the kernel which runs "/bin/sh".

So when the user interacts with the console, he is interacting with
GNU software (e.g. bash), not the kernel.

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

Re: `xterm-mouse-mode' has a bogus Custom group

[Han Boetes]

Kim F. Storm wrote:
> Does Emacs run on those systems?
>
> The "Linux kernel console" -- as the user sees it on a GNU/Linux
> system-- is typically just a process started by the kernel which
> runs "/bin/sh".
>
> So when the user interacts with the console, he is interacting
> with GNU software (e.g. bash), not the kernel.

In that case I am running BSD/Linux, since I removed bash and
replaced it with the much lighter and faster ash. :-)

Here is the buildrecepy for people who are interested how I did
that:

    http://www.xs4all.nl/~hanb/software/crux/han/ash/Pkgfile

I did notice a lot of bashism's in various scripts, though I must
admit that I didn't find many of them in GNU software.

  head /usr/bin/ldd # bug reported.

The beauty of *nix is that all parts are interchangeble and
therefor I want to encourage people to write scripts that work
with a POSIX compliant shell like ash.

Yes bash also is POSIX compliant, but it also supports a lot more,
even in sh-mode. In the long run this works like embrace and
extend.

I can't recommend end-users to replace bash with ash at the moment
since there are simply too many places where bashisms are
used. And that's not how it should be.



# Han

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

 > The "Linux kernel console" -- as the user sees it on a GNU/Linux system--
 > is typically just a process started by the kernel which runs "/bin/sh".
 > 
 > So when the user interacts with the console, he is interacting with
 > GNU software (e.g. bash), not the kernel.

In this context the user is always (indirectly) interacting with the kernel.
The shell needn't be bash though, it might be tcsh. I guess you could login
with no GNU software (init, mingetty, login, tcsh ?) although presumably you
couldn't do much useful. I think calling it the GNU/Linux console could harm
the GNU Project: it could create a backlash from kernel developers who are
currently sympathetic to the use of GNU/Linux to describe the system.

Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>>     The console clearly is exclusively a feature of the kernel.
>>>
>>> The console is implemented by the kernel, but you use it to log in
>>> to the whole system.
>>
>> There are embedded Linux systems that are most definitely not GNU, and
>> for example the system at <URL:http://www.skarnet.org/poweredby.html>
>> runs Linux, but not the GNU system.
>
> Does Emacs run on those systems?

Last time I looked, Emacs was not dependent on glibc and the GNU
utilities.  So there would be no reason for it not to run on such a
system.

> The "Linux kernel console" -- as the user sees it on a GNU/Linux
> system-- is typically just a process started by the kernel which
> runs "/bin/sh".

Nonsense.  The console is the device, like an X terminal is the device
on which an X session runs.

> So when the user interacts with the console, he is interacting with
> GNU software (e.g. bash),

Or zsh, or ash, or ksh and a number of other possibilities that have
nothing to do with GNU.

> not the kernel.

Either we consider the user a babbling idiot that would not be able to
differentiate between GNU and Linux even if he tried, in which case
all the fuss about educating people is at best hypocritical, since we
are then just pleading for our own share of misinformation, or not.

And the whole idea about telling people about GNU/Linux is about
educating, not misleading them in our favorite direction.  We really
undermine our credibility if we do exactly the same kind of
credit-mongering that we accuse others of.  Our case is hard enough to
make without dirty hands.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

 > The situation is obviously so messy that going for 100 percent
 > accurate documentation seems hopeless.  I include patches below whose
 > main difference docwise is that they include the word basically to
 > indicate that no 100 percent accuracy is claimed: "Basically, only
 > non-modified single clicks are supported."

Yes, I think this is enough detail.

 > The new patch for xt-mouse includes a more fundamental non-doc change,
 > which I could, of course, easily leave out if it would be deemed
 > undesirable: get rid of the "Mouse" which appears in the mode line if
 > the mode is activated.
 > 
 > The way I understand it, if you want Emacs to handle simple mouse
 > clicks while running in an xterm, you can simply enable the mode
 > unconditionally.  While you are using a window system, the mode does
 > nothing anyway.  Except for putting the confusing "Mouse" in the mode
 > line.  Also, this is the kind of thing you either enable permanently
 > or not at all.  It does not seem to be the kind of stuff that you
 > dis/enable all the time.  Hence, even while running Emacs in an xterm,
 > the "Mouse" just seems too waste precious space in the mode line.

I only enable xterm-mouse-mode in an xterm:

(if (eq window-system 'nil) 
    (if (string= "xterm" (getenv "TERM"))
        (progn
	  (xterm-mouse-mode 1)
      (load-library "t-mouse")
      (t-mouse-mode 1))
      ...

I've only found it helpful to have "Mouse" in the mode-line so I know it has
actually loaded. If it is removed, might it make sense to conditionally load
xt-mouse in startup.el to ensure its always loaded when needed?

Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Nick Roberts wrote:

   I only enable xterm-mouse-mode in an xterm:

I enabled it through Custom, and I assume that is what most users who
want to set it are going to do.  I do not believe that there is a lot
of harm or inefficiency in that, since `xterm-mouse-mode' does nothing
if window-system is non-nil.  If you enable it through Custom, you get
the "Mouse" in the modeline, even under X.

   I've only found it helpful to have "Mouse" in the mode-line so I know it has
   actually loaded. If it is removed, might it make sense to conditionally load
   xt-mouse in startup.el to ensure its always loaded when needed?

`xterm-mouse-mode' has an autoload cookie.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

 >    I've only found it helpful to have "Mouse" in the mode-line so I know it
 >    has actually loaded. If it is removed, might it make sense to
 >    conditionally load xt-mouse in startup.el to ensure its always loaded
 >    when needed?
 > 
 > `xterm-mouse-mode' has an autoload cookie.

By when needed, I mean "when Emacs is started in an xterm" i.e putting
something like:

(if (string= "xterm" (getenv "TERM")) (xterm-mouse-mode 1))

in startup.el so the user doesn't need to explicitly load it, as with tooltips.


Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

I mean enable not load.

Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    There are embedded Linux systems that are most definitely not GNU, and
    for example the system at <URL:http://www.skarnet.org/poweredby.html>
    runs Linux, but not the GNU system.

Emacs is evidently not included, nor could it run without GNU libc.

    We can't demand correctness from others with regard to GNU/Linux that
    we are not willing to provide ourselves.

I agree, but I've already explained why this is correct.

    In my opinion that should be the one that does not expose us as
    hypocrites: that hurts more than anything else could... 

My statements on the matter are sincere, not hypocritical.
You have no grounds to accuse me of dishonesty, and I take offense.

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    I think calling it the GNU/Linux console could harm
    the GNU Project: it could create a backlash from kernel developers who are
    currently sympathetic to the use of GNU/Linux to describe the system.

In 20 years I have learned that it is a mistake to worry too much
about the possibility of exaggerated negative reactions.  They happen
once in a while, and I live with them.

Re: `xterm-mouse-mode' has a bogus Custom group

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     There are embedded Linux systems that are most definitely not GNU, and
>     for example the system at <URL:http://www.skarnet.org/poweredby.html>
>     runs Linux, but not the GNU system.
>
> Emacs is evidently not included, nor could it run without GNU libc.
>
>     We can't demand correctness from others with regard to GNU/Linux that
>     we are not willing to provide ourselves.
>
> I agree, but I've already explained why this is correct.
>
>     In my opinion that should be the one that does not expose us as
>     hypocrites: that hurts more than anything else could... 
>
> My statements on the matter are sincere, not hypocritical.

Which is the more reason why we should avoid appearing otherwise.

> You have no grounds to accuse me of dishonesty, and I take offense.

I am describing how this discrepancy in accuracy must appear to
others.  You are blaming the messenger.  If you find that description
offensive, it would be sensible to try avoiding evoking it where
possible, and I already gave a wording that would fit better in that
regard.

If you don't trust my judgment on this, feel free to ask anybody whose
words you would rather rely on.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    I've only found it helpful to have "Mouse" in the mode-line so I know it has
    actually loaded. If it is removed, might it make sense to conditionally load
    xt-mouse in startup.el to ensure its always loaded when needed?

You could load it conditionally (only in an xterm) or unconditionally,
and either way, it would always be loaded when needed.

I see no need for it to put "Mouse" in the mode line,
and I don't see how it benefits you, given the usage you've
described.

    By when needed, I mean "when Emacs is started in an xterm" i.e putting
    something like:

    (if (string= "xterm" (getenv "TERM")) (xterm-mouse-mode 1))

    in startup.el

This would only cause a problem for a user who wants to use the
ordinary xterm mouse commands even when an Emacs is running there.
I doubt many users find that particularly better, and if they don't,
then this change would cause little problem.  And anyone who did
not like it could disable the mode.

So I think it is a good idea.

The natural place to do it is in lisp/term/xterm.el.
Would someone please install (xterm-mouse-mode 1) there?

Re: `xterm-mouse-mode' has a bogus Custom group

[Andreas Schwab]

Nick Roberts <nickrob@snap.net.nz> writes:

> By when needed, I mean "when Emacs is started in an xterm" i.e putting
> something like:
>
> (if (string= "xterm" (getenv "TERM")) (xterm-mouse-mode 1))

This should use string-match since there are many xterm-like terminal
descriptions with different names.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Richard Stallman wrote:

   So I think it is a good idea.

   The natural place to do it is in lisp/term/xterm.el.
   Would someone please install (xterm-mouse-mode 1) there?

It is a little bit more complex than that.  It has to be done in  the
right way for the defcustom.  Just writing (xterm-mouse-mode 1) in
term/xterm.el might cause problems with "Erase Customization" in
Custom buffers, as we discussed before.  I will take a look at it.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

 >    The natural place to do it is in lisp/term/xterm.el.
 >    Would someone please install (xterm-mouse-mode 1) there?
 > 
 > It is a little bit more complex than that.  It has to be done in  the
 > right way for the defcustom.  Just writing (xterm-mouse-mode 1) in
 > term/xterm.el might cause problems with "Erase Customization" in
 > Custom buffers, as we discussed before.  I will take a look at it.

I recently changed tooltip-mode to a minor-mode which previously used a
function and a variable and keywords like:

  :initialize 'custom-initialize-default

Have I created problems for customize here?


Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Nick Roberts wrote:

   I recently changed tooltip-mode to a minor-mode which previously used a
   function and a variable and keywords like:

     :initialize 'custom-initialize-default

   Have I created problems for customize here?

No, I believe the problem was already there before that change.
There are many customizable variables with similar problems.

Do `emacs -q', then `M-x customize-rogue'.

All the variables you see there suffer from the bug that if you
choose "Erase Customization" in Custom, they get reset to a wrong
(sometimes very wrong) default.  I guess we should try to fix as many
of them as possible before the release.

This problem occurs whenever code run at startup changes the value
given in the defcustom.  That should not happen.  The value an option
has by default should be identical to the value one gets by evaluating
the defcustom.

I will fix this for tooltip-mode.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

The following patches enable xterm-mouse-mode by default in xterm type
terminals, document this in the Emacs manual (I would also document it
in the NEWS) and fix the Custom related bug for tooltip-mode.

I can install if desired.

===File ~/man-frames.texi-diff==============================
*** frames.texi	04 Apr 2005 16:06:35 -0500	1.77
--- frames.texi	08 Apr 2005 21:11:43 -0500	
***************
*** 1055,1064 ****
  
  Some terminal emulators under X support mouse clicks in the terminal
  window.  In a terminal emulator which is compatible with @code{xterm},
! you can use @kbd{M-x xterm-mouse-mode} to enable simple use of the
! mouse---only single clicks are supported.  The normal @code{xterm} mouse
! functionality is still available by holding down the @kbd{SHIFT} key
! when you press the mouse button.
  
  @ignore
     arch-tag: 7dcf3a31-a43b-45d4-a900-445b10d77e49
--- 1055,1069 ----
  
  Some terminal emulators under X support mouse clicks in the terminal
  window.  In a terminal emulator which is compatible with @code{xterm},
! simple use of the mouse is, by default, controlled by Emacs---basically,
! only non-modified single clicks are supported.  The normal
! @code{xterm} mouse functionality for such clicks is still available by
! holding down the @kbd{SHIFT} key when you press the mouse button.
! 
! Put @code{(xterm-mouse-mode 0)} in your @file{.emacs}, or disable the
! option @code{xterm-mouse-mode} through the @samp{Customize} interface
! (@pxref{Easy Customization}), if you prefer all mouse clicks to be
! handled by the terminal emulator.
  
  @ignore
     arch-tag: 7dcf3a31-a43b-45d4-a900-445b10d77e49
============================================================

===File ~/xt-mouse.el-diff==================================
*** xt-mouse.el	03 Apr 2005 19:34:53 -0500	1.25
--- xt-mouse.el	08 Apr 2005 22:16:07 -0500	
***************
*** 150,165 ****
        (list mouse
  	    (append (list nil 'menu-bar) (nthcdr 2 (posn-at-x-y x y w t)))))))
  
- ;;;###autoload
  (define-minor-mode xterm-mouse-mode
    "Toggle XTerm mouse mode.
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
  Turn it on to use Emacs mouse commands, and off to use xterm mouse commands.
! This works in terminal emulators compatible with xterm.  Only single clicks
! are supported.  When turned on, the normal xterm mouse functionality is still
! available by holding down the SHIFT key while pressing the mouse button."
!   nil " Mouse" nil :global t :group 'mouse
    (if xterm-mouse-mode
        ;; Turn it on
        (unless window-system
--- 150,169 ----
        (list mouse
  	    (append (list nil 'menu-bar) (nthcdr 2 (posn-at-x-y x y w t)))))))
  
  (define-minor-mode xterm-mouse-mode
    "Toggle XTerm mouse mode.
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
  Turn it on to use Emacs mouse commands, and off to use xterm mouse commands.
! This works in terminal emulators compatible with xterm.  It only
! works for simple uses of the mouse.  Basically, only non-modified
! single clicks are supported.  When turned on, the normal xterm
! mouse functionality for such clicks is still available by holding
! down the SHIFT key while pressing the mouse button."
!   :global t :group 'mouse
!   :init-value (and (getenv "TERM")
! 		   (string-match "xterm" (getenv "TERM"))
! 		   (not window-system))
    (if xterm-mouse-mode
        ;; Turn it on
        (unless window-system
============================================================

===File ~/tooltip.el-diff===================================
*** tooltip.el	31 Mar 2005 08:49:03 -0600	1.46
--- tooltip.el	08 Apr 2005 21:44:48 -0500	
***************
*** 182,193 ****
  ;; set-buffer prevents redisplay optimizations, so every mouse motion
  ;; would be accompanied by a full redisplay.
  
- ;;;###autoload
  (define-minor-mode tooltip-mode
    "Toggle Tooltip display.
  With ARG, turn tooltip mode on if and only if ARG is positive."
    :global t
    :group 'tooltip
    (unless (or (null tooltip-mode) (fboundp 'x-show-tip))
      (error "Sorry, tooltips are not yet available on this system"))
    (let ((hook-fn (if tooltip-mode 'add-hook 'remove-hook)))
--- 182,198 ----
  ;; set-buffer prevents redisplay optimizations, so every mouse motion
  ;; would be accompanied by a full redisplay.
  
  (define-minor-mode tooltip-mode
    "Toggle Tooltip display.
  With ARG, turn tooltip mode on if and only if ARG is positive."
    :global t
    :group 'tooltip
+   :init-value (not (or noninteractive
+ 		       (if (boundp 'emacs-quick-startup)
+ 			   emacs-quick-startup)
+ 		       (if (fboundp 'display-graphic-p)
+ 			   (not (display-graphic-p)))
+ 		       (not (fboundp 'x-show-tip))))
    (unless (or (null tooltip-mode) (fboundp 'x-show-tip))
      (error "Sorry, tooltips are not yet available on this system"))
    (let ((hook-fn (if tooltip-mode 'add-hook 'remove-hook)))
============================================================

===File ~/startup.el-diff===================================
*** startup.el	08 Apr 2005 19:21:40 -0500	1.344
--- startup.el	08 Apr 2005 20:59:29 -0500	
***************
*** 728,743 ****
                (<= (frame-parameter nil 'tool-bar-lines) 0))
      (tool-bar-mode 1))
  
!   ;; Can't do this init in defcustom because the relevant variables
!   ;; are not set.
    (custom-reevaluate-setting 'blink-cursor-mode)
    (custom-reevaluate-setting 'normal-erase-is-backspace)
! 
!   (unless (or noninteractive
! 	      emacs-quick-startup
!               (not (display-graphic-p))
!               (not (fboundp 'x-show-tip)))
!     (tooltip-mode 1))
  
    ;; Register default TTY colors for the case the terminal hasn't a
    ;; terminal init file.
--- 728,741 ----
                (<= (frame-parameter nil 'tool-bar-lines) 0))
      (tool-bar-mode 1))
  
!   ;; Necessary for defcustoms that have to be defined before the
!   ;; relevant variables are set.  Also necessary for minor modes
!   ;; defined with `define-minor-mode' that are enabled by default,
!   ;; because they use `custom-initialize-default'
    (custom-reevaluate-setting 'blink-cursor-mode)
    (custom-reevaluate-setting 'normal-erase-is-backspace)
!   (custom-reevaluate-setting 'tooltip-mode)
!   (custom-reevaluate-setting 'xterm-mouse-mode)
  
    ;; Register default TTY colors for the case the terminal hasn't a
    ;; terminal init file.
============================================================

===File ~/loadup.el-diff====================================
*** loadup.el	19 Mar 2005 13:28:44 -0600	1.135
--- loadup.el	08 Apr 2005 19:54:48 -0500	
***************
*** 143,148 ****
--- 143,150 ----
        (load "select")))
  (load "emacs-lisp/timer")
  (load "isearch")
+ (load "tooltip")
+ (load "xt-mouse")
  
  (message "%s" (garbage-collect))
  (load "menu-bar")
============================================================

===File ~/src-Makefile.in-diff==============================
*** Makefile.in	19 Mar 2005 13:29:50 -0600	1.307
--- Makefile.in	08 Apr 2005 20:08:01 -0500	
***************
*** 720,725 ****
--- 720,727 ----
  	${lispsource}help.elc \
  	${lispsource}indent.elc \
  	${lispsource}isearch.elc \
+ 	${lispsource}tooltip.elc \
+ 	$(lispsource)xt-mouse.elc \
  	${lispsource}loadup.el \
  	${lispsource}loaddefs.el \
  	${lispsource}bindings.elc \
***************
*** 810,815 ****
--- 812,819 ----
  	../lisp/help.elc \
  	../lisp/indent.elc \
  	../lisp/isearch.elc \
+ 	../lisp/tooltip.elc \
+ 	../lisp/xt-mouse.elc \
  	../lisp/loadup.el \
  	../lisp/loaddefs.el \
  	../lisp/bindings.elc \
============================================================

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

 > The following patches enable xterm-mouse-mode by default in xterm type
 > terminals, document this in the Emacs manual (I would also document it
 > in the NEWS) and fix the Custom related bug for tooltip-mode.
 > 
 > I can install if desired.

You don't explain the reasoning behind loading xt-mouse in loadup.el. I
imagine it doesn't get used very often and I thought Richard said it should be
loaded/enabled in lisp/term/xterm.el. This would also address Andreas' point
about xterm-like terminal descriptions with different names:

>      (while (and term
>                  (not (load (concat term-file-prefix term) t t)))
>        ;; Strip off last hyphen and what follows, then try again
>        (setq term
>              (if (setq hyphend (string-match "[-_][^-_]+$" term))
>                  (substring term 0 hyphend)
>                nil)))

(excerpt from startup.el)

Also is it necessary to explain explicitly in the manual how to turn each mode
off?


Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Sat, 9 Apr 2005 17:22:29 +1200
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> You don't explain the reasoning behind loading xt-mouse in loadup.el. I
> imagine it doesn't get used very often and I thought Richard said it should be
> loaded/enabled in lisp/term/xterm.el. This would also address Andreas' point
> about xterm-like terminal descriptions with different names:
> 
> >      (while (and term
> >                  (not (load (concat term-file-prefix term) t t)))
> >        ;; Strip off last hyphen and what follows, then try again
> >        (setq term
> >              (if (setq hyphend (string-match "[-_][^-_]+$" term))
> >                  (substring term 0 hyphend)
> >                nil)))
> 
> (excerpt from startup.el)

Yes.  See also the various calls to (getenv "TERM") in startup.el,
xterm.el and rxvt.el: there are a few more terminal names that could
benefit from this change, which the code there mentions.

> Also is it necessary to explain explicitly in the manual how to turn each mode
> off?

FWIW, I don't think so.  The added verbiage should IMHO go into NEWS,
not the manual.

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

 > Yes.  See also the various calls to (getenv "TERM") in startup.el,
 > xterm.el and rxvt.el: there are a few more terminal names that could
 > benefit from this change, which the code there mentions.

Right. So xterm-mouse-mode shouldn't be enabled in xterm.el but im
startup.el with an appropriate conditional:

    (let ((term (getenv "TERM"))
          hyphend)
      (while (and term
                  (not (load (concat term-file-prefix term) t t)))
        ;; Strip off last hyphen and what follows, then try again
        (setq term
              (if (setq hyphend (string-match "[-_][^-_]+$" term))
                  (substring term 0 hyphend)
                nil)))
+>   (if (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)" term)
+>       (xterm-mouse-mode 1)))

I'm not sure what should be done for customize though. Luc?


Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Nick Roberts wrote:

   I'm not sure what should be done for customize though. Luc?

I could handle that.  However, I really start to doubt that enabling
xterm-mouse-mode by default in all terminals for which we believe it
makes sense is a good idea.  As we have seen, Xterm Mouse mode has a
very imperfect and unpredictable implementation.  It is basically
impossible to know whether a given type of mouse click is going to be
handled by Emacs or by the terminal without trying it out first (or
very carefully studying the code first).  That is why the Emacs manual
would have to tell people who get frustrated by all of this
unpredictability how to disable the mode.  Also the heuristic we use
to decide when to enable xterm-mouse-mode might miss some terminal
types for which it works.  People using these terminals would still
have to know which function or variable to use to enable it themselves.

I would say, let us keep the mode disabled by default.  If we want to
go through with enabling it by default, I will take care of the Custom
problems.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

 >    I'm not sure what should be done for customize though. Luc?
 > 
 > I could handle that.  However, I really start to doubt that enabling
 > xterm-mouse-mode by default in all terminals for which we believe it
 > makes sense is a good idea.  As we have seen, Xterm Mouse mode has a
 > very imperfect and unpredictable implementation.

Well it may imperfect but its certainly predictable, once you've used it a few
times.

 > It is basically impossible to know whether a given type of mouse click is
 > going to be handled by Emacs or by the terminal without trying it out first
 > (or very carefully studying the code first).  That is why the Emacs manual
 > would have to tell people who get frustrated by all of this
 > unpredictability how to disable the mode.

I think you exaggerate the frustration it will cause. The user can quickly
find its limits.

 > Also the heuristic we use to decide when to enable xterm-mouse-mode might
 > miss some terminal types for which it works.  People using these terminals
 > would still have to know which function or variable to use to enable it
 > themselves.

That heuristic is aready used in startup.el so it must be pretty good. If
there are cases that aren't covered, hopefully they'll come up in the pretest.

 > I would say, let us keep the mode disabled by default.  If we want to
 > go through with enabling it by default, I will take care of the Custom
 > problems.

I say let's enable it by default, I think Richard has already decided this.
Single mouse clicks work on the modeline and eleswhere now. I certainly think
most users would use it by preference.


Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

the changes seem good except for one point:

    *** loadup.el	19 Mar 2005 13:28:44 -0600	1.135
    --- loadup.el	08 Apr 2005 19:54:48 -0500	
    ***************
    *** 143,148 ****
    --- 143,150 ----
	    (load "select")))
      (load "emacs-lisp/timer")
      (load "isearch")
    + (load "tooltip")
    + (load "xt-mouse")

I don't like preloading xt-mouse, since most users don't want it.
Could you make lisp/term/xterm.el load it instead?

Preloading tooltip is ok, since that usually will not be wasted.


Also, please don't forget to mention in etc/NEWS that xterm-mouse-mode
will be enabled by default.

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    Also is it necessary to explain explicitly in the manual how to turn each mode
    off?

It isn't an absolute rule that we must always document turning off
everything, but in this case some people might want it.

Re: `xterm-mouse-mode' has a bogus Custom group

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sat, 09 Apr 2005 21:54:53 -0400
> Cc: emacs-devel@gnu.org
> 
> Preloading tooltip is ok, since that usually will not be wasted.

Except in Emacs compiled with --without-x and on MSDOS.  So please
let's not preload tooltip in those cases.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Eli Zaretskii wrote:

   Except in Emacs compiled with --without-x and on MSDOS.  So please
   let's not preload tooltip in those cases.

Actually, the reason I thought it had to be preloaded was because of
confusion with some prior similar cases.  The only drawback of not
preloading it is that we need to duplicate the same code in the
defcustom and in startup.el and make sure that the two stay exactly in
sync.  But that is not too bad.  The following patches enable tooltip
mode at startup while taking care of the Custom problem.  The patch to
startup.el merely adds a comment.

I can install if desired.

xterm-mouse-mode could be taken care of in a similar fashion (without
preloading) if that would be what we want to do.

===File ~/startup.el-diff===================================
*** startup.el	08 Apr 2005 19:21:40 -0500	1.344
--- startup.el	10 Apr 2005 07:28:30 -0500	
***************
*** 733,738 ****
--- 733,741 ----
    (custom-reevaluate-setting 'blink-cursor-mode)
    (custom-reevaluate-setting 'normal-erase-is-backspace)
  
+   ;; If you change the code below, you need to also change the
+   ;; corresponding code in the tooltip-mode defcustom.  The two need
+   ;; to be equivalent under all conditions, or Custom will get confused.
    (unless (or noninteractive
  	      emacs-quick-startup
                (not (display-graphic-p))
============================================================

===File ~/tooltip.el-diff===================================
*** tooltip.el	31 Mar 2005 08:49:03 -0600	1.46
--- tooltip.el	10 Apr 2005 07:27:01 -0500	
***************
*** 187,192 ****
--- 187,198 ----
    "Toggle Tooltip display.
  With ARG, turn tooltip mode on if and only if ARG is positive."
    :global t
+   ;; If you change the :init-value below, you also need to change the
+   ;; corresponding code in startup.el.
+   :init-value (not (or noninteractive
+ 		       emacs-quick-startup
+ 		       (not (display-graphic-p))
+ 		       (not (fboundp 'x-show-tip))))
    :group 'tooltip
    (unless (or (null tooltip-mode) (fboundp 'x-show-tip))
      (error "Sorry, tooltips are not yet available on this system"))
============================================================

Re: `xterm-mouse-mode' has a bogus Custom group

[Stefan Monnier]

> I don't like preloading xt-mouse, since most users don't want it.
> Could you make lisp/term/xterm.el load it instead?

Problem is, xterm.el is loaded after .emacs, so doing it in xterm.el makes
it difficult for users to turn it off.


        Stefan

Re: `xterm-mouse-mode' has a bogus Custom group

[Stefan Monnier]

> confusion with some prior similar cases.  The only drawback of not
> preloading it is that we need to duplicate the same code in the
> defcustom and in startup.el and make sure that the two stay exactly in
> sync.

There are other ways to avoid this duplication.  See patch below.


        Stefan


--- startup.el	08 avr 2005 10:38:07 -0400	1.344
+++ startup.el	10 avr 2005 10:35:33 -0400	
@@ -737,7 +737,8 @@
 	      emacs-quick-startup
               (not (display-graphic-p))
               (not (fboundp 'x-show-tip)))
-    (tooltip-mode 1))
+    (tooltip-mode 1)
+    (put 'tooltip-mode 'standard-value '(t)))
 
   ;; Register default TTY colors for the case the terminal hasn't a
   ;; terminal init file.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Stefan Monnier wrote:

   There are other ways to avoid this duplication.  See patch below.


	   Stefan


   --- startup.el	08 avr 2005 10:38:07 -0400	1.344
   +++ startup.el	10 avr 2005 10:35:33 -0400	
   @@ -737,7 +737,8 @@
		 emacs-quick-startup
		  (not (display-graphic-p))
		  (not (fboundp 'x-show-tip)))
   -    (tooltip-mode 1))
   +    (tooltip-mode 1)
   +    (put 'tooltip-mode 'standard-value '(t)))

If I remember (and understood) correctly, Richard rejected this kind
of solution when we first discussed this problem.

It gives at least two problems I am aware of:

1.  Loading tooltip again will set the standard value to nil again.

2. Selecting "Show initial Lisp expression" in a Custom buffer will
   not show the correct expression.  This expression is useful if you
   want to customize variables whose default depends on a bunch of
   stuff, because looking at that expression will ensure that you are
   aware of all aspects of the problem.

There may very well be other problems.  Custom just assumes that the
standard value is the expression given in the defcustom.

It certainly would simplify things if we could simply set the standard
values of all 20+ remaining options in the `emacs -q M-x customize-rogue'
buffer to the actual values they have just before the init files are
read in startup.el, as Lennart Borgman proposed (if I remember
correctly).  But Richard rejected that and, as pointed out above,
there are some problems with that approach.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Nick Roberts]

> > confusion with some prior similar cases.  The only drawback of not
 > > preloading it is that we need to duplicate the same code in the
 > > defcustom and in startup.el and make sure that the two stay exactly in
 > > sync.
 > 
 > There are other ways to avoid this duplication.  See patch below.

In the case of define-minor-mode, perhaps it could be arranged that, for
example, (tooltip-mode 2) sets tooltip-mode to the standard value. That might
mean a lot of changes but I guess its a problem thats not going to go away. I
don't know how to access the standard value (:init-value?), what would happen
if its not set, etc, but if its a sensible idea, I could look at it.

Nick

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Nick Roberts wrote:

   I don't know how to access the standard value (:init-value?), what
   would happen if its not set, etc, but if its a sensible idea, I
   could look at it.

The standard value is the _unevaluated_ expression given as value in
the defcustom.  In the case of define-minor-mode, that is the
expression given as :init-value.  Evaluating the defcustom produced by
define-minor-mode sets or resets it to that.

You access the standard value from Lisp as
(car (get symbol 'standard-value))

If you did not customize the option you also get it from selecting
"Show initial Lisp expression" in the Custom buffer.

"Erase Customization" in a Custom buffer sets the value for the
current session back to Custom's idea of the standard value.  So if
that is different from the real default, trouble may result for the
current session.

You can change Custom's idea of the standard value by changing the
'standard-value property of the option symbol to a list whose car is
the expression you want.  But if then for any reason whatsoever the
defcustom gets evaluated again, it will set the standard value back to
the expression given in the defcustom.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

Please do preload tooltip, except in the two conditions that Eli
identified.  Since it will nearly always be used, it's good to have
it preloaded.

However, xt-mouse should never be preloaded.

Please go ahead and adapt your change to that decision, and install it.

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    Problem is, xterm.el is loaded after .emacs, so doing it in xterm.el makes
    it difficult for users to turn it off.

In that case, I agree let's handle it Luc's way.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Richard Stallman wrote:

   Please do preload tooltip, except in the two conditions that Eli
   identified.  Since it will nearly always be used, it's good to have
   it preloaded.

Conditionally and explictly preloading it will not get rid of the
code duplication.  I would have to preload it _after_ startup.el, to
avoid making the code more complicated with boundp's and fboundp's, to
prevent errors for variables and functions that might not yet be
defined if loaded too early.

But does this make sense?  It would appear that, whenever tooltip
needs to be enabled, calling `(tooltip-mode 1)' will load it (by an
autoload cookie).  We would just be loading it a second time.  It
appears that `(tooltip-mode 1)' even adds the docstrings to etc/DOC.

So in a certain sense, tooltip is already preloaded when it needs to
be enabled.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

>From my previous message:

   Conditionally and explictly preloading it will not get rid of the
   code duplication.

Actually, preloading tooltip.el _before_ startup.el might avoid some
code duplication for the standard value code (which is small anyway),
but it would actually increase the total amount of code, and
tooltip.el would be loaded in cases where it is unnecessary.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

The following patches would enable Xterm Mouse mode when it makes
sense, without confusing Custom.  *Note* however, that there are some
additional problems I discovered (while testing the patches) with
enabling it.  Clicking mouse-1 can do all kinds of unexpected stuff,
without the usual mouse face, without the usual tooltips or echo-area
equivalent (because Emacs still does not respond to mouse-over) and
often without any clear fontification either.

Do I install the patches below anyway?

===File ~/startup.el-diff===================================
diff -c /home/teirllm/emacscvsdir/emacs/lisp/startup.el /home/teirllm/startup-a11.el
*** /home/teirllm/emacscvsdir/emacs/lisp/startup.el	Mon Apr 11 20:22:36 2005
--- /home/teirllm/startup-a11.el	Mon Apr 11 14:39:15 2005
***************
*** 954,959 ****
--- 957,966 ----
  
    ;; Load library for our terminal type.
    ;; User init file can set term-file-prefix to nil to prevent this.
+ 
+   ;; If you change the code below, you need to also change the
+   ;; corresponding code in the tooltip-mode defcustom.  The two need
+   ;; to be equivalent under all conditions, or Custom will get confused.
    (unless (or noninteractive
                window-system
                (null term-file-prefix))
***************
*** 965,971 ****
          (setq term
                (if (setq hyphend (string-match "[-_][^-_]+$" term))
                    (substring term 0 hyphend)
!                 nil)))))
  
    ;; Update the out-of-memory error message based on user's key bindings
    ;; for save-some-buffers.
--- 972,981 ----
          (setq term
                (if (setq hyphend (string-match "[-_][^-_]+$" term))
                    (substring term 0 hyphend)
!                 nil)))
!       (and term
! 	   (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)" term)
! 	   (xterm-mouse-mode 1))))
  
    ;; Update the out-of-memory error message based on user's key bindings
    ;; for save-some-buffers.

Diff finished.  Mon Apr 11 20:25:03 2005
============================================================

===File ~/xt-mouse.el-diff==================================
*** xt-mouse.el	03 Apr 2005 19:34:53 -0500	1.25
--- xt-mouse.el	11 Apr 2005 20:58:10 -0500	
***************
*** 156,165 ****
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
  Turn it on to use Emacs mouse commands, and off to use xterm mouse commands.
! This works in terminal emulators compatible with xterm.  Only single clicks
! are supported.  When turned on, the normal xterm mouse functionality is still
! available by holding down the SHIFT key while pressing the mouse button."
!   nil " Mouse" nil :global t :group 'mouse
    (if xterm-mouse-mode
        ;; Turn it on
        (unless window-system
--- 156,188 ----
  With prefix arg, turn XTerm mouse mode on iff arg is positive.
  
  Turn it on to use Emacs mouse commands, and off to use xterm mouse commands.
! This works in terminal emulators compatible with xterm.  It only
! works for simple uses of the mouse.  Basically, only non-modified
! single clicks are supported.  When turned on, the normal xterm
! mouse functionality for such clicks is still available by holding
! down the SHIFT key while pressing the mouse button."
!   :global t :group 'mouse
!   ;; Do not change the :init-value below without corresponding
!   ;; changes in the related code in startup.el.
!   :init-value (unless (or noninteractive
! 			  window-system
! 			  (null term-file-prefix))
! 		(let ((term (getenv "TERM"))
! 		      hyphend)
! 		  (while
! 		      (and term
! 			   (not (load (concat term-file-prefix term) t t)))
! 		    ;; Strip off last hyphen and what follows, then
! 		    ;; try again
! 		    (setq term
! 			  (if (setq hyphend
! 				    (string-match "[-_][^-_]+$" term))
! 			      (substring term 0 hyphend)
! 			    nil)))
! 		  (and term
! 		       (string-match "^\\(xterm\\|rxvt\\|dtterm\\|eterm\\)"
! 				     term)
! 		       t)))
    (if xterm-mouse-mode
        ;; Turn it on
        (unless window-system
============================================================

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

>From my previous mesage:
       
       ;; Load library for our terminal type.
       ;; User init file can set term-file-prefix to nil to prevent this.
   + 
   +   ;; If you change the code below, you need to also change the
   +   ;; corresponding code in the tooltip-mode defcustom.  The two need

That was a typo.  Meant was: in the xterm-mouse-mode defcustom.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

Ok, please install.

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    Conditionally and explictly preloading it will not get rid of the
    code duplication.  I would have to preload it _after_ startup.el, to
    avoid making the code more complicated with boundp's and fboundp's, to
    prevent errors for variables and functions that might not yet be
    defined if loaded too early.

Ok, preload it after startup.el.

It is not clear to me why that would not get rid of the code duplication.
After all, the code in startup.el runs when the dumped Emacs is started.

But maybe you're right about that.  If so, you can't get rid of the code
duplication.  But it is still desirable to conditionally preload tooltip.


    So in a certain sense, tooltip is already preloaded when it needs to
    be enabled.

Currently what happens is that it is loaded in each session.
That slows down startup.  Preloading it will speed up startup.

This benefit will occur regardless of where in loadup.el
the preloading of tooltip takes place.  In general, if most
users are going to use a certain file, preloading it is
better than loading it into most sessions during the session.

Re: `xterm-mouse-mode' has a bogus Custom group

[David Kastrup]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> I have now enabled Xterm Mouse mode by default in xterm style
> terminal emulators, as requested.  As I pointed out before, this is
> not without problems.
>
> One of the worst kind of problems occurs when you click on the mode
> line.  You get no tooltips or echo area messages to tell you what is
> going to happen, because, even with Xterm Mouse mode enabled, Emacs
> does not respond to mouse over.  So basically, when you click on the
> mode line you have no idea what is going to happen.

Tooltips are an optional help.  A lot of people make do without them.
XEmacs has no working tooltips even today.  So this is not so very
tragic.

> The main reason for wanting to click on the mode line is to resize
> the window.  Should we not disable all the other fireworks in the
> mode line when we can not warn the user about them, that is, when
> not running under a window system?

The "fireworks" are not destructive and usually deliver a text message
what happened.  I don't see much of a problem here.

We might want assign a mouse-button+modifier combination to explictly
providing a tooltip in the echo area: that way Xterm users can
"explore" things by clicking wildly in a similar way as mouse-over
enabled people can.  Since point-positioning is not useful on the
modeline, one could even use mouse-1 (when used undragged) for that,
reserving mouse-2 for the actual action.  That way people will tend
not to trigger something accidentally.

> A basic problem with Xterm Mouse mode is that mouse clicks are
> enabled, but the usual tools to tell you that mouse clicks are going
> to do something special and what that is (mouse face and tooltips or
> echo area messages) are not.

I don't see much tragedy here, like I said.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

I have now enabled Xterm Mouse mode by default in xterm style terminal
emulators, as requested.  As I pointed out before, this is not without
problems.

One of the worst kind of problems occurs when you click on the mode
line.  You get no tooltips or echo area messages to tell you what is
going to happen, because, even with Xterm Mouse mode enabled, Emacs
does not respond to mouse over.  So basically, when you click on the
mode line you have no idea what is going to happen.

The main reason for wanting to click on the mode line is to resize the
window.  Should we not disable all the other fireworks in the mode
line when we can not warn the user about them, that is, when not
running under a window system?

A basic problem with Xterm Mouse mode is that mouse clicks are
enabled, but the usual tools to tell you that mouse clicks are going
to do something special and what that is (mouse face and tooltips or
echo area messages) are not.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

I guess that you check for MSDOS with `(eq system-type 'ms-dos)' from
Lisp and with `#ifdef MSDOS' from C.

But how do you check whether configure was invoked with `--without-x'
from Lisp and from C?

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

David Kastrup wrote:

   Tooltips are an optional help.  A lot of people make do without them.
   XEmacs has no working tooltips even today.  So this is not so very
   tragic.

I did not complain about absence of tooltips as such.  I personally
disable tooltips, even under a window system.  But with Xterm Mouse
mode, you do not get their replacement, echo area messages either.
That is the problem.  And there is no mouse face.

   The "fireworks" are not destructive and usually deliver a text message
   what happened.  I don't see much of a problem here.

A not very experienced user has two windows, one showing Info.  He
clicks mouse-2 on the Info buffer mode line to make it cover the
entire frame.  But that is not what happens.  Instead, the Info buffer
widens.  The poor user may not even know what narrowing is, or how
Info is internally implemented.  He may have no idea what happened or
what to do next.

   We might want assign a mouse-button+modifier combination to explictly
   providing a tooltip in the echo area:

Even with Xterm Mouse mode enabled, mouse-button+modifier combinations
get handled by the terminal emulator, not by Emacs.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Stefan Monnier]

> I have now enabled Xterm Mouse mode by default in xterm style terminal
> emulators, as requested.  As I pointed out before, this is not without
> problems.

Indeed, xterm-mouse-mode is a nice hack, but it has rough edges and I'd
rather not see it turned on by default.


        Stefan

Re: `xterm-mouse-mode' has a bogus Custom group

[Jan D.]

2I guess that you check for MSDOS with `(eq system-type 'ms-dos)' from
> Lisp and with `#ifdef MSDOS' from C.
>
> But how do you check whether configure was invoked with `--without-x'
> from Lisp and from C?

#ifndef HAVE_X_WINDOWS

You can check window-system in Lisp (it is nil), but it doesn't tell if 
the running Emacs was configured with --without-x, only that it is 
currently running without X.  I.e. it could be emacs -nw, or simply 
running without an X display.  Does it make any difference?

	Jan D.

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    In the case of define-minor-mode, perhaps it could be arranged that, for
    example, (tooltip-mode 2) sets tooltip-mode to the standard value.

It would be a mistake to change a general Enacs convention just to
save some lines in startup.el.  Quite the contrary; I would gladly pay
the price of additional code in startup.el in order to make some general
Emacs convention cleaner.

Re: `xterm-mouse-mode' has a bogus Custom group

[Eli Zaretskii]

> Date: Tue, 12 Apr 2005 20:24:49 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> CC: eliz@gnu.org, emacs-devel@gnu.org
> 
> I guess that you check for MSDOS with `(eq system-type 'ms-dos)' from
> Lisp and with `#ifdef MSDOS' from C.

Only if no other good method exists.  Usually, testing some function
to be fboundp is a much better method.  For example, here's how
startup.el figures out that it runs on MSDOS or a text terminal with
no X support compiled in (thus, no primitive support for tooltips):

  (unless (or noninteractive
	      emacs-quick-startup
              (not (display-graphic-p))
              (not (fboundp 'x-show-tip)))
    (tooltip-mode 1))

The last 2 conditions is what you are looking for.  This is much
cleaner, as no OS names are mentioned, just the functionality you need
for the call you are about to make.

> But how do you check whether configure was invoked with `--without-x'
> from Lisp and from C?

See above: find some related C function with Lisp binding that is only
compiled in when X support is enabled, and test for it with fboundp.
That's for Lisp code; for C, Jan showed you the way.

Re: `xterm-mouse-mode' has a bogus Custom group

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, eliz@gnu.org, rms@gnu.org
> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Wed, 13 Apr 2005 06:58:04 +0200
> 
> > But how do you check whether configure was invoked with `--without-x'
> > from Lisp and from C?
> 
> #ifndef HAVE_X_WINDOWS

Actually, I'd suggest

 #ifdef HAVE_WINDOW_SYSTEM

because the latter will catch non-X windowed versions (e.g.,
MS-Windows) as well.  Unless the code is in X-specific file, like
xfns.c, where non-X toolkits are a non-issue.

> You can check window-system in Lisp (it is nil), but it doesn't tell if 
> the running Emacs was configured with --without-x, only that it is 
> currently running without X.  I.e. it could be emacs -nw, or simply 
> running without an X display.  Does it make any difference?

Yes, it makes a difference: Emacs compiled with --without-x cannot
invoke code that calls X-specific primitives, because that would
signal errors complaining about void functions.  Emacs that does have
X support but runs with -nw will silently do nothing when such code is
invoked because (modulo bugs) these features are coded to do nothing
when the required graphic display facilities are not available.

Re: `xterm-mouse-mode' has a bogus Custom group

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     In the case of define-minor-mode, perhaps it could be arranged that, for
>     example, (tooltip-mode 2) sets tooltip-mode to the standard value.
>
> It would be a mistake to change a general Enacs convention just to
> save some lines in startup.el.  Quite the contrary; I would gladly pay
> the price of additional code in startup.el in order to make some general
> Emacs convention cleaner.

Customize in Emacs-22 has themes now even though I don't think they
are used anywhere right now.  It would seem to be a useful convention
if minor mode functions could just provide a theme name.  In that case
(tooltip-mode 'standard) would set the system default, and
(tooltip-mode 'user) would set the user-customized default.

Actually, I think we should encourage in future that things like
"Newbie configuration", "MacOSX configuration", "Windows typical
configuration" for prepackaged Emacsen are provided using themes.  In
contrast to setq and similar, they should not cause problems with
customize.

It is probably a bit late in the game to make themes a first class
feature with regard to documentation as well as code, but maybe we
should at least point them out more prominently to get feedback from
users for future amendments.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    The main reason for wanting to click on the mode line is to resize the
    window.  Should we not disable all the other fireworks in the mode
    line when we can not warn the user about them, that is, when not
    running under a window system?

That is a good idea.  For those features that don't work right,
it is better if they fail in a clear way.

The simplest way is to change xt-mouse to simply drop any events that
are expected not to work right.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

The C and Lisp conditions for loading tooltip in the patches below are
not completely equivalent, but I believe I understood that this does
not matter too much.  I saw everything else that was conditionally
loaded use a FOO_SUPPORT macro, so I defined a TOOLTIP_SUPPORT macro.

I can only test this on GNU/Linux.

===File ~/src-Makefile.in-diff==============================
*** Makefile.in	19 Mar 2005 13:29:50 -0600	1.307
--- Makefile.in	13 Apr 2005 20:37:51 -0500	
***************
*** 686,691 ****
--- 686,697 ----
  #define WINNT_SUPPORT
  #endif
  
+ #if defined (HAVE_WINDOW_SYSTEM) && !defined (MSDOS)
+ #define TOOLTIP_SUPPORT ${lispsource}tooltip.elc
+ #else
+ #define TOOLTIP_SUPPORT
+ #endif
+ 
  /* List of Lisp files loaded into the dumped Emacs.  It's arranged
     like this because it's easier to generate it semi-mechanically from
     loadup.el this way.
***************
*** 779,784 ****
--- 785,791 ----
  	${lispsource}emacs-lisp/timer.elc \
  	${lispsource}vc-hooks.elc \
  	${lispsource}ediff-hook.elc \
+ 	TOOLTIP_SUPPORT \
  	VMS_SUPPORT \
  	MSDOS_SUPPORT \
  	WINNT_SUPPORT \
***************
*** 885,890 ****
--- 892,898 ----
    ${dotdot}/lisp/ls-lisp.elc ${dotdot}/lisp/dos-fns.elc \
    ${dotdot}/lisp/w32-fns.elc ${dotdot}/lisp/dos-w32.elc \
    ${dotdot}/lisp/disp-table.elc ${dotdot}/lisp/dos-vars.elc \
+   ${dotdot}/lisp/tooltip.elc \
    ${dotdot}/lisp/international/ccl.elc \
    ${dotdot}/lisp/international/codepage.elc
  
============================================================

===File ~/loadup-diff=======================================
*** loadup.el	19 Mar 2005 13:28:44 -0600	1.135
--- loadup.el	13 Apr 2005 20:15:24 -0500	
***************
*** 192,197 ****
--- 192,200 ----
  
  (load "vc-hooks")
  (load "ediff-hook")
+ (and (display-graphic-p)
+      (fboundp 'x-show-tip)
+      (load "tooltip"))
  (message "%s" (garbage-collect))
  
  ;If you want additional libraries to be preloaded and their
============================================================

===File ~/startup-diff======================================
*** startup.el	13 Apr 2005 17:18:03 -0500	1.350
--- startup.el	13 Apr 2005 20:17:53 -0500	
***************
*** 746,751 ****
--- 746,754 ----
    (custom-reevaluate-setting 'blink-cursor-mode)
    (custom-reevaluate-setting 'normal-erase-is-backspace)
  
+   ;; If you change the code below, you need to also change the
+   ;; corresponding code in the tooltip-mode defcustom.  The two need
+   ;; to be equivalent under all conditions, or Custom will get confused.
    (unless (or noninteractive
  	      emacs-basic-display
                (not (display-graphic-p))
============================================================

===File ~/tooltip-diff======================================
*** tooltip.el	31 Mar 2005 08:49:03 -0600	1.46
--- tooltip.el	10 Apr 2005 07:27:01 -0500	
***************
*** 187,192 ****
--- 187,198 ----
    "Toggle Tooltip display.
  With ARG, turn tooltip mode on if and only if ARG is positive."
    :global t
+   ;; If you change the :init-value below, you also need to change the
+   ;; corresponding code in startup.el.
+   :init-value (not (or noninteractive
+ 		       emacs-quick-startup
+ 		       (not (display-graphic-p))
+ 		       (not (fboundp 'x-show-tip))))
    :group 'tooltip
    (unless (or (null tooltip-mode) (fboundp 'x-show-tip))
      (error "Sorry, tooltips are not yet available on this system"))
============================================================

Re: `xterm-mouse-mode' has a bogus Custom group

[Eli Zaretskii]

> Date: Wed, 13 Apr 2005 21:16:40 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> CC: jan.h.d@swipnet.se, emacs-devel@gnu.org
> 
> + #if defined (HAVE_WINDOW_SYSTEM) && !defined (MSDOS)

You don't need to test for MSDOS here, since the MSDOS port doesn't
define HAVE_WINDOW_SYSTEM.

Re: `xterm-mouse-mode' has a bogus Custom group

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> ===File ~/loadup-diff=======================================
> *** loadup.el	19 Mar 2005 13:28:44 -0600	1.135
> --- loadup.el	13 Apr 2005 20:15:24 -0500	
> ***************
> *** 192,197 ****
> --- 192,200 ----
>   
>   (load "vc-hooks")
>   (load "ediff-hook")
> + (and (display-graphic-p)
> +      (fboundp 'x-show-tip)
> +      (load "tooltip"))
>   (message "%s" (garbage-collect))


Since loadup.el is run in --batch mode, I would assume that
(display-graphic-p) is always false in that context.

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

Re: `xterm-mouse-mode' has a bogus Custom group

[Richard Stallman]

    The C and Lisp conditions for loading tooltip in the patches below are
    not completely equivalent, but I believe I understood that this does
    not matter too much.  I saw everything else that was conditionally
    loaded use a FOO_SUPPORT macro, so I defined a TOOLTIP_SUPPORT macro.

It seems reasonable.  But don't forget to update SOME_MACHINE_LISP.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Kim Storm wrote:

   Since loadup.el is run in --batch mode, I would assume that
   (display-graphic-p) is always false in that context.

Indeed, I should have tested my patches better.  And window-system is
always nil too.

One possibility is to only avoid preloading tooltip on MSDOS and not
worry about `--without-x'.  (How many people compile Emacs
`--without-x'?)  Then we could use `(eq system-type 'ms-dos)', which
presumably works in loadup, because I have seen it used there.  The
other possibility is to not bother preloading tooltip at all.  I would
guess that we are only talking about saving a very small fraction of a
second when starting up Emacs.

Unless somebody knows how to accurately test whether Emacs was
compiled --without-x in loadup.el.

Sincerely,

Luc.

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Richard Stallman wrote:

   It seems reasonable.  But don't forget to update SOME_MACHINE_LISP.

I did that:

SOME_MACHINE_LISP = ${dotdot}/lisp/mouse.elc \
  ${dotdot}/lisp/select.elc ${dotdot}/lisp/scroll-bar.elc \
  ${dotdot}/lisp/vmsproc.elc ${dotdot}/lisp/vms-patch.elc \
  ${dotdot}/lisp/ls-lisp.elc ${dotdot}/lisp/dos-fns.elc \
  ${dotdot}/lisp/w32-fns.elc ${dotdot}/lisp/dos-w32.elc \
  ${dotdot}/lisp/disp-table.elc ${dotdot}/lisp/dos-vars.elc \
  ${dotdot}/lisp/tooltip.elc \
  ${dotdot}/lisp/international/ccl.elc \
  ${dotdot}/lisp/international/codepage.elc

Re: `xterm-mouse-mode' has a bogus Custom group

[Miles Bader]

On 4/15/05, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
> (How many people compile Emacs `--without-x'?)

I do (on a system I only access remotely via ssh).

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: `xterm-mouse-mode' has a bogus Custom group

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Unless somebody knows how to accurately test whether Emacs was
> compiled --without-x in loadup.el.

Since x-show-tip is only defined with X/W32/MAC, this should work:

(if (fboundp 'x-show-tip)
    (load "tooltip"))

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

Re: `xterm-mouse-mode' has a bogus Custom group

[Ismail Donmez]

On Friday 15 April 2005 11:23, Miles Bader wrote:
> On 4/15/05, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
> > (How many people compile Emacs `--without-x'?)

Well I do. Because Xlib/Gtk+ interface is not as good as cli one ( interface 
wise ) imho.

ismail

Re: `xterm-mouse-mode' has a bogus Custom group

[Eli Zaretskii]

> Date: Thu, 14 Apr 2005 21:04:31 -0500 (CDT)
> From: Luc Teirlinck <teirllm@dms.auburn.edu>
> CC: eliz@gnu.org, jan.h.d@swipnet.se, emacs-devel@gnu.org
> 
> One possibility is to only avoid preloading tooltip on MSDOS and not
> worry about `--without-x'.  (How many people compile Emacs
> `--without-x'?)

Please don't go this way.  If someone builds Emacs with --without-x,
they mean it, and we should honor their choice and not cause them any
unnecessary grief.

Also, --without-x could be a result of bad or missing X installation.
For example, I cannot compile with X support on fencepost.gnu.org
(didn't have time to investigate what package is not installed there).

> Then we could use `(eq system-type 'ms-dos)', which
> presumably works in loadup

That's not a good idea, either: there's a DOS port of Xlib, which
allows to build Emacs with X support (or at least did that in the
past; I haven't checked that configuration for a very long time).

Basically, checking the OS name shoudl be the very last resort, not
the first one we try.  Let's keep Emacs as clean of ugly OS-specific
hacks as possible.

> Unless somebody knows how to accurately test whether Emacs was
> compiled --without-x in loadup.el.

What's wrong with testing x-show-tip for being fboundp?

Re: `xterm-mouse-mode' has a bogus Custom group

[Luc Teirlinck]

Eli Zaretskii wrote:

   What's wrong with testing x-show-tip for being fboundp?

and Kim Storm wrote:

   Since x-show-tip is only defined with X/W32/MAC, this should work:

   (if (fboundp 'x-show-tip)
       (load "tooltip"))

OK, I have installed that.

Sincerely,

Luc.