Filename problem in CEDET merge

Filename problem in CEDET merge

[Chong Yidong]

While working on the CEDET merge, I've come across a problem with the
8+3 filename restriction.

Semantic, CEDET's parser library, contains filenames that look like
this:

 semantic.el
 semantic-analyze.el
 semantic-analyze-complete.el
 semantic-analyze-debug.el

These clearly break the 8+3 limit.  In the past, we've dealt with this
by renaming files, e.g. shortening "semantic" to "sem", but even this
fails:

 sem-analyze.el
 sem-analyze-complete.el
 sem-analyze-debug.el

Renaming would also have the extremely bad effect of diverging from the
CEDET upstream, which I'd like to avoid if possible.

Does anyone have suggestions for resolving this problem?  As far as
possible, it should remain possible to untar and compile Emacs on DOS,
though it's acceptable if the CEDET library doesn't work on DOS.

Re: Filename problem in CEDET merge

[Eric M. Ludlam]

Hi,

  First, I just want to say, that if needed, I don't mind doing some
renames to simplify maintenance.  As for having CEDET not work on DOS, I
suppose that is up to the folks who use DOS.

Alternately, here is an experiment you can try.  If the directory

~/lisp

  is in your load path, and you create:

~/lisp/hack/fooble.el

  with the contents:

-----------
; A hack.
(provide 'hack/fooble)
-----------

then you can do this:

(require 'hack/fooble)

and Emacs finds it and loads it.  This could be a magic way to have
"long" file names on DOS.  Just providing 'fooble won't work.

My preference, of course, is the current naming convention, but this
might work too.

Eric

On Thu, 2009-08-27 at 18:50 -0400, Chong Yidong wrote:
> While working on the CEDET merge, I've come across a problem with the
> 8+3 filename restriction.
> 
> Semantic, CEDET's parser library, contains filenames that look like
> this:
> 
>  semantic.el
>  semantic-analyze.el
>  semantic-analyze-complete.el
>  semantic-analyze-debug.el
> 
> These clearly break the 8+3 limit.  In the past, we've dealt with this
> by renaming files, e.g. shortening "semantic" to "sem", but even this
> fails:
> 
>  sem-analyze.el
>  sem-analyze-complete.el
>  sem-analyze-debug.el
> 
> Renaming would also have the extremely bad effect of diverging from the
> CEDET upstream, which I'd like to avoid if possible.
> 
> Does anyone have suggestions for resolving this problem?  As far as
> possible, it should remain possible to untar and compile Emacs on DOS,
> though it's acceptable if the CEDET library doesn't work on DOS.
> 
> 

Re: Filename problem in CEDET merge

[Eli Zaretskii]

> From: "Eric M. Ludlam" <eric@siege-engine.com>
> Date: Thu, 27 Aug 2009 22:26:42 -0400
> Cc: zappo@gnu.org, emacs-devel@gnu.org
> 
>   First, I just want to say, that if needed, I don't mind doing some
> renames to simplify maintenance.

Thank you.  Would doing it as I suggested in my other mail be
acceptable to you?

> As for having CEDET not work on DOS, I suppose that is up to the
> folks who use DOS.

I would like CEDET to work on DOS, unless it uses networking or async
subprocesses in its core features.

> ; A hack.
> (provide 'hack/fooble)
> -----------
> 
> then you can do this:
> 
> (require 'hack/fooble)
> 
> and Emacs finds it and loads it.  This could be a magic way to have
> "long" file names on DOS.  Just providing 'fooble won't work.

This might work for `require', but I don't think it will work for
`load' (e.g., in ~/.emacs).

Re: Filename problem in CEDET merge

[Eric M. Ludlam]

On Fri, 2009-08-28 at 12:45 +0300, Eli Zaretskii wrote:
> > From: "Eric M. Ludlam" <eric@siege-engine.com>
> > Date: Thu, 27 Aug 2009 22:26:42 -0400
> > Cc: zappo@gnu.org, emacs-devel@gnu.org
> > 
> >   First, I just want to say, that if needed, I don't mind doing some
> > renames to simplify maintenance.
> 
> Thank you.  Would doing it as I suggested in my other mail be
> acceptable to you?

My concern with your other method is that we'd end up with some pretty
generic file names and no way to know that they are related to this
package by name alone.  (ie, the require statement might say:

(require 'analyze)

which doesn't say too much, where as

(require 'semantic/analyze)

does, which is why I proposed the below.

> > As for having CEDET not work on DOS, I suppose that is up to the
> > folks who use DOS.
> 
> I would like CEDET to work on DOS, unless it uses networking or async
> subprocesses in its core features.
> 
> > ; A hack.
> > (provide 'hack/fooble)
> > -----------
> > 
> > then you can do this:
> > 
> > (require 'hack/fooble)
> > 
> > and Emacs finds it and loads it.  This could be a magic way to have
> > "long" file names on DOS.  Just providing 'fooble won't work.
> 
> This might work for `require', but I don't think it will work for
> `load' (e.g., in ~/.emacs).

Load still works with my example, as:

(load "hack/fooble")

I recognize that this is non-standard, and if it is not appropriate
because of that, that's fine.  Since no-one uses it this way, I don't
doubt that there are bugs hiding here too, so there is a risk to taking
this tactic.

Thanks
Eric

Re: Filename problem in CEDET merge

[Miles Bader]

"Eric M. Ludlam" <eric@siege-engine.com> writes:
>> > (provide 'hack/fooble)
....
>> > (require 'hack/fooble)
>> > 
>> > and Emacs finds it and loads it.  This could be a magic way to have
>> > "long" file names on DOS.  Just providing 'fooble won't work.
>> 
>> This might work for `require', but I don't think it will work for
>> `load' (e.g., in ~/.emacs).
>
> Load still works with my example, as:
>
> (load "hack/fooble")

This is excellent -- it seems to work great when I tried it for
load/require/provide.  It seems a _much_ better method for shortening
filenames than the "painfully contrived cryptic abbreviations" method
we've used previously.

In addition, it actually makes the source tree look better:  Redundant
prefixes on every file in a package are ugly even when the filesystem
can deal with the extra length, but I thought they were required to make
require/provide work -- but as you point out, maybe not...!

If we're going to group all the files for a package in a subdirectory
anyway, why not take advantage of that structure?

-Miles

-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: Filename problem in CEDET merge

[Eli Zaretskii]

> From: "Eric M. Ludlam" <eric@siege-engine.com>
> Cc: cyd@stupidchicken.com, zappo@gnu.org, emacs-devel@gnu.org
> Date: Fri, 28 Aug 2009 07:16:00 -0400
> 
> > > (require 'hack/fooble)
> > > 
> > > and Emacs finds it and loads it.  This could be a magic way to have
> > > "long" file names on DOS.  Just providing 'fooble won't work.
> > 
> > This might work for `require', but I don't think it will work for
> > `load' (e.g., in ~/.emacs).
> 
> Load still works with my example, as:
> 
> (load "hack/fooble")

Perhaps I don't understand your suggestion.  Can you please tell how
will this work with the original files in CEDET that prompted Yidong
to start this thread?

Re: Filename problem in CEDET merge

[Eric M. Ludlam]

On Fri, 2009-08-28 at 16:33 +0300, Eli Zaretskii wrote:
> > From: "Eric M. Ludlam" <eric@siege-engine.com>
> > Cc: cyd@stupidchicken.com, zappo@gnu.org, emacs-devel@gnu.org
> > Date: Fri, 28 Aug 2009 07:16:00 -0400
> > 
> > > > (require 'hack/fooble)
> > > > 
> > > > and Emacs finds it and loads it.  This could be a magic way to have
> > > > "long" file names on DOS.  Just providing 'fooble won't work.
> > > 
> > > This might work for `require', but I don't think it will work for
> > > `load' (e.g., in ~/.emacs).
> > 
> > Load still works with my example, as:
> > 
> > (load "hack/fooble")
> 
> Perhaps I don't understand your suggestion.  Can you please tell how
> will this work with the original files in CEDET that prompted Yidong
> to start this thread?

Sure,

  The file set like this:

semantic.el
semantic-lex.el
semantic-analyze.el
semantic-analyze-debug.el
semantic-analyze-fcn.el
semantic-analyze-refs.el

would end up as:

semantic.el
semantic/lex.el
semantic/analyze.el
semantic/analyze/debug.el
semantic/analyze/fcn.el
semantic/analyze/refs.el

which would show up in requires as:

(require 'semantic)
(require 'semantic/lex)
(require 'semantic/analyze)
(require 'semantic/analyze/debug.el)
(require 'semantic/analyze/fcn)
(require 'semantic/analyze/refs)

but this code would not work:

(require 'lex)
(require 'fcn)

because those other directories would not be on the path.

Eric

Re: Filename problem in CEDET merge

[Eli Zaretskii]

> From: "Eric M. Ludlam" <eric@siege-engine.com>
> Cc: cyd@stupidchicken.com, zappo@gnu.org, emacs-devel@gnu.org
> Date: Fri, 28 Aug 2009 09:55:57 -0400
> 
> semantic.el
> semantic/lex.el
> semantic/analyze.el
> semantic/analyze/debug.el
> semantic/analyze/fcn.el
> semantic/analyze/refs.el
> 
> which would show up in requires as:
> 
> (require 'semantic)
> (require 'semantic/lex)
> (require 'semantic/analyze)
> (require 'semantic/analyze/debug.el)
> (require 'semantic/analyze/fcn)
> (require 'semantic/analyze/refs)

Ah, that's fine with me, of course.  It's similar to what I suggested,
but with the additional advantage of being specific in `require'.

Thanks.

Re: Filename problem in CEDET merge

[Chong Yidong]

Eli Zaretskii <eliz@gnu.org> writes:

>> semantic.el
>> semantic/lex.el
>> semantic/analyze.el
>> semantic/analyze/debug.el
>> semantic/analyze/fcn.el
>> semantic/analyze/refs.el
>> 
>> which would show up in requires as:
>> 
>> (require 'semantic)
>> (require 'semantic/lex)
>> (require 'semantic/analyze)
>> (require 'semantic/analyze/debug.el)
>> (require 'semantic/analyze/fcn)
>> (require 'semantic/analyze/refs)
>
> Ah, that's fine with me, of course.  It's similar to what I suggested,
> but with the additional advantage of being specific in `require'.

Good, then that's the approach we'll take.

Re: Filename problem in CEDET merge

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

>>> semantic.el
>>> semantic/lex.el
>>> semantic/analyze.el
>>> semantic/analyze/debug.el
>>> semantic/analyze/fcn.el
>>> semantic/analyze/refs.el
>>>
>>> which would show up in requires as:
>>>
>>> (require 'semantic)
>>> (require 'semantic/lex)
>>> (require 'semantic/analyze)
>>> (require 'semantic/analyze/debug.el)
>>> (require 'semantic/analyze/fcn)
>>> (require 'semantic/analyze/refs)
>>
>> Ah, that's fine with me, of course.  It's similar to what I suggested,
>> but with the additional advantage of being specific in `require'.
>
> Good, then that's the approach we'll take.

One minor disadvantage of this approach, BTW, is that we'll need to
revise our byte-compilation process.  Otherwise the semantic/foo.el
files won't be byte-compiled during "make bootstrap" or "make
recompile".  But this change probably isn't difficult.

Re: Filename problem in CEDET merge

[Andreas Schwab]

Chong Yidong <cyd@stupidchicken.com> writes:

> One minor disadvantage of this approach, BTW, is that we'll need to
> revise our byte-compilation process.  Otherwise the semantic/foo.el
> files won't be byte-compiled during "make bootstrap" or "make
> recompile".  But this change probably isn't difficult.

Shouldn't be much different from the term/*.el case.

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: Filename problem in CEDET merge

[Stefan Monnier]

> Load still works with my example, as:
> (load "hack/fooble")
> I recognize that this is non-standard, and if it is not appropriate
> because of that, that's fine.  Since no-one uses it this way, I don't
> doubt that there are bugs hiding here too, so there is a risk to taking
> this tactic.

It may not be the most standard way to load a file, but I know it's used
at various places, most notably for the term/$TERM.el files.  Bugs in
this area seem *very* unlikely to me, and would need to be fixed.


        Stefan

Re: Filename problem in CEDET merge

[Eli Zaretskii]

> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Thu, 27 Aug 2009 18:50:20 -0400
> Cc: zappo@gnu.org
> 
> While working on the CEDET merge, I've come across a problem with the
> 8+3 filename restriction.
> 
> Semantic, CEDET's parser library, contains filenames that look like
> this:
> 
>  semantic.el
>  semantic-analyze.el
>  semantic-analyze-complete.el
>  semantic-analyze-debug.el
> 
> These clearly break the 8+3 limit.  In the past, we've dealt with this
> by renaming files, e.g. shortening "semantic" to "sem", but even this
> fails:
> 
>  sem-analyze.el
>  sem-analyze-complete.el
>  sem-analyze-debug.el

How about making a subdirectory, in addition to shortening?

 semantic.el                    --> semantic/semantic.el
 semantic-analyze.el            --> semantic/analyze.el
 semantic-analyze-complete.el   --> semantic/analyz-complete.el
 semantic-analyze-debug.el      --> semantic/analyz-debug.el

> Renaming would also have the extremely bad effect of diverging from the
> CEDET upstream, which I'd like to avoid if possible.

Maybe the upstream maintainer will agree to rename, in which case we
don't diverge.

> Does anyone have suggestions for resolving this problem?

Any other solution would mean more work.  We could implement some
file-name remapping feature, for example, whereby Emacs looks up a map
of file names and loads/visits the target of the mapping.  But I
wouldn't even dream requesting such a development effort on behalf of
the DOS port; renaming is so much easier, and is a one-time effort.

> As far as possible, it should remain possible to untar and compile
> Emacs on DOS, though it's acceptable if the CEDET library doesn't
> work on DOS.

Why would it be acceptable for CEDET not to work on DOS?  Up until
now, the only Emacs features that didn't work were those which were
based on infrastructure absent on DOS: networking and async
subprocesses.  It doesn't make sense to me to continue maintaining the
DOS port if we start omitting useful features from it based on
file-name clashes or such likes.

Re: Filename problem in CEDET merge

[Stefan Monnier]

> How about making a subdirectory, in addition to shortening?

>  semantic.el                    --> semantic/semantic.el
>  semantic-analyze.el            --> semantic/analyze.el
>  semantic-analyze-complete.el   --> semantic/analyz-complete.el
>  semantic-analyze-debug.el      --> semantic/analyz-debug.el

That would be OK, as long as we're careful to to add .../semantic to
load-path (otherwise we'd have to be careful to avoid conflicts between
semantic/foo.el and other foo.el packages).

>> Renaming would also have the extremely bad effect of diverging from the
>> CEDET upstream, which I'd like to avoid if possible.
> Maybe the upstream maintainer will agree to rename, in which case we
> don't diverge.

Yes, I think the only acceptable solutions require the upstream version
to apply the same changes.


        Stefan

Re: Filename problem in CEDET merge

[Leo]

On 2009-08-27 23:50 +0100, Chong Yidong wrote:
> Semantic, CEDET's parser library, contains filenames that look like
> this:
>
>  semantic.el
>  semantic-analyze.el
>  semantic-analyze-complete.el
>  semantic-analyze-debug.el
>
> These clearly break the 8+3 limit.  In the past, we've dealt with this
> by renaming files, e.g. shortening "semantic" to "sem", but even this
> fails:
>
>  sem-analyze.el
>  sem-analyze-complete.el
>  sem-analyze-debug.el

It seems renaming is best way forward. However,

The CEDET package has been in existence for over a decade and probably
has long names for quite a while and yet no complaint has been made to
its developers in that time. It seems premature to shorten the file
names now. And the DOS folks most likely already have their solutions to
what CEDET is trying to offer.

Short names such as hilit for highlight create language noise. It
appears to be a proper word but it is not.

-- 
Leo's Emacs uptime: 5 days, 17 hours, 21 minutes, 40 seconds

Re: Filename problem in CEDET merge

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Fri, 28 Aug 2009 13:14:53 +0100
> 
> The CEDET package has been in existence for over a decade and probably
> has long names for quite a while and yet no complaint has been made to
> its developers in that time. It seems premature to shorten the file
> names now. And the DOS folks most likely already have their solutions to
> what CEDET is trying to offer.

You can say the same about any other changes we will do as part of
adding CEDET to Emacs.  They all have been part of CEDET for many
years, but we still make those changes.

Emacs has certain standards that each included package needs to adhere
to.  Being 8+3 clean is one of them.

> Short names such as hilit for highlight create language noise. It
> appears to be a proper word but it is not.

There's no problem with having very long file names in Emacs; we
already have quite a lot of them.  Only file names that clash after
8+3 truncation are a problem.