[links-list] Re: Elinks 0.4pre4, a wishlist, [POOL] Config file format II.

Petr Baudis 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 ? :)
> 
> http://pasky.ji.cz/elinks/elinks-0.4pre4.tar.bz2
> md5sum:
> 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
> elinks-0.4pre4-20020328/elinks.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. 

Sure.

> 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

Sure.

> > > 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
accept it.

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
> allow)

!@($*!(%*~)$*~)(@$*!(%)_@(%_#@$(%^@*$^)(@%$(@*#$)(@*#$)(@*^*&#*^%!*($&~:][,

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:

module {
  # Load the module now
  name = "cookies";
}

script {
  name = "../foobar.lua";
  lang = "lua";
}

menu {
  id = 1;
  name = "My Super Menu";
  field {
    name = "Open with n3tsc4p3";
    action = "exec netscape %";
  }
  field {
    name = "Do something cool"
    action = "something-cool";
  }
}

bind {
  action = "something-cool";
  key = "Alt-C";
}

assoc {
  type = "text/plain";
  viewer = "less %";
}

include {
  name = "that.conf";
}

options {
  protocols {
    http {
      referer {
        type = "fake";
        fake = "http://asdf.gh.jkl/";
      }
      version = "1.1";
    }
    mime {
      honour_mailcap = 1;
    }
  }
}

..or..:

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:

   ,-- [Protocols]
   |     +-- [HTTP]
   |     |     +-- [Referer]
   |     |     |     +-- Type
   |     |     |     `-- Fake
   |     |     +-- Version
   |     |     `-- Redirect_bug
   |     +-- [FTP]
   |     |     `-- Anon_password
   |     +-- [User]
   |     |     +-- mailto
   |     |     +-- telnet
   |     |     +-- tn3270
   |     |     +-- news
   |     |     +-- gopher
   |     |     `-- ping_or_whatever
   |     `-- [MIME]
   |           +-- text/plain
   |           `-- ../..
   +-- [Cookies]
   |     +-- Use
   |     +-- Save
   |     +-- Resave
   |     `-- Paranoid
   +-- [HTML]
   |     `-- [Colors]
   |           +-- Default_fg
   |           `-- Default_link
  ...

  Your thoughts?

-- 

				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 mailing list