[links-list] Re: Elinks 0.4pre4, a wishlist, [POOL] Config file format II.
pasky at pasky.ji.cz
Wed Apr 3 10:19:38 PST 2002
Dear diary, on Wed, Apr 03, 2002 at 06:52:07PM CEST, I got a letter,
where "zimon at iki.fi" <zimon at niksula.hut.fi> told me, that...
> (quite long)
> On Wed, Apr 03, 2002 at 03:54:28PM +0200, Petr Baudis wrote:
> > Dear diary, on Wed, Apr 03, 2002 at 01:27:14PM CEST, I got a letter,
> > where "zimon at iki.fi" <zimon at niksula.hut.fi> told me, that...
> > > I installed the latest unstable 0.4pre4 and all web-forms stopped working
> > > for me. (Lua support not compiled in, as .configure couldn't recognize
> > > it although lua is installed in the build machine. lua-4.0-8.i386.rpm)
> > >
> > > Is it a known bug?
> > Huh.. strange, I fixed it about a hour after release and retagged the release
> > and repackaged the tarball.. when did you download it from where ? :)
> Mar 28 04:39 /usr/src/redhat/SOURCES/elinks-0.4pre4.tar.bz2
> 6a5ec830a8e4702ef7db34f3d8e0e486 /usr/src/redhat/SOURCES/elinks-0.4pre4.tar.bz2
> Hmm...I even reloaded the tarball to check md5sums.
Indeed, I probably didn't retag it correctly, fool me! Apologies.. I'll
probably release 0.4pre5 soon anyway, though, in the meantime please use
nightly CVS snapshot or CVS directly.
> And btw, would be usefull to have elinks.spec file in the tarball, ....
> $ tar tjf /tmp/elinks-0.4pre4.tar.bz2 | grep .spec
> ...so most Linux users (RedHat distributions and also other distributions
> which support rpm) could install/upgrade latest build just with:
> # maybe some CVS stuff here first
> $ rpm -ta /tmp/elinks-0.4pre4.tar.bz2
> $ rpm -Uv /usr/src/redhat/RPMS/i386/elinks-0.4pre4-1.i386.rpm
> I have the elinks.spec file available, which I myself use to build
> (and install) elinks rpm packages to my system:
> < http://www.iki.fi/zimon/public/elinks.spec >
> It does change binary name from links to elinks though when installing to
> the system, so some may not like that (see deprecated_name, program_name in
> the elinks.spec file). Needs quick editing before each release, basically
> just version, and versiondate lines. Also "Packager:"-line needs editing
> in case someone puts .rpm files available.
I added that file to contrib/. Some patch for telling auto* to update stuff
there would be nice. I'm unsure if adding it to AC_OUTPUT will be enough..
> > > 1) Sometimes Elinks adds the exact same URLs or URIs to the history list.
> > > This happens in pages where are frames and clicking i.e. on some frame
> > > keeps updating data in another frame but the main URL shown in "=" or
> > > with "G" stays the same. Code to skip adding URL to the history list if
> > > it is the exact same as the last added one would be more a bug fix than
> > > feature, maybe.
> > So, you mean that when you go to a link with target in another frame,
> > frameset's URL get added to the history?
> Yes. Over and over again, although it is the exact same as previous in the
> history. But...just re-tested, and oh yes, frameset URL is added to the
> shown history, but it seems to work anyhow and take to the correct previous
> page. Just looked funny as all URLs in the history shows to be the same
> after some time in this one web news page, where subjects are on left
> frame and article bodies come to the right frame. I guess it is ok after
> all. Stupid me, should had tested it throughly before whining ;-)
It's strange though..
> > > 2) On busy web-servers, when one orders reload "^R" and request hangs, and
> > > one gives a 2nd thought and wants to cancel the request, one hits "arrow
> > > left" which does cancel the request but also puts the current page back
> > > one step from the history, which was not wanted. "^G" as an "Cancel"
> > > command would be good, as in Lynx, which wouldn't go back in history but
> > > just would cancel the previously given but not yet completed command.
> > And see? Now we have conflict in proposed keybindings! ;)
> Someone suggested ^C, or is ^G already bound to some other function?
> ^C should maybe left as it is, SIGINT and quit. At least on many
> programs, which runs on xterm or console, ^G means cancel. (lynx, slrn, ...)
They wanted ^G to emit ACT_ESC. But I like your usage of ^G more. When I'll see
a patch? :^)
> > > 3) In bookmarks, "/" would be good another shortcut to Search-command as it
> > > is de-facto standard key command in many console based programs. (more,
> > > less, slrn, mutt)
> > Zas?
> Zas? :-) Z-as? Just as?
Nop, it's nick of our bookmarks guy :^).
> Key-sequence example in elinks document view mode:
> s, /
> ...would do same as:
> s, s
> ...does now.
> The bookmark window buttons could be changed then to:
> [ Goto ] [ Edit ] [ Delete ] [ Add ]
> [ Search / ] [ Close ]
I don't like that.
> > > 4) Also in bookmarks search, when the search is done, the default command
> > > when Enter is hit is Search again, although to me more logical would be
> > > Goto-command. So the cursor would stay on Goto-button after each
> > > completed search.
> > Zas?
> Key-sequence example, in document view mode:
> s, s, ^U, a, ENTER, ENTER
> ....will bring "Search bookmarks" dialog window again, although at least I
> would had expect same thing as with:
> s, s, ^U, a, ENTER, g
> > > 5) Support for meta auto-Refresh: <meta http-equiv="Refresh" content="300">
> > > But ability to turn support for auto-Refresh off from menu.
> > That's planned.
> > > And with
> > > the shortcut "^G" Cancel-command, which would be overloaded on this case,
> > > and would turn auto-refresh off on that specific page but not toggle the
> > > global auto-refresh switch.
> > > Refresh "^R" would naturally turn the autorefresh on again for that
> > > current page, if there is the meta-header and global auto-refresh switch
> > > in the menu is enabled.
> > > Menu: "File/Auto Reload/Meta Refresh support: on/off"
> Meaning, auto-reload could be turned off with ^G, or paused, until the page is
> reloaded manually once again (with ^R or given as G URL)
That won't be so easy probably, we'll see.
> > > 6) Support for forced auto-refresh, where turned on would ask in a dialog
> > > the wished auto-refresh time interval.
> > > Menu: "File/Auto Reload/Own Auto Refresh Interval: N secs"
> > > (Maybe with some configurable safe counter, that if over M Reloads then
> > > Auto Reload is automaticly turned off)
> > ..?
> I mean, to have some URL auto-refreshed every N secs although its
> HTML-headers does not have <meta http-equiv="Refresh" ...> line.
> Choosing command from Menu: "File/Auto Reload/Auto Refresh Interval"
> ...would pop up dialog window:
> | Auto Reload this page |
> | <URL: http://blah.bleh/foo/bar > |
> | every __________ secs | <= Default value 60s?
> | max __________ times. | <= 0 times would mean no limit,
> | | so forever.
> | | Default value 100 times?
> | [ OK ] [ Cancel ] |
> (And that Reload by that way/method it would always be forced MISS from proxy)
> Maybe even make it so, that with <meta http-equiv="Refresh" ...>
> in the html document, user would be able to modify the document given
> Refresh-interval her/himself from the menu with the same dialog sub-window.
Sounds nice. Patch? :) (btw I think most ppl would use 0 as max times anyway,
and expect that, so it's reasonable default)
> > > 7) Yeah, even minimal ECMA-script (js) support would be real cool, which
> > > would also enable to use auto proxy scripts (*.pac) as in Mozilla.
> > Are you going to code it ? ;p
> Heh. That is prolly going to be huge task. I wonder (but I guess you guys
> already have checked) if there would be already some ECMA-script interpreter
> giving shared libraries or even plugins. If not, there surely would be
> a need for one, although at first seems like a mission impossible to keep
> HTML-parsing in the application and ECMA-script handling in shared plugin.
If EcmaScript support won't be clearly separated in a separate dir, I won't
I checked, only thing I found is the URL someone mentioned here, but that is
in java :(.
> >From scratch, ECMAscript interpreter should IMHO be done with lex and yacc.
> Maybe even also the HTML-parser with yacc and lex would give lots of code
> usability and maybe help keep the code well structured more easily?
I don't like the lex/yacc idea. It would be damn hard to implement the fuzzy
syntax HTML has there (we need to be very fault-tolerant), the result wouldn't
be excitingly great, and at any rate we want to make up own syntactic tree from
the document. See also src/document/html/README.
> Found one, not complete interpreter but checker at least done with yacc and
> lex. It is not exactly explicitly told to be open source though:
> < http://www.soton.net/jssyntaxchecker/ >
I'll have a look.
> > > 8) "User specified colors for TEXT, LINK, VLINK and ALINK" to the menu.
> > > (was already in the TODO though)
> > > In fact, ability to change almost all configurable options also in
> > > running time via menu-commands.
> > That's already being coded.
> Hmm...must be only with Lua then, (have to get that Lua compiled in and
> figure out why it currently doesn't) because I cannot see any way to
> configure that behaviour from menu in 0.4pre4
Being coded != finished != included. Currently, we're finishing the design
phase :^). This thing is 0.5 release goal! :)
> > > btw, why "Html options" are in "View" main menu and not in "Setup"?
> > Ask Mikulas :^). I'm going to unify document and other options. Somehow.
> In "Re: hierarchical options", pasky wrote:
> > I would like to have the config file format a bit more
> > generic, as I may possibly want also other things than options there. Like
> > macros definitions etc.
> This is crazy bloated suggestion, but why not change all configure scripts
> and files to XML. Then someone (who? :-) add XML-support (as a plugin :P)
> and then XML would also be supported in the web documents, not just in
> configure files. i.e. Galeon uses XML also in its configuration, history
> and bookmarks files. XML is editable by people, because it is although
> well structured still text based, and also ofcourse by automatic programs
> or even by AI's !
> (and XML interpreter/plugin programmed with lex and yacc, again)
> Sometimes in my weak moments I hope all UNIX configuration
> files (in /etc or elsewhere) would be in XML. So frustrating to learn
> zillion different configuration and script languages. Wow, wouldn't it
> be fun to just edit system configuration also with Elinks, with its
> XML-plugin. $ elinks /etc/hosts.xml /etc/inetd.conf.xml
> (XML-plugin would allow edit xml-documents inline, if write permissions
Ehm.. I'm sorry ;). Well, basically, as I said already, the future config file
should rather have nature of a script. Uhm.. I'm not really sure about that
yet, though.. would you like:
# Load the module now
name = "cookies";
name = "../foobar.lua";
lang = "lua";
id = 1;
name = "My Super Menu";
name = "Open with n3tsc4p3";
action = "exec netscape %";
name = "Do something cool"
action = "something-cool";
action = "something-cool";
key = "Alt-C";
type = "text/plain";
viewer = "less %";
name = "that.conf";
type = "fake";
fake = "http://asdf.gh.jkl/";
version = "1.1";
honour_mailcap = 1;
set module.cookies = 1
set script.1.name = "../foobar.lua"
set script.1.lang = "lua";
set script.1.load = 1;
set menu.1.name = "My Super Menu"
set menu.1.field1.name = "OWN"
set menu.1.field1.action = "exec netscape %"
set menu.1.field2.name = "DSC"
set menu.1.field2.action = "something-cool"
set bind.something-cool = "Alt-C"
set assoc.text/plain = "less %"
set protocols.http.referer.type = "fake"
set protocols.http.referer.fake = ".."
set protocols.http.version = "1.1"
set protocols.mime.honour-mailcap = 1
I like the first one more and more.. :) It is longer, but it give us more
flexibility, file format which is more common and it is still config file, not
some scripting-like hybrid (after all, we've Lua for that ;).
However, to prevent any possible confusion, I'm not going to make XML the
config file format. I believe it's above that thin bloat-border, we would need
to implement XML support first, and it would be just overkill for us, IMHO.
The hiearchic bookmarks, in order to refresh your memory, will look like:
| +-- [HTTP]
| | +-- [Referer]
| | | +-- Type
| | | `-- Fake
| | +-- Version
| | `-- Redirect_bug
| +-- [FTP]
| | `-- Anon_password
| +-- [User]
| | +-- mailto
| | +-- telnet
| | +-- tn3270
| | +-- news
| | +-- gopher
| | `-- ping_or_whatever
| `-- [MIME]
| +-- text/plain
| `-- ../..
| +-- Use
| +-- Save
| +-- Resave
| `-- Paranoid
| `-- [Colors]
| +-- Default_fg
| `-- Default_link
Petr "Pasky" Baudis
* ELinks maintainer * IPv6 guy (XS26 co-coordinator)
* IRCnet operator * FreeCiv AI hacker
Teamwork is essential -- it allows you to blame someone else.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
Unsubscribe: send email to links-list-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the links-list