Re: lynx-dev lynx: various emacs-like HOOKS that eg CAN run (call?) eg perl?

[Vlad Harchev]

On Tue, 13 Jun 2000, David Combs wrote:

> Emacs has always had the concept of a "hook", like a hook on
> the wall where you can hang, NOT a coat or hat but rather some
> CODE, that (once something is hanging from the hook) gets
> executed whenever execution hits that point.
> 
> Is a really cool concept -- distribute these hooks around in 
> interesting places in the emacs code, and then the USER can
> use an emacs' USER-cmd to PLACE code on this or that hook,
> and he has CHANGED how emacs works -- without EVER having
> to see (or hack!) the emacs's source!
> 
> (All he has to do is read in the user-manual how to ADD something
> to one of the pre-placed hooks.  And know ENOUGH of the 
> language that the
> emacs interpreter knows (emacs lisp) to be able to WRITE
> the code he wants to hang there.)
> 
> Seems like "hooks" would be a neat feature for lynx, ESPECIALLY
> for the SYS-ADMINS who have various in-house "customers" --
> it would let them add pseudo-features TO lynx, and quickly, too.
> 
> ----
> 
> Now, some lynx-hackers on this list also know PERL, a not
> bad language for perhaps adding quicko extensions to lynx -- 
> esp with all the string-stuff, internet-stuff, etc, that it
> provides.
> 
> Myself, am still learning perl (one HUGE language, filled
> with "dwim" that (unlike in emacs with IT'S dwim) you
> MUST know in order to read any code (which is I suppose
> why some people prefer python -- which itself might be
> a good (better?) lang for these "personal-extensions" to
> lynx)) -- 
> 
> --  but SOME LYNX-hackers likely also program in
> perl (or python, or scheme, or SOMETHING that might be
> good for this) -- which is why I make this suggestion to
> our list.
> 
> --
> 
> So, perhaps a hook could be placed at, for instance, the central
> "get and execute next command" loop , enabling us
> to add our own commands?   Etc, etc.
> 
> Any comments or ideas on this "hooks for lynx" idea?
> 

 As for me, IMO lynx's internals are badly suited for interface with anything
external, even C code, and making them suitable will be a waste of time
compared to the goals to achieve. Also, it looks like there are only few
places where hooks could extend lynx's functionality (seems it has a command 
or option for almost anything needed (well, except interactive control over 
rendering frames and tables)). Also, "new commands" and "hooks to existing
code" should be separated since these are different tasks that can be achieved
in different more simple ways. As for commands  - since lynx is console app,
it can be scripted/controlled externally using tools like expect or screen.
 As for hooks to existing code - it seems it's better to do functionality they
provide in C, and control them with yet another lynx.cfg settings.

 The point stated above is from POV view of a rather experienced lynx user. As
for lynx newbie's POV, hooks would be nice - but 99% of them would be
interaction with newbie user sort of "do you want the list of visited
documents to be saved?" on exit, etc (i.e. duplicate the functionality that 
experienced lynx user could achieve by tweaking lynx.cfg or C code:)
  As for scripts to choose - it's maintainer's headache IMO. From that POV it 
could be perferable to use SLang scripting language that is provided with 
slang terminal handling package - it's small and portable, though rather 
lowlevel as C.

> David
> 
> 
> 
> ; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden
> 

 Best regards,
  -Vlad


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden