a little searching aid

[Gurce Isikyildiz]

I needed an improved search facility to help get my brain back into gear on this topic, as information is dispersed across a few sources at present.

• There were some loose text files/documents
  
• At one stage, I had rolled my own wiki, with some of my own doc material, and cross-links to other material elsewhere
• Ben initiated the github-based wiki docs
• Paul has his blog posts
• We have our forum discussions here

So I decided to add multiple search buttons on my wiki, just as a quick way to ping any of these resources:

http://gurce.net/mega65/doku.php

In the top-right, you'll see all the search bars.

In this example, I'm searching through Paul's blog on anything regarding "cpu speed" (by clicking on the "Search Blog" button).

Anyway, just a little perk to help getting to that info quicker :)

[Gurce Isikyildiz]

Added the Xemu wiki too, just to cast the net a little wider :)

[Paul Gardner-Stephen]

Hello,

It would be great to look at pulling this information into markdown files in the github repo, so that it can be updated to match the code all the time.

Paul.

--
You received this message because you are subscribed to the Google Groups "MEGA65 Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to c65gs-development+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gurce Isikyildiz]

Yup, I hear you, it's an ideal to have everyone contributing their knowledge to the one searchable place.

There's always many factors that get in the way of that ideal, ofcourse. I'll elaborate a little, not intending to be mean-spirited about this, but just sharing my thoughts on the matter:

- There's a lot of info out there in multiple locations, I don't think one person could tackle pushing it all into one place alone. Perhaps each contributor can slowly get into the habit of nurturing the github repo docs.
- I'm sure there are developers still unfamiliar with github's wiki-tags, commit+push style of changes, no easy preview ability (unless via installation of grip tool), no internal automated TOC facility (except via 3rd party techniques). All those kind of gripes can act as deterrents that slow down the adoption.
- For a measure of this slow adoption, we can take a look at the git logs to see who has contributed to the "doc/" folder so far, and how often. Ben is the most significant contributor, followed by a few updates by yourself and me.
- Sometimes a doc contributor's work is not so visible to us, due to us focusing on the main repo/branch, whereas the contributor's document updates are within their own fork/branch, awaiting a merge to master, or pull request to be accepted.

So anyway, I can understand why the habit isn't there yet for most, and why the blogs & forums will always contain plenty of nuggets of info worth searching for.

Anyway, I'll continue to make github repo doc additions, in an incremental fashion, as I hope others will too, as their time permits.

Still, accepting that the ideal, utopian single-source for knowledge won't be here for a while, having some interim search measure like the one I devised can help, at the very least for myself, but perhaps for others too. For those that want to chase up info they remembered reading somewhere, but they're just not sure exactly where :)

[Paul Gardner-Stephen]

All sounds good, and I didn't mean to discourage you in any way from improving what you already have.

Paul.

--

[Gurce Isikyildiz]

PS. Just wanted to also gives some extra assurance that I wasn't using this search facility I created as a means to promote my own wiki, my own site, or myself, as there's always the possibility others could interpret it that way.

For my own wiki, it was something that came about in 2016, when I was initially learning about the project, reading info from multiple sources, and wanted a place to quickly accumulate links to these sources, and also add my own. It was through those efforts that I eventually came across Ben's github repo docs, which were housed in his own branch/fork at the time. I was quite surprised to find it, because his doc efforts were significant, and I didn't think the community was aware of it, so I highlighted it in the forums here.

This then led to some discussion on where such information should be housed, and Paul decided that it should be the github repo, which I have complied with, and contributed to.

For my part, I have disabled my wiki's registration process, no new users are permitted. I still make some modest doc additions to it, as I find making updates via a live wiki to be quick and fast, whereas doing it via github repos tends to be a bit more sluggish.

As for that wiki being hosted on my site, that came about solely as it was easy enough for me to install a free wiki system there and make use of it. If there was ever a problem with location, I've always been willing for it to be hosted elsewhere (till the point where the info within it has moved into github). A dokuwiki consists solely of text files, so it can be easily zipped up and hosted elsewhere (no need for sql databases).

To allay any concerns that I made the search engine as a promotion of myself, (a feeding my ego ;)), I'll say that personally, I made it more out of sensing a personal need for it. I'm about to embark on a dev task, I needed information on the matter, it was housed in different mediums presently, so I wanted to make it easier for myself to search those multiple locations quickly.

Another factor in why I did this (and fairly quickly), was because I've done it before, in my own workplace. My workplace also has multiple documentation sources: sharepoint, along with multiple wikis from different eras, different teams in different worldwide locations. The frustrations of running around from place to place hunting for info led to this shortstop solution.

With all this being said, I suppose all of us programmers accomplish things with a little desire to promote ourselves, let the world know what we're capable of, maybe that much can be forgiven :) I tend measure myself as the more modest sort, not much of a horn-tooter. Still, my wife says modesty is just a hidden form of horn-tooting ("Oh, he's so modest! How nice! ;)"), so perhaps nobody is immune :)

As for verbosity, perhaps some might feel this level of verbosity is unnecessary (TL;DR). For me, I hope not to delve into it too often, but perhaps it's warranted early on, when it's easy for others in a community to read into small actions, have concerns about an approach, a mindset, and start trying to get a measure of the modus operandi of a person. So for me, these days, I'm finding it best just to get it out from the outset, and share the "why" behind my actions, rather than leave it to guesswork  ;)

Anyways, enough verbosity from me, back to that task ;)

[Paul Gardner-Stephen]

Hello,

The thought didn't even cross my mind, don't worry about it at all.

Paul.

--

[Gurce Isikyildiz]

Cheers Paul for the assurance.

On the ide scrollback task, just small nibbles at present.

I was able to replicate the issue for a start, but just wanted to get familiar with cc65 a bit before delving further.

I made a simple example program to print out cgetc() keycodes of typed characters and ran this via xemu.

I'm hoping to pick out two codes for a page-up and page-down action (to help me get to the bottom of a file quicker). Maybe I'll pick out C-F (page down) and C-B (page up), as they were a bit vim-like and were stuck in my head. Will try add them in tomorrow and delve deeper.

[Paul Gardner-Stephen]

No worries.

C= + up and C= + down seems logical also.  Easier on a C65 keyboard where you don't have to do C= + shift + down for page up.

Paul.

--