Re: Open Hypspec with w3m

[Tim X]

Jason Earl <jearl@notengoamigos.org> writes:

> On Sat, Jan 29 2011, Tim X wrote:
>
>> Jason Earl <jearl@notengoamigos.org> writes:
>>
>>> On Fri, Jan 28 2011, Stefan Monnier wrote:
>>>
>>>>> within my grasp.  You do realize, of course, that you are essentially
>>>>> volunteering to look over some potentially very bad Elisp.  The only
>>>>
>>>> There's no worse Elisp than the one that's not yet written.
>>>> And believe me, I've seen my share of bad Elisp,
>>>
>>> Thank you very much for the encouragement then.
>>>
>>
>> The things I've found with lisp generally and elisp in particular
>> (because I use it more and more)
>>
>> * Lisp and elisp are actually very easy to learn. Very little syntax,
>>   no difficult to remember operator precedence and consistent form.
>
> The more I learn about Lisp the more I wish I had become curious about
> Lisp years ago.  I have been *using* Emacs to write software for years.
> I can not believe that it never occurred to me to spend more time
> actually hacking Emacs.  When I think of all of the tiny throwaway
> Python scripts I have written over the years to mangle text files
> (usually so that I could edit them in Emacs) it makes me want to cry.
>
>> * Mastering lisp is an on-going process. I suspect this can take years.
>>   Its actually one of the aspects I like about it as I am always seeing
>>   new bits of code or ways of expressing various common idioms. I find
>>   this keeps things 'fresh' and interesting. 
>
> Any skill worth mastering is an on-going process.
>
>> * Really search the manual. Many times I've been trying to implement
>>   some extension or customization and am struggeling with how to
>>   implement some feature only to find, after searching the elisp manual,
>>   that either it already exists or most of the hard work has been done
>>   and all I need to do is glue the bits together. 
>
> Yes, if I would have gotten all the way to defadvice in the manual I
> would not have needed to ask my questions.  Although, I will admit that
> getting sucked into /Practical Common Lisp/ did not help my study of the
> Emacs Lisp Reference.
>
> I realize that I need to study harder, but I am still grateful to you
> and to Stefan for pointing me in the right direction.

It never does any harm to ask for pointers and suggestion in this group.
There are a number of regulars in this group, like Stefan, who are
active contributors/maintainers of emacs. They have both a wealth of
information and are aware of current development/improvements in emacs.

>
>> * Have a go. Just get in there and do it. At first, it will probably be
>>   slow and sometimes frustrating, but it gets much easier as the various
>>   pennies drop into place. While everyone is a bit different, many find
>>   (including me) that writing lisp is almost like a flow of
>>   consciousness - as I'm working out the solution, I'm jotting down
>>   these notes/rough draft and it just turns out that my notes are lisp.
>>   Often, once the basic outline is written down, all I need to do is go
>>   through refining and editing "the story".  
>
> One thing is certain, the parentheses no longer bother me.  That's
> certainly progress.
>
>> * Use the scratch buffer and IELM (M-x ielm) to experiment and try out
>>   ideas. I find 'exploring' a problem this way really helps cement a
>>   solution. Also useful when learning. 
>
> The *scratch* buffer is pretty handy.  I have been using it for
> experimentation, and with company-mode on it is a pretty good tool.
> However, I was wondering why there wasn't something like Slime's REPL
> for Emacs Lisp.  As I mentioned above, I have been working through
> /Practical Common Lisp/ using w3m to read the HTML version and Slime to
> experiment in a REPL as I read.  If you ask me that is the most
> brilliant way to learn a language imaginable.  I am going to buy the
> actual book, as I believe that Peter Seibel and Apress richly deserve my
> money.  But that setup is *way* better than reading a book.  I have done
> most of my studying on my netbook, and so the whole thing is even more
> portable than the book.
>
> Anyway, it turns out that there was something like Slime's REPL for
> Emacs Lisp.  I just did not know what that something was called.
>
> Thank you.
>

Note that emacs also has a cl compatibility package (require 'cl). It is
not a 100% cl compatibility layer, but does bring in some of the useful
cl functions that are not part of standard elisp. This can be very
handy. However, you do need to be careful as there are significant
differences between elisp and cl (I use to constantly get confused!). 

Practicle common lisp is a good text. I also found Paradigms of
Artificial Intelligence really good (don't be put off by the reference
to AI, it has a lot of really good lisp stuff). ANSI Common Lisp is also
quite good and while it took a couple of goes, On Lisp is really good
once you get to the point where you want to start getting to grips with
macros in a serious manner. Although somewhat criticised, I also found
Let Over Lambda an interesting read. 

>> * Read/browse the source code. You will learn various techniques and
>>   'tricks' and get to see how to do many common tasks. This is an
>>   excellent way of understanding a new mode and gives you insight into
>>   how you can tweak it for yourself. 
>
> That is definitely one of the real advantages of Emacs.  Today I decided
> I would "port" one of my small test CL programs to Emacs Lisp.  This
> seemed like an easier first Elisp project than figuring out how to patch
> browse-url.el so that browse-url can use different browsers depending on
> the URL.
>
> Baby steps.
>
> I needed a function that returned the list of files in a directory.
> Firing up ielm I was quickly able to find directory-files (simply by
> starting to type directory hitting TAB and seeing what showed up).
> Unfortunately, that returned the '.' and '..' entries as well as the
> files I actually wanted.
>
> My first impulse was to simply special case those entries, but I was
> curious to see what actual Emacs hackers did.  So I poked around in
> files.el and came across directory-files-no-dot-files-regexp.
>
> This:
>
> (directory-files "/home/jearl/" t directory-files-no-dot-files-regexp)
>
> was precisely what I needed.
>
> Emacs not only has a ridiculously comprehensive manual, easy access to
> all of the docstrings in all of the Elisp (and C) code, and tools like
> the *scratch* buffer and ielm, but it also comes with piles and piles of
> the actual Elisp source that makes up the program.
>
> I hate to admit it, but I basically use Emacs because it was basically
> the only tool around when I first started using Linux.  I got used to
> it, and even for pure end users it is a pretty impressive tool.  Now
> that I am beginning to see it as a learning tool/development environment
> I am a little surprised it is not more popular ;).
>

Yes. A similar situation. I came from vi to emacs (I started with old
Unix systems long before Linux). However, due to some bad luck, I lost
my sight and at the time (mid 90s) the only good interface on Linux for
blind users was emacs and an extension package called emacspeak, which
uses defadvice a lot to add speech support. The learning curve was very
steep at first and emacs seemed very alien compared to the vi. However
now I am very much at home with it. Last year, after over 15 years, I
was lucky enough to get a considerable amount of sigh back, but even
though I could go back to using vi, I've been totally sucked in by the
power and flexibility of emacs. 

There are frequent arguments/debates in this group regarding emacs'
failure as an IDE. I think the critics are possibly missing the main
point. While other IDEs, like eclipse or visual studio etc, may offer
lots of great features and do so pretty much out of the box, you still
need to very much structure your workflow to fit the tool. For me, emacs
has the advantage of allowing me to structure the tool to fit with my
preferred workflow, plus I can do most of my development related tasks
which are not strictly speaking coding, with it as well. I find the
combination of org-mode, the various development modes, vcs, w3m and
mail all being within one tool, emacs, incredibly useful.  I have built
up a toolbox of handy and useful bits of elisp and collected even more
from posts to this and other groups. I really like the fact that all my
important stuff is in plain text format and managed under version
control. For the last year or so, I've been making increasing use of
org-mode. It has revolutionised how I work . A mode I cannot recommend
highly enough for any emacs user. 

>> As you get more comfortable with elisp, you will likely be surprised
>> how often you crank out a simple rough emacs function to automate some
>> task your doing - even just one-offs that were maybe a little too
>> complicated for just a macro. However, just one warning. It can become
>> addictive. f your not careful, you may find yourself spending too many
>> hours hacking out bits of elisp or re-inventing features which already
>> exist. Not really a problem unless it starts cuasing negative impact
>> on the rest of your life!
>

Tim

-- 
tcross (at) rapttech dot com dot au