Re: Another 'best' practices question ??

Re: Another 'best' practices question ??

[Robert Thorpe]

On May 3, 6:47 pm, William Case <billli...@rogers.com> wrote:
> Should I create a new directory in "/usr/share/emacs/22.0.95/lisp" or
> add the file to an existing directory?  I tried to include it with the
> XHTML-mode but I could find specific XHTML, HTML or PHP mode files or
> directories to include it with.  Is that a good idea or not?

The normal procedures is to keep the regular Emacs separate from your
customizations of it.  So, usually you put modes that you have
downloaded from elsewhere somewhere out of the way of the normal Emacs
tree.  This allows you to upgrade Emacs more simply.  The normal place
to put these modes is in "site-lisp".  There are two "site-lisp"
directories, one in /usr/share/emacs/site-lisp is intended for things
that can work on many versions of emacs.  The one in /usr/share/emacs/
22.0.95/site-lisp is intended for things that are there for the
benefit of that particular version of Emacs.

A simple mode consisting of a single .el file I would put straight
into the site-lisp directory.  If the mode consists of many files that
would make reading the directory confusing then I'd make a new
directory just to put the mode in.  Then add that dir to the load-path
in .emacs.  Or, add a line into .emacs to load the main file of the
mode directly rather than relying on the load-path.

There are no hard-and-fast rules.

Re: Another 'best' practices question ??

[Sebastian Tennant]

Quoth Robert Thorpe <rthorpe@realworldtech.com>:
> The normal procedures is to keep the regular Emacs separate from your
> customizations of it.  So, usually you put modes that you have
> downloaded from elsewhere somewhere out of the way of the normal Emacs
> tree.  This allows you to upgrade Emacs more simply.  The normal place
> to put these modes is in "site-lisp".  There are two "site-lisp"
> directories, one in /usr/share/emacs/site-lisp is intended for things
> that can work on many versions of emacs.  The one in /usr/share/emacs/
> 22.0.95/site-lisp is intended for things that are there for the
> benefit of that particular version of Emacs.

There's a reason these directories contain the word 'site', namely
that whatever is found in them is availble site-wide, i.e, to all the
users of your machine.  Consequently adding files to these directories
requires root privileges.

If what you want to 'install' is just for your own personal use then
create a ~/elisp directory, put the source files there, and add
~/.elisp to your load-path.

> A simple mode consisting of a single .el file I would put straight
> into the site-lisp directory.  If the mode consists of many files that
> would make reading the directory confusing then I'd make a new
> directory just to put the mode in.  Then add that dir to the load-path
> in .emacs.  Or, add a line into .emacs to load the main file of the
> mode directly rather than relying on the load-path.
>
> There are no hard-and-fast rules.

Indeed, there are not.  But it's always possible to do the right
thing, or the wrong one ;-)

Sebastian

P.S. Apologies if I'm missing the point, having not read the thread
     from the beginning.

Re: Another 'best' practices question ??

[William Case]

Thanks Robert;

This exactly the kind of thing I was looking for.

On Fri, 2007-05-04 at 09:36 -0700, Robert Thorpe wrote:
[snip]
> The normal procedures is to keep the regular Emacs separate from your
> customizations of it.  So, usually you put modes that you have
> downloaded from elsewhere somewhere out of the way of the normal Emacs
> tree.  This allows you to upgrade Emacs more simply.  The normal place
> to put these modes is in "site-lisp".  There are two "site-lisp"
> directories, one in /usr/share/emacs/site-lisp is intended for things
> that can work on many versions of emacs.  The one in /usr/share/emacs/
> 22.0.95/site-lisp is intended for things that are there for the
> benefit of that particular version of Emacs.
> 
> A simple mode consisting of a single .el file I would put straight
> into the site-lisp directory.  If the mode consists of many files that
> would make reading the directory confusing then I'd make a new
> directory just to put the mode in.  Then add that dir to the load-path
> in .emacs.  Or, add a line into .emacs to load the main file of the
> mode directly rather than relying on the load-path.
> 
> There are no hard-and-fast rules.

I gather.  

However, this question and your answer are seldom mentioned in
documentation.  They are normally the kind of thing that one picks up
from colleagues.  But when you are retired, working at home, there are
no colleagues to ask.  So your explanation is doubly appreciated.  

I recently went through the SVN manual.  One of the things that made it
a real learner was the authors took the time to write a "best practises"
paragraph or two at the conclusion of major sections.  It's a nice way
to summarize what has been taught previously and to relieve any concern
that a new user might have about looking like an idiot greenhorn the
first time they use a program publicly.


-- 
Regards Bill

Re: Another 'best' practices question ??

[Robert Thorpe]

On May 4, 8:58 pm, William Case <billli...@rogers.com> wrote:
> On Fri, 2007-05-04 at 09:36 -0700, Robert Thorpe wrote:
<snip>
> > A simple mode consisting of a single .el file I would put straight
> > into the site-lisp directory.  If the mode consists of many files that
> > would make reading the directory confusing then I'd make a new
> > directory just to put the mode in.  Then add that dir to the load-path
> > in .emacs.  Or, add a line into .emacs to load the main file of the
> > mode directly rather than relying on the load-path.
>
> > There are no hard-and-fast rules.
>
> I gather.

Sebastian also has a point, stuff in site-lisp is "site wide"
available to every user on the machine.  I find this is normally the
right thing to do, but it might not be in every circumstance.

> I recently went through the SVN manual.  One of the things that made it
> a real learner was the authors took the time to write a "best practises"
> paragraph or two at the conclusion of major sections.  It's a nice way
> to summarize what has been taught previously and to relieve any concern
> that a new user might have about looking like an idiot greenhorn the
> first time they use a program publicly.

That might be useful.  If you think that would be useful then you
could suggest it to the Emacs development team, emacs-devel@gnu.org .

Another 'best' practices question ??

[William Case]

Hi;

I have downloaded nxhtml-1.00.070501.zip.  I now have to put it
somewhere and then add it to my loadpath.  Is that correct?

If so, where should I put it?  I am looking for a best practises answer
that would be applicable to other downloaded or created *.el files.

I have a half answer from the emacswiki, but that leaves me with
choosing the location and as a relative newbie it is not clear what
would be the best choice.

I have emacs 22, on a Fedora core 6 machine.  My existing loadpath is:

("/usr/share/emacs/22.0.95/site-lisp" 
"/usr/share/emacs/site-lisp" 
"/usr/share/emacs/site-lisp/site-start.d" 
"/usr/share/emacs/22.0.95/lisp" 
"/usr/share/emacs/22.0.95/lisp/url" 
"/usr/share/emacs/22.0.95/lisp/textmodes" 
"/usr/share/emacs/22.0.95/lisp/progmodes" 
"/usr/share/emacs/22.0.95/lisp/play" 
"/usr/share/emacs/22.0.95/lisp/obsolete" 
"/usr/share/emacs/22.0.95/lisp/net" 
"/usr/share/emacs/22.0.95/lisp/mh-e" 
"/usr/share/emacs/22.0.95/lisp/mail" 
"/usr/share/emacs/22.0.95/lisp/language" 
"/usr/share/emacs/22.0.95/lisp/international" 
"/usr/share/emacs/22.0.95/lisp/gnus" 
"/usr/share/emacs/22.0.95/lisp/eshell" 
"/usr/share/emacs/22.0.95/lisp/erc" 
"/usr/share/emacs/22.0.95/lisp/emulation" 
"/usr/share/emacs/22.0.95/lisp/emacs-lisp" 
"/usr/share/emacs/22.0.95/lisp/calendar" 
"/usr/share/emacs/22.0.95/lisp/calc" 
"/usr/share/emacs/22.0.95/leim")

Should I create a new directory in "/usr/share/emacs/22.0.95/lisp" or
add the file to an existing directory?  I tried to include it with the
XHTML-mode but I could find specific XHTML, HTML or PHP mode files or
directories to include it with.  Is that a good idea or not?

-- 
Regards Bill

Re: Another 'best' practices question ??

[Lennart Borgman (gmail)]

William Case wrote:
> Hi;
> 
> I have downloaded nxhtml-1.00.070501.zip.  I now have to put it
> somewhere and then add it to my loadpath.  Is that correct?

Unpack it and follow the instructions in readme.txt. You do not have to 
put it in your load-path. If you follow the instructions some 
directories will instead be added to your load-path.

> If so, where should I put it?

Anywhere, see above.

When you open your first .html file you will get some more instructions.

> Should I create a new directory in "/usr/share/emacs/22.0.95/lisp" or
> add the file to an existing directory?  I tried to include it with the
> XHTML-mode but I could find specific XHTML, HTML or PHP mode files or
> directories to include it with.  Is that a good idea or not?

I am not sure what you mean, but nXhtml includes a new mode for XHTML 
called nxhtml-mode. You can also use the mode that comes with Emacs 22, 
html-mode, but then you will miss completion for XHTML.

nXhtml also includes a php-mode. Please use that one, not some other 
version, since I have made some corrections to it.

Re: Another 'best' practices question ??

[William Case]

Hi Lennart;

I appreciate your personal response.

On Thu, 2007-05-03 at 19:59 +0200, Lennart Borgman (gmail) wrote:
> William Case wrote:
> > Hi;
> > 
> > I have downloaded nxhtml-1.00.070501.zip.  I now have to put it
> > somewhere and then add it to my loadpath.  Is that correct?
> 
> Unpack it and follow the instructions in readme.txt. You do not have to 
> put it in your load-path. If you follow the instructions some 
> directories will instead be added to your load-path.
> 
> > If so, where should I put it?
> 
> Anywhere, see above.
> 
> When you open your first .html file you will get some more instructions.
> 
> > Should I create a new directory in "/usr/share/emacs/22.0.95/lisp" or
> > add the file to an existing directory?  I tried to include it with the
> > XHTML-mode but I could find specific XHTML, HTML or PHP mode files or
> > directories to include it with.  Is that a good idea or not?
> 
> I am not sure what you mean, but nXhtml includes a new mode for XHTML 
> called nxhtml-mode. You can also use the mode that comes with Emacs 22, 
> html-mode, but then you will miss completion for XHTML.
> 
> nXhtml also includes a php-mode. Please use that one, not some other 
> version, since I have made some corrections to it.
> 

I can see that my above questions, might have been particularly
newbie-dumb, but I am not the only dumb newbie out there. Might not it
have been useful to other users to see your response.

Particularly, since I have followed your instructions and have the new
nXhtml-mode working, I would now like to congratulate you on your work.
I think that those kudos from me and others should be on the public
list.

I am really impressed with what you have done and what you have shown
can be done with Lisp in emacs. 

-- 
Regards Bill

Re: Another 'best' practices question ??

[Lennart Borgman (gmail)]

William Case wrote:

> Particularly, since I have followed your instructions and have the new
> nXhtml-mode working, I would now like to congratulate you on your work.
> I think that those kudos from me and others should be on the public
> list.
> 
> I am really impressed with what you have done and what you have shown
> can be done with Lisp in emacs. 

Thanks William. I myself am impressed by the possibility to use 
completion and validation when you write XHTML code. But I am not the 
father of that, I have only built on the work James Clark put into 
nxml-mode, a general XML mode for Emacs with completion and validation. 
I have just twisted it a bit to make it better for XHTML.

Re: Another 'best' practices question ??

[Christian Herenz]

William Case wrote:
>
> I can see that my above questions, might have been particularly
> newbie-dumb, but I am not the only dumb newbie out there. Might not it
> have been useful to other users to see your response.
I also feel a little bit stupid, when I ask questions on this list,
because I am also a newbie, and in on of the last threads  (How old are
emacs users?) were people who use emacs for more than a decade.

But I just wanted to say, that I have in my home dir's (at home and at
work) a dir called emacs-scripts, where I put some of the code snippets
and bigger scripts, so that path is in my load path... I do not know if
that is "best practice" but I use it like that and it works.

Greetz,
Christian

Re: Another 'best' practices question ??

[Tom Tromey]

>>>>> "Christian" == Christian Herenz <herenz@physik.hu-berlin.de> writes:

Christian> But I just wanted to say, that I have in my home dir's (at
Christian> home and at work) a dir called emacs-scripts, where I put
Christian> some of the code snippets and bigger scripts, so that path
Christian> is in my load path... I do not know if that is "best
Christian> practice" but I use it like that and it works.

Yes, that's the common practice in a nutshell.

I'd like to plug ELPA here though.  If enough things are packaged we
could move away from manually hacking load-path and instead just
manage packages via a buffer-menu-like mode.  See:

    http://tromey.com/elpa/

Tom

Re: Another 'best' practices question ??

[Sebastian Tennant]

Quoth Tom Tromey <tromey@redhat.com>:
> I'd like to plug ELPA here though.  If enough things are packaged we
> could move away from manually hacking load-path and instead just
> manage packages via a buffer-menu-like mode.  See:
>
>     http://tromey.com/elpa/

Just did what ^^^ tells me to do in my apt-installed 'snapshot Emacs'
(22.0.95) and package-menu-refresh encounters a:

  let: Symbol's function definition is void: read-from-whole-string

error.

Indeed, the only read-from-* functions I have to hand are:

 read-from-string       and     read-from-minibuffer

You may need to include the read-from-whole-string function definition
in package.el as it's clearly not a stock function, or maybe globally
replacing read-from-whole-string with read-from-string in package.el
will suffice.  I don't know because I don't know what
read-from-whole-string is supposed to do.

Or maybe, some version sniffing is all that's needed...

If I had time I'd dig deeper but...

ELPA sounds like a good concept though.

HTH

Sebastian

Re: Another 'best' practices question ??

[Tom Tromey]

>>>>> "Sebastian" == Sebastian Tennant <sebyte@smolny.plus.com> writes:

>> http://tromey.com/elpa/

Sebastian> Just did what ^^^ tells me to do in my apt-installed
Sebastian> 'snapshot Emacs' (22.0.95) and package-menu-refresh
Sebastian> encounters a:

It works ok with Emacs 21, FWIW.

Sebastian>   let: Symbol's function definition is void: read-from-whole-string
Sebastian> error.

Oops.  That is fixed in the next release (I'll push it soon).
Meanwhile you can (require 'thingatpt) to work around it... sigh, sort
of the opposite of the effect I was going for :-).
Sorry about that.

Tom

Re: Another 'best' practices question ??

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> Oops.  That is fixed in the next release (I'll push it soon).

Haha, I found what happened -- I released package.el 0.3 a while ago,
but I neglected to upload it to ELPA.  How ironic!

I've uploaded 0.3 now.  The reported bug is fixed there.

I haven't yet made it simple to upgrade package.el using itself.  I'm
considering adding that in a future version.  Meanwhile you'll have to
download package.el by hand and install it over the old copy.  The
direct link is:

    http://tromey.com/elpa/package.el

... but if you haven't yet installed package.el you probably should
just use the auto-installer.

Tom

Re: Another 'best' practices question ??

[Sebastian Tennant]

Quoth Tom Tromey <tromey@redhat.com>:
>>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
>
> Tom> Oops.  That is fixed in the next release (I'll push it soon).
>
> Haha, I found what happened -- I released package.el 0.3 a while ago,
> but I neglected to upload it to ELPA.  How ironic!
Don't let an oversight, however ironic, discourage you ;-)

> I've uploaded 0.3 now.  The reported bug is fixed there.
>
> I haven't yet made it simple to upgrade package.el using itself.  I'm
> considering adding that in a future version.  Meanwhile you'll have to
> download package.el by hand and install it over the old copy.  The
> direct link is:
>
>     http://tromey.com/elpa/package.el
>
> ... but if you haven't yet installed package.el you probably should
> just use the auto-installer.

Now all is well. Updated the list, and installed (and played a game
of) sudoku without any problems.  I haven't tried downloading games
from the net or anything like that yet.

Nice one geezer.  (Yes, I'm from London).

I've no idea if this is of any interest to you but there were a couple
of warnings during compilation:

  In get-board-wget:
  sudoku.el:1258:18:Warning: reference to free variable `sudoku-wget-process'

  In get-board-w3:
  sudoku.el:1281:7:Warning: url-retrieve called with 1 argument, but requires 2-3


Regarding ELPA, a couple of suggestions if I may be so bold:

 1.  How about 'installed' rather than <blank> in the status column.

 2.  A hint as to how to run the newly installed package (not in the
     description because there isn't room, but somewhere).  For
     instance, having installed sudoku in a snip, I then had to
     navigate to the source file and read the commentary to find out
     that I had to eval (require 'sudoku') before I was good to go.

 3.  'g' in the Package buffer is described as 'revert'.  Is this not
      better described as 'refresh'?

Sebastian

Re: Another 'best' practices question ??

[Tom Tromey]

>>>>> "Sebastian" == Sebastian Tennant <sebyte@smolny.plus.com> writes:

Sebastian>   In get-board-wget:
Sebastian>   sudoku.el:1258:18:Warning: reference to free variable `sudoku-wget-process'

Sebastian>   In get-board-w3:
Sebastian>   sudoku.el:1281:7:Warning: url-retrieve called with 1 argument, but requires 2-3

These both look like buglets in sudoku.el -- the first due to how it
defines sudoku-wget-process and the second just some sort of oversight
(or perhaps reliance on some old version of url, I didn't look).

Sebastian> Regarding ELPA, a couple of suggestions if I may be so bold:
Sebastian>  1.  How about 'installed' rather than <blank> in the status column.

I made a note.

I chose blank because it looks sort of busy with "installed".  But I
don't really know what is best -- "installed" is clearer.

Sebastian>  2.  A hint as to how to run the newly installed package (not in the
Sebastian>      description because there isn't room, but somewhere).  For
Sebastian>      instance, having installed sudoku in a snip, I then had to
Sebastian>      navigate to the source file and read the commentary to find out
Sebastian>      that I had to eval (require 'sudoku') before I was good to go.

Yeah, this is a problem.  I don't really know what to do about it.

For most packages, package.el will extract ";;;###autoload" comments
and make those available at package-activation time.

But I see I didn't add these to sudoku.el :(.

If you try the bubbles game you can see it in action a bit more
clearly: it will download, install, and activate the game, and then
you can just do M-x bubbles.

Sebastian>  3.  'g' in the Package buffer is described as 'revert'.
Sebastian>  Is this not better described as 'refresh'?

In 0.4 I'm using "refresh" for the 'r' option.  "g" is "revert" by
analogy with dired or buffer-menu -- it undoes local changes but does
not download a new copy of the archive contents.

Tom

Re: Another 'best' practices question ??

[Sebastian Tennant]

Quoth Tom Tromey <tromey@redhat.com>:
> Sebastian> Regarding ELPA, a couple of suggestions if I may be so bold:
> Sebastian>  1.  How about 'installed' rather than <blank> in the
> status column.
> [...]
> I chose blank because it looks sort of busy with "installed".  But I
> don't really know what is best -- "installed" is clearer.

The answer is simple. How about some font-lock-keyword highlighting?
'Installed' could be in a different colour (in about 3 lines of code)
could it not?

> Sebastian>  2.  A hint as to how to run the newly installed package (not in the
> Sebastian>      description because there isn't room, but somewhere).  For
> Sebastian>      instance, having installed sudoku in a snip, I then had to
> Sebastian>      navigate to the source file and read the commentary to find out
> Sebastian>      that I had to eval (require 'sudoku') before I was good to go.
>
> Yeah, this is a problem.  I don't really know what to do about it.
>
> For most packages, package.el will extract ";;;###autoload" comments
> and make those available at package-activation time.

I did notice a buffer called sudoku-autoloads.el (or something like
that) lying around after I'd installed the package and played the
game, but I didn't examine it closely.  I'm pretty sure it didn't
include any clear instructions.

> But I see I didn't add these to sudoku.el :(.

Don't worry man... it works.  That's all that matters.  Others will
take care of things when it catches on.  I, for one, think it's a
great tool.

> If you try the bubbles game you can see it in action a bit more
> clearly: it will download, install, and activate the game, and then
> you can just do M-x bubbles.

I'm afraid I can't spend my time just playing games, as much as I'd
like to ;-)

> Sebastian>  3.  'g' in the Package buffer is described as 'revert'.
> Sebastian>  Is this not better described as 'refresh'?
>
> In 0.4 I'm using "refresh" for the 'r' option.  "g" is "revert" by
> analogy with dired or buffer-menu -- it undoes local changes but does
> not download a new copy of the archive contents.

Ah what the hell... :-)

Sebastian

P.S. I think it's time you started a thread called 'ELPA - Every Load
     Path Answer', or something like that.  Actually, something like
     that, but you get my point I hope.