Brady Montz <bradym_at_cs.arizona.edu> writes:
> "Jose' Manuel Pereira" <jmp_at_NOdigitais.ist.utl.pt> writes:
> >
> > Too late. scwm is based on it. I currently have installed one of the first
> > releases (0.4, I think) and it is impressively usable & stable.
> > (Then again, they started from fvwm-2.0.46...;-)
> >
> > The authors did what people here are discussing once again:
> >
> > - Junked the current "interpreter". According to fvwm-list, this is
> > a_good_thing.
> >
> > - Chose Guile (scheme) as the new supporting language. According to
> > fvwm-list, this is _evil_, but only for religious reasons. ;-)
>
> Well, I've only suggested that it might be _unwise_ for political reasons.
Many people will tell you :
You know, you've been programming lisp too long, (if (....
(found in a siganture)
Many people don't like the parentheses, but also many people use emacs and
happily use / program elisp.
> > Just one example: the dreaded GSFR is already done. They didn't submit it
> > to this list, allegedly because the C code is too different now for a
> > patch to be any use to fvwm...
> >
> > Yes, the Great Style Flags Rewrite. Big deal, uh?
well not that big, but nobody touched it, because we were waiting for chuck
and nobody wanted to take over. And chuck had much too little time.
> > Personally, I just keep using fvwm2. It does the job and I simply don't have
> > the time to rewrite the .rc again for another wm (although, using Greg
> > Badros' config, now written in scheme, looks strikingly similar to the one I
> > picked up for fvwm...)
Brady Montz:
> Well, this sounds pretty cool to me. I'd wished that I'd heard about it
> sooner. I did an altavista search for scwm, but didn't find anything. Ah, just
> found it on the guile webpage.
>
> I'd even go so far to say that I think we should release the current fvwm, and
> make scwm fvwm version 3. Since scwm looks like what a lot of people would
> like fvwm to become, and renaming scwm to fvwm3 would give them instant name
> recognition and a large user/tester base, it could be a good thing for
> everybody. The only issues would be political (which often are the hardest to
> overcome).
hmm, don't have time now to fiddle, but I'll look into it.
I can't add much to Brady's statement, without testing the product.
I do like the versatility of emacs-lisp, so I sure would jump on a
multithreaded lisp-extensible WM.
o) external access to data
In a prior posting, I also pointed out that a complete language is
still not enough. One still might want to throw in some external
programs, so all internal structures should be accessible from
outside.
You can do that with a lisp-wrapper, as the various lisp-modes in
emacs show (command, compilation, man-mode, shell-mode, and so on).
o) I still would like the interpreter to be optional / transient /
permanent / split / in a shared library.
For most people it's enough to set variables. So they only need
either
a config data dump to be read in at startup or
a transient interpreter, which terminates after setup
If you use lisp functions or hooks you can still benefit from
a split ascii-to-bytecode translator & bytecode interpreter.
All the junky tokens & syntax tables are in the translator
and are therefore dumped after reading and parsing the
config info.
This also speeds things up considerably, since only
bytecode is executed.
Only in the case that an external program outputs ascii lisp
commands to be executed by fvwm or eval() is used, this has to be
fed through the translator.
So the ideal layout would be core fvwm with an option (or command) to
speedload a variable image, and for complex commands a split bytecode
interpreter and ascii-to-bytecode translator.
The bytecode interpreter has to be some sort of library. Getting/putting
common functions from/into a dynamically loaded shared library would be
great. It will usually be swapped out / unloaded after not being
accessed for a while.
The translator (Tokenizer / syntax checker) can be either shared library
or external. Both ways it will be dumped, when it's not used for a while.
--
Albrecht Kadlec
Vienna University of Technology / Department of Automation
----------------------------------------------------------
If you love it, set it free.
If it doesn't come back, hunt it down and kill it. -- (maybe) James McGregor
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu May 07 1998 - 13:03:53 BST