Another 'best' practices question ??

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.

ELPA package listings [formerly: Another 'best' practices question ??]

[Sebastian Tennant]

Hi Tom,

Just upgraded to package.el version 0.6.  Glad to see ELPA (Every
Load-Path Answer) is going from strength to strength.

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.

'installed' may be clearer, but you're right, it makes it too busy...
font-lock-highlighting to the rescue... (and this time I've found the time
to do something about it myself!)


diff -c /home/sebyte/.emacs.d/elpa/package.el\~ /home/sebyte/.emacs.d/elpa/package.el
*** /home/sebyte/.emacs.d/elpa/package.el~	Mon Oct 29 11:15:02 2007
--- /home/sebyte/.emacs.d/elpa/package.el	Mon Oct 29 13:40:10 2007
***************
*** 1044,1049 ****
--- 1044,1051 ----
  (defvar package-menu-mode-map nil
    "Local keymap for `package-menu-mode' buffers.")
  
+ (defvar package-menu-font-lock-keywords '(("^.*installed.*$" . font-lock-comment-face)))
+ 
  (unless package-menu-mode-map
    (setq package-menu-mode-map (make-keymap))
    (suppress-keymap package-menu-mode-map)
***************
*** 1074,1079 ****
--- 1076,1082 ----
    (use-local-map package-menu-mode-map)
    (setq major-mode 'package-menu-mode)
    (setq mode-name "Package Menu")
+   (setq font-lock-defaults (list 'package-menu-font-lock-keywords t))
    (setq truncate-lines t)
    (setq buffer-read-only t)
    ;; Support Emacs 21.

Diff finished.  Mon Oct 29 14:24:16 2007


Hope this is useful in some way.

Sebastian

Re: ELPA package listings [formerly: Another 'best' practices question ??]

[Sebastian Tennant]

Quoth Sebastian Tennant <sebyte@smolny.plus.com>:
> + (defvar package-menu-font-lock-keywords '(("^.*installed.*$" . font-lock-comment-face)))

That regexp should undoubtedly be

 "^.*\\<installed\\>.*$"

in case 'uninstalled', or such like, is ever added to the listing.

Sebastian