If I may butt in... On Tue, Jun 06, 2006 at 08:33:48PM -0400, cga2000 wrote: > On Tue, Jun 06, 2006 at 05:33:05AM EDT, Jonas Fonseca wrote: > > cga2000 <[EMAIL PROTECTED]> wrote Mon, Jun 05, 2006: > > > On Mon, Jun 05, 2006 at 10:08:37AM EDT, Jonas Fonseca wrote: > > > > > > I'm not really convinced 256 colors was such a good idea to begin > > > with. Naturally, it's orders of magnitude better than the 8/8 or > > > even 8/16 on regular terms.. But why not go the whole hog and have a > > > terminal that supports what the video card is capable of? 16-bit - > > > 64k colors would probably have been a sensible choice and made life > > > easier for everybody? > > > > > > Only one extra byte per cell..
The onus is on the developers of the terminal emulators. I'm still waiting for 256-colour support on the Linux console. > > Someone posted a patch for something like this, using the X libraries. > > It never was polished to a degree where it was worth merging, tho'. Which patch was that? > Interesting. Obviously 64k or 16M different colors doesn't make much > difference. None that I can see anyway. I asked the xterm maintainer how > the 256-color palette was chosen but he did not give me much detail. My > personal concern was that the default xterm palette has very few blues. > So if you try to harmonize the contents of an xterm with for instance > the default background of Window Maker (I call it WindowMaker blue) you > don't find an xterm color that is anywhere near. That's when I started > taking an interest in these aspects. You can use X resources to change XTerm's palette. man xterm or look in /etc/X11/app-defaults/XTerm-color (at least on Debian systems). Mind you, ELinks will not necessarily know that you've changed the colours, so if you weird things (change red to blue), it might reflect strangely in ELinks's rendering. > > > > Ok, but if you feel like modding up your ELinks you should really try > > > > the Spidermonkey Javascript scripting backend created by Miciah. It's > > > > fairly easy to get working on a debian system > > > > > > Really? I was never able to get xterm, gnu/scren, and elinks.. to build > > > from source - the debian way, I mean.. I was in a rush and it seemed I > > > had to become a debian packaging expert before I could hope to get that > > > to work.. So now I have a bunch of stuff that's all /.configure'd and > > > compiled from source. Annoying. I don't bother packaging ELinks; I just install to my home directory. You can install to /usr/local, or maybe try something like checkinstall (which is packaged in Debian). > > I can imagine. Only ever felt the need to compile school related stuff, > > elinks, git, (cogito), and xterm. The last one to get 256 colors, and I > > am still using the one I compiled on my previous debian system. > > > > > This said, I'm very curious of the Javascript capabilities and I would > > > really like to see the difference it makes. I do run into pages where I > > > am stuck and I have to fire up mozilla and I suspect that not having > > > Javascript enabled is part of my problem. > > > > Sorry, that I was not clear. I am talking about using JavaScript for > > browser scripting, not document scripting. > > Ok. I need to add JavaScript to the list of things I must look into. > I'll check and see if there is an online tutorial available somewhere. My preferred tutorial is to read code. My preferred reference is <http://www.devguru.com/Technologies/ecmascript/quickref/javascript_intro.html> --note that that is oriented towards Web programming, tho. I should probably write some documentation for the browser scripting interfaces. > > That is, using JavaScript > > to define hooks that can handle stuff from the goto URL dialog or > > preformat the HTML source. > > > Yes, but I do need it for page rendering as well..? Especially those > home pages that have some sort of horizontal menu bar that ends up a > vertical list of links in my setup? EMCAScript in documents shouldn't usually significantly affect the rendering of documents; normally it is more important towards functionality. Particularly in ELinks, which doesn't support enough ECMAScript to support the whiz-bang interfaces that really do depend on ECMAScript to dynamically generate content, add and hide stuff, and so on, you should see little difference in how a document is actually displayed based on whether you have ECMAScript enabled. The example of the mis-rendered menu bar is probably an issue of ELinks's limited CSS support. > > > > Having a sane default configuration is very important. The many > > > > options is a weakness if you end up scaring new users away. If > > > > they feel they have to know of all the little details. > > > > > > That's pretty much what I meant. But as a new user I only noticed > > > all the options when I took a look at the elinks.conf file. But then > > > I was in so much of a rush that I did not really look at the o - > > > "Option Manager" until recently.. > > > > As a new user you hopefully will get a long way by only using the > > terminal option dialog (under Setup in the main menu). Once your > > screen/terminal is configured most things should just work. > > > I'm pretty confident now that I my terminal setup is sound. The only > improvement I can think of is running an xterm with a white background. > Now the thing is I currently run everything under gnu/screen. I have to > figure out if I could change the background to a light color without > restarting the underlying xterm. And then see if I could automate this > ie. change the background to white when I switch to elinks and then back > to black when I switch back to vim or mutt. If you want the background to be white, what is wrong with configuring it in ELinks, as Jonas explained? Setup -> Options manager -> Document -> Default color settings -> Background color. > > > Actually what I missed - again as a new user - was more samples of > > > elinks "in action".. I did find a few screenshots but I would have liked > > > to see more. > > > > I have some (mostly 256 related) at http://jonas.nitro.dk/screenshots/ > > > I had looked at these a few weeks back. I took another look while > writing this and now I see things I didn't see back then. I compared > those sites that are still around such as OSTG, OSDN, slashdot.. and > it's obvious I'm not quite there yet.. Nasty truth ahead: Many sites, including Slashdot, have switched to CSS-based designs, and ELinks's CSS support is so limited that these pages now look horrible. > > > Now, the reason I say this is that for a new user and for something > > > such as elinks that has the potential to display such a wide variety > > > of documents.. I was never sure I was configured correctly and > > > seeing what you or the other seasoned users of elinks are seeing. > > > This nagging feeling that I may not be making the most of the > > > product. > > > > > > For instance, until you told me this thing about setting my > > > foreground and background to "black" I was seeing lots of pages > > > revert to my xterm's black background. Now practically everything is > > > rendered with a white/light background.. I don't know if this makes > > > sense.. But my point is that being the only elinks user in my > > > neighborhood .. as far as I know .. it was not likely one of the > > > seasoned users I mentioned would have stopped by.. and said.. wait a > > > minute.. this isn't right.. looked at my setup and fixed a couple > > > of things. And conversely I could not walk up to someone's desk > > > looked over his shoulder for a couple minutes and said.. wait a > > > minute.. his elinks looks a lot better than mine.. iow, I was > > > totally in the dark as to how an optimal setup of elinks should > > > behave in real-life situations. May still be, for that matter.. I think that the unknown is smaller than you think. There is no 'optimal setup'. 256-colour support and CSS are nice and configuring the keys as you like them and customising a few options (link numbering, maybe colours) should get you an ELinks that is optimised for you. > > Screenshots sells, I agree. Although most apps are easily downloaded, > > configured and installed, the first appearance by which you make the > > decision whether to even bother with all that may often be a > > screenshot. And properly more so for something as seemingly > > "out-dated" as a text-mode browser. > > What would be nice is to have the web pages and the screenshots. > Because even if the site still exists six months from now the > contents.. or even the page design.. are going to be different. Thus if > the new user has the html document and the .png .. when he wants to make > sure his configuration is optimal he just needs to point elinks to the > web document and compare with the screenshot. He might need to change > his font to the one that was used when the the screenshot was taken but > otherwise it should be pretty painless? Indeed, discrepancies between screenshots and what you see in ELinks can partly be explained by Web sites changing their designs, as I mentioned above. Otherwise, if you have a terminal emulator that supports 256 colours and enable CSS, there isn't any reason that Web pages should look less illustrious on your system than they do on the most tweaked-out power-ELinks-user's system. The only other important thing that comes to mind is that your colour configuration not be wack (e.g., when your terminal emulator's default background is white). > > Anyway, I have the same feeling about Mutt. I feel I am only using a > > very small subset of its capabilities and that some of my usage > > patterns might be a bit broken, but it works for me, I have become > > comfortable with it, and that is really all that matters. Especially, > > since I don't want to spent a lot of time configuring and reading > > docs. > > Same here.. :-) > > I have a feeling that all those mutt capabilities are pretty easy to > figure out for someone who really knows electronic mail. But as far as > usability mutt is really great. Mutt is nifty. E-mail is simple. I'm not sure what functionality you think that you're missing. There are a few features like tagging and limiting that are beyond the very beginner level, and some people might need complicated macros and hooks, but it is, after all, an MUA. If it does what you want, what do you think that you're missing? OTOH, maybe you deal with more E-mail than I do--I can imagine somebody saying similar to the foregoing about, say, a Web browser. > > > I don't know if it's realistic/possible but it might be a good idea > > > to have elinks "test pages" .. you go to the test page and if you're > > > set up right you should see this.. and a link to a screenshot. > > > > > > Confessions of the isolated noob.. not sure that's very useful. > > > > > > :-) > > > > It's certainly a new approach to a more visual tutorial and might suit > > ELinks better than the poor introduction we have now. On the other > > hand I wonder if most users of text-mode browser is this "visually > > oriented". But then again, Links2 has this calibration page to help > > you get the basics working and that is of course a great help. > > > thanks, "calibration" is pretty much what I had in mind. And it should > remain pretty simple. Just giving the new user the ability to verify > that web pages are rendering correctly. As to a tutorial I don't really > see the need for one. As long as a default configuration is provided the > user can learn the basics of elinks by just using it. Same as any gui > app. It is mildly ironic to speak about a screenshot tutorial of a text-mode Web browser. However, I do see that it might be useful. > > BTW, being new to ELinks, you should go over contrib/elinks.fortune, > > there's some good tips and tricks in it. > > > done. :-) > > practically everything that's in this file, I already use without > thinking. But then it was easy for me to find these tricks just > reviewing the contents of the elinks menus.. because I was looking for > these capabilities in the first place. The fact that they are available > in elinks being possibly the main reason why I switched. If they hadn't > been available I would not be using elinks now. > > actually, there's one thing I hadn't found by myself and that's the > Ctrl-W to bring up a history of links on the 'g' goto dialog.. *and* the > popup list is searchable..! How do I repeat the search? During the search you can press tab to move between matches. However, the search function doesn't save searches, so there is no way to repeat an old search. Hm, imagine if there were: open the Go to URI box, press ctrl-w to complete, press / to search the completions, then press ctrl-w again to complete old searches--the thought rather amuses me. > > > > > As far as user satisfaction > > > > > goes I would have given mozilla six out of ten.. At this point in > > > > > time, > > > > > I would give elinks 7.5.. and apart from changing a few keyboard > > > > > actions > > > > > I haven't really done anything to customize it. But it's nice to know > > > > > that just about anything I may need to customize *is* customizable. > > > > > > > > Now you are just being nice. ;) > > > > > > No, I'm dead serious: > > > > > > 1. I'm on a bb connection that performs quite well for stuff like iso > > > images downloads etc. Most pages in mozilla take some five to twenty > > > seconds to render.. Twenty seconds..! I mean that's pretty much a worse > > > case scenario but it adds up to ten minutes' wait doing nothing to > > > access a mere thirty web pages.. If like me you google a lot for tech > > > info and try a number of links before you find something that looks half > > > useful that's clearly unacceptable. > > > > I mostly use ELinks for this sort of thing: "dict this", "g that", > > because it is less frustrating. > > > > > 2. Now that I have aligned my basic navigation keyboard actions to vim's > > > - j,k to scroll .. h,l to go back and forward.. and J,K to jump to the > > > next/previous link I'm having the most comfortable surfing experience > > > ever.. And once I had figured how to use the "Keybinding Manager" it > > > only took a couple of intuitive minutes to set my bindings > > > *interactively*.. Try to do that in mozilla. I just wish that it weren't so difficult to find the desired action in the list. > > I am still mousing my way through mozilla. Well, apart from when I start > > pounding the Tab key to get to some link. :-P If tabbing between links in Mozilla didn't behave in the worst possible way (scrolling about instead of picking a visible link), that would be a _tremendous_ usability improvement. > Mozilla has a very nice "search as you type" feature where - provided > the cursor is not in a data entry field you just need to type the link's > text to select the link. I prefer it to numbered links (I'm pretty sure > there is a mozilla patch that enables this) or elinks' typeahead search > (because you don't need a keyboard actions such as '#' to enable this > mode in mozilla). It's configurable somewhere under Edit->Preference - > you can search any text or just links.. You would use Ctrl+g to repeat > the search and ' (single quote) to start a new search before the timer > expires. With a bit of practice you get to do it without thinking (= no > overhead) because you are reading the links' text so doing it becomes a > second nature. Instead of reading the link aloud or mentally you type > it.. The only problem is with pages that force the cursor to a text > entry field (search usually). That.. I understand, is yet another > JavaScript trick and quite annoying. Fortunately it's limited to the > home pages of commercial sites. So what you want is the incremental search AKA search as you type AKA type-ahead find, but you don't like having to press a key to start it? Got it covered! Setup -> Options manager -> Document -> Browsing -> Searching -> Typeahead searching. The catch is that you must delete all bindings that will conflict with this--i.e., you mustn't bind actions to letters without modifiers--there go your Vi keys! > > And you really can't > > always depend on the Up/Down keys doing what you expect since the page > > layout may make pressing Down jump to the bottom of the page. > > > > > 3. Because elinks is a text-mode browser I don't have to put up with all > > > the distractions.. click here and there to block all this commercial > > > shockflash stuff .. with mozilla it usually takes a minute or more > > > before I have enough peace and quiet and then I am able to (re)focus and > > > actually start reading. With elinks, I can choose to display a picture > > > when I want/need it. Freedom, you know.. I just wish that Web authors used less spacers and decorative images and more alt text! > > On the otherhand you don't get to experience the tasty new slashdot > > design. But using the URL passing mechanism you can easily fireup the > > firefox. > > As far as I am concerned the quintessence of web page design is the > standard linux HOWTO. Text preferably all the same size and some pale > blue background to highlight stuff like source code.. shell commands > etc.. ;-) > > But seriously I want a computer screen that looks like a computer > screen.. not a lame attempt at copying cheap magazines. > > > > > Come to think of it.. I got my math wrong.. if each of the above is > > > worth only one extra point I should have rated mozilla 4.5 and elinks > > > 7.5/10.. > > > > > > :-) > > > > Heh. Again thanks for the input. > > Thank you very much for listening.. and providing all this very useful > "meta data" that is nowhere else to be found .. (the stuff that's not > technical and hence not in manuals.. howto's.. man pages etc..) .. > > Thanks, > > cga ELinks can use more documentation. Thanks for your suggestions regarding such; do let us know where we can improve. -- Miciah Masters <[EMAIL PROTECTED]> / <[EMAIL PROTECTED]> _______________________________________________ elinks-users mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/elinks-users
