Why is touch-screen.el preloaded?

Why is touch-screen.el preloaded?

[Eli Zaretskii]

I thought this library is only relevant to touch-screen devices, but I
see that we are preloading it unconditionally.  Why?

The comment in loadup.el says:

  ;; touch-screen.el is tiny and is used liberally throughout the button
  ;; code etc, so it may as well be preloaded everywhere.

But touch-screen.el is not "tiny": it's more than 2K lines.

Can we please avoid preloading it, except when the build supports
touch-screen devices?

TIA

Re: Why is touch-screen.el preloaded?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I thought this library is only relevant to touch-screen devices, but I
> see that we are preloading it unconditionally.  Why?
>
> The comment in loadup.el says:
>
>   ;; touch-screen.el is tiny and is used liberally throughout the button
>   ;; code etc, so it may as well be preloaded everywhere.
>
> But touch-screen.el is not "tiny": it's more than 2K lines.
>
> Can we please avoid preloading it, except when the build supports
> touch-screen devices?

Its functions are called from other preloaded functions, such as those
in subr.el and minibuffer.el.

Besides, we plan to support touch screen devices on all builds in due
course.

Re: Why is touch-screen.el preloaded?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 26 Nov 2023 10:02:57 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I thought this library is only relevant to touch-screen devices, but I
> > see that we are preloading it unconditionally.  Why?
> >
> > The comment in loadup.el says:
> >
> >   ;; touch-screen.el is tiny and is used liberally throughout the button
> >   ;; code etc, so it may as well be preloaded everywhere.
> >
> > But touch-screen.el is not "tiny": it's more than 2K lines.
> >
> > Can we please avoid preloading it, except when the build supports
> > touch-screen devices?
> 
> Its functions are called from other preloaded functions, such as those
> in subr.el and minibuffer.el.

Those calls could be made conditional on some fboundp or similar.

> Besides, we plan to support touch screen devices on all builds in due
> course.

In due course we will think about preloading it, then.  For now,
please make it not preloaded.  (And in the future, please bring up any
additional file you'd like to preload.)

Thanks.

Re: Why is touch-screen.el preloaded?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> In due course we will think about preloading it, then.  For now,
> please make it not preloaded.  (And in the future, please bring up any
> additional file you'd like to preload.)

This must still be preloaded under X and Android, however.  I'm a bit
pressed for time at the moment, so it could be several days before I get
around to doing this.

Thanks.

Re: Why is touch-screen.el preloaded?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 26 Nov 2023 19:51:21 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In due course we will think about preloading it, then.  For now,
> > please make it not preloaded.  (And in the future, please bring up any
> > additional file you'd like to preload.)
> 
> This must still be preloaded under X and Android, however.

On systems that support such devices OOTB, it is indeed okay to
preload touch-screen.  Like we do with x-dnd, for example.

> I'm a bit pressed for time at the moment, so it could be several
> days before I get around to doing this.

Thanks, there's no rush.

Re: Why is touch-screen.el preloaded?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Its functions are called from other preloaded functions, such as those
  > in subr.el and minibuffer.el.

If they are used only with touch screens, maybe it is possible
to call them only if the screen is a touch screen.  Then this file
could be loaded only in that case.

  > Besides, we plan to support touch screen devices on all builds in due
  > course.

If the build is capable of supporting touch screens, it could still load
touch-screen.el only when it is actually using one of those.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Why is touch-screen.el preloaded?

[Po Lu]

Po Lu <luangruo@yahoo.com> writes:

> This must still be preloaded under X and Android, however.  I'm a bit
> pressed for time at the moment, so it could be several days before I get
> around to doing this.
>
> Thanks.

How are global variables that are let-bound from many locations
generally addressed?  Can they be autoloaded in some form or fashion?

Introducing defvar statements before each attempt to setq or let-bind
such variables as touch-screen-display-keyboard would be ungainly at
best.

Re: Why is touch-screen.el preloaded?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Tue, 28 Nov 2023 13:07:20 +0800
> 
> How are global variables that are let-bound from many locations
> generally addressed?  Can they be autoloaded in some form or fashion?
> 
> Introducing defvar statements before each attempt to setq or let-bind
> such variables as touch-screen-display-keyboard would be ungainly at
> best.

I don't think I understand the problem with using defvar.  AFAIU, this
is our usual technique in these cases.

Re: Why is touch-screen.el preloaded?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I understand the problem with using defvar.  AFAIU, this
> is our usual technique in these cases.

Setting these variables is an operation that will be executed
frequently, so it'll cause plenty of confusion to force every such
setter to declare them.  Some will never noticed it is not preloaded on
a few systems, and the code they produce will not compile correctly on
those systems.

Re: Why is touch-screen.el preloaded?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 29 Nov 2023 08:02:22 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think I understand the problem with using defvar.  AFAIU, this
> > is our usual technique in these cases.
> 
> Setting these variables is an operation that will be executed
> frequently, so it'll cause plenty of confusion to force every such
> setter to declare them.  Some will never noticed it is not preloaded on
> a few systems, and the code they produce will not compile correctly on
> those systems.

I don't think I understand what you are saying.  Can you perhaps show
an example and explain this using that example?

Re: Why is touch-screen.el preloaded?

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't think I understand what you are saying.  Can you perhaps show
> an example and explain this using that example?

OK.  calc.el binds touch-screen-display-keyboard to t, preventing window
creation hooks it installs from removing the virtual keyboard when the
selected window changes as its calculator windows are created.

    ;; not hidden by accident.
    (let ((touch-screen-display-keyboard t))
      (when (get-buffer-window "*Calc Keypad*")

This let statement binding a global variable won't take effect if
byte-compiled on systems where touch-screen.el is not preloaded unless a
defvar statement is inserted, and much code will omit this statement,
since their authors will be unaware it might be necessary.  Such code
will function improperly if compiled on those systems.

Re: Why is touch-screen.el preloaded?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 29 Nov 2023 19:53:58 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I don't think I understand what you are saying.  Can you perhaps show
> > an example and explain this using that example?
> 
> OK.  calc.el binds touch-screen-display-keyboard to t, preventing window
> creation hooks it installs from removing the virtual keyboard when the
> selected window changes as its calculator windows are created.
> 
>     ;; not hidden by accident.
>     (let ((touch-screen-display-keyboard t))
>       (when (get-buffer-window "*Calc Keypad*")
> 
> This let statement binding a global variable won't take effect if
> byte-compiled on systems where touch-screen.el is not preloaded unless a
> defvar statement is inserted, and much code will omit this statement,
> since their authors will be unaware it might be necessary.  Such code
> will function improperly if compiled on those systems.

But we have this issue in gazillion places in Emacs.  It is the job of
whoever writes such code to make sure there is a defvar.  Otherwise
this is a subtle bug, which will be fixed when reported by someone
from the affected platforms.

A random example:

  (defvar w32-collate-ignore-punctuation) ; Declare for non-w32 builds.

  (defsubst ls-lisp-string-lessp (s1 s2)
    "Return t if string S1 should sort before string S2.
  Case is significant if `ls-lisp-ignore-case' is nil.
  Uses `string-collate-lessp' if `ls-lisp-use-string-collate' is non-nil,
  `compare-strings' otherwise.
  On GNU/Linux systems, if the locale specifies UTF-8 as the codeset,
  the sorting order will place together file names that differ only
  by punctuation characters, like `.emacs' and `emacs'.  To have a
  similar behavior on MS-Windows, customize `ls-lisp-UCA-like-collation'
  to a non-nil value."
    (let ((w32-collate-ignore-punctuation ls-lisp-UCA-like-collation))
      (if ls-lisp-use-string-collate
	  (string-collate-lessp s1 s2 nil ls-lisp-ignore-case)
	(let ((u (compare-strings s1 0 nil s2 0 nil ls-lisp-ignore-case)))
	  (and (numberp u) (< u 0))))))

So I don't see any grave problem here.  It's nothing new.