This message is triggered by Waldek's comments on emacsreadline.
I am trying to generalise the issues, with examples.
In February, Andreas Eder discovered that adding emacsreadline to the
startup image allowed more complex command lines to be dealt with.
(Used in the popracer project in 32 bit Poplog)
In 32-bit Poplog (up to V15) that inclusion was the default and I suspect a
number of projects/demos made use of that functionality.
Waldek commented:
> so loading 'emacsreadline' gives behaviour from V15. In V15
> 'mkstartup' loads a lot of things, including 'readline'.
>
> In V16 'mkstartup' is much smaller. Smaller 'mkstartup' is
> needed to allow build without X. AFAICS if more things
> should go into startup image, then they should be added
> to 'pop/lib/lib/startup.p'. This requires a bit of work,
> as things depending on X should go into proper conditional.
>
> BTW: 64-bit V15 had a bug in memory management and putting
> stuff in 'mkstartup' probably was a workaround. But no
> such workaround should be needed in V16.
Perhaps there could be a default basic startup with a 'minimal' amount of
functionality, and minimal dependence on additional linux libraries,
avaliable at startup so as to allow poplog to be used in as many different
environments as possible (including impoverished environments), with the
option for users either to add extra machinery in the process that builds
the 'startup' saved image to be run on top of basepop11, or to use the
standard startup and build more complex mechanisms on top of that in
higher-order saved images, using the layering mechanisms already available
to build any of prolog, common lisp, or standard ML, or combinations of
those, on top of the pop11 startup.psv. That uses higher-order
saved images -- stacked saved images that can be invoked at startup.
It is already (or was) quite common for different users or different teams
to have different saved images in $popsavelib (or private extension
libraries).
This would need tutorials and demos showing how to achieve that.
But some additional facilities cannot be added that way because they
require changes during the construction of basepop11 e.g. adding support
for motif.
It's not clear how best to support this variety of options.
A bit of history may be relevant. For several years Brian Logan worked with
me on a sequence of poplog-based projects. I always used Ved for my
editing, but Brian disliked it so much that he did quite a lot of work to
enable emacs to replicate all the required functionality of Ved while
communicating with poplog in a separate process.
This required extensions to emacs (which is also programmable) as well as
extensions to poplog. The poplog developers at Sussex university had
previously provided an interface to emacs, but Brian extended it
significantly. This included extending emacs addons. Hence the existence of
vedemacs. See
$usepop/pop/help/vedemacs
(Which preceded Brian's work)
That raises the question: can we provide options at the time poplog is
built, that allow different sorts of functionality to be included at quite
a low level, like the functionality required for libemacs, but also
allowing them not to be included if if poplog is to be used in an
environment where the required components are absent?
Compare the ability to include or not include motif, provided by Waldek,
and reported at the end of the poplog installation process, which now
prints out
NB IF YOU INTEND TO USE MOTIF,
MAKE SURE THE LINUX MOTIF LIBRARY HAS BEEN INSTALLED, E.G.
motif-devel IN FEDORA, ETC, libmotif-dev IN UBUNTU AND openmotif IN ARCH
To link poplog with motif first make sure that $usepop is set
Then do $usepop/pop/src/newpop -link -x=-xm -norsv
That does quite a lot of re-building at a low level, to include support for
interactions with motif libraries
Could something similar be done after installation to support the vedemacs
package without requiring the mechanisms always to be built in?
Of course, the more such options are provided, the more complex and messy
Poplog becomes -- but it does provide support for more potential users.
Not all such extensions need be compatible with the others.
Can all this be done by a group of people mostly with other main
occupations, collaborating part-time through github?
It will need a clean, high level design, for a set of build-time options,
e.g. motif without emacs, emacs wtihout motif, or both emacs and motif.
Incidentally there's a major part of poplog that was used by commercial
customes of ISL, which depends on motif (or, in the old days on sun
workstations, Openlook)
See
$usepop/pop/help/poplog_ui
$usepop/pop/help/poplog_ui
$usepop/pop/com/mkpui
$usepop/pop/x/ui
I have never used that interface, thoug it has useful features for
beginners.
A parallel kind of menu-based functionality was built at a lower level in
the poplog 'menus' subsystem, built in BIrmingham on rclib (using
rc_graphic commands and ved functionality). It was found quite useful by
some students. Menus could autoload other menus.
See
$usepop/pop/packages/rcmenu/menus/menu*.p
$usepop/pop/packages/rcmenu/help
$usepop/pop/packages/rcmenu/teach
I don't think any of that required motif, and the results were not as
pretty as the motif tools, but easier for users to extend.
Perhaps something more elegant would be useful.
The main question is: how much flexibility should the new poplog, and its
installation processes, support, and what kinds of flexibility?
Is there a simpler/cleaner way of presenting the issues -- and possible
solutions?
Aaron
