Branches
Articles referencing this project
Comments
[»]
A breath of fresh air...
by Vladimir Lukyanov - Oct 25th 2004 16:41:10
Of all browsers I have tried none, truly none, can face up to the speed,
simplicity and niftiness of Links. Thought you cannot copy text in Links
and some very few pages do display incorrectly in X11 mode this browser is
simply the best.
[reply]
[top]
[»]
Re: A breath of fresh air...
by barrett9h - Jan 18th 2005 20:30:25
> Thought you cannot copy text in Links
You can, holding the SHIFT key.
[reply]
[top]
[»]
ELinks on old handhelds
by RyanCooper - Dec 2nd 2003 07:41:55
I've been searching for a decent text web browser to run on old handheld
systems with 21 x 16 character displays, and ELinks seems to be a good
candidate. However, I'm running into some problems. To your knowledge, has
anyone attempted this before? If there is any information out there about
this, it would make my life a lot easier :)
[reply]
[top]
[»]
links
by gt3 - Sep 22nd 2002 07:55:10
For a lot of people, running X is something they only feel the need, or
want, to do when they need to use a web browser. Links saves the day for
people who wish to stay in their sacred consoles. Setting the proper
associations in your .links.cfg file to console based multi-media
applications such as seejpeg, mpg123, etc.. along with the built-in page
rendering capabilities links offers is truely a breath of fresh air.
[reply]
[top]
[»]
A great piece of software
by S. Anthony Sequeira - Jun 4th 2002 12:44:26
A real pleasure to use, even statically linked on my old 486 (kernel
2.0.32). Nutscrape has disappeared hooray!
--
Tony
[reply]
[top]
[»]
2.0pre3 version has debugging code still enabled
by Eli Sand - May 26th 2002 11:04:44
For all of you who wonder why there's garbage text all over, debug code was
left enabled in the 2.0pre3 version.
To disable it, there are 2 files you need to edit (do a grep -r
"debug" . in the root directory to see all references to debug).
The macros idebug() and debug() need to be #undef'd and then #define'd to
nothing. The code has been commented out, so it's just a matter of
uncommenting it.
Also, graphics don't seem to work at all in framebuffers, unless I've done
something wrong :(
[reply]
[top]
[»]
elinks
by Petr Baudis - Dec 22nd 2001 07:29:10
Hi,
just to notify you all, main links branch is not actually maintained, as
Mikulas has no time for it now. Instead, elinks (experimental links) branch
is maintained and bugfixes and new features get there. Despite its name,
its STABLE branch should be really stable and usable.
I suggest you to use elinks instead of links, as it has many bugs fixed
and it's just always better to use maintained software instead of
unmaintained one ;-).
See freshmeat's elinks record or experimental branch of links record if
you want to check it out :).
[reply]
[top]
[»]
Re: elinks
by Karel Kulhavy - May 22nd 2002 05:45:34
Links is actively maintained by Mikulas, Clock,
Brain and PerM (Twibright devolopment group together). It is being
developped as a school project.
> Hi,
>
> just to notify you all, main links
> branch is not actually maintained, as
> Mikulas has no time for it now. Instead,
> elinks (experimental links) branch is
> maintained and bugfixes and new features
> get there. Despite its name, its STABLE
> branch should be really stable and
> usable.
>
> I suggest you to use elinks instead
> of links, as it has many bugs fixed and
> it's just always better to use
> maintained software instead of
> unmaintained one ;-).
>
> See freshmeat's elinks record or
> experimental branch of links record if
> you want to check it out :).
[reply]
[top]
[»]
Re: elinks
by Petr Baudis - Jun 12th 2002 09:25:56
> Links is actively maintained by Mikulas,
> Clock,
> Brain and PerM (Twibright devolopment
> group together). It is being developped
> as a school project.
Sure, apologies; the situation was different when I wrote that comment.
However, ELinks (now Enhanced/Extended Links) is still available for
those, who
honour higher configurability, sane cookies support, authentication
support etc
rather than javascript or graphics support (altough that's being prepared
as
well).
[reply]
[top]
[»]
Diky!
by Chris Leslie - Dec 9th 2000 17:04:46
Mikulas --
Diky moc za super textovy browser! Chris z Sev. Karoliny
[reply]
[top]
[»]
Review of links 0.84
by bneely - Apr 7th 2000 13:49:29
Linuxcare has published a review of links as part of its App of the Week
column.
Read
the review!
-bneely
[reply]
[top]
[»]
aalib support?
by Kim Slawson - Mar 29th 2000 21:34:17
Keep up the good work, Mikulas!
Now Links just needs to support aalib for rendering graphics :P
[reply]
[top]
[»]
Conversion html to text
by hq_software - Feb 3rd 2000 17:41:24
with lynx I can type
$ lynx -dump doc.html > doc.txt
to do subj. Will links ever have such possibilities?
[reply]
[top]
[»]
cookies and authentication
by jeff covey - Dec 26th 1999 13:10:48
since mikulas isn't interested in doing it, would anyone be interested
in adding cookie support to links? sorry, but it's required for some
sites i visit (and i don't mind).
more importantly, when will links support authentication? i had to
use w3m to sign in to post this comment. :)
--
vs lbh pna ernq guvf, lbh'er n trrx.
[reply]
[top]
[»]
Lynx & wb0 fusion -- useful at all?
by Karel Kulhavy - Nov 30th 1999 10:33:13
Look at wb0 announce which will come soon. Do you mean that it is
worth of effort to try to weld Links and wb0 together? I think the
images are relatively wanted even by hackers and that browsers
that typeset the images into the text will never run fast. So my idea
is to display the image after a click on a text link for it. But do it
all in graphics mode, because loading external viewer is a half-solution.
Also, the grx mode removes the problem with
display charsets.
[reply]
[top]
[»]
Why I wrote Links
by Mikulas Patocka - Nov 26th 1999 11:00:45
There have been questions why to write Links instead of improving Lynx and
W3M. Links and Lynx have absolutely different programming style. Links uses
callback mode to manage most actions - when we want to (for example) make
connection, we call function make_connection and pass pointer to functions
that will be called when the connection is ready. make_connection registers
request and returns immediatelly. (Netscape does it the same way). In
contrast Lynx and W3M use blocking calls for many actions - they call
make_connection, it waits until connection is done and then returns. As a
result, Links easily manages more simultaneous connections. Lynx and W3M
don't and _never_ will.
Lynx will never have features like continuing loading page even if
user selected 'Back', downloading files in background, preloading
documents, revalidating cache in background. Links will.
Joining Links and Lynx is hard. They can reuse html parser and table
code in Lynx, but the core is completely different.
[reply]
[top]
[»]
Good work Mikulas!
by Michal Suszycki - Nov 26th 1999 04:30:26
Wokan wrote: "Does it have very different goals from the Lynx program? ".
So what? Does gnome project have very different goals from kde project?
What's wrong with too many text editors? There are many people with
different preferences so there IS a need for different programs that have
same goals. Here rules natural selection. If some program is not used and
people doesn't like it then it probably dies. I have been playing with
"links" for last few hours and I like it very much - for me it is better
than lynx.
Keep on going Mikulas.
[reply]
[top]
[»]
Because it's a complete re-write?
by abo - Nov 25th 1999 23:50:03
I suspect one reason for the split is that this is a complete re-write from
scratch, not just a few hacked in additional features. The code size is
claimed to be considerably smaller than lynx... something you don't get by
just adding features in a "fork".
Sometimes a complete re-write is a good thing to flush out heaps of
evolutionary cruft. At the same time, the older app is usualy more
"mature", and still deserves consideration because of this. Merging the
work on two totaly different implementations like this is nearly impossible
and counter-productive in any case.
Normaly I agree with the sentiment that it is better to contribute to
an existing project than create another one (how many text editors are
there?), but in this case I think there is room for two text web browsers,
and lynx is probably getting a bit long in the tooth.
[reply]
[top]
[»]
Why a parallel project?
by Wokan - Nov 25th 1999 20:07:06
I'm just wondering why this project was started. Does it have very
different goals from the Lynx program? Couldn't this table and keepalive
support been added to Lynx instead of starting a new browser?
I'm all for having choice in browsers, but in this case, the two are
so close in nature, it seems silly to have them seperate.
[reply]
[top]
|
