another try at sepia
Joe Brenner
M-x sepia-repl pretty much just works out-of-the-box as a good
way of executing snippets of perl code.
So, first off, I tried just typing:
@INC
That confirmed that sepia was seeing my usual PERL5LIB settings,
and hence it should be able to find my modules in their development
locations.
Then I tried:
require Emacs::Run
$er = Emacs::Run->new;
And got this error message:
error: Unknown method 'IPC::Capture::success' called at /home/doom/End/Cave/EmacsPerl/Wall/Emacs-Run/lib//Emacs/Run.pm line 1561
Needless to say, you don't see this problem with Emacs::Run outside of
sepia: it's tests currently pass on my machine, and so on [1]
Doing a "require IPC::Capture" first has no effect.
There's something profoundly weird about sepia that I just don't
understand. If you skim through the documentation, there are a large
number of features (like, code browsing and integration with the perl
debugger) that just don't make any sense unless there's a way to point
it at some existing code that you want to work on.
So how do you do that?
Am I blind, or is this basic point not covered in the documentation?
(By the way, clicking on that error message does jump directly to the
indicated line, which is good... that's one things that puts the "I" in
"IDE".)
[1] Emacs::Run even passes on some, though by no means all of the smoke
test machines:
LanX
2. start the REPL subprocess with M-x sepia-repl
3. change the file to sepia-mode with M-x sepia-mode
The documented commands can be applied now. (more or less)
The documentation is very sparse since Sean assumes a deep
knowledge of Emacs, GUD and LISP coding culture of interactively developing code.
And some of the features are even buggy. (e.g. sepia-perl-pe-region)
LanX
http://blog.jrock.us/articles/Stylish%20REPL.pod
The nice screencast included shows much of the strategies to use a REPL to interactively develop code.
http://www.iinteractive.com/stylish-repl-screencast.ogv
Note how it does support lexical variables 8)
Joe Brenner
Joe Brenner <do...@kzsu.stanford.edu> wrote:
> So, first off, I tried just typing:
>
> @INC
>
> That confirmed that sepia was seeing my usual PERL5LIB settings,
Or so I thought. I hadn't looked closely enough: really there was one
odd location right at the top, pointing at one of my old perl 5.8.8
libraries. I wasn't seeing that when running perl from the shell,
and since I'm now running perl 5.10.0, it could easily have been
causing problems for me.
In fact, it was causing this problem:
> and hence it should be able to find my modules in their development
> locations.
>
> Then I tried:
>
> require Emacs::Run
> $er = Emacs::Run->new;
>
> And got this error message:
>
> error: Unknown method 'IPC::Capture::success' called at /home/doom/End/Cave/EmacsPerl/Wall/Emacs-Run/lib//Emacs/Run.pm line 1561
Apparently this was because I had an old version of IPC::Capture
installed in the 5.8.8 location. I can't say I see what was
wrong with the old version, but forcibly deleting it made that
particular problem go away.
(That was a relief, because "success" is not a statically defined
routine in IPC::Capture, it's an accessor dynamically created by
an AUTOLOAD routine... this is a pretty common idiom in perl-OOP,
but Sean is quite the object-hater, and I was afraid he might not
have bothered to support it.)
But where could this silly 5.8.8 location be coming from in my @INC?
In turns out that I had this stuck in my tree of emacs init files,
leftover from one of my older experiments with Sepia:
;;;========
;;; sepia setup
(setq sepia-perl5lib (list (expand-file-name "/usr/local/share/perl/5.8.8/")))
(defalias 'perl-mode 'sepia-mode)
(defalias 'cperl-mode 'sepia-mode) ;; TODO makes sense, right?
(require 'sepia)
So that one was definitely my bad.
Joe Brenner
LanX <lanx...@googlemail.com> wrote:
> 1. open a perl file
> 2. start the REPL subprocess with M-x sepia-repl
> 3. change the file to sepia-mode with M-x sepia-mode
Manually going into sepia-mode does indeed get me further.
The documented "Getting Started" instructions recommend using
defalias to substitute sepia-mode for perl-mode. I did indeed
have it set-up that way, but for some reason it wasn't having any
effect.
At a guess, the trouble is in my own emacs init files (the order
in which I'm doing things may not be quite right, for example).
If the "defalias" stuff seems problematic, I might suggest just
hacking the auto-mode-alist:
(add-to-list 'auto-mode-alist '("\\.\\([pP][Llm]\\|al\\|t\\|pod\\)\\'" . sepia-mode))
(I don't know how I feel about sepia being implemented as a
major-mode, by the way, but I can understand why you would do it
that way: derived major modes are easy to do, minor modes are
hard... also arguably there wouldn't be much point in doing this
as a minor mode, since you're not going to use it with anything
but cperl-mode anyway.)
LanX
> major-mode, by the way, but I can understand why you would do it
> that way: derived major modes are easy to do, minor modes are
> hard... also arguably there wouldn't be much point in doing this
> as a minor mode, since you're not going to use it with anything
> but cperl-mode anyway.)
experimenting with sepia.
I think it was the cheapest strategy for Sean to extend cperl-mode,
but will he always
update to the newest cperl-release ... or does sepia automatically
derive from the installed
cperl-version?
I'm still puzzled about GUD integration and all the "breackpoint"
support.
Well I know now how to send the actual buffer to sepia-repl but it's
automatically run
and how do I set breakpoints ... ?
This hole LISP-development culture is to alien for me to intuitively
understand all what
Sean and J. Rockway intend to achieve...
Couldn't you invite them again to join the group ;-)
Or I'm gonna send Sean a bug report and will point again to this
group.
LanX
> At a guess, the trouble is in my own emacs init files (the order
> in which I'm doing things may not be quite right, for example).
hard to customize )
I started a strategy of putting all moduls and encapsulate
corresponding customization in nested subdirs which i source from a
master init.el. (still struggling how to define relative path in
elisp)
For instance this is my javascript-subdir with different JS-modes
~$ ls .emacs.d/elisp/js/
espresso init.el javascript js2 moz
~$ ls .emacs.d/elisp/js/espresso/
espresso.el init.el
Like this I can try out new moduls and disable them just by commenting
out a line or two in the mastering init.
Of course sourcing threw a list of nested init.el doesn't speed up
start-up ... but auto-compiling them into one big init-file should be
the next step...
Randy J. Ray
At a guess, the trouble is in my own emacs init files (the order in which I'm doing things may not be quite right, for example).Yeah a classical 100kb init.el is part of the EIHTC Problem (emacs-is- hard to customize ) I started a strategy of putting all moduls and encapsulate corresponding customization in nested subdirs which i source from a master init.el. (still struggling how to define relative path in elisp)
(defconst homedir (getenv "HOME") "My home dir, regardless of host.")
(setq load-path (cons (concat homedir "/.emacs.d") load-path))
Thus, everything in ~/.emacs.d is findable by (require), (load), etc.
Randy
-- """"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""" Randy J. Ray Sunnyvale, CA http://www.rjray.org rj...@blackperl.com http://www.svsm.org randy...@gmail.com
Joe Brenner
LanX <lanx...@googlemail.com> wrote:
> > (I don't know how I feel about sepia being implemented as a
> > major-mode, by the way, but I can understand why you would do it
> > that way: derived major modes are easy to do, minor modes are
> > hard... also arguably there wouldn't be much point in doing this
> > as a minor mode, since you're not going to use it with anything
> > but cperl-mode anyway.)
> I think it was the cheapest strategy for Sean to extend cperl-mode,
Yes, exactly, that's what I was saying. (I may have a problem or two
about sepia docs, but they're nothing compared to the elisp
documentation for writing minor modes... major modes are a *lot*
easier.)
> but will he always update to the newest cperl-release ... or does
> sepia automatically derive from the installed cperl-version?
From glancing at the code, I gather that it just works with the
installed version of cperl, as it should.
What that means, though, is that an update to cperl might accidentally
break sepia.
> I'm still puzzled about GUD integration and all the "breackpoint"
> support.
It might make sense to just learn how to use "M-x perldb" first.
> Well I know now how to send the actual buffer to sepia-repl but it's
> automatically run and how do I set breakpoints ... ?
In the perldb it'd be a "b" for breakpoint, and maybe an "R" for restart.
Haven't tried this inside of sepia as of yet.
> Couldn't you invite them again to join the group ;-)
I haven't given up exactly, I just don't want to appear impatient about
repeatedly bugging them. (What I've been doing is putting some stuff
up on a new emacswiki Sepia node, with pointers back to here. Sean was
saying he tracks emacswiki...).
> Or I'm gonna send Sean a bug report and will point again to this
> group.
Okay, don't get too heavy-handed about it, though, you might just drive
him away (in a lot of ways it's really impressive to find someone who's
more cantankerous than I am).
Joe Brenner
LanX <lanx...@googlemail.com> wrote:
> > At a guess, the trouble is in my own emacs init files (the order
> > in which I'm doing things may not be quite right, for example).
>
> Yeah a classical 100kb init.el is part of the EIHTC Problem (emacs-is-
> hard to customize )
I wouldn't say "hard" exactly, just "not easy". It's complex software,
which means that there's lots of ways to get things wrong.
> I started a strategy of putting all moduls and encapsulate
> corresponding customization in nested subdirs which i source from a
> master init.el. (still struggling how to define relative path in
> elisp)
It sounds like you've gone a little farther than I have with this.
I've got a directory full of init files for different purposes,
and my ~/.emacs does very little more than load them. The idea is
that when I need to look for the source of a subtle problem, I
can just comment out a few lines in my ~/.emacs to narrow it down.
(The next step is going to be to automate that process so I can
write test code that starts up emacs in different ways, and checks
to see if it's working properly... but that is a whole other subject.)
> For instance this is my javascript-subdir with different JS-modes
>
> ~$ ls .emacs.d/elisp/js/
> espresso init.el javascript js2 moz
> ~$ ls .emacs.d/elisp/js/espresso/
> espresso.el init.el
>
> Like this I can try out new moduls and disable them just by commenting
> out a line or two in the mastering init.
Subdirectories are a basic way of organizing files of code, but I think
they're slightly problematic with elisp, because every subdir needs
to be added to the load-path manually. It's not like with perl modules,
where @INC is a series of root locations where perl automatically looks
for things in sub-directories.
(Though I suppose, code could be written to update the load-path
automatically... for that matter, on my workstation, @INC is set-up
automatically by a perl script that I wrote that looks for "blib"
or "lib" locations in all my development locations...)
> Of course sourcing threw a list of nested init.el doesn't speed up
> start-up ... but auto-compiling them into one big init-file should be
> the next step...
I don't worry about speed of start-up myself. On my main workstation,
I just leave emacs up for months at a time... on my laptop, I just live
with it.
On the other hand, when I'm working a job where I need to work on remote
servers over flaky net connections, I do start to envy the "vim" crowd a
little.
Joe Brenner
> >> At a guess, the trouble is in my own emacs init files (the order
> >> in which I'm doing things may not be quite right, for example).
> > Yeah a classical 100kb init.el is part of the EIHTC Problem (emacs-is-
> > hard to customize )
> >
> > I started a strategy of putting all moduls and encapsulate
> > corresponding customization in nested subdirs which i source from a
> > master init.el. (still struggling how to define relative path in
> > elisp)
> >
>
> I have this in my .emacs:
>
> (defconst homedir (getenv "HOME") "My home dir, regardless of host.")
> (setq load-path (cons (concat homedir "/.emacs.d") load-path))
>
> Thus, everything in ~/.emacs.d is findable by (require), (load), etc.
Oh right, I forgot that LanX isn't up on elisp. That could be just what
he needed.
I've got a perl to elisp "rosetta" that I've been working on off and
on:
http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html
I kind of like this idiom:
(setq script-location
(substitute-in-file-name "$HOME/bin"))
LanX
> http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html
Thanks for reminding me... this page/site is on my TODO list for a
long time now... I even already created a user-css to make it readable
for me ;-)
---------------
@namespace url(http://www.w3.org/1999/xhtml);
@-moz-document domain("obsidianrook.com") {
BODY {
background: #eee !important; /* light gray */
color: #000 !important; /* like joe's soul */
font-family: helvetica, verdana, arial, sans-serif;
}
A:link {color: #235 !important; }
A:visited {color: #939!important ;}
A:active {color: red; }
-------------
Cheers
Rolf
Joe Brenner
> > http://obsidianrook.com/devnotes/elisp-for-perl-programmers.html
>
> Thanks for reminding me... this page/site is on my TODO list for a
> long time now... I even already created a user-css to make it readable
> for me ;-)
Is that an objection to my green-screen colors?