`term' prefix for gpm support

`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."

Any reason not to change all those "term_" into gpm_ or term_gpm_ ?


        Stefan

Re: `term' prefix for gpm support

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > 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.

Re: `term' prefix for gpm support

[Nick Roberts]

 >   > 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.

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 have no strong opinions about these issues and certainly don't mind if
someone wants to make changes.

-- 
Nick http://www.inet.net.nz/~nickrob

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