Re: `term' prefix for gpm support

[Stefan Monnier]

>> > By the way, am I the only one annoyed by the Gpm code's use of the
>> > `term' prefix?  I mean `term-open-connection' sounds like a very odd
>> > choice of name for a function which "Open a connection to Gpm."
>> 
>> Agreed.  I would even say that the GPM code in term.c can go into a
>> separate file, that will reduce the amount of #ifdefs in term.c.

> Maybe t-mouse-open, t-mouse-close would be better.  I can't recall how I
> arrived at those names but it was probably convoluted.

Actually, the "t-mouse" part of the name comes from an earlier version of
the feature implemented in ELisp, but nowadays it only appears in the
t-mouse.el file whose content are minimal:

(define-minor-mode t-mouse-mode
  "Toggle t-mouse mode to use the mouse in Linux consoles."
  :global t :group 'mouse
  (if window-system
      (error "t-mouse only works in the console on GNU/Linux")
    (if t-mouse-mode
        (progn
          (unless (fboundp 'term-open-connection)
            (progn
              (setq t-mouse-mode nil)
              (error "Emacs must be built with Gpm to use this mode")))
          (unless (term-open-connection)
            (progn
              (setq t-mouse-mode nil)
              (error "Can't open mouse connection"))))
      ;; Turn it off
      (term-close-connection))))

so we might as well rename it to something else.  Adding `gpm' to its name
makes sense.  Also the "open-connection" part of the name is a bit
misleading because it makes me feel like this is going to return
a connection.

> There are four #ifdef HAVE_GPM blocks in term.c which doesn't seem that
> many (term.c has 21 ifdefs in all).  More importantly, when I wrote it,
> the gpm code called static functions in term.c like write_glyphs.
> If after multi-tty these functions are no longer part of term.c, maybe the
> gpm code can go into a separate file.

I think it's OK to keep it in term.c.


        Stefan