Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2011-01

Permuted index (KWIC) of function descriptions

35 messages · 11 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mark Morgan Lloyd

As a comparative beginner, I still find myself stumbling across RTL functions that I've previously hand-coded.

Is there an easy way of generating a complete permuted index from the one-line descriptions of the functions in the RTL (and optionally FCL and LCL)?

For example, can I rapidly get all function descriptions with "space" as part of the description, which could subsequently be filtered (e.g. if I were interested in text operations I could quickly ignore anything with "file" in the description)?

Copy2Space Returns first space character Copy2SpaceDel Deletes first space character DelSpace Delete a space from DelSpace1 Reduces of space characters DelSpace1 Reduces 1 space character IntToBin Converts inserting spaces at IsEmptyStr Check disregaring whitespace characters

That's somewhat abbreviated so that it's not screwed too badly by wrap.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Unknown author
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 6 lines
As a comparative beginner, I still find myself stumbling across RTL functions that I've previously hand-coded. Is there an easy way of generating a complete permuted index from the one-line descriptions of the functions in the RTL (and optionally FCL and LCL)?

Shortly said: no.

Show quoted text 15 lines
For example, can I rapidly get all function descriptions with "space" as part of the description, which could subsequently be filtered (e.g. if I were interested in text operations I could quickly ignore anything with "file" in the description)? Copy2Space Returns first space character Copy2SpaceDel Deletes first space character DelSpace Delete a space from DelSpace1 Reduces of space characters DelSpace1 Reduces 1 space character IntToBin Converts inserting spaces at IsEmptyStr Check disregaring whitespace characters That's somewhat abbreviated so that it's not screwed too badly by wrap.

Creating such an index requires additional keywords, which are simply not present now.

That said, I am still looking for a good search engine *written in Object pascal* for the FPC html docs. Any hints/tips are appreciated.

Michael.

Reply by email

Marco van de Voort
to Unknown author

In our previous episode, said:

Show quoted text 7 lines
> IntToBin Converts inserting spaces at > IsEmptyStr Check disregaring whitespace characters > > That's somewhat abbreviated so that it's not screwed too badly by wrap. Creating such an index requires additional keywords, which are simply not present now.

Categorization of routines (string,file etc) would be a good place to start. I have thought about this before (for chm), but while the CHM format supports this (building e.g. a list of string routines over multiple independantly compiled CHMs), the Windows viewer's support for this is too basic, and the *nix viewers are even worse.

It seems to be functionality intended for MSDN that never was finished because of the move to later formats.

That said, I am still looking for a good search engine *written in Object pascal* for the FPC html docs. Any hints/tips are appreciated.

CHM has a basic phrase indexer, and it operates on the html. The search part is maybe part of the viewer, and one would have to see how complex it is. (Iow if the complexity is in index or search, if the search is relative simple one could look at kchmviewer)

Reply by email

Mark Morgan Lloyd
to Marco van de Voort
Marco van de Voort wrote 24 lines
In our previous episode, said: >> IntToBin Converts inserting spaces at >> IsEmptyStr Check disregaring whitespace characters >> >> That's somewhat abbreviated so that it's not screwed too badly by wrap. > Creating such an index requires additional keywords, which are simply not > present now. Categorization of routines (string,file etc) would be a good place to start. I have thought about this before (for chm), but while the CHM format supports this (building e.g. a list of string routines over multiple independantly compiled CHMs), the Windows viewer's support for this is too basic, and the *nix viewers are even worse. It seems to be functionality intended for MSDN that never was finished because of the move to later formats. > That said, I am still looking for a good search engine *written in Object > pascal* for the FPC html docs. Any hints/tips are appreciated. CHM has a basic phrase indexer, and it operates on the html. The search part is maybe part of the viewer, and one would have to see how complex it is. (Iow if the complexity is in index or search, if the search is relative simple one could look at kchmviewer)

I used something called Perlfect Search for a while- which might fulfil Michael's criterion if Lazarus could handle Perl plugins :-)

As shipped though I think it was oriented towards word (rather than phrase) indexing, and it had a limit of 64K files. http://www.perlmonks.org/index.pl?node_id=27509

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Unknown author
to Marco van de Voort: In our previous episode, said: Categorization of routines (string,file etc) would be a…
Marco van de Voort wrote 25 lines
In our previous episode, said: >> IntToBin Converts inserting spaces at >> IsEmptyStr Check disregaring whitespace characters >> >> That's somewhat abbreviated so that it's not screwed too badly by wrap. > > Creating such an index requires additional keywords, which are simply not > present now. Categorization of routines (string,file etc) would be a good place to start. I have thought about this before (for chm), but while the CHM format supports this (building e.g. a list of string routines over multiple independantly compiled CHMs), the Windows viewer's support for this is too basic, and the *nix viewers are even worse. It seems to be functionality intended for MSDN that never was finished because of the move to later formats. > That said, I am still looking for a good search engine *written in Object > pascal* for the FPC html docs. Any hints/tips are appreciated. CHM has a basic phrase indexer, and it operates on the html. The search part is maybe part of the viewer, and one would have to see how complex it is. (Iow if the complexity is in index or search, if the search is relative simple one could look at kchmviewer)

Secretly, I am still waiting for Michael Hess to open source his IDKSM indexer. It was/is exactly what we need... Maybe the Lazarus devels can exert some mild pressure :-)

Michael.

Reply by email

Unknown author
to Mark Morgan Lloyd: I used something called Perlfect Search for a while- which might fulfil Michael's…
Mark Morgan Lloyd wrote 30 lines
Marco van de Voort wrote: > In our previous episode, said: >>> IntToBin Converts inserting spaces at >>> IsEmptyStr Check disregaring whitespace characters >>> >>> That's somewhat abbreviated so that it's not screwed too badly by wrap. >> Creating such an index requires additional keywords, which are simply not >> present now. > > Categorization of routines (string,file etc) would be a good place to > start. > I have thought about this before (for chm), but while the CHM format > supports this (building e.g. a list of string routines over multiple > independantly compiled CHMs), the Windows viewer's support for this is too > basic, and the *nix viewers are even worse. > > It seems to be functionality intended for MSDN that never was finished > because of the move to later formats. > >> That said, I am still looking for a good search engine *written in Object >> pascal* for the FPC html docs. Any hints/tips are appreciated. > > CHM has a basic phrase indexer, and it operates on the html. The search > part > is maybe part of the viewer, and one would have to see how complex it is. > (Iow if the complexity is in index or search, if the search is relative > simple one could look at kchmviewer) I used something called Perlfect Search for a while- which might fulfil Michael's criterion if Lazarus could handle Perl plugins :-)

The criterion is: *written* in object pascal.
Not 'callable from Object pascal' :-)

And I will rather spend an eternity in hell than use a perl tool... ;)

Michael.

Reply by email

Marco van de Voort
to Mark Morgan Lloyd: I used something called Perlfect Search for a while- which might fulfil Michael's…

In our previous episode, Mark Morgan Lloyd said:

> simple one could look at kchmviewer) I used something called Perlfect Search for a while- which might fulfil Michael's criterion if Lazarus could handle Perl plugins :-)

Pascal, and pascal only. We might make exceptions for extremely common C libraries on Unix but that is it.

If we were lenient with that, you now had to install Perl, Python, Ruby, PHP, Java, .NET and LUA as well as cygwin just to be able run FPC/Lazarus on Windows.

Programming is about programming, not about smartshopping. (unless you can find somebody crazy enough to foot the bill for integration and support)

As shipped though I think it was oriented towards word (rather than phrase) indexing, and it had a limit of 64K files. http://www.perlmonks.org/index.pl?node_id=27509

There should me more than enough decent C libs to port. No need to go to extremes like Perl.

Reply by email

Marco van de Voort
to Unknown author: The criterion is: *written* in object pascal. Not 'callable from Object pascal' :-) And I…

In our previous episode, said:

Show quoted text 7 lines
> I used something called Perlfect Search for a while- which might fulfil > Michael's criterion if Lazarus could handle Perl plugins :-) The criterion is: *written* in object pascal. Not 'callable from Object pascal' :-) And I will rather spend an eternity in hell than use a perl tool... ;)

I still wakeup screaming in the night sometimes because of the last one. The little 1.5MB script that converted Latex to html. :-)

Reply by email

Mark Morgan Lloyd
to Unknown author: Shortly said: no. Creating such an index requires additional keywords, which are simply…
Show quoted text 29 lines
On Wed, 26 Jan 2011, Mark Morgan Lloyd wrote: > As a comparative beginner, I still find myself stumbling across RTL > functions that I've previously hand-coded. > > Is there an easy way of generating a complete permuted index from the > one-line descriptions of the functions in the RTL (and optionally FCL > and LCL)? Shortly said: no. > > For example, can I rapidly get all function descriptions with "space" > as part of the description, which could subsequently be filtered (e.g. > if I were interested in text operations I could quickly ignore > anything with "file" in the description)? > > Copy2Space Returns first space character > Copy2SpaceDel Deletes first space character > DelSpace Delete a space from > DelSpace1 Reduces of space characters > DelSpace1 Reduces 1 space character > IntToBin Converts inserting spaces at > IsEmptyStr Check disregaring whitespace characters > > That's somewhat abbreviated so that it's not screwed too badly by wrap. Creating such an index requires additional keywords, which are simply not present now.

Even looked at superficially gives useful partial results:

fpcdocs$ grep -r -B 1 '<short>' *

I'm sure that somebody familiar with XML (which I'm afraid doesn't include me) could knock out something half-way decent in a few minutes.

Or is the problem actually XML in this case, i.e. it's obvious that we want to extract the short description but that leaves an uncertain context?

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Unknown author
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 40 lines
wrote: > On Wed, 26 Jan 2011, Mark Morgan Lloyd wrote: > >> As a comparative beginner, I still find myself stumbling across RTL >> functions that I've previously hand-coded. >> >> Is there an easy way of generating a complete permuted index from the >> one-line descriptions of the functions in the RTL (and optionally FCL and >> LCL)? > > Shortly said: no. > >> >> For example, can I rapidly get all function descriptions with "space" as >> part of the description, which could subsequently be filtered (e.g. if I >> were interested in text operations I could quickly ignore anything with >> "file" in the description)? >> >> Copy2Space Returns first space character >> Copy2SpaceDel Deletes first space character >> DelSpace Delete a space from >> DelSpace1 Reduces of space characters >> DelSpace1 Reduces 1 space character >> IntToBin Converts inserting spaces at >> IsEmptyStr Check disregaring whitespace characters >> >> That's somewhat abbreviated so that it's not screwed too badly by wrap. > > Creating such an index requires additional keywords, which are simply not > present now. Even looked at superficially gives useful partial results: fpcdocs$ grep -r -B 1 '<short>' * I'm sure that somebody familiar with XML (which I'm afraid doesn't include me) could knock out something half-way decent in a few minutes. Or is the problem actually XML in this case, i.e. it's obvious that we want to extract the short description but that leaves an uncertain context?

The short description is not a problem. But the "Returns" "Deletes" "Reduces" etc ?

Michael.

Reply by email

Marcos Douglas
to Marco van de Voort: In our previous episode, Mark Morgan Lloyd said: Pascal, and pascal only. We might make…
Marco van de Voort wrote 8 lines
In our previous episode, Mark Morgan Lloyd said: > > simple one could look at kchmviewer) > > I used something called Perlfect Search for a while- which might fulfil > Michael's criterion if Lazarus could handle Perl plugins :-) Pascal, and pascal only. We might make exceptions for extremely common C libraries on Unix but that is it.

I agree.

If we were lenient with that, you now had to install Perl, Python, Ruby, PHP, Java, .NET and LUA as well as cygwin just to be able run FPC/Lazarus on Windows.

If you allow, the correct is Lua, not LUA.

Marcos Douglas

Reply by email

Marco van de Voort
to Unknown author: The short description is not a problem. But the "Returns" "Deletes" "Reduces" etc ?…

In our previous episode, said:

Show quoted text 8 lines
> I'm sure that somebody familiar with XML (which I'm afraid doesn't include > me) could knock out something half-way decent in a few minutes. > > Or is the problem actually XML in this case, i.e. it's obvious that we want > to extract the short description but that leaves an uncertain context? The short description is not a problem. But the "Returns" "Deletes" "Reduces" etc ?

IMHO that is overkill. It only works comprehensively for a handful routines.

Categorizing routines, with subcategs if need be will be trouble enough, specially if you want to do it future proof (and also be able to flag the static method approach that Delphi current favours)

Reply by email

Unknown author
to Marco van de Voort
Marco van de Voort wrote 11 lines
In our previous episode, said: >> I'm sure that somebody familiar with XML (which I'm afraid doesn't include >> me) could knock out something half-way decent in a few minutes. >> >> Or is the problem actually XML in this case, i.e. it's obvious that we want >> to extract the short description but that leaves an uncertain context? > > The short description is not a problem. But the "Returns" "Deletes" "Reduces" > etc ? IMHO that is overkill. It only works comprehensively for a handful routines.

Well, a set of "tags" (not in XML sense, but in keyword sense) for each routine would be sufficient. This can be added easily, but the main problem is updating the many thousands of existing identifiers.

Categorizing routines, with subcategs if need be will be trouble enough, specially if you want to do it future proof (and also be able to flag the static method approach that Delphi current favours)

OK, that was totally chinese. I'll have to ask my chinese pillow to translate this.

Michael.

Reply by email

Marco van de Voort
to Unknown author

In our previous episode, said:

Show quoted text 6 lines
> Categorizing routines, with subcategs if need be will be trouble enough, > specially if you want to do it future proof (and also be able to flag the static > method approach that Delphi current favours) OK, that was totally chinese. I'll have to ask my chinese pillow to translate this.

I mean procedures and functions is not enough. It must be possible to add static methods to this categorization system too (to be visible in the same overviews as normal functions), because newer delphi versions stuff all new routines as static methods into classes, and sooner or later we will have to deal with that too.

With subcateg(ory)s I meant that simply one dimensional tagging might not be enough. You might want to have a broad category with several smaller ones nested in it.

I hope you and your chinese pillow will be allright :-)

Reply by email

Mark Morgan Lloyd
to Marco van de Voort
Marco van de Voort wrote 17 lines
In our previous episode, said: >> Categorizing routines, with subcategs if need be will be trouble enough, >> specially if you want to do it future proof (and also be able to flag the static >> method approach that Delphi current favours) > OK, that was totally chinese. I'll have to ask my chinese pillow to > translate this. I mean procedures and functions is not enough. It must be possible to add static methods to this categorization system too (to be visible in the same overviews as normal functions), because newer delphi versions stuff all new routines as static methods into classes, and sooner or later we will have to deal with that too. With subcateg(ory)s I meant that simply one dimensional tagging might not be enough. You might want to have a broad category with several smaller ones nested in it.

The problems with tagging etc. are that (a) somebody's got to do the work retroactively and (b) there's a temptation to fit things into existing categories (should Soundex support go into sorting, hashing, or its own category?).

As a user with limited experience, I'd settle for something that generated a simple KWIC list, even if I had to manually exclude some possibilities.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Andrew Haines
to Marco van de Voort: In our previous episode, said: Categorization of routines (string,file etc) would be a…
Marco van de Voort wrote 6 lines
CHM has a basic phrase indexer, and it operates on the html. The search part is maybe part of the viewer, and one would have to see how complex it is. (Iow if the complexity is in index or search, if the search is relative simple one could look at kchmviewer)

As far as I remember the chm search only indexes whole words. So searching for "space" would not return "LotsOfSpace" I'm not sure if it would find "SpaceFoo" since it starts with space.

Does changing the indexer to extract words from capitalized words make sense? i.e. "DoSomethingCool" becomes "do", "something", "cool" ?

Regards,

Andrew Haines

Reply by email

Max Vlasov
to Unknown author: Shortly said: no. Creating such an index requires additional keywords, which are simply…
Show quoted text 20 lines
> For example, can I rapidly get all function descriptions with "space" as > part of the description, which could subsequently be filtered (e.g. if I > were interested in text operations I could quickly ignore anything with > "file" in the description)? > ... > That's somewhat abbreviated so that it's not screwed too badly by wrap. > Creating such an index requires additional keywords, which are simply not present now. That said, I am still looking for a good search engine *written in Object pascal* for the FPC html docs. Any hints/tips are appreciated.

Michael, are the docs hand-prepared or automatically generated from some db/xml?

If the former, can it be safely assumed that the url http://www.freepascal.org/docs-html/rtl/{unitname}/{functionname}.html<http://www.freepascal.org/docs-html/rtl/%7Bunitname%7D/%7Bfunctionname%7D.html> is standardized?

if the latter, is it possible to download this data from somewhere for experimenting?

Thanks

Max Vlasov

Reply by email

Sven Barth
to Unknown author: Shortly said: no. Creating such an index requires additional keywords, which are simply…

Am 26.01.2011 13:06, schrieb

That said, I am still looking for a good search engine *written in Object pascal* for the FPC html docs. Any hints/tips are appreciated.

I have never tested it, but I once stumpled upon the Ioda search engine ( http://ioda.sourceforge.net/ ) which fulfills your criteria and also is already compileable by FPC (according to the author).

Regards,
Sven

Reply by email

Unknown author
to Max Vlasov: Michael, are the docs hand-prepared or automatically generated from some db/xml? If the…
Max Vlasov wrote 24 lines
On Wed, Jan 26, 2011 at 3:06 PM, wrote: > > > > > >> For example, can I rapidly get all function descriptions with "space" as >> part of the description, which could subsequently be filtered (e.g. if I >> were interested in text operations I could quickly ignore anything with >> "file" in the description)? >> ... >> That's somewhat abbreviated so that it's not screwed too badly by wrap. >> > > Creating such an index requires additional keywords, which are simply not > present now. > > That said, I am still looking for a good search engine *written in Object > pascal* for the FPC html docs. Any hints/tips are appreciated. > > Michael, are the docs hand-prepared or automatically generated from some db/xml?

They are generated from fpdoc XML files.

If the former, can it be safely assumed that the url http://www.freepascal.org/docs-html/rtl/{unitname}/{functionname}.html<http://www.freepascal.org/docs-html/rtl/%7Bunitname%7D/%7Bfunctionname%7D.html> is standardized?

Yes, it is safe to assume so. I have no plans to change this :-)

Michael.

Reply by email

Unknown author
to Sven Barth: Am 26.01.2011 13:06, schrieb I have never tested it, but I once stumpled upon the Ioda…
Sven Barth wrote 7 lines
Am 26.01.2011 13:06, schrieb > That said, I am still looking for a good search engine *written in Object > pascal* for the FPC html docs. Any hints/tips are appreciated. I have never tested it, but I once stumpled upon the Ioda search engine ( http://ioda.sourceforge.net/ ) which fulfills your criteria and also is already compileable by FPC (according to the author).

I know this engine, but the sources are not available. Not for download, not from CVS.

Michael.

Reply by email

Mark Morgan Lloyd
to Unknown author
Show quoted text 14 lines
On Thu, 27 Jan 2011, Sven Barth wrote: > Am 26.01.2011 13:06, schrieb >> That said, I am still looking for a good search engine *written in >> Object >> pascal* for the FPC html docs. Any hints/tips are appreciated. > > I have never tested it, but I once stumpled upon the Ioda search > engine ( http://ioda.sourceforge.net/ ) which fulfills your criteria > and also is already compileable by FPC (according to the author). I know this engine, but the sources are not available. Not for download, not from CVS.

I don't know whether this is complete but I note
http://sourceforge.net/projects/ioda/files/ioda/1.3/ioda-1.3-src.tar.bz2/download

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Sven Barth
to Mark Morgan Lloyd
Mark Morgan Lloyd wrote 18 lines
wrote: > On Thu, 27 Jan 2011, Sven Barth wrote: > >> Am 26.01.2011 13:06, schrieb >>> That said, I am still looking for a good search engine *written in >>> Object >>> pascal* for the FPC html docs. Any hints/tips are appreciated. >> >> I have never tested it, but I once stumpled upon the Ioda search >> engine ( http://ioda.sourceforge.net/ ) which fulfills your criteria >> and also is already compileable by FPC (according to the author). > > I know this engine, but the sources are not available. Not for > download, not > from CVS. I don't know whether this is complete but I note http://sourceforge.net/projects/ioda/files/ioda/1.3/ioda-1.3-src.tar.bz2/download

This should be the complete and latest one (I have attached that in the other mail). Must have been my internet connection, cause I couldn't download it some minutes ago. ^^

Regards,
Sven

Reply by email

Unknown author
to Sven Barth
Sven Barth wrote 23 lines
Am 27.01.2011 10:14, schrieb Mark Morgan Lloyd: > wrote: >> On Thu, 27 Jan 2011, Sven Barth wrote: >> >>> Am 26.01.2011 13:06, schrieb >>>> That said, I am still looking for a good search engine *written in >>>> Object >>>> pascal* for the FPC html docs. Any hints/tips are appreciated. >>> >>> I have never tested it, but I once stumpled upon the Ioda search >>> engine ( http://ioda.sourceforge.net/ ) which fulfills your criteria >>> and also is already compileable by FPC (according to the author). >> >> I know this engine, but the sources are not available. Not for >> download, not >> from CVS. > > I don't know whether this is complete but I note > http://sourceforge.net/projects/ioda/files/ioda/1.3/ioda-1.3-src.tar.bz2/download This should be the complete and latest one (I have attached that in the other mail). Must have been my internet connection, cause I couldn't download it some minutes ago. ^^

Duh... how could I have missed that ?

Thanks, I downloaded it. Let's see what we can do with this.

Michael.

Reply by email

Graeme Geldenhuys
to Unknown author: Shortly said: no. Creating such an index requires additional keywords, which are simply…

Op 2011-01-26 14:06, het
geskryf:

That said, I am still looking for a good search engine *written in Object pascal* for the FPC html docs. Any hints/tips are appreciated.

What exactly do you want to use it for? Or How? Doesn't Google index the online HTML already?

Isn't DocView's (INF help) searching or some CHM viewer (your mileage may vary depending which viewer and platform you use) good enough for searching the help?

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/

Reply by email

Graeme Geldenhuys
to Andrew Haines: As far as I remember the chm search only indexes whole words. So searching for "space"…

Op 2011-01-27 02:27, Andrew Haines het geskryf:

As far as I remember the chm search only indexes whole words. So searching for "space" would not return "LotsOfSpace" I'm not sure if it would find "SpaceFoo" since it starts with space.

That's the problem with CHM viewers, they are all in varying states of what they support or how good they perform at such tasks. Linux alone has about 5 or more CHM viewers, and they are all pretty crap in their own way.

You are welcome to take a peek at fpGUI's DocView searching code (but how well it can be translated to LHelp is unknown to me). DocView has extensive searching support with instant results, even in searching was done across multiple INF documents. The search features in DocView includes:

* Search across multiple open INF documents

* Search by phrases by including multiple words in double quotes. eg: "cross platform"

* Finer control over search results, by including a + or - symbol in front of a word. For example, the search term "OnClick -Button' will search for topics that contain "OnClick", but NOT have the word "Button" in the text.

* Partial word matches. eg: Searching for "win", will find "window", "following", "showing" etc. The better the match, the higher the search ranking, and thus the closer to the top of the search results it will appear. By "better the match" I mean, is the search term found in the title of the topic, in the index entry, in the body of the topic, or closer to a full word.

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/

Reply by email

Unknown author
to Graeme Geldenhuys: Op 2011-01-26 14:06, het geskryf: What exactly do you want to use it for? Or How?…
Graeme Geldenhuys wrote 8 lines
Op 2011-01-26 14:06, het geskryf: > > That said, I am still looking for a good search engine *written in Object > pascal* for the FPC html docs. Any hints/tips are appreciated. What exactly do you want to use it for? Or How? Doesn't Google index the online HTML already?

Probably, but I don't want to rely on Google.

Isn't DocView's (INF help) searching or some CHM viewer (your mileage may vary depending which viewer and platform you use) good enough for searching the help?

Not if I want to have it as a CGI on the server.

Michael.

Reply by email

Marco van de Voort
to Graeme Geldenhuys: Op 2011-01-27 02:27, Andrew Haines het geskryf: That's the problem with CHM viewers, they…

In our previous episode, Graeme Geldenhuys said:

Show quoted text 8 lines
> As far as I remember the chm search only indexes whole words. So > searching for "space" would not return "LotsOfSpace" I'm not sure if it > would find "SpaceFoo" since it starts with space. That's the problem with CHM viewers, they are all in varying states of what they support or how good they perform at such tasks. Linux alone has about 5 or more CHM viewers, and they are all pretty crap in their own way.

Did I miss something? Does the .INF viewer in the textmode IDE spontaneously support search now?

IOW, the situation with .INF is exactly the same :-)

Reply by email

Graeme Geldenhuys
to Unknown author: Probably, but I don't want to rely on Google. Not if I want to have it as a CGI on the…

Op 2011-01-28 11:18, het
geskryf:

> What exactly do you want to use it for? Or How? Doesn't Google index the > online HTML already? Probably, but I don't want to rely on Google.

In that case, there is always Bing too. ;-)

For those wanting to use Google, here is the search term format to use (By the way, Google offers a search box embedded inside your web pages for ages too). Just one or two lines of HTML.

<text to seach> site:freepascal.org

eg:

FileExists site:freepascal.org

Not if I want to have it as a CGI on the server.

Fair enough. But why would you want to spend time on that then? I thought you see the HTML help format (and probably TXT, RTF, CHM and INF too) as second rated, and the "real format" help is only PDF. :)

Regards,
- Graeme -

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/

Reply by email

Unknown author
to Graeme Geldenhuys
Graeme Geldenhuys wrote 8 lines
Op 2011-01-28 11:18, het geskryf: >> What exactly do you want to use it for? Or How? Doesn't Google index the >> online HTML already? > > Probably, but I don't want to rely on Google. In that case, there is always Bing too. ;-)

Have you ever tried finding something on Bing ?

Show quoted text 5 lines
> Not if I want to have it as a CGI on the server. Fair enough. But why would you want to spend time on that then? I thought you see the HTML help format (and probably TXT, RTF, CHM and INF too) as second rated, and the "real format" help is only PDF. :)

Oh, but I still think PDF is the only format.

But unfortunately, this is not a dictatorship, and many people prefer HTML.

Michael.

Reply by email

José Mejuto
to Unknown author: Probably, but I don't want to rely on Google. Not if I want to have it as a CGI on the…

Hello FPC-Pascal,

you wrote
> Isn't DocView's (INF help) searching or some CHM viewer (your mileage > may vary depending which viewer and platform you use) good enough for > searching the help?

mvwb> Not if I want to have it as a CGI on the server.

Do you plan to add Joda to CCR or anywhere ? I'm asking because I'm also using Joda for a local project and I wish to extend it a bit and doubling code in an incompatible way is not a very good thing ;)

My primary target is Windows, so I had changed some code here and there to allow windows file names, end line chars and others.

Best regards, José

Reply by email

Tomas Hajny
to Marco van de Voort: In our previous episode, Graeme Geldenhuys said: Did I miss something? Does the .INF…
Marco van de Voort wrote 16 lines
In our previous episode, Graeme Geldenhuys said: > > As far as I remember the chm search only indexes whole words. So > > searching for "space" would not return "LotsOfSpace" I'm not sure if > it > > would find "SpaceFoo" since it starts with space. > > That's the problem with CHM viewers, they are all in varying states of > what they support or how good they perform at such tasks. Linux alone > has about 5 or more CHM viewers, and they are all pretty crap in their > own way. Did I miss something? Does the .INF viewer in the textmode IDE spontaneously support search now? IOW, the situation with .INF is exactly the same :-)

Well, I believe that the point made by Graeme was primarily related to existence of good CHM viewers for Linux, not to the format itself (this time at least ;-) ) or support of this or that format in our textmode IDE. Nevertheless, having the support of searching added also to our IDE would be indeed nice. ;-) Proper support for IBM .INF documents (including the OS/2 API documentation) in his viewer would be very nice too. ;-)))

Tomas

Reply by email

Ben Smith
to Tomas Hajny

2011/1/28 Tomas Hajny

existence of good CHM viewers for Linux,

No such viewers exist. :-)

time at least ;-) ) or support of this or that format in our textmode IDE.

Is there actually somebody that still uses a text mode IDE for day to day development? I couldn't justify spending any time on enhancing a text mode IDE, especially since there are thousands of better GUI text editors or GUI IDE's out there.

be indeed nice. ;-) Proper support for IBM .INF documents (including the OS/2 API documentation) in his viewer would be very nice too. ;-)))

I remember using OS/2 years ago, and from memory the OS/2 API documentation (*.inf files) used many windows open at the same time in the VIEW program. I cannot see how that can ever be converted to something that will work in the textmode IDE. Plus you will also loose any bitmap images/screenshots in any such help files (INF, CHM, HLP, HTML etc).

              Ben.

Reply by email

Marco van de Voort
to Ben Smith

In our previous episode, Ben Smith said:

Show quoted text 6 lines
> time at least ;-) ) or support of this or that format in our textmode IDE. Is there actually somebody that still uses a text mode IDE for day to day development? I couldn't justify spending any time on enhancing a text mode IDE, especially since there are thousands of better GUI text editors or GUI IDE's out there.

Not for day to day main app (I spend 40-50 hrs a week in Delphi), but I use it a lot for quick and dirty work. Scripting so to say, and little modifications. keeps its state on a per directory basis (multiple projects with their own context selectable by the dir where you start), and compile is just pressing F9 after startup.

The configuration files are simple, short ini/cfg's that can be generated (e.g. to initiate a new project, or pass another directory to all projects), and their contents are fixed pretty much since last century (my 2003 projects STILL start, though on Windows driveletter changes make that less useful as on *nix)

And better is subjective, specially if not qualified with a workflow or purpose, and nobody said that a choice has to be exclusive.

An ordinary texteditor is barely a substitute for an IDE btw. Poor session support, no help, often inferior syntax highlighting. The only one I sometimes use is Joe (partially because joe-textmodeide-lazarus-delphi all support wordstar extensions to some degree which makes switching bareable). Cygwin on windows.

Show quoted text 7 lines
> be indeed nice. ;-) Proper support for IBM .INF documents (including the > OS/2 API documentation) in his viewer would be very nice too. ;-))) I remember using OS/2 years ago, and from memory the OS/2 API documentation (*.inf files) used many windows open at the same time in the VIEW program. I cannot see how that can ever be converted to something that will work in the textmode IDE.

The textmode IDE is windowed, and now hardware modes don't matter anymore, there is a lot more space than the classic 80x25 or 80x50. I usually work at 160x90 or so.

Multiply that by the font size, and there really isn't that much

Plus you will also loose any bitmap images/screenshots in any such help files (INF, CHM, HLP, HTML etc).

Yes. But currently the help simply works best in the textmode IDE. It is almost instantly there, and takes you to the right topic. And both IDE and help are extremely quick to start, so ideal for the little bits. The only bit it needs is a disambiguation possibility (if multiple topic match, let them choose). It's on my agenda :)

Moreover, I have been converting my "always on" machines to ARMs, which I can access over ssh, and work directly in the IDE.

Sure there is remote X over ssh, and while that is even doable with nowadays internet traffic (my rule of thumb is about 40kbyte/s bidirectionally to work comfortably), for the quick checking or adaptation a ssh prompt and the textmode IDE is way quicker.

Reply by email

Marco van de Voort
to Tomas Hajny: Well, I believe that the point made by Graeme was primarily related to existence of good…

In our previous episode, Tomas Hajny said:

Show quoted text 14 lines
>> That's the problem with CHM viewers, they are all in varying states of >> what they support or how good they perform at such tasks. Linux alone >> has about 5 or more CHM viewers, and they are all pretty crap in their >> own way. > > Did I miss something? Does the .INF viewer in the textmode IDE > spontaneously > support search now? > > IOW, the situation with .INF is exactly the same :-) Well, I believe that the point made by Graeme was primarily related to existence of good CHM viewers for Linux, not to the format itself (this time at least ;-) )

I run the textmode IDE on Linux. It is fine :-)

Nevertheless, having the support of searching added also to our IDE would be indeed nice. ;-) Proper support for IBM .INF documents (including the OS/2 API documentation) in his viewer would be very nice too. ;-)))

For some of the new features I have to work around the current helpsystem. But I'll try to set that up with some base class that queries for capabilities. Then if pigs fly, and sb works on those formats, they can implement it.

Reply by email

Tomas Hajny
to Ben Smith: 2011/1/28 Tomas Hajny No such viewers exist. :-) Is there actually somebody that still…
Ben Smith wrote
2011/1/28 Tomas Hajny

.
.

Show quoted text 9 lines
> be indeed nice. ;-) Proper support for IBM .INF documents (including the > OS/2 API documentation) in his viewer would be very nice too. ;-))) I remember using OS/2 years ago, and from memory the OS/2 API documentation (*.inf files) used many windows open at the same time in the VIEW program. I cannot see how that can ever be converted to something that will work in the textmode IDE. Plus you will also loose any bitmap images/screenshots in any such help files (INF, CHM, HLP, HTML etc).

1) Graeme's INF viewer which was the point of the previous posts (cf. "...in his viewer" above) is not text mode.
2) Actually, an INF viewer working in text mode existed even for traditional text modes (80x25, 80x50, etc.) in DOS (IBM shipped it with its PC DOS). The main limitation of that viewer are the memory constraints (it is a real-mode application).
3) There's no reason why multiple windows couldn't work even in our text mode IDE (although that was not the original point of my statement).
4) OS/2 API documentation contains no bitmap images or screenshots (Linux man pages or MSDN documentation for MS Windows API don't require bitmap images either).

Tomas

Reply by email