Files in wrong subdirs of emacs/lisp?

Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

Can anyone suggest Lisp files that ought to be moved to a different
place under the `lisp' directory?

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Wed, 14 May 2003 09:48:55 -0400, Richard Stallman <rms@gnu.org> wrote:

> Can anyone suggest Lisp files that ought to be moved to a different
> place under the `lisp' directory?

options.el, emacs-lisp/float.el and emacs-lisp/lmenu.el could be moved
to lisp/obsolete, IMHO.

                                                           /L/e/k/t/u

Re: Files in wrong subdirs of emacs/lisp?

[Stefan Monnier]

> > Can anyone suggest Lisp files that ought to be moved to a different
> > place under the `lisp' directory?
> 
> options.el, emacs-lisp/float.el and emacs-lisp/lmenu.el could be moved
> to lisp/obsolete, IMHO.

Agreed.  Same thing for `tcp.el'.


	Stefan


PS: I was recently thinking that we could create a `version-control'
    or `vc' subdirectory where we could put vc*.el, pcvs*.el, ediff*.el
    diff*.el, log-*.el, cvs-status.el, smerge-mode.el, add-log.el.

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

> > options.el, emacs-lisp/float.el and emacs-lisp/lmenu.el could be moved
> > to lisp/obsolete, IMHO.
> 
> Agreed.

unused.el should perhaps be moved too.

What about other Lucid-related modules?

  emacs-lisp/levents
  emacs-lisp/lselect
  emacs-lisp/lucid

Other posible candidates to obsolescence (but I don't really know
whether they're currently used or not, they just seem to me to be
scarcely useful *and* not very frequently maintained):

  cdl
  chistory
  ebuff-menu
  echistory
  float-sup
  ledit
  misc
  reposition
  soundex
  emacs-lisp/tq
  progmodes/mantemp
  textmodes/scribe
  net/rcompile

> PS: I was recently thinking that we could create a `version-control'
>     or `vc' subdirectory where we could put vc*.el, pcvs*.el, ediff*.el
>     diff*.el, log-*.el, cvs-status.el, smerge-mode.el, add-log.el.

Yeah, that'd be good.

My personal preference would be to create at least two more subdirs, one
for things related to abbreviation, expansion and things like that:

  abbrev
  complete
  completion
  dabbrev
  expand
  hippie-exp
  icomplete
  pcmpl*
  pcomplete
  tempo ?
  thingatpt ?
  repeat ?
  skeleton ?
  emacs-lisp/crm

and another one for utilities whose function is to make easier moving
among files or buffers, and loading files:

  bs
  bookmark
  desktop ?
  dired* ?
  find-dired
  find-file ?
  finder ?
  filecache
  filesets
  ffap
  ibuf*
  ido
  info* ?
  iswitchb
  msb
  recentf
  saveplace
  speedbar

Both lists are highly tentative, of course.

                                                                Juanma

Re: Files in wrong subdirs of emacs/lisp?

[Kai Großjohann]

Juanma Barranquero <jmbarranquero@laley.wke.es> writes:

>   reposition

I use C-M-l from time to time.  Is there some more modern facility
that can be used in its place?
-- 
This line is not blank.

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Wed, 21 May 2003 09:50:54 +0200
kai.grossjohann@gmx.net (Kai Großjohann) wrote:

> I use C-M-l from time to time.  Is there some more modern facility
> that can be used in its place?

No that I know of... so reposition can be taken out the list ;)

Seriously: the list was just a bunch of files off the top of my head,
not a deep analysis by any long shot, so surely there are some of these
modules that aren't obsolete, just perfect :) and so unchanged for a
long while.

But it does seem hard to imagine that current Emacs runs in non-floating
point-supporting machines, isn't it? (vide lisp/float-sup.el)

                                                                Juanma

Re: Files in wrong subdirs of emacs/lisp?

[Robert J. Chassell]

    But it does seem hard to imagine that current Emacs runs in
    non-floating point-supporting machines, isn't it? (vide
    lisp/float-sup.el)

Why is it so hard to imagine?

My understanding is that some of the currently popular small devices
do not support floating point.  I do not know for sure, but if true,
then potentially, millions of people could use such an Emacs.

(These small machines do not have much capacity, so I imagine that
developers would include just those parts of Emacs that they need.  At
one point, I reduced the Emacs 18 footprint to 300 kilobytes for a
version that did what *I* mostly used.  So I know that Emacs can be
made small, and still be useable.

(I do not know the current minimal footprint for version 21, but
likely it is below the 1.8 megabytes total memory on the Atari ST that
Diane Barlow Close used for writing a good bit of GNU documentation.
As far as I know, the current small machines generally have more than
2 megabytes of memory, so they should have the physical capability to
run a small machine Emacs.)

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             bob@rattlesnake.com

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Wed, 21 May 2003 08:32:00 -0400 (EDT)
"Robert J. Chassell" <bob@rattlesnake.com> wrote:

> Why is it so hard to imagine?

A lack of imagination on my part, I suppose :)

> My understanding is that some of the currently popular small devices
> do not support floating point.  I do not know for sure, but if true,
> then potentially, millions of people could use such an Emacs.
> 
> (These small machines do not have much capacity, so I imagine that
> developers would include just those parts of Emacs that they need.  At
> one point, I reduced the Emacs 18 footprint to 300 kilobytes for a
> version that did what *I* mostly used.  So I know that Emacs can be
> made small, and still be useable.

Yes, if Emacs were to be compiled for Windows CE, Windows for Smartphone,
Symbian, EPOC or PalmOS, checking for floating-point support would be
useful.

I'd bet, though, that these systems (and the hardware they run on) will
support floating point long before someone takes the pain to trying
compiling Emacs for them... You're talking about Emacs 18, and the
changes in the CVS are for Emacs 22 (or 21.5 at the very least). I don't
think the current CVS sources are nowhere near configurable enough to be
easily downsized to such small machines... And if posible, well,
lisp/obsolete/float-sup.el is not much farther away than
lisp/float-sup.el, isn't it?

Just my .02€
                                                                Juanma



Note: However, I must insist again: My list wasn't "hey, guys, let's go
obsolete these modules", but more like "hey, does someone know if
they're still useful and maintained?" I have no interest whatsoever in
obsoleting or not obsoleting any of them, other than tidying up the
current lisp/ hierarchy.

Re: Files in wrong subdirs of emacs/lisp?

[Miles Bader]

On Wed, May 21, 2003 at 08:32:00AM -0400, Robert J. Chassell wrote:
> My understanding is that some of the currently popular small devices
> do not support floating point.

Yeah, but such machines also typically have software floating point support
handled transparently by the compiler/C-runtime, so emacs probably doesn't
need to worry about it.

[This is especially true of any machine/compiler combination that emacs is
likely to run on.]

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    My understanding is that some of the currently popular small devices
    do not support floating point.  I do not know for sure, but if true,
    then potentially, millions of people could use such an Emacs.

Nowadays GCC provides emulated floating point even if the machine
does not support it.

Re: Files in wrong subdirs of emacs/lisp?

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     My understanding is that some of the currently popular small
>     devices do not support floating point.  I do not know for sure,
>     but if true, then potentially, millions of people could use such
>     an Emacs.
> 
> Nowadays GCC provides emulated floating point even if the machine
> does not support it.

But on embedded devices one might not particularly cherish the
program space taken up by floating point emulation routines that you
might never need.  And on some of those small devices, gcc might not
be available.

I don't know whether this is relevant compared to the size and
availability of Emacs overall, but it might be something to keep in
mind.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Files in wrong subdirs of emacs/lisp?

[Stefan Monnier]

> >     My understanding is that some of the currently popular small
> >     devices do not support floating point.  I do not know for sure,
> >     but if true, then potentially, millions of people could use such
> >     an Emacs.
> > 
> > Nowadays GCC provides emulated floating point even if the machine
> > does not support it.
> 
> But on embedded devices one might not particularly cherish the
> program space taken up by floating point emulation routines that you
> might never need.  And on some of those small devices, gcc might not
> be available.
> 
> I don't know whether this is relevant compared to the size and
> availability of Emacs overall, but it might be something to keep in
> mind.

I don't think it's relevant.
I also don't think that float.el is what people would use if they want
Emacs to support floating point (it's probably more efficient to use a libc
or libm implementation instead).  Finally, I seriously doubt that Emacs
as it currently stands can be built without floating point support.

Looks like we need a reality check here.

If someone wants to get a "float-free Emacs" working, fetching float.el
from the obsolete subdirectory (or even from a tarball of an old
Emacs version) will be the least of the guy's worries.


	Stefan

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    What about other Lucid-related modules?

      emacs-lisp/levents
      emacs-lisp/lselect
      emacs-lisp/lucid

I think these are still useful for their original purposes.
Do you know of some reason to think they are obsolete?

    Other posible candidates to obsolescence (but I don't really know
    whether they're currently used or not, they just seem to me to be
    scarcely useful *and* not very frequently maintained):

I don't know any reason to consider them obsolete.

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Wed, 21 May 2003 11:30:59 -0400
Richard Stallman <rms@gnu.org> wrote:

> I think these are still useful for their original purposes.
> Do you know of some reason to think they are obsolete?

No. That's why I asked.

> I don't know any reason to consider them obsolete.

Well, me neither, exactly, but:

 - ledit.el is for a Franz Lisp circa 1985. Is still useful/used?

 - misc.el contains just one editing command (from 1989). If it is
useful, why hasn't it been moved to bindings.el, simple.el, or another
appropriate module?

 - What about unused.el? (I forgot to mention it in my previous message).
A file whose description says "editing commands in GNU Emacs that turned
out not to be used" and with no significant revision ever should be a
candidate for obsolescence, shouldn't it?

- progmodes/mantemp.el's description says "create manual template
instantiations from g++ 2.7.2 output". Last significant change was six
years ago... Either the description is unexact (and should perhaps refer
to more recent GCCs) or the module is outdated. Even with GCC's
outstanding back-compatibility is difficult to believe its output wrt
templates hasn't changed in six years. But I can be wrong, of course.

 - textmodes/scribe.el: If I undestand correctly, is from 1985, for a
VAX text formater, and the last significant changes were from 8 years
ago. It is still used by someone?

 - emacs-lisp/tq.el: I don't doubt it's useful, but is not used anywhere
in Emacs (that I can see), and from a cursory search in Google it
doesn't seem to be much used outside either.

                                                                Juanma

Re: Files in wrong subdirs of emacs/lisp?

[Thien-Thi Nguyen]

Juanma Barranquero <jmbarranquero@laley.wke.es> writes:

   It is still used by someone?

this can never be answered reliably by the people on this list.

thi

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On 22 May 2003 07:04:36 -0400
Thien-Thi Nguyen <ttn@glug.org> wrote:

>    It is still used by someone?
> 
> this can never be answered reliably by the people on this list.

Unless the answer is "yes", you mean? :-)

But more seriously, the question remains: do we obsolete code only when
it's superseeded by other code, or there are ways to obsolete code that
supports old systems (tools, operating systems, whatever) if we think
it's probably not used anymore? Taking into account that, currently,
obsoleting a lisp module is nothing more than moving it to obsolete/;
there's no clear directive about when, if ever, obsolete/*.el are going
to be deleted from the distribution.


                                                                Juanma

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    But more seriously, the question remains: do we obsolete code only when
    it's superseeded by other code, or there are ways to obsolete code that
    supports old systems (tools, operating systems, whatever) if we think
    it's probably not used anymore?

We can call something obsolete when we have positive reason to believe
it is *not useful* any more.

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Fri, 23 May 2003 18:49:04 -0400, Richard Stallman <rms@gnu.org> wrote:

> We can call something obsolete when we have positive reason to believe
> it is *not useful* any more.

Perhaps it's just semanthics, but I wouldn't call "still useful"
to something if no one uses it.


                                                           /L/e/k/t/u

Re: Files in wrong subdirs of emacs/lisp?

[Thien-Thi Nguyen]

   From: Juanma Barranquero <lektu@terra.es>
   Date: Sat, 24 May 2003 14:38:41 +0200

   Perhaps it's just semanthics, but I wouldn't call "still useful"
   to something if no one uses it.

in the context of providing things "useful" indicates only potentiality.
in the context of using things "useful" indicates some (perhaps large)
amount of actual use.  because not all users are represented in these
discussions, we cannot assume the latter context holds.  if you purport
to represent all users you lose credibility.

something can be rendered "not useful" in the providing context if it is
not cleanly composable w/ other provided things or if there is a clear
bug in it standalone, in which case we have the option of fixing these
problems in order to return it to a "useful" state (but that's still
only a potential wrt the other context).

thi

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Sat, 24 May 2003 08:49:31 -0400, Thien-Thi Nguyen <ttn@glug.org> wrote:

> in the context of providing things "useful" indicates only potentiality.
> in the context of using things "useful" indicates some (perhaps large)
> amount of actual use.

Of course.

> because not all users are represented in these
> discussions, we cannot assume the latter context holds.  if you purport
> to represent all users you lose credibility.

I sincerely hope that "you" is meant as generic and you're not
suggesting I did such a thing.

So, assuming the generic, what you're saying is that we can *never*
obsolete anything, because we can never be sure there's no "some amount
of actual use". Funnily enough, in the 21.X series we've declared
obsolete at least 40 functions and variables without too much worring
about the actual amount of use...

> something can be rendered "not useful" in the providing context if it is
> not cleanly composable w/ other provided things or if there is a clear
> bug in it standalone, in which case we have the option of fixing these
> problems in order to return it to a "useful" state (but that's still
> only a potential wrt the other context).

I think you're being way too "philosophical" for something as
unconsecuential as deciding if some modules should be in lisp/ or
lisp/obsolete/. Even if we moved some files to obsolete/, users wouldn't
see any difference (obsolete is in subdirs.el). Emacs still has
variables and functions that were deemed obsolete "before 19.15" (dot*,
baud-rate, buffer-flush-undo...), so it's not like we're going to empty
obsolete/ any century now.

This is getting ridiculous. RMS asked about alternate locations for modules.
I've suggested some. Others don't like. That's all there is.

                                                           /L/e/k/t/u

Re: Files in wrong subdirs of emacs/lisp?

[Thien-Thi Nguyen]

   From: Juanma Barranquero <lektu@terra.es>
   Date: Sat, 24 May 2003 15:21:27 +0200

   I think you're being way too "philosophical" [...]

forgive me, i have difficulty balancing philosophy and practice
sometimes.  feel free to ignore me.

thi

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    Perhaps it's just semanthics, but I wouldn't call "still useful"
    to something if no one uses it.

I disagree with you; if something is unused but potentially useful,
we should not delete it.

The whole idea is purely academic, because we have no empirical
way to determine that any feature is unused.  So we don't try.
We don't make our decisions about what is obsolete in that way.

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

     - ledit.el is for a Franz Lisp circa 1985. Is still useful/used?

I don't know.  We cannot tell just by thinking abstractly.

     - misc.el contains just one editing command (from 1989). If it is
    useful, why hasn't it been moved to bindings.el, simple.el, or another
    appropriate module?

You can't argue that a command is useless because of which file it is
in.  The reason we have not moved it is that we had no reason to move
it.  It is ok where it is.

misc.el might be a good place to put other editing commands that
someone wants to install but that don't need to be loaded by default,
such as zap-up-to-char.

    - progmodes/mantemp.el's description says "create manual template
    instantiations from g++ 2.7.2 output". Last significant change was six
    years ago.

This might be obsolete.  It would be useful to ask the GCC maintainers
whether it still works.  If it has broken, it might be better to fix 
it than to delete it.  I don't know--I have never used C++.

    Even with GCC's
    outstanding back-compatibility is difficult to believe its output wrt
    templates hasn't changed in six years.

The output in question is error messages, not code.  These error
messages may indeed be unchanged in 6 years.

     - textmodes/scribe.el: If I undestand correctly, is from 1985, for a
    VAX text formater, and the last significant changes were from 8 years
    ago. It is still used by someone?

Scribe had nothing in particular to do with the Vax, but it may
be obsolete.  So this Lisp package may be obsolete.

     - emacs-lisp/tq.el: I don't doubt it's useful, 

If the feature is useful, then it is not obsolete.
						    
						    but is not used anywhere
    in Emacs (that I can see), and from a cursory search in Google it
    doesn't seem to be much used outside either.

That is not a reason to call something obsolete.

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Fri, 23 May 2003 08:05:31 -0400
Richard Stallman <rms@gnu.org> wrote:

> misc.el might be a good place to put other editing commands that
> someone wants to install but that don't need to be loaded by default,
> such as zap-up-to-char.

That I would understand. I was not arguing about the precise command
contained in misc, but the fact that having a file in lisp/ for a single
command, and not a very complicated or idiosyncratic one, is weird.

> The output in question is error messages, not code.  These error
> messages may indeed be unchanged in 6 years.

Yeah, I know is error messages. Still I'd be surprised. I follow the GCC
list, and changes to error messages and warnings are often hot topics.

>      - emacs-lisp/tq.el: I don't doubt it's useful, 
> 
> If the feature is useful, then it is not obsolete.

Ok. Still, I fail to grasp why you sometimes oppose adding a five-line
function as "cruft", and at some other moment support maintaining a
module no one is sure it's used anywhere :)

> That is not a reason to call something obsolete.

<sigh> I haven't called (almost) anything obsolete. I've asked if some
mdules where or not, and stated why I thought they perhaps were...

What about unused.el?

                                                                Juanma

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    > The output in question is error messages, not code.  These error
    > messages may indeed be unchanged in 6 years.

    Yeah, I know is error messages. Still I'd be surprised. I follow the GCC
    list, and changes to error messages and warnings are often hot topics.

It would be useful to find out

1. Whether the job done by that file is still necessary.
   If the answer to #1 is no, then the file is obsolete.

2. Whether the file still works.
   If the answer to #2 is no, then the file could use fixing.

3. If the answers are Yes and No, who would like
   to update the file.

    Ok. Still, I fail to grasp why you sometimes oppose adding a five-line
    function as "cruft", and at some other moment support maintaining a
    module no one is sure it's used anywhere :)

A separate file that normally isn't loaded costs very little.
Added text in an existing file makes it more complicated.
Added text in an existing preloaded file also makes the executable bigger.

    What about unused.el?

Maybe combine it with misc.el.

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Sat, 24 May 2003 19:18:54 -0400, Richard Stallman <rms@gnu.org> wrote:

> It would be useful to find out
> 
> 1. Whether the job done by that file is still necessary.
>    If the answer to #1 is no, then the file is obsolete.
> 
> 2. Whether the file still works.
>    If the answer to #2 is no, then the file could use fixing.
> 
> 3. If the answers are Yes and No, who would like
>    to update the file.

Asking the author (Tom Houlder <thoulder@icor.fr>), if he's still around,
would be the best way to find out, I'd say. (Not sure if he's the same
Tom Houlder from http://c2.com/cgi/wiki?TomHoulder)

> A separate file that normally isn't loaded costs very little.

In run time or exe size metrics, sure. But every single file added to
lisp/ (or src/ or whatever) adds complexity that has to be handled
somehow.

>     What about unused.el?
> 
> Maybe combine it with misc.el.

Well, at least that way we'll have one file for
probably-not-used-by-anyone elisp functions instead of two ;-)


                                                           /L/e/k/t/u

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    My personal preference would be to create at least two more subdirs, one
    for things related to abbreviation, expansion and things like that:

That isn't enough files to be a good subdir.  We don't want to
accumulate lots of small subdirectories.

    and another one for utilities whose function is to make easier moving
    among files or buffers, and loading files:

That one may be big enough, but the description of the category
doesn't seem coherent--I don't see that things really fit together.
It seems to be a number of different categories, not really a single
one.

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Wed, 21 May 2003 11:31:00 -0400
Richard Stallman <rms@gnu.org> wrote:

> That isn't enough files to be a good subdir.

That's 18 files, more or less. Certainly less than gnus' whopping 151
non-.elc files, but more than mh-e/ (15) or obsolete/ (16) :)

> We don't want to accumulate lots of small subdirectories.

It's your call, of course. I personaly would prefer (small or large)
subdirectories rather than having 288 non-.elc files in lisp/.

> That one may be big enough, but the description of the category
> doesn't seem coherent--I don't see that things really fit together.
> It seems to be a number of different categories, not really a single
> one.

Yes, I agree. That's why I had never proposed it.

Still, current structure isn't that coherent either.

For example, textmodes/ leaves out allout.el and foldout.el even if it
has outline.el. And includes artist.el, picture.el and page-ext.el, that
don't seem to much "textmode" related to me (no connection with nroff,
ispell, makeinfo, fill, et al).

emacs-lisp/ doesn't seem too coherent either. It seems to try to be:

 - for emacs-lisp implementation: assoc.el, backquote.el, byte-opt.el,
   bytecomp.el, cl-*.el, cust-print.el, float.el, ring.el.

 - for compatibility: levents.el, lmenu.el, lselect.el, lucid.el.

 - for relatively low-level lisp mechanisms: advice.el, debug.el,
   disass.el, edebug.el, elp.el, helper.el, syntax.el.

 - for emacs-lisp developers: copyright.el, benchmark.el, bindat.el,
   checkdoc.el, copyright.el, crm.el, easy-mmode.el, easymenu.el,
   eldoc.el, elint.el, ewoc.el, find-func.el, find-gc.el, lisp-mnt.el,
   lisp-mode.el, lisp.el, pp.el, regexp-opt.el, tq.el, trace.el,
   unsafep.el.

 - for Emacs maintaining: authors.el, autoload.el, gulp.el, shadow.el.

 - other: re-builder.el, rx.el, sregex.el, testcover*.el.

I fail to see what would make bytecomp.el, benchmark.el, authors.el and
re-builder.el to be on the same directory :)


                                                                Juanma

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    Still, current structure isn't that coherent either.

I think it is coherent enough.  Any categorization is likely to be
fuzzy at the boundaries--that doesn't mean the basic idea is
incoherent.

    For example, textmodes/ leaves out allout.el and foldout.el even if it
    has outline.el.

Perhaps these files are in the wrong place.  But I am not sure they
are in the wrong place.  outline.el is intended specificlally for
text, but I think allout and foldout are not specifically for text.  I
think I have seen foldout used in Lisp programs.

    emacs-lisp/ doesn't seem too coherent either.

It is less well defined than the others, but these all have a
relationship to supporting Emacs Lisp.  What you have pointed at is
that there are different kinds of support.

It could be that some other files belong in emacs-lisp which are not
there.  Perhaps subr.el.  Any others?

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Fri, 23 May 2003 08:05:40 -0400
Richard Stallman <rms@gnu.org> wrote:

> outline.el is intended specificlally for
> text, but I think allout and foldout are not specifically for text.  I
> think I have seen foldout used in Lisp programs.

Still, foldout contains "folding extensions for outline-mode and
outline-minor-mode". If foldout is not just for text, perhaps outline.el
isn't either.

> It is less well defined than the others, but these all have a
> relationship to supporting Emacs Lisp.  What you have pointed at is
> that there are different kinds of support.

re-builder.el, for example, is only vaguely related to supporting Emacs
Lisp. I use it often, but never on anything related to developing or
maintaning elisp, but as a sort of incremental occur...

> It could be that some other files belong in emacs-lisp which are not
> there.  Perhaps subr.el.  Any others?

Likely candidates IMO:

 byte-run
 derived
 float-sup (if not obsoleted)
 map-ynp
 regi
 timer
 warnings

For progmodes/, if it's deemed to contain not only programming language
*modes* but also programming language tools (as suggested by cwarn,
cmacexp, compile, cpp, ebrowse, etags, glasses, hideif, hideshow and
mantemp):

 time-stamp ?
 skeleton
 which-func

For textmodes:

  enriched



                                                                Juanma

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    Still, foldout contains "folding extensions for outline-mode and
    outline-minor-mode". If foldout is not just for text, perhaps outline.el
    isn't either.

When I wrote outline.el, I thought of it as specifically for text.
And I think it is only used for text (though I could be wrong).
Perhaps foldout.el extends it to be useful for other things.
I am not sure what foldout actually does; I never used it.

    re-builder.el, for example, is only vaguely related to supporting Emacs
    Lisp. I use it often, but never on anything related to developing or
    maintaning elisp, but as a sort of incremental occur...

Its main intended use is for maintaining the complex regexps in Lisp
programs, so it belongs in emacs-lisp.

    > It could be that some other files belong in emacs-lisp which are not
    > there.  Perhaps subr.el.  Any others?

    Likely candidates IMO:

     byte-run
     derived
     float-sup (if not obsoleted)
     map-ynp
     regi
     timer
     warnings

I agree about moving all of these to emacs-lisp.

     time-stamp ?

I don't think that has any specific relationship to editing programs,
so it doesn't belong in progmodes.

     skeleton

Is that specifically for editing programs, or is it for editing
all sorts of things?  I don't know; I never used it.

     which-func

That does seem to fit in progmodes.

    For textmodes:

      enriched

Yes.

I can't understand the doc strings in regi.el; I don't know
what job that file does.  I will ask Barry Warsaw to
write some sort of overview for it.

Re: Files in wrong subdirs of emacs/lisp?

[Stefan Monnier]

>     Still, foldout contains "folding extensions for outline-mode and
>     outline-minor-mode". If foldout is not just for text, perhaps outline.el
>     isn't either.
> 
> When I wrote outline.el, I thought of it as specifically for text.
> And I think it is only used for text (though I could be wrong).
> Perhaps foldout.el extends it to be useful for other things.
> I am not sure what foldout actually does; I never used it.

work/emacs-0% grep -l outline-regexp lisp/progmodes/*.el
lisp/progmodes/ada-mode.el
lisp/progmodes/antlr-mode.el
lisp/progmodes/cc-mode.el
lisp/progmodes/cperl-mode.el
lisp/progmodes/scheme.el
lisp/progmodes/tcl.el
work/emacs-0% 

It's also defined in lisp-mode (which is in emacs-lisp).
I also define it in sml-mode, so I expect other non-bundled packages use it
that way for programming modes.

Admittedly, for programming languages that allow/encourage the definition
of local functions, outline is a bit limited (if the headings are defined
as the function-heads, outline will believe that the end of a subfunction
is either the beginning of the next subfunction or the end of the enclosing
function :-( ).

But I use it very happily (together with reveal-mode) in elisp.


	Stefan

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    work/emacs-0% grep -l outline-regexp lisp/progmodes/*.el

Thanks for checking this.

It looks like the right thing to do is move outline.el to the main
lisp directory, where foldout.el and allout.el are.

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Sat, 24 May 2003 19:19:06 -0400, Richard Stallman <rms@gnu.org> wrote:

>      byte-run
>      derived
>      float-sup (if not obsoleted)
>      map-ynp
>      regi
>      timer
>      warnings
> 
> I agree about moving all of these to emacs-lisp.

Glad to hear.

>      skeleton
> 
> Is that specifically for editing programs, or is it for editing
> all sorts of things?  I don't know; I never used it.

Well, it says:

 ;; A very concise language extension for writing structured statement
 ;; skeleton insertion commands for programming language modes.  This
 ;; originated in shell-script mode and was applied to ada-mode's
 ;; commands which shrunk to one third.  And these commands are now
 ;; user configurable.

so yes, it's for editing programs, or at least it was initially.

                                                           /L/e/k/t/u

Re: Files in wrong subdirs of emacs/lisp?

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

>      skeleton
>
> Is that specifically for editing programs, or is it for editing
> all sorts of things?

Like tempo, I use it for SGML/XML, wikipedia and plain text files.

-- 
                                                         |      ,__o
http://www.gnu.franken.de/ke/                            |    _-\_<,
ke@suse.de (work) / keichwa@gmx.net (home)               |   (*)/'(*)

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    >      skeleton
    >
    > Is that specifically for editing programs, or is it for editing
    > all sorts of things?

    Like tempo, I use it for SGML/XML, wikipedia and plain text files.

I guess it should remain where it is.  Thanks.

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

I don't think that add-log.el, diff*, ediff* and smerge-mode fall
under the category of "version control" as we normally use the term.
Maybe we can find a somewhat more general word that does cover them.
"multiversions" perhaps?  That would also include compare-w.el.

Note that vc*.el includes vcursor.el, but that file is not related
to vc and shouldn't be moved.

Re: Files in wrong subdirs of emacs/lisp?

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> I don't think that add-log.el, diff*, ediff* and smerge-mode fall
> under the category of "version control" as we normally use the term.
> Maybe we can find a somewhat more general word that does cover them.
> "multiversions" perhaps?  That would also include compare-w.el.

How about `scm,' for `source code management'?  I thought that was a
more general term often used to talk about version control and the like.

[I guess it's a misnomer, strictly speaking, since you can obviously
use CVS etc for more than just source code, but not a serious one.]

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    > Maybe we can find a somewhat more general word that does cover them.
    > "multiversions" perhaps?  That would also include compare-w.el.

    How about `scm,' for `source code management'?

That seems less descriptive and less correct than "multiversions".

Re: Files in wrong subdirs of emacs/lisp?

[Stefan Monnier]

>     > Maybe we can find a somewhat more general word that does cover them.
>     > "multiversions" perhaps?  That would also include compare-w.el.
> 
>     How about `scm,' for `source code management'?
> 
> That seems less descriptive and less correct than "multiversions".

I don't really understand why.  SCM is indeed a widespread acronym
as far as I can tell, used along with configuration-management (which
includes SCM and adds some although I'm not 100% sure what).


	Stefan

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    I don't really understand why.  SCM is indeed a widespread acronym

I never heard of it, so I am reluctant to use it.
Also, diff.el is not "source code management"
although it is a way to deal with different versions of a file.

Re: Files in wrong subdirs of emacs/lisp?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 23 May 2003 18:47:48 -0400
> 
> Also, diff.el is not "source code management"
> although it is a way to deal with different versions of a file.

I think we should keep in mind that, if we generalize too much, almost
every Emacs package can be seen as SCM in some sense, since Emacs is
mostly used for editing program source files, and most aspects of that
are some kind of "source code management".

Perhaps that means we should not use too broad categories in this kind
of classification.

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    options.el, emacs-lisp/float.el and emacs-lisp/lmenu.el could be moved
    to lisp/obsolete, IMHO.

Why do you think lmenu.el is obsolete?

I agree about the other two.  Would someone who knows how to move
files in CVS please move them?

Re: Files in wrong subdirs of emacs/lisp?

[Juanma Barranquero]

On Tue, 20 May 2003 21:55:31 -0400
Richard Stallman <rms@gnu.org> wrote:

> Why do you think lmenu.el is obsolete?

I took the

  ;; Keywords: emulations obsolete

line to mean it was an emulation of old Lucid Emacs code, not current
XEmacs.

> I agree about the other two.  Would someone who knows how to move
> files in CVS please move them?

Perhaps the Savannah people know how to move the files and preserve
history and everything?

                                                                Juanma

Re: Files in wrong subdirs of emacs/lisp?

[Andreas Schwab]

Juanma Barranquero <jmbarranquero@laley.wke.es> writes:

|> > I agree about the other two.  Would someone who knows how to move
|> > files in CVS please move them?
|> 
|> Perhaps the Savannah people know how to move the files and preserve
|> history and everything?

You don't want to do that, it breaks checkouts of old versions.  Just 'cvs
rm' the current file and 'cvs add' it to the new location.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    I took the

      ;; Keywords: emulations obsolete

    line to mean it was an emulation of old Lucid Emacs code, not current
    XEmacs.

I don't know whether XEmacs has changed.  Does anyone actually know?

Re: Files in wrong subdirs of emacs/lisp?

[Stefan Monnier]

>     options.el, emacs-lisp/float.el and emacs-lisp/lmenu.el could be moved
>     to lisp/obsolete, IMHO.
> 
> Why do you think lmenu.el is obsolete?
> 
> I agree about the other two.  Would someone who knows how to move
> files in CVS please move them?

Just do:

	cp oldname newname
	cvs rm oldname
	cvs add newname

it's not perfect but neither is any other solution.
This one is the most reliable one.


	Stefan

Re: Files in wrong subdirs of emacs/lisp?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Can anyone suggest Lisp files that ought to be moved to a different
> place under the `lisp' directory?

Into emacs-lisp:
        image.el
        ls-lisp.el

Into emulations:
        delsel.el
        s-region.el

Into net:
        kermit.el
        server.el
        talk.el
        terminal.el

Into progmodes:
        cdl.el
        gdb-ui.el
        hexl.el
        newcomment.el
        skeleton.el

Into term:
        ansi-color.el
        vt100-led.el
        vt-control.el
        xt-mouse.el

Into textmodes:
        add-log.el
        arc-mode.el
        forms.el
        forms-*.*
        jka-compr.el
        ses.el
        tar-mode.el

Create a new `vc' subdirectory:
        cvs-status.el
        diff.el
        diff-mode.el
        ediff*.el
        emerge.el
        log-edit.el
        log-view.el
        pcmpl-*.el
        pcvs-*.el
        smerge-mode.el
        vc*.el


It could also be considered to make a new `help' subdir for things like:

        apropos.el
        help*.el
        info*.el
        man.el
        woman.el
        
and perhaps put the custom things in there as well.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Files in wrong subdirs of emacs/lisp?

[Kenichi Handa]

In article <m31xr61235.fsf@kfs-l.imdomain.dk>, storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>>  Can anyone suggest Lisp files that ought to be moved to a different
>>  place under the `lisp' directory?
[...]
> Into textmodes:
>         add-log.el
>         arc-mode.el
>         forms.el
>         forms-*.*
>         jka-compr.el
>         ses.el
>         tar-mode.el

Could you please not move arc-mode.el, jka-compr.el,
tar-mode.el until the merging with emacs-unicode is
finished.  As far as I know, cvs can not handle moved files
well on merging.  In addition, their use is not only for
text.

---
Ken'ichi HANDA
handa@m17n.org

Re: Files in wrong subdirs of emacs/lisp?

[Miles Bader]

On Tue, Dec 16, 2003 at 08:13:15AM +0900, Kenichi Handa wrote:
> Could you please not move arc-mode.el, jka-compr.el, tar-mode.el until the
> merging with emacs-unicode is finished.  As far as I know, cvs can not
> handle moved files well on merging.  In addition, their use is not only for
> text.

Yeah, I'd go so far as to say that moving them into textmodes/ is simply wrong.

-Miles
-- 
Run away!  Run away!

Re: Files in wrong subdirs of emacs/lisp?

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Tue, Dec 16, 2003 at 08:13:15AM +0900, Kenichi Handa wrote:
> > Could you please not move arc-mode.el, jka-compr.el, tar-mode.el until the
> > merging with emacs-unicode is finished.  As far as I know, cvs can not
> > handle moved files well on merging.  In addition, their use is not only for
> > text.
> 
> Yeah, I'd go so far as to say that moving them into textmodes/ is simply wrong.

I was in doubt about those files myself -- let's leave them where they are.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Files in wrong subdirs of emacs/lisp?

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: 15 Dec 2003 17:24:14 +0100
> 
> Into emacs-lisp:
>         image.el
>         ls-lisp.el

I don't think ls-lisp belongs to emacs-lisp.  Perhaps emulation is a
better place.  And if we move ls-lisp anywhere, find-lisp should be
moved to the same place.

> Into progmodes:
>         cdl.el
>         gdb-ui.el
>         hexl.el
>         newcomment.el
>         skeleton.el

I'd say either leave hexl alone or move it to textmodes.  I frequently
use it to look at files that have nothing to do with programming.

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

Thanks for looking for these rearrangements.  I agree with you on many
of them, so I'll comment on the ones I disagree with.

    Into emulations:
	    delsel.el
            s-region.el

These are not specifically for emulation; they are just optional
features.

    Into net:
	    terminal.el

terminal.el has nothing in particular to do with the net.
It just emulates a terminal.

    Into progmodes:
	    cdl.el

This seems to be a mode for editing a "data language",
so I don't think it belongs in progmodes.

	    hexl.el
	    skeleton.el

hexl mode is for examining binary files,
and skeleton.el is a sort of advanced Emacs macro facility.
Neither of them particularly has to do with developing or debugging
programs outside Emacs.

    Into textmodes:

These modes are for editing "text" in the sense of "files whose
contents are written in a human language for humans to read".

	    add-log.el

I don't think of change logs as "text" in this sense.

	    arc-mode.el
	    tar-mode.el

Archive files certainly are not text.

	    forms.el
	    forms-*.*

I don't think these concern text, in the appropriate sense.
The canonical example is /etc/passwd, which is not a file
of text meant for humans to read.

	    jka-compr.el

Compression has nothing to do with whether the file's contents are
text.

	    ses.el

A spreadsheet certainly isn't text.

    Create a new `vc' subdirectory:

It is very useful to have identified a good candidate for
a new coherent subdirectory.  Thanks.

The name `vc' would be slightly misleading, because that refers to the
feature implemented by the vc*.el files.  It would be stretching
things to include anything but vc*.el in a directory with that name,
and including diff* and ediff* would be a big stretch.

So please use the name `versioning' instead.  That concept is more
abstract, but still clear.  With that name, diff* and ediff* fit
naturally.

    It could also be considered to make a new `help' subdir for things like:

It is undesirable to make a new subdirectory with just 12 source files.
We don't want to make lots of small subdirectories.

If we could come up with a good name in which both documentation
and customization fit, then I think it would reach the threshold
of being a good idea.

Re: Files in wrong subdirs of emacs/lisp?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Thanks for looking for these rearrangements.  I agree with you on many
> of them, so I'll comment on the ones I disagree with.
> 
>     Into emulations:
> 	    delsel.el
>             s-region.el
> 
> These are not specifically for emulation; they are just optional
> features.

I'm ok with delsel.el, although in my mind it sort of emulates
fundamental behaviour of other editors and applications.

But I think s-region.el should be moved.  It provides functionality
similar to pc-selection-mode and cua-mode which are both in emulation.
It seems inconsistent not to have them all in the same directory.


> 
>     Into net:
> 	    terminal.el
> 
> terminal.el has nothing in particular to do with the net.
> It just emulates a terminal.

I was using a broader interpretation of 'net' as in 'communication'.
A terminal emulator would fit that category.

> It is undesirable to make a new subdirectory with just 12 source files.
> We don't want to make lots of small subdirectories.
> 
> If we could come up with a good name in which both documentation
> and customization fit, then I think it would reach the threshold
> of being a good idea.


Below, I have tried to split all of the current *.el files in lisp/ into
some existing and new directories.


Move to emacs-lisp/
-------------------
composite.el
disp-table.el
electric.el
ielm.el
image.el
loadhist.el
patcomp.el
thingatpt.el
timezone.el

Rationale:
- ielm.el clearly belongs in emasc-lisp.
- The other files are like libraries for other packages to use, more than
  providing any useful functionality on their own.


Move to emulation/
------------------
s-region.el

Rationale:
- s-region.el provides functionality similar to cua and pc-select which are
  also in emulation.


Move to net/   (communication+networking)
-----------------------------------------
kermit.el
talk.el
term.el
terminal.el

Rationale:
- These are communication packages, and thus belongs in "net" (in a
  broader sense).


Move to progmodes/
------------------
gdb-ui.el

Rationale:
- It obviously belongs with gud.el.


Move to term/  (including o/s specific files)
---------------------------------------------
ansi-color.el
dos-fns.el
dos-vars.el
dos-w32.el
flow-ctrl.el
mwheel.el
vms-patch.el
vmsproc.el
vt-control.el
vt100-led.el
w32-fns.el
w32-vars.el
xt-mouse.el

Rationale:
- Move terminal and mouse specific files here.
- Move o/s specific files here too (there are some there already, so
  we can just as well put all of them in term/).


Move to NEW datamodes/   (19 files)
-----------------------------------
add-log.el
allout.el
arc-mode.el
calculator.el
cdl.el
foldout.el
forms-d2.el
forms-pass.el
forms.el
generic-x.el
generic.el
hexl.el
jka-compr.el
outline.el
rot13.el
ses.el
soundex.el
tar-mode.el
xml.el

Rationale:
- These files work on non-(human-)text file formats and data.  I think they
  deserve their own directory, rather than polluting the lisp base directory. 


Move to NEW editing/  (48 files)
--------------------------------
abbrev.el
abbrevlist.el
align.el
array.el
autoarg.el
autoinsert.el
autorevert.el
avoid.el
bookmark.el
dabbrev.el
delim-col.el
delsel.el
double.el
edmacro.el
elide-head.el
expand.el
follow.el
hi-lock.el
hilit-chg.el
hippie-exp.el
hl-line.el
indent.el
isearch.el
kmacro.el
macros.el
master.el
misc.el
mouse-copy.el
mouse-drag.el
mouse-sel.el
newcomment.el
paren.el
rect.el
register.el
repeat.el
replace.el
reposition.el
reveal.el
ruler-mode.el
scroll-all.el
skeleton.el
sort.el
strokes.el
tabify.el
tempo.el
type-break.el
vcursor.el
whitespace.el

Rationale:
- These files all deal with various aspects of editing the contents
  of a buffer independent on the actual type of text or data.


Move to NEW assist/   (28 files)
--------------------------------
apropos.el
button.el
cus-dep.el
cus-edit.el
cus-face.el
cus-load.el
cus-start.el
cus-theme.el
custom.el
descr-text.el
ehelp.el
finder-inf.el
finder.el
help-at-pt.el
help-fns.el
help-macro.el
help-mode.el
help.el
info-look.el
info-xref.el
info.el
informat.el
makesum.el
man.el
wid-browse.el
wid-edit.el
widget.el
woman.el

Rationale:
- These files assist users to learn about emacs and to customize it
  according to their own preferences.


Move to NEW navigation/   (24 files)
------------------------------------
bs.el
buff-menu.el
dired-aux.el
dired-x.el
dired.el
dirtrack.el
ebuff-menu.el
ffap.el
filecache.el
filesets.el
find-dired.el
find-file.el
format.el
ibuf-ext.el
ibuf-macs.el
ibuffer.el
ido.el
image-file.el
iswitchb.el
msb.el
recentf.el
rfn-eshadow.el
saveplace.el
uniquify.el

Rationale:
- These files deal with navigating between buffer, files and/or
  directories.


Move to NEW shell/  (16 files)
------------------------------
cmuscheme.el
comint.el
env.el
find-lisp.el
gs.el
ledit.el
locate.el
lpr.el
ls-lisp.el
printing.el
ps-bdf.el
ps-mule.el
ps-print.el
resume.el
server.el
shell.el

Rationale:
- This is a directory for misc. files dealing with running or
  emulating external commands, including printing.
- I'm not quite satisfied with the name.  Maybe external/ is better?
 

Move to NEW versioning/  (39 files)
-----------------------------------
compare-w.el
cvs-status.el
diff-mode.el
diff.el
ediff-diff.el
ediff-help.el
ediff-hook.el
ediff-init.el
ediff-merg.el
ediff-mult.el
ediff-ptch.el
ediff-util.el
ediff-vers.el
ediff-wind.el
ediff.el
emerge.el
log-edit.el
log-view.el
pcmpl-cvs.el
pcmpl-gnu.el
pcmpl-linux.el
pcmpl-rpm.el
pcmpl-unix.el
pcvs-defs.el
pcvs-info.el
pcvs-parse.el
pcvs-util.el
pcvs.el
shadowfile.el
smerge-mode.el
time-stamp.el
userlock.el
vc-cvs.el
vc-hooks.el
vc-mcvs.el
vc-rcs.el
vc-sccs.el
vc-svn.el
vc.el

Rationale:
- There are many aspects (and interfaces) to version control systems.
  Packages dealing with those aspects belong together.


Files that should stay in lisp/
-------------------------------
battery.el
bindings.el
case-table.el
chistory.el
complete.el
completion.el
desktop.el
echistory.el
emacs-lock.el
facemenu.el
faces.el
fast-lock.el
files.el
font-core.el
font-lock.el
frame.el
fringe.el
icomplete.el
imenu.el
jit-lock.el
lazy-lock.el
ldefs-boot.el
loaddefs.el
loadup.el
menu-bar.el
midnight.el
minibuf-eldef.el
mouse.el
novice.el
paths.el
pcomplete.el
scroll-bar.el
select.el
simple.el
speedbar.el
startup.el
subdirs.el
subr.el
time.el
tmm.el
tooltip.el
version.el
view.el
windmove.el
window.el
winner.el

Rationale:
- I don't know where else to put these files :-)


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    But I think s-region.el should be moved.  It provides functionality
    similar to pc-selection-mode and cua-mode which are both in emulation.
    It seems inconsistent not to have them all in the same directory.

Is s-region an emulation of something?  If so, what?

    >     Into net:
    > 	    terminal.el
    > 
    > terminal.el has nothing in particular to do with the net.
    > It just emulates a terminal.

    I was using a broader interpretation of 'net' as in 'communication'.
    A terminal emulator would fit that category.

I don't think so.  It is a way to run other programs under Emacs,
analogous to M-x shell.

Re: Files in wrong subdirs of emacs/lisp?

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

> Is s-region an emulation of something?  If so, what?

It could be construed as a subset of cua mode.  Microsoft Windows
applications typically allow the user to mark a region by holding down
the Shift key while moving the cursor.

I think if cua is an emulation, then s-region should also be an
emulation.

Kai

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    I think if cua is an emulation, then s-region should also be an
    emulation.

Ok.

    It could be construed as a subset of cua mode.  Microsoft Windows
    applications typically allow the user to mark a region by holding down
    the Shift key while moving the cursor.

Is there a duplication here that ought to be eliminated, perhaps?

Re: Files in wrong subdirs of emacs/lisp?

[Miles Bader]

On Thu, Dec 18, 2003 at 09:04:51AM -0500, Richard Stallman wrote:
>     It could be construed as a subset of cua mode.  Microsoft Windows
>     applications typically allow the user to mark a region by holding down
>     the Shift key while moving the cursor.
> 
> Is there a duplication here that ought to be eliminated, perhaps?

Yes.

CUA-mode actually contains quite a few different features that are orthogonal
to each other, and could be very useful individually.  In a perfect world
they would be split into separate packages: the shift key selection stuff,
the rectangle operations, the C-x/c/v copy-paste keys, etc.

Presumably if this split was done, s-region.el would be unnecessary.

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: Files in wrong subdirs of emacs/lisp?

[Per Abrahamsen]

Kai Grossjohann <kai@emptydomain.de> writes:

> I think if cua is an emulation, then s-region should also be an
> emulation.

CUA conflicts with the Emacs UI.  Does s-region conflict with Emacs
in any way?  Or is it a clean extension?  If it does not conflict and
is generally useful, maybe it should be enabled by default and thus
become part of the Emacs UI.

Re: Files in wrong subdirs of emacs/lisp?

[Kim F. Storm]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Kai Grossjohann <kai@emptydomain.de> writes:
> 
> > I think if cua is an emulation, then s-region should also be an
> > emulation.
> 
> CUA conflicts with the Emacs UI.  

In what way?

By default, CUA remaps C-z and C-v keys, and makes C-x and C-c behave
"intelligently" when the region is active, but you can easily
customize those bindings away and still use other cua features (like
the shift region making).

>                                   Does s-region conflict with Emacs
> in any way?  Or is it a clean extension?  If it does not conflict and
> is generally useful, maybe it should be enabled by default and thus
> become part of the Emacs UI.

I would strongly advise against this -- IMHO the s-region.el package is
really an ugly hack, and I doubt many users are using it.

For one thing s-region completely messes up the key bindings for the
shifted keys it rebinds (they are all bound to the same function, so
there's no useful doc string printed by C-h k for these keys).

Furthermore, it uses an overlay to show the marked region rather than
relying on transient-mark-mode which does the same thing automatically.

A better place for it might actually be obsolete/.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Files in wrong subdirs of emacs/lisp?

[Per Abrahamsen]

storm@cua.dk (Kim F. Storm) writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>
>> CUA conflicts with the Emacs UI.  
>
> In what way?
>
> By default, CUA remaps C-z and C-v keys, and makes C-x and C-c behave
> "intelligently" when the region is active, but you can easily
> customize those bindings away and still use other cua features (like
> the shift region making).

That way at least.

CUA should probably be split into "emulation" and "new functionality"
parts, perhaps with some of the new functionality integrated in the
standard Emacs UI.  I don't see any reason shift regions shouldn't be
part of the Emacs UI.

Re: Files in wrong subdirs of emacs/lisp?

[Kai Grossjohann]

storm@cua.dk (Kim F. Storm) writes:

> By default, CUA remaps C-z and C-v keys, and makes C-x and C-c behave
> "intelligently" when the region is active, but you can easily
> customize those bindings away and still use other cua features (like
> the shift region making).

I was very happy using CUA, but I did turn the key remappings off.
Maybe going whole hog is too radical a change, but I think that even
old-school Emacs users who resist change will like
CUA-with-keys-turned-off.

What do people think about perhaps enabling CUA with keys turned off?

Kai

Re: Files in wrong subdirs of emacs/lisp?

[Benjamin Riefenstahl]

Hi all,

Kai Grossjohann <kai@emptydomain.de> writes:
> What do people think about perhaps enabling CUA with keys turned off?

What is the difference of this to pc-selection-mode?

benny

Re: Files in wrong subdirs of emacs/lisp?

[Kai Grossjohann]

Benjamin Riefenstahl <Benjamin.Riefenstahl@epost.de> writes:

> What is the difference of this to pc-selection-mode?

CUA has the global mark feature, and it allows for rectangle marking,
and other stuff.  (I think that those features do not emulate the CUA
specification, but rather they are add-ons.  Either way, it's great.)

Kai

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    CUA has the global mark feature, and it allows for rectangle marking,
    and other stuff.

Perhaps one or more of these features should be separated from CUA mode
and installed as a separate feature.

Re: Files in wrong subdirs of emacs/lisp?

[Kai Grossjohann]

Richard Stallman <rms@gnu.org> writes:

> Perhaps one or more of these features should be separated from CUA mode
> and installed as a separate feature.

AFAIK (I can't check now for lack of access to the CVS tree) the
features are already separated in the implementation; they only have
CUA in the name and maybe they are not documented separately.

Kai

Re: Files in wrong subdirs of emacs/lisp?

[Kim F. Storm]

Kai Grossjohann <kai@emptydomain.de> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > Perhaps one or more of these features should be separated from CUA mode
> > and installed as a separate feature.
> 
> AFAIK (I can't check now for lack of access to the CVS tree) the
> features are already separated in the implementation; they only have
> CUA in the name and maybe they are not documented separately.

The global mark and rectangle functionality has been split into
separate files, but they are still tied into CUA mode, as they
hook quite deep into the basic CUA cut and paste functionality.

I think it will be possible to split them off entirely from CUA, but
it will be a little tricky (and not very elegant).  However, since CUA
is now installed with emacs, it might be acceptable to make hooks for
cua in some of the basic emacs functions -- meaning that cua doesn't
need to be as "clever" as it is now.

Since I haven't had a personal need to do this, I have prioritized
other tasks over this.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    AFAIK (I can't check now for lack of access to the CVS tree) the
    features are already separated in the implementation; they only have
    CUA in the name and maybe they are not documented separately.

How about documenting them separately?  It could be that some
of these features should be enabled by default, but we have
to consider each one separately.  Also, it could be that
one of these features should replace s-region.el.  Could you
look and see?

Re: Files in wrong subdirs of emacs/lisp?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     We already have both pc-selection-mode and cua-mode doing the
>     same thing, so IMO s-region is obsolete.
> 
> The behavior of cua-mode is very different from the behavior
> of s-region, so we certainly cannot tell users "use cua mode
> instead of s-region."

Yes, s-region has one unique feature (compared to cua and pc-select)
which is that it only shows the region highlight temporarily (for one
second).  But other than that, cua can be customized to just provide
the same functionality as s-region and pc-selection mode.


But there are some fundamental problems with s-region which make me doubt
doubt that anyone is actually using it:

The list of keys which are rebound by s-region is pretty short.  Based
on the feedback I have got from users of CUA, I believe that those who
use shifted movement keys to select a region want such a mode to work
for practically all commands that move the cursor, not just the very
incomplete list provided by s-region.el.

S-region is activated just by loading the file, i.e. it doesn't have a
toggle-mode function with an autoload cookie.  It works by modifying
the global key bindings, and there is no way to turn it off again.

This also means that if some modes redefines these keys in their local
map, they lose their s-region binding (this happens for cua and
pc-select as well, but at least with cua mode, this is *easy* to
handle).

Also s-region uses an awful method of binding all the keys that it
controls to the same function (so C-h k doesn't really work).

> 
> Would a user who uses pc-selection-mode instead of s-region
> notice any differences in behavior?  If so, what differences?

The major difference is that with pc-selection-mode the region remains
highlighted while s-region only highlights it temporarily.  
Also pc-selection-mode has a few more bindings to make it recognize more
shifted movements.

BTW, pc-selection-mode also uses a method of rebinding a lot of keys
in the -mark (shifted) and -nomark (unshifted) state, e.g. S-left is
bound to forward-char-mark and left is bound to forward-char-nomark.
This means that it is non-trivial to add more movement commands to
pc-selection-mode, as you need to write lisp code to do that.  And it
also repeats the doc string for each of the original commands.  

CUA on the other hand doesn't rebind any of the movement keys (it
actually looks for the shift-modifier on user input), and it is
trivial to add more movement commands to be recognized by CUA (via
customize).


My conclusion is that s-region, no matter how ugly it is, has a unique
feature (temporary region highlighting) which may make it useful for
some users.  It doesn't harm to keep it, but I would still make it
obsolete, as I don't think it is something we should actively spend
any time on maintaining it.

Actually, the temporary highlighting of the region is ortogonal to the
shift region selection, so it might be useful to implement that as a
general mechanism based on transient-mark-mode: We could add a
transient-region-highlight-timeout setting which causes the
highlighting of the region to disappear N milliseconds after the last
user command (and shows the highlighting again if the mark is still
active when you execute the next command).  Personally, I would find
that confusing though...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

    Yes, s-region has one unique feature (compared to cua and pc-select)
    which is that it only shows the region highlight temporarily (for one
    second).  But other than that, cua can be customized to just provide
    the same functionality as s-region and pc-selection mode.

Do you think that is a useful feature?  If so, maybe it would
be good to add that feature to cua, perhaps has an option.

    The major difference is that with pc-selection-mode the region remains
    highlighted while s-region only highlights it temporarily.  

I think most people will prefer the permanent highlighting.
Maybe it isn't worth adding the temporary highlighting option.

    But there are some fundamental problems with s-region which make me doubt
    doubt that anyone is actually using it:

Ok, let's declare it obsolete.

Re: Files in wrong subdirs of emacs/lisp?

[Richard Stallman]

Regarding the new suggestions:

The datamodes directory might be a good idea.
However, I don't think soundex belongs there.
It is not a mode, just a subroutine for converting text.
Just 18 files is a bit on the small side.

I don't think that os-specific files belong in term.

s-region.el should not be moved, as far as I can see now.
term.el and terminal.el should not be moved.

The assist directory is a good idea.

I am not sure `navigation' is coherent.

`shell' is too small.