update-subdirs and lisp/term

update-subdirs and lisp/term

[Eli Zaretskii]

Does anyone know why we skip lisp/term in update-subdirs?

  for file in *; do
      case $file in
	  *.elc | *.el | term | RCS | CVS | Old | . | .. | =* | *~ | *.orig | *.rej)
	    ;;
	  *)
	      if [ -d $file ]; then
		  if [ "$file" = "obsolete" ]; then
		      subdirs="$subdirs \"$file\""
		  else
		      subdirs="\"$file\" $subdirs"
		  fi
	      fi
	      ;;
      esac
  done

Re: update-subdirs and lisp/term

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Does anyone know why we skip lisp/term in update-subdirs?

Because files in lisp/term are always loaded with the term/ prefix.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 26 Sep 2009 12:44:05 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Does anyone know why we skip lisp/term in update-subdirs?
> 
> Because files in lisp/term are always loaded with the term/ prefix.

Thanks.  But why is that a good idea?  A remnant from past, perhaps,
when lisp/term held only terminal-specific files?

Re: update-subdirs and lisp/term

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> A remnant from past, perhaps, when lisp/term held only
> terminal-specific files?

Doesn't it still do?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 26 Sep 2009 15:24:17 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > A remnant from past, perhaps, when lisp/term held only
> > terminal-specific files?
> 
> Doesn't it still do?

No.

Re: update-subdirs and lisp/term

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> > A remnant from past, perhaps, when lisp/term held only
>> > terminal-specific files?
>> 
>> Doesn't it still do?
>
> No.

In which way?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sat, 26 Sep 2009 19:55:34 +0200
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > A remnant from past, perhaps, when lisp/term held only
> >> > terminal-specific files?
> >> 
> >> Doesn't it still do?
> >
> > No.
> 
> In which way?

All of them.

Re: update-subdirs and lisp/term

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> > A remnant from past, perhaps, when lisp/term held only
>> >> > terminal-specific files?
>> >> 
>> >> Doesn't it still do?
>> >
>> > No.
>> 
>> In which way?
>
> All of them.

Please expand.  In which way is term/vt100.el not terminal-specific?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 26 Sep 2009 20:46:40 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> >> > A remnant from past, perhaps, when lisp/term held only
> >> >> > terminal-specific files?
> >> >> 
> >> >> Doesn't it still do?
> >> >
> >> > No.
> >> 
> >> In which way?
> >
> > All of them.
> 
> Please expand.  In which way is term/vt100.el not terminal-specific?

I didn't mean vt100.el (or its ilk).

Re: update-subdirs and lisp/term

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> >> > A remnant from past, perhaps, when lisp/term held only
>> >> >> > terminal-specific files?
>> >> >> 
>> >> >> Doesn't it still do?
>> >> >
>> >> > No.
>> >> 
>> >> In which way?
>> >
>> > All of them.
>> 
>> Please expand.  In which way is term/vt100.el not terminal-specific?
>
> I didn't mean vt100.el (or its ilk).

??? But it is one of them.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 26 Sep 2009 22:59:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> >> > A remnant from past, perhaps, when lisp/term held only
> >> >> >> > terminal-specific files?
> >> >> >> 
> >> >> >> Doesn't it still do?
> >> >> >
> >> >> > No.
> >> >> 
> >> >> In which way?
> >> >
> >> > All of them.
> >> 
> >> Please expand.  In which way is term/vt100.el not terminal-specific?
> >
> > I didn't mean vt100.el (or its ilk).
> 
> ??? But it is one of them.

Yes, but not the only one.

Re: update-subdirs and lisp/term

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> 
>> >> >> >> > A remnant from past, perhaps, when lisp/term held only
>> >> >> >> > terminal-specific files?
>> >> >> >> 
>> >> >> >> Doesn't it still do?
>> >> >> >
>> >> >> > No.
>> >> >> 
>> >> >> In which way?
>> >> >
>> >> > All of them.
>> >> 
>> >> Please expand.  In which way is term/vt100.el not terminal-specific?
>> >
>> > I didn't mean vt100.el (or its ilk).
>> 
>> ??? But it is one of them.
>
> Yes, but not the only one.

But you said "all of them", which includes vt100.el.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 26 Sep 2009 23:07:03 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> >> 
> >> >> >> >> > A remnant from past, perhaps, when lisp/term held only
> >> >> >> >> > terminal-specific files?
> >> >> >> >> 
> >> >> >> >> Doesn't it still do?
> >> >> >> >
> >> >> >> > No.
> >> >> >> 
> >> >> >> In which way?
> >> >> >
> >> >> > All of them.
> >> >> 
> >> >> Please expand.  In which way is term/vt100.el not terminal-specific?
> >> >
> >> > I didn't mean vt100.el (or its ilk).
> >> 
> >> ??? But it is one of them.
> >
> > Yes, but not the only one.
> 
> But you said "all of them", which includes vt100.el.

"All of them" was a response to the question "in which way".  IOW,
"in all of the ways", not "all of the files".

Re: update-subdirs and lisp/term

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> 
>> >> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> >> 
>> >> >> >> >> > A remnant from past, perhaps, when lisp/term held only
>> >> >> >> >> > terminal-specific files?
>> >> >> >> >> 
>> >> >> >> >> Doesn't it still do?
>> >> >> >> >
>> >> >> >> > No.
>> >> >> >> 
>> >> >> >> In which way?
>> >> >> >
>> >> >> > All of them.
>> >> >> 
>> >> >> Please expand.  In which way is term/vt100.el not terminal-specific?
>> >> >
>> >> > I didn't mean vt100.el (or its ilk).
>> >> 
>> >> ??? But it is one of them.
>> >
>> > Yes, but not the only one.
>> 
>> But you said "all of them", which includes vt100.el.
>
> "All of them" was a response to the question "in which way".  IOW,
> "in all of the ways", not "all of the files".

But they are all terminal-specific in some way.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Date: Sun, 27 Sep 2009 09:37:36 +0200
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> >> 
> >> >> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> >> >> 
> >> >> >> >> >> > A remnant from past, perhaps, when lisp/term held only
> >> >> >> >> >> > terminal-specific files?
> >> >> >> >> >> 
> >> >> >> >> >> Doesn't it still do?
> >> >> >> >> >
> >> >> >> >> > No.
> >> >> >> >> 
> >> >> >> >> In which way?
> >> >> >> >
> >> >> >> > All of them.
> >> >> >> 
> >> >> >> Please expand.  In which way is term/vt100.el not terminal-specific?
> >> >> >
> >> >> > I didn't mean vt100.el (or its ilk).
> >> >> 
> >> >> ??? But it is one of them.
> >> >
> >> > Yes, but not the only one.
> >> 
> >> But you said "all of them", which includes vt100.el.
> >
> > "All of them" was a response to the question "in which way".  IOW,
> > "in all of the ways", not "all of the files".
> 
> But they are all terminal-specific in some way.

No, only some of them.  Others are non-specific in all ways.

Re: update-subdirs and lisp/term

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> 
>> >> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> >> 
>> >> >> >> Eli Zaretskii <eliz@gnu.org> writes:
>> >> >> >> 
>> >> >> >> >> >> > A remnant from past, perhaps, when lisp/term held only
>> >> >> >> >> >> > terminal-specific files?
>> >> >> >> >> >> 
>> >> >> >> >> >> Doesn't it still do?
>> >> >> >> >> >
>> >> >> >> >> > No.
>> >> >> >> >> 
>> >> >> >> >> In which way?
>> >> >> >> >
>> >> >> >> > All of them.
>> >> >> >> 
>> >> >> >> Please expand.  In which way is term/vt100.el not terminal-specific?
>> >> >> >
>> >> >> > I didn't mean vt100.el (or its ilk).
>> >> >> 
>> >> >> ??? But it is one of them.
>> >> >
>> >> > Yes, but not the only one.
>> >> 
>> >> But you said "all of them", which includes vt100.el.
>> >
>> > "All of them" was a response to the question "in which way".  IOW,
>> > "in all of the ways", not "all of the files".
>> 
>> But they are all terminal-specific in some way.
>
> No, only some of them.  Others are non-specific in all ways.

No.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: update-subdirs and lisp/term

[Richard Stallman]

    > >> > A remnant from past, perhaps, when lisp/term held only
    > >> > terminal-specific files?
    > >> 
    > >> Doesn't it still do?
    > >
    > > No.
    > 
    > In which way?

    All of them.

That response is too cryptic to communicate any meaning.
As far as I can see, all the files in `term' are for specific
terminal types or else loaded based on the window system type,
and `term' is always explicitly specified for these files.
There is no need for them to be found in searches
for file names with no directory specified.

Re: update-subdirs and lisp/term

[Stefan Monnier]

>> > A remnant from past, perhaps, when lisp/term held only
>> > terminal-specific files?
>> Doesn't it still do?
> No.

Which file there is not terminal-specific (other than
lisp/term/common-win.el)?


        Stefan

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  emacs-devel@gnu.org
> Date: Sat, 26 Sep 2009 17:04:16 -0400
> 
> >> > A remnant from past, perhaps, when lisp/term held only
> >> > terminal-specific files?
> >> Doesn't it still do?
> > No.
> 
> Which file there is not terminal-specific (other than
> lisp/term/common-win.el)?

tty-colors.el.

And I think the *-win.el files don't belong there, either, as they are
not terminal-specific, strictly speaking.

Btw, I'm quite okay with dropping this discussion, as I don't mind
leaving things as they are.

Re: update-subdirs and lisp/term

[Stefan Monnier]

>> >> > A remnant from past, perhaps, when lisp/term held only
>> >> > terminal-specific files?
>> >> Doesn't it still do?
>> > No.
>> Which file there is not terminal-specific (other than
>> lisp/term/common-win.el)?
> tty-colors.el.

Good point.  It probably deserves to be moved elsewhere.

> And I think the *-win.el files don't belong there, either, as they are
> not terminal-specific, strictly speaking.

Well, that depends on your definition of "terminal" and Emacs uses
different such definitions at different places.  In the sense of
"terminal" used in `frame-terminal' (for instance), then they do
belong there, but in the sense of $TERM they don't.  So I don't think
that's a strong argument to move them out of there.

OTOH I do think it would be worthwhile to byte-compile them (after all,
they hold a sizable amount of code nowadays), and currently files in
lisp/term aren't byte-compiled.  Maybe we should byte-compile the
lisp/term files (IIRC elc files get loaded more efficiently because they
do not go through load-with-code-conversion, so even if they don't
contain much code, it's worthwhile).


        Stefan

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: schwab@linux-m68k.org,  emacs-devel@gnu.org
> Date: Sun, 27 Sep 2009 14:12:06 -0400
> 
> >> Which file there is not terminal-specific (other than
> >> lisp/term/common-win.el)?
> > tty-colors.el.
> 
> Good point.  It probably deserves to be moved elsewhere.

Richard didn't like its being there from day one.  Mea culpa, I guess.

> currently files in lisp/term aren't byte-compiled.

Some of them are.

Re: update-subdirs and lisp/term

[Stefan Monnier]

>> >> Which file there is not terminal-specific (other than
>> >> lisp/term/common-win.el)?
>> > tty-colors.el.
>> Good point.  It probably deserves to be moved elsewhere.
> Richard didn't like its being there from day one.  Mea culpa, I guess.

So, whoever wants to move it should feel free (tho at this point, I'd
prefer to do it after the switch to Bzr).

>> currently files in lisp/term aren't byte-compiled.
> Some of them are.

Yup, sorry, I looked at the wrong folder.  So other than tty-colors.el
I think the rest is fine where it is.


        Stefan

Re: update-subdirs and lisp/term

[Stefan Monnier]

>> > Does anyone know why we skip lisp/term in update-subdirs?
>> Because files in lisp/term are always loaded with the term/ prefix.
> Thanks.  But why is that a good idea?

It reduces the length of load-path and increases our namespace?

> A remnant from past, perhaps,
> when lisp/term held only terminal-specific files?

Let me put it another way: why would it be a good idea to put lisp/term
in update-subdirs?


        Stefan

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,  emacs-devel@gnu.org
> Date: Sat, 26 Sep 2009 10:07:34 -0400
> 
> >> > Does anyone know why we skip lisp/term in update-subdirs?
> >> Because files in lisp/term are always loaded with the term/ prefix.
> > Thanks.  But why is that a good idea?
> 
> It reduces the length of load-path and increases our namespace?

But this can be said about any other subdirectory of lisp/, can't it?

> Let me put it another way: why would it be a good idea to put lisp/term
> in update-subdirs?

To avoid a special case that someone could trip on.  Every other
subdirectory gets subdirs.el created in it, but term does not.
Imagine that we will want to have subdirectories under term some day.
Why ask maintainers to use up one more register for remembering this
factoid, or risk strange failures/bugs?

That said, I won't argue.  If the above is not convincing, then so be
it.

Re: update-subdirs and lisp/term

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

  > > From: Stefan Monnier <monnier@iro.umontreal.ca>
  > > Cc: Andreas Schwab <schwab@linux-m68k.org>,  emacs-devel@gnu.org
  > > Date: Sat, 26 Sep 2009 10:07:34 -0400
  > > 
  > > >> > Does anyone know why we skip lisp/term in update-subdirs?
  > > >> Because files in lisp/term are always loaded with the term/ prefix.
  > > > Thanks.  But why is that a good idea?
  > > 
  > > It reduces the length of load-path and increases our namespace?
  > 
  > But this can be said about any other subdirectory of lisp/, can't it?
  > 
  > > Let me put it another way: why would it be a good idea to put lisp/term
  > > in update-subdirs?
  > 
  > To avoid a special case that someone could trip on.  Every other
  > subdirectory gets subdirs.el created in it, but term does not.
  > Imagine that we will want to have subdirectories under term some day.
  > Why ask maintainers to use up one more register for remembering this
  > factoid, or risk strange failures/bugs?
  > 
  > That said, I won't argue.  If the above is not convincing, then so be
  > it.

IMHO it's not convincing at all.  Let's look at the history, the latest
files added in lisp/term:

term/common-win.el on 2008-07-20 (it's just a refactoring of existing term/*win.el files)
term/ns-win.el on 2008-07-15 -- new port, we don't get these very often, we have 4 total...
term/cygwin.el on 2005-07-22 
term/linux.el on 1997-07-04 

Based on the past, the probability of something dramatic happening there
is very small, and it can be dealt with at the time it happens.

Re: update-subdirs and lisp/term

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> Let me put it another way: why would it be a good idea to put lisp/term
>> in update-subdirs?
>
> To avoid a special case that someone could trip on.  Every other
> subdirectory gets subdirs.el created in it, but term does not.

The CEDET subdirectories will also lack subdirs.el.  In fact, you agreed
to it yourself, as a solution to the 8+3 filename restriction for CEDET,
remember?

Re: update-subdirs and lisp/term

[Stefan Monnier]

>>> Let me put it another way: why would it be a good idea to put lisp/term
>>> in update-subdirs?
>> To avoid a special case that someone could trip on.  Every other
>> subdirectory gets subdirs.el created in it, but term does not.
> The CEDET subdirectories will also lack subdirs.el.  In fact, you agreed
> to it yourself, as a solution to the 8+3 filename restriction for CEDET,
> remember?

BTW, if the Org people want to use a similar trick, I'd be happy to add
`org' to the list of exceptions that aren't added to load-path (so all
the files lisp/org/org-foo.el can be renamed lisp/org/foo.el and then
loaded via (require 'org/foo)).


        Stefan

Re: update-subdirs and lisp/term

[Carsten Dominik]

On Sep 26, 2009, at 11:03 PM, Stefan Monnier wrote:

>>>> Let me put it another way: why would it be a good idea to put  
>>>> lisp/term
>>>> in update-subdirs?
>>> To avoid a special case that someone could trip on.  Every other
>>> subdirectory gets subdirs.el created in it, but term does not.
>> The CEDET subdirectories will also lack subdirs.el.  In fact, you  
>> agreed
>> to it yourself, as a solution to the 8+3 filename restriction for  
>> CEDET,
>> remember?
>
> BTW, if the Org people want to use a similar trick, I'd be happy to  
> add
> `org' to the list of exceptions that aren't added to load-path (so all
> the files lisp/org/org-foo.el can be renamed lisp/org/foo.el and then
> loaded via (require 'org/foo)).

Nice.  I wish I had known this 2 year ago when I was really
struggling with some of those 8+3 filenames.

For now we are fine, but thanks for the offer.

- Carsten

Re: update-subdirs and lisp/term

[Stefan Monnier]

>> >> > Does anyone know why we skip lisp/term in update-subdirs?
>> >> Because files in lisp/term are always loaded with the term/ prefix.
>> > Thanks.  But why is that a good idea?
>> It reduces the length of load-path and increases our namespace?
> But this can be said about any other subdirectory of lisp/, can't it?

Yes, it can.  Simply the other ones have counter-balancing reasons
(mostly the fact that the other files usually come from random places
and just expect to be found directly in load-path.  E.g. many of the
files started in emacs/lisp before being moved to a subdirectory).

But as can be seen with CEDET, the case of lisp/term is not
inherently unique.


        Stefan

Re: update-subdirs and lisp/term

[Richard Stallman]

    > Because files in lisp/term are always loaded with the term/ prefix.

    Thanks.  But why is that a good idea?  A remnant from past, perhaps,
    when lisp/term held only terminal-specific files?

Omitting this directory speeds up searches for other files.
An there is no need to change it.

Re: update-subdirs and lisp/term

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: schwab@linux-m68k.org, emacs-devel@gnu.org
> Date: Sun, 27 Sep 2009 23:43:41 -0400
> 
>     > Because files in lisp/term are always loaded with the term/ prefix.
> 
>     Thanks.  But why is that a good idea?  A remnant from past, perhaps,
>     when lisp/term held only terminal-specific files?
> 
> Omitting this directory speeds up searches for other files.

This might have been a good reason back when term/ was the only
subdirectory in lisp/ (Emacs 19.x).  But nowadays we have 21
subdirectories besides term/ (and soon we will have 5 more).  Does a
single directory really make a difference?

Re: update-subdirs and lisp/term

[Richard Stallman]

    > Omitting this directory speeds up searches for other files.

    This might have been a good reason back when term/ was the only
    subdirectory in lisp/ (Emacs 19.x).  But nowadays we have 21
    subdirectories besides term/ (and soon we will have 5 more).  Does a
    single directory really make a difference?

It makes some difference; why make even a small slowdown
for all the users just for a small simplification?

Perhaps it would be useful to design some other way to
speed up the search for files.

Re: update-subdirs and lisp/term

[joakim]

Richard Stallman <rms@gnu.org> writes:

>     > Omitting this directory speeds up searches for other files.
>
>     This might have been a good reason back when term/ was the only
>     subdirectory in lisp/ (Emacs 19.x).  But nowadays we have 21
>     subdirectories besides term/ (and soon we will have 5 more).  Does a
>     single directory really make a difference?
>
> It makes some difference; why make even a small slowdown
> for all the users just for a small simplification?
>
> Perhaps it would be useful to design some other way to
> speed up the search for files.

I havent thought this through very well, but I would be interested in a
mechanism that speeds up searching for files, as well as dealing with
various file names issues, for embedded devices. I was thinking this
could be done with some kind of lisp reader that consults and index file
and reads the elisp files from an archive(like a tar file). 

>
-- 
Joakim Verona

Re: update-subdirs and lisp/term

[Chong Yidong]

joakim@verona.se writes:

> I havent thought this through very well, but I would be interested in
> a mechanism that speeds up searching for files, as well as dealing
> with various file names issues, for embedded devices. I was thinking
> this could be done with some kind of lisp reader that consults and
> index file and reads the elisp files from an archive (like a tar
> file).

I think the first step is to demonstrate that this really is a
bottleneck first.