* update-subdirs and lisp/term
@ 2009-09-26 9:48 Eli Zaretskii
2009-09-26 10:44 ` Andreas Schwab
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-26 9:48 UTC (permalink / raw
To: emacs-devel
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 9:48 update-subdirs and lisp/term Eli Zaretskii
@ 2009-09-26 10:44 ` Andreas Schwab
2009-09-26 11:16 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2009-09-26 10:44 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 10:44 ` Andreas Schwab
@ 2009-09-26 11:16 ` Eli Zaretskii
2009-09-26 13:24 ` Andreas Schwab
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-26 11:16 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 11:16 ` Eli Zaretskii
@ 2009-09-26 13:24 ` Andreas Schwab
2009-09-26 16:13 ` Eli Zaretskii
2009-09-26 14:07 ` Stefan Monnier
2009-09-28 3:43 ` Richard Stallman
2 siblings, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2009-09-26 13:24 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 11:16 ` Eli Zaretskii
2009-09-26 13:24 ` Andreas Schwab
@ 2009-09-26 14:07 ` Stefan Monnier
2009-09-26 16:19 ` Eli Zaretskii
2009-09-28 3:43 ` Richard Stallman
2 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2009-09-26 14:07 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Andreas Schwab, emacs-devel
>> > 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 13:24 ` Andreas Schwab
@ 2009-09-26 16:13 ` Eli Zaretskii
2009-09-26 17:55 ` Andreas Schwab
2009-09-26 21:04 ` Stefan Monnier
0 siblings, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-26 16:13 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 14:07 ` Stefan Monnier
@ 2009-09-26 16:19 ` Eli Zaretskii
2009-09-26 16:45 ` Dan Nicolaescu
` (2 more replies)
0 siblings, 3 replies; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-26 16:19 UTC (permalink / raw
To: Stefan Monnier; +Cc: schwab, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 16:19 ` Eli Zaretskii
@ 2009-09-26 16:45 ` Dan Nicolaescu
2009-09-26 16:53 ` Chong Yidong
2009-09-26 21:01 ` Stefan Monnier
2 siblings, 0 replies; 34+ messages in thread
From: Dan Nicolaescu @ 2009-09-26 16:45 UTC (permalink / raw
To: Eli Zaretskii; +Cc: schwab, Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 16:19 ` Eli Zaretskii
2009-09-26 16:45 ` Dan Nicolaescu
@ 2009-09-26 16:53 ` Chong Yidong
2009-09-26 21:03 ` Stefan Monnier
2009-09-26 21:01 ` Stefan Monnier
2 siblings, 1 reply; 34+ messages in thread
From: Chong Yidong @ 2009-09-26 16:53 UTC (permalink / raw
To: Eli Zaretskii; +Cc: schwab, Stefan Monnier, emacs-devel
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?
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 16:13 ` Eli Zaretskii
@ 2009-09-26 17:55 ` Andreas Schwab
2009-09-26 18:41 ` Eli Zaretskii
2009-09-26 21:04 ` Stefan Monnier
1 sibling, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2009-09-26 17:55 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 17:55 ` Andreas Schwab
@ 2009-09-26 18:41 ` Eli Zaretskii
2009-09-26 18:46 ` Andreas Schwab
2009-09-27 12:39 ` Richard Stallman
0 siblings, 2 replies; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-26 18:41 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 18:41 ` Eli Zaretskii
@ 2009-09-26 18:46 ` Andreas Schwab
2009-09-26 20:14 ` Eli Zaretskii
2009-09-27 12:39 ` Richard Stallman
1 sibling, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2009-09-26 18:46 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 18:46 ` Andreas Schwab
@ 2009-09-26 20:14 ` Eli Zaretskii
2009-09-26 20:59 ` Andreas Schwab
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-26 20:14 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
> 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).
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 20:14 ` Eli Zaretskii
@ 2009-09-26 20:59 ` Andreas Schwab
2009-09-26 21:06 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2009-09-26 20:59 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 16:19 ` Eli Zaretskii
2009-09-26 16:45 ` Dan Nicolaescu
2009-09-26 16:53 ` Chong Yidong
@ 2009-09-26 21:01 ` Stefan Monnier
2 siblings, 0 replies; 34+ messages in thread
From: Stefan Monnier @ 2009-09-26 21:01 UTC (permalink / raw
To: Eli Zaretskii; +Cc: schwab, emacs-devel
>> >> > 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 16:53 ` Chong Yidong
@ 2009-09-26 21:03 ` Stefan Monnier
2009-09-29 9:19 ` Carsten Dominik
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2009-09-26 21:03 UTC (permalink / raw
To: Chong Yidong; +Cc: Eli Zaretskii, schwab, emacs-devel
>>> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 16:13 ` Eli Zaretskii
2009-09-26 17:55 ` Andreas Schwab
@ 2009-09-26 21:04 ` Stefan Monnier
2009-09-27 7:28 ` Eli Zaretskii
1 sibling, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2009-09-26 21:04 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Andreas Schwab, emacs-devel
>> > 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 20:59 ` Andreas Schwab
@ 2009-09-26 21:06 ` Eli Zaretskii
2009-09-26 21:07 ` Andreas Schwab
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-26 21:06 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 21:06 ` Eli Zaretskii
@ 2009-09-26 21:07 ` Andreas Schwab
2009-09-27 7:29 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2009-09-26 21:07 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 21:04 ` Stefan Monnier
@ 2009-09-27 7:28 ` Eli Zaretskii
2009-09-27 18:12 ` Stefan Monnier
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-27 7:28 UTC (permalink / raw
To: Stefan Monnier; +Cc: schwab, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 21:07 ` Andreas Schwab
@ 2009-09-27 7:29 ` Eli Zaretskii
2009-09-27 7:37 ` Andreas Schwab
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-27 7:29 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
> 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".
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-27 7:29 ` Eli Zaretskii
@ 2009-09-27 7:37 ` Andreas Schwab
2009-09-27 10:35 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Andreas Schwab @ 2009-09-27 7:37 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-27 7:37 ` Andreas Schwab
@ 2009-09-27 10:35 ` Eli Zaretskii
2009-09-27 11:13 ` Andreas Schwab
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-27 10:35 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-27 10:35 ` Eli Zaretskii
@ 2009-09-27 11:13 ` Andreas Schwab
0 siblings, 0 replies; 34+ messages in thread
From: Andreas Schwab @ 2009-09-27 11:13 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 18:41 ` Eli Zaretskii
2009-09-26 18:46 ` Andreas Schwab
@ 2009-09-27 12:39 ` Richard Stallman
1 sibling, 0 replies; 34+ messages in thread
From: Richard Stallman @ 2009-09-27 12:39 UTC (permalink / raw
To: Eli Zaretskii; +Cc: schwab, emacs-devel
> >> > 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-27 7:28 ` Eli Zaretskii
@ 2009-09-27 18:12 ` Stefan Monnier
2009-09-27 19:09 ` Eli Zaretskii
0 siblings, 1 reply; 34+ messages in thread
From: Stefan Monnier @ 2009-09-27 18:12 UTC (permalink / raw
To: Eli Zaretskii; +Cc: schwab, emacs-devel
>> >> > 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-27 18:12 ` Stefan Monnier
@ 2009-09-27 19:09 ` Eli Zaretskii
2009-09-27 22:55 ` Stefan Monnier
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-27 19:09 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-27 19:09 ` Eli Zaretskii
@ 2009-09-27 22:55 ` Stefan Monnier
0 siblings, 0 replies; 34+ messages in thread
From: Stefan Monnier @ 2009-09-27 22:55 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
>> >> 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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 11:16 ` Eli Zaretskii
2009-09-26 13:24 ` Andreas Schwab
2009-09-26 14:07 ` Stefan Monnier
@ 2009-09-28 3:43 ` Richard Stallman
2009-09-28 6:36 ` Eli Zaretskii
2 siblings, 1 reply; 34+ messages in thread
From: Richard Stallman @ 2009-09-28 3:43 UTC (permalink / raw
To: Eli Zaretskii; +Cc: schwab, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-28 3:43 ` Richard Stallman
@ 2009-09-28 6:36 ` Eli Zaretskii
2009-09-28 21:58 ` Richard Stallman
0 siblings, 1 reply; 34+ messages in thread
From: Eli Zaretskii @ 2009-09-28 6:36 UTC (permalink / raw
To: rms; +Cc: emacs-devel
> 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?
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-28 6:36 ` Eli Zaretskii
@ 2009-09-28 21:58 ` Richard Stallman
2009-09-28 22:10 ` joakim
0 siblings, 1 reply; 34+ messages in thread
From: Richard Stallman @ 2009-09-28 21:58 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
> 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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-28 21:58 ` Richard Stallman
@ 2009-09-28 22:10 ` joakim
2009-09-28 22:15 ` Chong Yidong
0 siblings, 1 reply; 34+ messages in thread
From: joakim @ 2009-09-28 22:10 UTC (permalink / raw
To: rms; +Cc: Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-28 22:10 ` joakim
@ 2009-09-28 22:15 ` Chong Yidong
0 siblings, 0 replies; 34+ messages in thread
From: Chong Yidong @ 2009-09-28 22:15 UTC (permalink / raw
To: joakim; +Cc: Eli Zaretskii, rms, emacs-devel
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.
^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: update-subdirs and lisp/term
2009-09-26 21:03 ` Stefan Monnier
@ 2009-09-29 9:19 ` Carsten Dominik
0 siblings, 0 replies; 34+ messages in thread
From: Carsten Dominik @ 2009-09-29 9:19 UTC (permalink / raw
To: Stefan Monnier; +Cc: Chong Yidong, schwab, Eli Zaretskii, emacs-devel
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
^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2009-09-29 9:19 UTC | newest]
Thread overview: 34+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-26 9:48 update-subdirs and lisp/term Eli Zaretskii
2009-09-26 10:44 ` Andreas Schwab
2009-09-26 11:16 ` Eli Zaretskii
2009-09-26 13:24 ` Andreas Schwab
2009-09-26 16:13 ` Eli Zaretskii
2009-09-26 17:55 ` Andreas Schwab
2009-09-26 18:41 ` Eli Zaretskii
2009-09-26 18:46 ` Andreas Schwab
2009-09-26 20:14 ` Eli Zaretskii
2009-09-26 20:59 ` Andreas Schwab
2009-09-26 21:06 ` Eli Zaretskii
2009-09-26 21:07 ` Andreas Schwab
2009-09-27 7:29 ` Eli Zaretskii
2009-09-27 7:37 ` Andreas Schwab
2009-09-27 10:35 ` Eli Zaretskii
2009-09-27 11:13 ` Andreas Schwab
2009-09-27 12:39 ` Richard Stallman
2009-09-26 21:04 ` Stefan Monnier
2009-09-27 7:28 ` Eli Zaretskii
2009-09-27 18:12 ` Stefan Monnier
2009-09-27 19:09 ` Eli Zaretskii
2009-09-27 22:55 ` Stefan Monnier
2009-09-26 14:07 ` Stefan Monnier
2009-09-26 16:19 ` Eli Zaretskii
2009-09-26 16:45 ` Dan Nicolaescu
2009-09-26 16:53 ` Chong Yidong
2009-09-26 21:03 ` Stefan Monnier
2009-09-29 9:19 ` Carsten Dominik
2009-09-26 21:01 ` Stefan Monnier
2009-09-28 3:43 ` Richard Stallman
2009-09-28 6:36 ` Eli Zaretskii
2009-09-28 21:58 ` Richard Stallman
2009-09-28 22:10 ` joakim
2009-09-28 22:15 ` Chong Yidong
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.