bfox%vision@HUB.UCSB.EDU (Brian Fox) (11/11/89)
Posted-Date: Thu, 09 Nov 89 13:54:56 +1300
Date: Thu, 09 Nov 89 13:54:56 +1300
From: Ray Nickson <Ray.Nickson@comp.vuw.ac.nz>
Initial difficulties:
- readline.texinfo won't texinfo-format-buffer (because
inc-readline.texinfo lacks a @setfilename(?)).
How is the readline texinfo stuff supposed to work? Even if I add
@setfilename inc-readline.info in inc-readline.texinfo, the `Readline
Top' entry can't find it (emacs 18.55).
While I'm at it, does 1.03's bash.texinfo file work? 18.55's info
complains about the @result symbol - is this added to a later
unreleased emacs?
[ BTW - `help' implies that there might exist a standalone info
program - is such a thing in the pipeline??? ]
There is a standalone Info program, and in addition there is a program
for making info files from texinfo source, called Makeinfo.
I guess that Makeinfo does something different with @include than
M-x texinfo-format-buffer. This difference will go away.
Bash's bash.texinfo file does not work, and is poorly written, and is
only there because without it, there is no documentation for the shell
at all. We now have someone actively writing documentation so
hopefully we will have a Bash manual soon!
The standalone Info program works, but has no bells and whistles (e.g.
it doesn't understand about window systems, so no mousing, etc.), the
standalone Makeinfo program is working, and in fact, is the program
that we use to format our documentation (we = FSF).
I don't know when an official release will be made, but I believe it
will be very soon.
General:
- readline should export a readline_version function or variable, so
(for example) bashcan set a READLINE_VERSION shell variable.
Good idea. New variable readline_version now exists.
- there should also be a way of finding out readline bindings - either
a function that returns some well-defined representation of the
top-level keymap structure, or explicit `describe-key', `where-is',
`list-all-bindings' functions. (I prefer the latter).
So do I. I guess I'll write them.
- readline initialization. Should there be a single advertised
function that programs must call to initialize readline, or should
every exported readline function check to see whether initialization
has been does (as it sort of does at present). I prefer the former.
I don't know what you mean. Who has to initialize readline? And
there are a very large number of exported functions in readline; every
function beginning with `rl_' for example. Here is the output from
M-x list matching lines "initialize" in readline.c:
Lines matching "initialized" in buffer readline.c.
175:static int rl_initialized = 0;
957: if (!rl_initialized)
960: rl_initialized++;
- there are still a few #ifdef SHELL sections in readline. These must
go - if it's appropriate for readline to call out to bash, then it's
possible that it will be appropriate to make corresponding callouts
to other programs, so there should be a variable controlling this
behaviour. The same libreadline.a should be usable from any program.
Lines matching "ifdef SHELL" in buffer readline.c.
4614:#ifdef SHELL
That doesn't look like a "few" to me. Hmmm.
I cannot remove that "ifdef SHELL" block. When we have the GNU
kernel, all programs will benifit from the symbolic link following
that is explicitly done in the shell.
- other: . we need M-x (with completion!).
I don't think that will happen. If you really want full M-x, then you
probably want emacs-lisp as well. We already have a program that has
both of those features.
. bash should allow interactive binding (via rl_macro_bind (),
rl_named_function (), rl_bind_key (), all of which should
be advertised).
I am still thinking about this one. If you do it through Bash, there
are problems. The biggest problem is that Bash gets to evaluate the
words that are to be passed to Readline. This could lead to syntax
like:
bash$ readline_bind \"\\C-xf\" \"\\C-a\\C-kemacs\ -f\ find-file\ \\C-y\\C-j\"
Yeechh!
. the syntax of .inputrc is getting painful - forget backward
compatability!
Please explain in which way it is painful. I thought it was rather
straight-forward and obvious.
Brian