Open Hypspec with w3m

Open Hypspec with w3m

[Jason Earl]

I have been spending a bit of my free time learning Common Lisp (and
enjoying it).  Part of learning Common Lisp is getting to know the
HyperSpec.  The fact that Emacs includes a function 'hyperspec-lookup
that makes this a matter of a few keystrokes is very helpful.  However,
by default this opens up the page in Firefox, and I would pretty much
always like to open the HyperSpec in w3m.  I would change the default
browse-url-browser-function, but I generally want to open URLs with
Firefox.

For Common Lisp buffers I make 'browse-url-browser-function a local
variable and set it to 'w3m-browse-url.

--8<---------------cut here---------------start------------->8---
(add-hook 'lisp-mode-hook 'jadoea-lispstuff)

;; my python configuration
(defun jadoea-lispstuff ()
  "Custom Lisp Configurator.

Turn on flyspell-prog-mode.  Clean up whitespace on save (leave
tabs).  Make browse-url-browser-function buffer-local and set it
to browse-url-w3m."
  (flyspell-prog-mode)
  (add-hook 'before-save-hook
            (lambda ()
	      (jadoea-clean-whitespace t nil)) nil t)
  (make-local-variable 'browse-url-browser-function)
  (setq browse-url-browser-function 'w3m-browse-url))
--8<---------------cut here---------------end--------------->8---

This works great as long as I am in a Common Lisp buffer, but I find
myself constant wanting to look up stuff from the HyperSpec while in a
Slime REPL, or some other type of buffer.

So is there a way to override 'hyperspec-lookup so that it always
behaves as if browse-url-browser-function was 'w3m-browse-url?

I build Emacs from source, and I maintain my own branch so that I can
easily deploy Emacs on various machines.  So I considered simply hacking
common-lisp-hyperspec to do what I wanted.  However, that hardly seems
like the cleanest way to do this sort of thing.

Any suggestions?

Thanks,
Jason

Re: Open Hypspec with w3m

[Tim X]

Jason Earl <jearl@notengoamigos.org> writes:

> I have been spending a bit of my free time learning Common Lisp (and
> enjoying it).  Part of learning Common Lisp is getting to know the
> HyperSpec.  The fact that Emacs includes a function 'hyperspec-lookup
> that makes this a matter of a few keystrokes is very helpful.  However,
> by default this opens up the page in Firefox, and I would pretty much
> always like to open the HyperSpec in w3m.  I would change the default
> browse-url-browser-function, but I generally want to open URLs with
> Firefox.
>
> For Common Lisp buffers I make 'browse-url-browser-function a local
> variable and set it to 'w3m-browse-url.
>
> (add-hook 'lisp-mode-hook 'jadoea-lispstuff)
>
> ;; my python configuration
> (defun jadoea-lispstuff ()
>   "Custom Lisp Configurator.
>
> Turn on flyspell-prog-mode.  Clean up whitespace on save (leave
> tabs).  Make browse-url-browser-function buffer-local and set it
> to browse-url-w3m."
>   (flyspell-prog-mode)
>   (add-hook 'before-save-hook
>             (lambda ()
> 	      (jadoea-clean-whitespace t nil)) nil t)
>   (make-local-variable 'browse-url-browser-function)
>   (setq browse-url-browser-function 'w3m-browse-url))
>
> This works great as long as I am in a Common Lisp buffer, but I find
> myself constant wanting to look up stuff from the HyperSpec while in a
> Slime REPL, or some other type of buffer.
>
> So is there a way to override 'hyperspec-lookup so that it always
> behaves as if browse-url-browser-function was 'w3m-browse-url?
>
> I build Emacs from source, and I maintain my own branch so that I can
> easily deploy Emacs on various machines.  So I considered simply hacking
> common-lisp-hyperspec to do what I wanted.  However, that hardly seems
> like the cleanest way to do this sort of thing.
>
> Any suggestions?
>

You could try using defadvice and advise hyperspec-lookup. In the advice,
locally bind browse-url-browser-function to use w3m. I guess you would
need either 'before or 'around form of defadvice. 

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Open Hypspec with w3m

[Stefan Monnier]

> So is there a way to override 'hyperspec-lookup so that it always
> behaves as if browse-url-browser-function was 'w3m-browse-url?

You can use defadvice (with `around' advice) on hyperspec-lookup to
let-bind browse-url-browser-function for the duration of that function.


        Stefan


PS: Another attack vector is to globally set browse-url-browser-function
to a function that either invokes emacs-23m or firefox depending on
the URL.  Some Emacs maintainer I know might even be willing to accept
patches to provide such a feature more generally, e.g. via
a configuration variable that lists URL patterns that should use
emacs-w3m.

Re: Open Hypspec with w3m

[Jason Earl]

On Fri, Jan 28 2011, Tim X wrote:

> Jason Earl <jearl@notengoamigos.org> writes:
>
>> I have been spending a bit of my free time learning Common Lisp (and
>> enjoying it).  Part of learning Common Lisp is getting to know the
>> HyperSpec.  The fact that Emacs includes a function 'hyperspec-lookup
>> that makes this a matter of a few keystrokes is very helpful.  However,
>> by default this opens up the page in Firefox, and I would pretty much
>> always like to open the HyperSpec in w3m.  I would change the default
>> browse-url-browser-function, but I generally want to open URLs with
>> Firefox.
>>
>> For Common Lisp buffers I make 'browse-url-browser-function a local
>> variable and set it to 'w3m-browse-url.
>>
>> (add-hook 'lisp-mode-hook 'jadoea-lispstuff)
>>
>> ;; my python configuration
>> (defun jadoea-lispstuff ()
>>   "Custom Lisp Configurator.
>>
>> Turn on flyspell-prog-mode.  Clean up whitespace on save (leave
>> tabs).  Make browse-url-browser-function buffer-local and set it
>> to browse-url-w3m."
>>   (flyspell-prog-mode)
>>   (add-hook 'before-save-hook
>>             (lambda ()
>> 	      (jadoea-clean-whitespace t nil)) nil t)
>>   (make-local-variable 'browse-url-browser-function)
>>   (setq browse-url-browser-function 'w3m-browse-url))
>>
>> This works great as long as I am in a Common Lisp buffer, but I find
>> myself constant wanting to look up stuff from the HyperSpec while in a
>> Slime REPL, or some other type of buffer.
>>
>> So is there a way to override 'hyperspec-lookup so that it always
>> behaves as if browse-url-browser-function was 'w3m-browse-url?
>>
>> I build Emacs from source, and I maintain my own branch so that I can
>> easily deploy Emacs on various machines.  So I considered simply hacking
>> common-lisp-hyperspec to do what I wanted.  However, that hardly seems
>> like the cleanest way to do this sort of thing.
>>
>> Any suggestions?
>>
>
> You could try using defadvice and advise hyperspec-lookup. In the
> advice, locally bind browse-url-browser-function to use w3m. I guess
> you would need either 'before or 'around form of defadvice.

That looks like what I need.  Thank you very much.  I will do a little
bit of experimenting and post a solution.

Jason

[SOLUTION] Open Hypspec with w3m

[Jason Earl]

On Fri, Jan 28 2011, Jason Earl wrote:

> On Fri, Jan 28 2011, Tim X wrote:
>
>> Jason Earl <jearl@notengoamigos.org> writes:
>>
>>> I have been spending a bit of my free time learning Common Lisp (and
>>> enjoying it).  Part of learning Common Lisp is getting to know the
>>> HyperSpec.  The fact that Emacs includes a function 'hyperspec-lookup
>>> that makes this a matter of a few keystrokes is very helpful.  However,
>>> by default this opens up the page in Firefox, and I would pretty much
>>> always like to open the HyperSpec in w3m.  I would change the default
>>> browse-url-browser-function, but I generally want to open URLs with
>>> Firefox.
>>>
>>> For Common Lisp buffers I make 'browse-url-browser-function a local
>>> variable and set it to 'w3m-browse-url.
>>>
>>> (add-hook 'lisp-mode-hook 'jadoea-lispstuff)
>>>
>>> ;; my python configuration
>>> (defun jadoea-lispstuff ()
>>>   "Custom Lisp Configurator.
>>>
>>> Turn on flyspell-prog-mode.  Clean up whitespace on save (leave
>>> tabs).  Make browse-url-browser-function buffer-local and set it
>>> to browse-url-w3m."
>>>   (flyspell-prog-mode)
>>>   (add-hook 'before-save-hook
>>>             (lambda ()
>>> 	      (jadoea-clean-whitespace t nil)) nil t)
>>>   (make-local-variable 'browse-url-browser-function)
>>>   (setq browse-url-browser-function 'w3m-browse-url))
>>>
>>> This works great as long as I am in a Common Lisp buffer, but I find
>>> myself constant wanting to look up stuff from the HyperSpec while in a
>>> Slime REPL, or some other type of buffer.
>>>
>>> So is there a way to override 'hyperspec-lookup so that it always
>>> behaves as if browse-url-browser-function was 'w3m-browse-url?
>>>
>>> I build Emacs from source, and I maintain my own branch so that I
>>> can easily deploy Emacs on various machines.  So I considered simply
>>> hacking common-lisp-hyperspec to do what I wanted.  However, that
>>> hardly seems like the cleanest way to do this sort of thing.
>>>
>>> Any suggestions?
>>>
>>
>> You could try using defadvice and advise hyperspec-lookup. In the
>> advice, locally bind browse-url-browser-function to use w3m. I guess
>> you would need either 'before or 'around form of defadvice.
>
> That looks like what I need.  Thank you very much.  I will do a little
> bit of experimenting and post a solution.

It turns out the solution was much easier than I would have guessed.  I
assumed that I would have to read the manual for a bit.  However, this
bit of Elisp seems to have done the trick.

--8<---------------cut here---------------start------------->8---
(defadvice hyperspec-lookup (around hyperspec-lookup-around)
  "I always want `hyperspec-lookup' to use 'w3m-browse-url."
  (let ((browse-url-browser-function 'w3m-browse-url))
    ad-do-it))

(ad-activate 'hyperspec-lookup)
--8<---------------cut here---------------end--------------->8---

Jason

Re: Open Hypspec with w3m

[Jason Earl]

On Fri, Jan 28 2011, Stefan Monnier wrote:

>> So is there a way to override 'hyperspec-lookup so that it always
>> behaves as if browse-url-browser-function was 'w3m-browse-url?
>
> You can use defadvice (with `around' advice) on hyperspec-lookup to
> let-bind browse-url-browser-function for the duration of that
> function.

That worked perfectly.  Thank you.

> PS: Another attack vector is to globally set
> browse-url-browser-function to a function that either invokes
> emacs-23m or firefox depending on the URL.  Some Emacs maintainer I
> know might even be willing to accept patches to provide such a feature
> more generally, e.g. via a configuration variable that lists URL
> patterns that should use emacs-w3m.

I would love to try and do that, despite the fact that the defadvice
solution seems to do precisely what I want.  I think that should be
within my grasp.  You do realize, of course, that you are essentially
volunteering to look over some potentially very bad Elisp.  The only
reason that I needed your advice is that I haven't made it all the way
through the Elisp manual :).

Either way, thanks for the challenge.

Jason

Re: [SOLUTION] Open Hypspec with w3m

[Stefan Monnier]

> --8<---------------cut here---------------start------------->8---
> (defadvice hyperspec-lookup (around hyperspec-lookup-around)
>   "I always want `hyperspec-lookup' to use 'w3m-browse-url."
>   (let ((browse-url-browser-function 'w3m-browse-url))
>     ad-do-it))

> (ad-activate 'hyperspec-lookup)
> --8<---------------cut here---------------end--------------->8---
IIRC you can replace the call to ad-activate with an `activate' argument
after `hyperspec-lookup-around'.


        Stefan

Re: Open Hypspec with w3m

[Stefan Monnier]

> 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,


        Stefan

Re: [SOLUTION] Open Hypspec with w3m

[Jason Earl]

On Fri, Jan 28 2011, Stefan Monnier wrote:

>> --8<---------------cut here---------------start------------->8---
>> (defadvice hyperspec-lookup (around hyperspec-lookup-around)
>>   "I always want `hyperspec-lookup' to use 'w3m-browse-url."
>>   (let ((browse-url-browser-function 'w3m-browse-url))
>>     ad-do-it))
>
>> (ad-activate 'hyperspec-lookup)
>> --8<---------------cut here---------------end--------------->8---
> IIRC you can replace the call to ad-activate with an `activate' argument
> after `hyperspec-lookup-around'.

Thanks, that is much better.  I should have read the manual more
closely.

Jason

Re: Open Hypspec with w3m

[Jason Earl]

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.

Jason

Re: Open Hypspec with w3m

[Tim X]

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.

* 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. 

* 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. 

* 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".  

* 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. 

* 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. 

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!

have fun

Tim


-- 
tcross (at) rapttech dot com dot au

Re: Open Hypspec with w3m

[rusi]

On Jan 30, 3:53 am, Tim X <t...@nospam.dev.null> wrote:
>
> * 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.

Thanks (learn something new everyday)

Re: Open Hypspec with w3m

[Jason Earl]

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.

> * 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.

> * 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 ;).

> 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!

Everyone needs a hobby.  Hacking Emacs at least is potentially useful.

Thanks again.

Jason

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

Re: Open Hypspec with w3m

[Perry Smith]

On Jan 29, 2011, at 10:05 PM, rusi wrote:

> On Jan 30, 3:53 am, Tim X <t...@nospam.dev.null> wrote:
>> 
>> * 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.
> 
> Thanks (learn something new everyday)

Me too.  I was exploring and (blush) discovered that my alt key is
hooked up as "super".  Been using GNU emacs since it first appeared
in, what was it 86 or so?, and I didn't know that!  I knew that emacs 
had the lisp super concept but didn't know that it was hooked up on
my Mac.

Re: Open Hypspec with w3m

[Krzysztof Bieniasz]

> Me too.  I was exploring and (blush) discovered that my alt key is
> hooked up as "super".  Been using GNU emacs since it first appeared in,
> what was it 86 or so?, and I didn't know that!  I knew that emacs had
> the lisp super concept but didn't know that it was hooked up on my Mac.

That's funny. My Emacs recognizes the "windows key" as Super and the 
"menu key" as M-x. There are no predefined s- keybindings in Emacs 
(AFAIK) so it's a wonderful opportunity for customizations. It seams that 
the "windows key" won't be disappearing from the PC keyboards anytime 
soon -- although it should be considered a criminal offense to place the 
logo there. There is also the possibility of rebinding the "menu key" to 
Hyper allowing for still greater amount of customizations. It could be 
almost like working on a Lisp Machine :).

KB

Re: Open Hypspec with w3m (morphed into keyboards, etc)

[Perry Smith]

On Jan 30, 2011, at 9:11 AM, Krzysztof Bieniasz wrote:

>> Me too.  I was exploring and (blush) discovered that my alt key is
>> hooked up as "super".  Been using GNU emacs since it first appeared in,
>> what was it 86 or so?, and I didn't know that!  I knew that emacs had
>> the lisp super concept but didn't know that it was hooked up on my Mac.
> 
> That's funny. My Emacs recognizes the "windows key" as Super and the 
> "menu key" as M-x. There are no predefined s- keybindings in Emacs 
> (AFAIK) so it's a wonderful opportunity for customizations. It seams that 
> the "windows key" won't be disappearing from the PC keyboards anytime 
> soon -- although it should be considered a criminal offense to place the 
> logo there. There is also the possibility of rebinding the "menu key" to 
> Hyper allowing for still greater amount of customizations. It could be 
> almost like working on a Lisp Machine :).

I think they roughly match up.  Moving left from the space bar, on the Mac,
you have the "command" key, then the "alt / option" key, then the control key,
and then another key sometimes called control and other times called "fn" on
the laptop's keyboard.

I need to be careful though because I use emacs via VNC / X11.  I need
to experiment while at work to see how these keys map in that environment.

Re: Open Hypspec with w3m (morphed into keyboards, etc)

[Krzysztof Bieniasz]

> I think they roughly match up.  Moving left from the space bar, on the
> Mac, you have the "command" key, then the "alt / option" key, then the
> control key, and then another key sometimes called control and other
> times called "fn" on the laptop's keyboard.

Mac's "option/alt" key is in the place of PC's "windows" key while the 
"command" key (the one with an apple) is in the place of PC's alt key. To 
further confuse things the "windows" key is only on the left while 
symmetrically on the right we have the "menu" key. And the right Alt is 
in fact an "AltGr" which is a different modifier then the left Alt. 
Furthermore some keyboards (especially on laptops) have a "Fn" modifier 
for hardware operations, which is placed only on the left, between the 
"control" and "windows". So obviously your Alt and my "windows" are the 
same key, only they have different names.

Re: Open Hypspec with w3m (morphed into keyboards, etc)

[Krzysztof Bieniasz]

> I think they roughly match up.  Moving left from the space bar, on the
> Mac, you have the "command" key, then the "alt / option" key, then the
> control key, and then another key sometimes called control and other
> times called "fn" on the laptop's keyboard.

Mac's "option/alt" key is in the place of PC's "windows" key while the 
"command" key (the one with an apple) is in the place of PC's alt key. To 
further confuse things the "windows" key is only on the left while 
symmetrically on the right we have the "menu" key. And the right Alt is 
in fact an "AltGr" which is a different modifier then the left Alt. 
Furthermore some keyboards (especially on laptops) have a "Fn" modifier 
for hardware operations, which is placed only on the left, between the 
"control" and "windows". So obviously your Alt and my "windows" are the 
same key, only they have different names.

Re: Open Hypspec with w3m (morphed into keyboards, etc)

[Krzysztof Bieniasz]

> I think they roughly match up.  Moving left from the space bar, on the
> Mac, you have the "command" key, then the "alt / option" key, then the
> control key, and then another key sometimes called control and other
> times called "fn" on the laptop's keyboard.

Mac's "option/alt" key is in the place of PC's "windows" key while the 
"command" key (the one with an apple) is in the place of PC's alt key. To 
further confuse things the "windows" key is only on the left while 
symmetrically on the right we have the "menu" key. And the right Alt is 
in fact an "AltGr" which is a different modifier then the left Alt. 
Furthermore some keyboards (especially on laptops) have a "Fn" modifier 
for hardware operations, which is placed only on the left, between the 
"control" and "windows". So obviously your Alt and my "windows" are the 
same key, only they have different names.

Re: Open Hypspec with w3m

[Jason Earl]

Thank you (again) very much for responding.

On Sun, Jan 30 2011, Tim X wrote:

[...]

> 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.

I really do appreciate the pointers.

[...]

> 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.

Thanks for the advice.  It certainly does help to know what to study
next.

[...]

>> 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.

I am glad that you got (most of) your sight back.  I want to use phrases
like eye-opening or enlightening, but I do not want you to think that I
am making the obvious bad pun.

> 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.

I have high hopes that with the inclusion of CEDET that Emacs can start
making progress on the IDE front.  I basically feel the same way about
Emacs as you do.  I've used Eclipse and Netbeans, and I did not like
them, even for Java development.  Sure, there were some things that they
did *much* better than Emacs, but mostly they just seemed to get in the
way.

I've played a bit with CEDET's EDE, however, and it was definitely cool
to build Autoconf projects from Emacs.  Eventually I really would like
to be able to help move things forward.

Jason

Re: Open Hypspec with w3m

[rusi]

> On Sun, Jan 30 2011, Tim X wrote:
> > 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,

OOO Thats very good to hear!

On Feb 1, 9:15 am, Jason Earl <je...@notengoamigos.org> wrote:
> I have high hopes that with the inclusion of CEDET that Emacs can start
> making progress on the IDE front.  I basically feel the same way about
> Emacs as you do.  I've used Eclipse and Netbeans, and I did not like
> them, even for Java development.  Sure, there were some things that they
> did *much* better than Emacs, but mostly they just seemed to get in the
> way.
>
> I've played a bit with CEDET's EDE, however, and it was definitely cool
> to build Autoconf projects from Emacs.  Eventually I really would like
> to be able to help move things forward.

It seems to me that cooperativeness helps open source projects more
than competitiveness.
In particular if emacs had something like eclim it would be the best
of all worlds.
The only downside would be memory footprint.  Who cares about that
anyway nowadays especially if we have customizability, autoloading etc

Re: Open Hypspec with w3m

[Tim X]

rusi <rustompmody@gmail.com> writes:

>> On Sun, Jan 30 2011, Tim X wrote:
>> > 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,
>
> OOO Thats very good to hear!

Sometimes I'm a fool! The main reason I mentioned my sight issue was to
mention what an interesting package emacspeak is. This is one package
whih shows what you can do with emacs and a little imagination.
Essentially, it adds spoken feedback to everything you do in emacs. As
you type, letters are spelt out and spoken, lines are spoken and you can
get the whole screen spoken. In addition to that, it has something
unique in the adaptive technology field - voice lock. This is like
font-lock, except rather than using colours, it uses different voices
and voice pitch. So, when doing something like programming, keywords,
constants comments, strings etc are all spoken in a different voice.
Sound icons are used to indicate various operations, such as saving a
file or opening an email message which also contains atachments etc. 

Nearly all of this is made possible through the use of defadvice and
lots of supporting helper functions. It shows that what you can do with
emacs is largely down to your imagination as all the power is there. 

>
> On Feb 1, 9:15 am, Jason Earl <je...@notengoamigos.org> wrote:
>> I have high hopes that with the inclusion of CEDET that Emacs can start
>> making progress on the IDE front.  I basically feel the same way about
>> Emacs as you do.  I've used Eclipse and Netbeans, and I did not like
>> them, even for Java development.  Sure, there were some things that they
>> did *much* better than Emacs, but mostly they just seemed to get in the
>> way.
>>
>> I've played a bit with CEDET's EDE, however, and it was definitely cool
>> to build Autoconf projects from Emacs.  Eventually I really would like
>> to be able to help move things forward.
>
> It seems to me that cooperativeness helps open source projects more
> than competitiveness.
> In particular if emacs had something like eclim it would be the best
> of all worlds.
> The only downside would be memory footprint.  Who cares about that
> anyway nowadays especially if we have customizability, autoloading etc

There are a few things I'd like to see improved with emacs. I wished it
had multi-threading for example. While elisp is great for the main tasks
it does, I'd also love a more sophisticated/powerful language. While I'm
doubtful it will ever happen, it would be interesting to have an emacs
that used something like guile or even common lisp as its underlying
extension language. This has been talked about for years, but I'm not
sure if we will ever get there. I'm not even sure if the way to go would
be to convert emacs to something like guile or start a whole new system
that was able to benefit from the experience of Emacs and maybe avoid
some of the mistakes or poorer design decisions . This is not to say that
I'm critical of the work which has and is being done - there seem to be
very few decisions that have been poor choices. For the years I've been
using emacs, I think on the whole, the emacs development and maintenance
team have done an excellent job and I would not want my comments to seem
critical of this. What I'm referring to is the ability to make better
choices now we have the benefit of more experience and greater
udnerstanding of the issues. In fact, it seems to me that there has been
some reinvigoration with respect to emacs development over the last few
years and things do appear brighter than they have at times in the past. 

For now, I'm pleased we have what we have and am thankful for that.

Tim


 
-- 
tcross (at) rapttech dot com dot au

Current Emacs Development (was: Open Hypspec with w3m)

[Jason Earl]

On Tue, Feb 01 2011, Tim X wrote:

[...]

> Sometimes I'm a fool! The main reason I mentioned my sight issue was
> to mention what an interesting package emacspeak is. This is one
> package whih shows what you can do with emacs and a little
> imagination.  Essentially, it adds spoken feedback to everything you
> do in emacs. As you type, letters are spelt out and spoken, lines are
> spoken and you can get the whole screen spoken. In addition to that,
> it has something unique in the adaptive technology field - voice
> lock. This is like font-lock, except rather than using colours, it
> uses different voices and voice pitch. So, when doing something like
> programming, keywords, constants comments, strings etc are all spoken
> in a different voice.  Sound icons are used to indicate various
> operations, such as saving a file or opening an email message which
> also contains atachments etc.
>
> Nearly all of this is made possible through the use of defadvice and
> lots of supporting helper functions. It shows that what you can do
> with emacs is largely down to your imagination as all the power is
> there.

I've actually played a bit with Emacspeak.  It is a very cool piece of
software.  It is strangely comforting to think that I could use Emacs
even if I were to go blind.

> There are a few things I'd like to see improved with emacs. I wished
> it had multi-threading for example.

I lurk on emacs-devel, and apparently Tom Tromey has a multi-threading
branch that is getting ready to be merged to trunk.  In fact, I think
that it would be merged already, but they've had issues with the Windows
build stuff.

From what I understand this is mostly just scaffolding, but real work is
apparently getting done.

> While elisp is great for the main tasks it does, I'd also love a more
> sophisticated/powerful language. While I'm doubtful it will ever
> happen, it would be interesting to have an emacs that used something
> like guile or even common lisp as its underlying extension language.

I could point to work being done on this front as well, but I could
probably have done that 5 years ago as well.

I don't know enough scheme or Common Lisp to know where I stand in this
debate.  But there are certainly worse tools than Emacs Lisp.

> This has been talked about for years, but I'm not sure if we will ever
> get there. I'm not even sure if the way to go would be to convert
> emacs to something like guile or start a whole new system that was
> able to benefit from the experience of Emacs and maybe avoid some of
> the mistakes or poorer design decisions . This is not to say that I'm
> critical of the work which has and is being done - there seem to be
> very few decisions that have been poor choices. For the years I've
> been using emacs, I think on the whole, the emacs development and
> maintenance team have done an excellent job and I would not want my
> comments to seem critical of this. What I'm referring to is the
> ability to make better choices now we have the benefit of more
> experience and greater udnerstanding of the issues. In fact, it seems
> to me that there has been some reinvigoration with respect to emacs
> development over the last few years and things do appear brighter than
> they have at times in the past.

There was a time when I went actively looking for a replacement for
Emacs.  It seems that nearly every computer language ever invented has
spawned an Emacs-alike (or two).  Some are even pretty good.  None of
them, that I tried anyway, got to the point where they replaced Emacs
for me.

There are plenty of editors these days where it is easy (or even
trivial) to rewrite bits yourself.  But there are none that have the
traction, history, and huge code base that Emacs does.

> For now, I'm pleased we have what we have and am thankful for that.

Exactly.

Personally, I think that Emacs development is even moving in
approximately the right direction.  Not to disparage RMS, but he simply
was too busy (and too conservative) to really drive Emacs along.

All I know is that I would not even consider using a released version of
Emacs again.  The version in bzr is much better (even if it breaks
occasionally).

Jason

Re: Current Emacs Development

[Stefan Monnier]

> I lurk on emacs-devel, and apparently Tom Tromey has a multi-threading
> branch that is getting ready to be merged to trunk.  In fact, I think
> that it would be merged already, but they've had issues with the Windows
> build stuff.

That's not quite what is happening.  There is a concurrency branch that
provides a proof-of-concept implementation of
cooperative multithreading.  Tom is working on updating the branch to be
in sync with the current trunk, and he's also working on including the
refactoring part of that branch into the trunk, so that the concurrency
branch is easier to maintain while still being outside of the trunk.

We had plans to possibly include the concurrency branch into 24 as an
experimental feature.  It's still not clear whether that will happen
or not.  I'm personally more concerned with merging the lexical-scoping
branch for Emacs-24 (and I think lexical-scoping is an important
prerequisite for concurrency), but that also needs some more work.


        Stefan

Re: Current Emacs Development

[Jason Earl]

On Tue, Feb 01 2011, Stefan Monnier wrote:

>> I lurk on emacs-devel, and apparently Tom Tromey has a multi-threading
>> branch that is getting ready to be merged to trunk.  In fact, I think
>> that it would be merged already, but they've had issues with the Windows
>> build stuff.
>
> That's not quite what is happening.  There is a concurrency branch
> that provides a proof-of-concept implementation of cooperative
> multithreading.  Tom is working on updating the branch to be in sync
> with the current trunk, and he's also working on including the
> refactoring part of that branch into the trunk, so that the
> concurrency branch is easier to maintain while still being outside of
> the trunk.
>
> We had plans to possibly include the concurrency branch into 24 as an
> experimental feature.  It's still not clear whether that will happen
> or not.  I'm personally more concerned with merging the
> lexical-scoping branch for Emacs-24 (and I think lexical-scoping is an
> important prerequisite for concurrency), but that also needs some more
> work.

Thanks for clearing that up.

Jason

Re: Open Hypspec with w3m

[Andy Moreton]

On Fri 28 Jan 2011, Jason Earl wrote:

> So is there a way to override 'hyperspec-lookup so that it always
> behaves as if browse-url-browser-function was 'w3m-browse-url?

Something like this (untested) code may help:

(defadvice common-lisp-hyperspec (around common-lisp-hyperspec/w3m activate)
  "Use w3m to lookup symbols in the Common Lisp HyperSpec."
  (let ((browse-url-browser-function 'w3m-browse-url))
    ad-do-it))

HTH,

    AndyM