Denial

Push... push push push... why didn't they put that in the right-click menu?

Pushing.

Perhaps I need to make some translation part in the code so that the tokenlist that could have "end,eN, $80 etc... " will grab the eN and translate the N into the "in editor shifted N"-petscii code, no tokens use upper case letters so perhaps that will be a feasible solution.
For now they all just have an x in front of them.

The idea was to have single column tokenlists still working, but I'm not sure I got that right (either).

Hehe, yes, I had a feeling you wouldn't like "push" I didn't like it either to begin with... And now... Well, I've learned to 'tolerate' it

Mercurial/Git have all sorts of funny-sounding commands that take a while to sink into the brain (eg, "pull", "update").

...and even after they sink in, sometimes it's still a fair question for anyone to ask, "why can't I simply just do one 'commit' action and be done with it, rather than fiddling with all these other commands as well?!"

Well, I can summarise my experiences so far with Git/Hg this way:

PROS:
- work on your own private local repo without worrying about interfering with other developers' efforts
- can commit to your local repo even when you don't have internet access (since it's on your hard-disk)
Eg, I took my laptop to a remote country town one weekend, kept committing locally, then once I got back to work on monday, pushed to the repo onto our work server.
- access to your local repo is *lightning fast* (compared to svn/cvs, which need to do network comms to a server)
- Eg, If I want to study the commit-history of an svn project, I have to endure a lengthy pause while svn retrieves this info from the server over the net. Whereas with Git/Hg, I get this info instantly as it retrieves it from my local repo which is sitting on my local hard-drive.

CONS:
- painful learning curve
- more commands
- commands aren't always intuitive, it take a while to absorb their purpose, and absorb all the various parameters that alter their behaviour
- have to do more merges, on occasions when you push and the server-repo differs from your local-repo due to other colleagues committing and pushing things prior to you.
(on the upside, doing more merges means you get more experience with merging)

So I suppose for an online/collaborative team of developers, there are enough pros there to make it of interest and hopefully make the cons marginally forgivable

There could be a reminder pop-up in a new installation "remember to push as well to upload to server" or something.

I hope I'll have time to fiddle with this a bit more before the week is over.

Yes, I suppose there could be, if developers of gui-frontends such as TortoiseHg take on feedback like this. You could suggest it in the TortoiseHg issue-tracker if you like

https://bitbucket.org/tortoisehg/thg/is ... tatus=open

PS. I saw your two commits pushed onto the server now, and thanks for all the code comments you added too

Using BasEdit.net for the Tenliner competition... EXTREM...

I tried the Num Lock option for the first time, and I thought the keymap changed as I did so - until I understood that I had also activated the optional commands of this laptop keyboard...


Apart from undo I miss "Copy", "Cut" and "Paste" commands under the "Edit" menu option, that's where you usually find them. I tend to forget the custom commands between sessions.

I have no idea how to get the shifted characters into the abbreviations of the second column of commands - so any help is appreciated.

All the best with the compo entry

Yeah, an "undo" command would be nice, but would require a modest amount of elbow-grease that I couldn't fathom right now.

But as for easier access to cut/copy/paste, I've made a commit to the repo where I've provided a few new commands to the "Edit" menu.

To retrieve my latest commit from the mercurial repo, you will need to do two commands in your TortoiseHg gui again, "pull" and "update"... Sorry for yet another painful pairing of mercurial commands

"pull" = retrieves the latest commits from the online repo into your pc's local repo
This lets you see my commit in the commit-history of the gui, but it doesn't affect your current source files, they remain as they are. Eg, if you currently have edits that you haven't committed yet, you won't lose them.

"update" = right-click on my new commit and select "update". This then updates the source on your drive to my latest commit.
There's a chance this might fail, if it notices that you have edited a file on your local-pc that it wants update with my version. It might offer you to merge or force-overwriting. If you're lucky, it might even successfully auto-merge our changes But in the worst case scenario, if the thought of learning the "mercurial merging" process makes you want to puke, then don't try that for now. Just copy your changes to another backup folder, force "update" your main folder to my new commit, then copy over your changed files from your backup folder into your main folder.

I know... It's annoying... You're going to hate these steps just as much as "commit" and "push" from last time... Perhaps you'll hate them even more!

As for info on my commit, my added commands are:

• "Cut Block" = CTRL+Shift+X (or also the prior Shift-Del)
• "Copy Block" = CTRL+Shift+C (or also the prior Ctrl-Del)
• "Paste Block" = CTRL+Shift+V (or also the prior Shift-Ins)

Some caveats though:

• I chose these "CTRL+Shift" shortcuts due to the standard CTRL+X/C/V presently being used to draw various petscii chars
• One side-affect of "CTRL+Shift" shortcuts is that the app presently uses this key-pair to toggle between upper & lowercase charsets
• To try workaround this, I tried disabling the charset-swapping behaviour if you use the CTRL key on the right-side of your keyboard

Ie, I thought it'd be nicer to preserve the left-CTRL key's behaviour to emulate the commodore-key, as its position was also in the bottom-left. Although one downside of this choice is that most people prefer to do cut/copy/paste with the left-ctrl-key too. So doing it with the right-ctrl-key might feel a bit awkward too.

As for the shifted-characters, I haven't had a chance to ponder it through, but would something like this work? Let a particular 'unique' ibm-ascii key equate to "c64-shift-key" and another one equate to "commodore-key". Eg, '~' (tilde=shift) and '|' (pipe=commodore). So that "P (shift) R" would equate to "P~R" and the parser code could identify these special characters and "shift-ify" the character that follows it?

PS. I visited your site and saw your wiki on Channel F / VES programming. Wow, I never knew about that gaming hardware before, I had to google it to learn more It takes a lot of enthusiasm to share a wiki like that, congrats to you

Yes, some extra byte in there that is handled in the program, probably the easiest way to solve it.

I was walking the dog yesterday and thought it might be handy to have a keymap swap sequence, when pushed you'd have the normal PC keyboard and behaviour. Ctrl+C and all those would work etc etc, toggle it and you'd get the custom map.

Maybe Ctrl+C etc could work differently if the Caps Lock was active or not, adding shift to the equation makes it a bit less handy. Shift+Del and Shift+Insert is quite handy (at least on this laptop) it takes some getting used to.

New things I'm missing, line wrap at adjustable width, when working with maximum line length (256 bytes) it could be useful to get line breaks at maybe 64bytes to get a better overview. Not that it happens much, but in the current project (for this week). Also missing a horizontal slide bar - would probably not have needed one if the line breaks were available.

I wonder if it would be easier to add a line length calculation tool than all the abbreviated commands...


The VES wiki was started by my programming partner Tim Ryan, he had it running on one of his own computers when at school but it crashed and I adopted an older backup and started building it up again. Most of the contents is his work.

I've used Basedit a lot lately when developing my backgammon game. And, I found some bugs in Basedit:

* When starting/loading/maximizing the window, a strange blue marking is over the text in upper left corner.
* Search doesn't scroll the screen enough but marks the finding just below the visible area instead.
* Open disk image doesn't work.
* Renumber doesn't work.
* A couple of times, about second half of the program suddenly went missing.
* Syntax check gives errors for faulty gotos behind a REM command.
* Syntax check approves of lines containing IF but no THEN.

So, there are a couple of things for you to work on.

I think Basedit is a great program, with or without those bugs. I found it rather indispensable when developing my backgammon game. The tiny screen of the Vic-20 felt like a big hinder when developing a complex algorithm like that. (Having a programming language with real functions and subroutines would have helped a lot too haha).

I compiled it with austro compiler, which I think is great. Best way is to do it in VICE and run it in warp speed. You have to turn on true drive emulation, or it will fail.

Hi Boray,

Glad to hear this program still gets used. I also enjoyed using this program too.

Just so you know the current state of play, Björg Stojalowski, the original author made the source public domain, so I've added it to an online repository here:

https://sourceforge.net/projects/baseditnet/

The aim was so that if anybody wanted to contribute a few bug-fixes, they could.

So if you ever feel like you'd enjoy fixing a few of those bugs, you're welcome to tinker and commit your changes to the repo.

Here's a wiki-page summarising the steps of how to go about it:

• Sourceforge: - BasEdit.Net - How to contribute

The site also offers a bug-tracker (they call it 'Tickets' there). I haven't used it a great deal, but it might be of use, so you/others (and me ) are welcome to raise issues (or 'Create Tickets', in sourceforge-speak) there:

https://sourceforge.net/p/baseditnet/tickets/

When I try an action of pressing a F5 button
(save & run), instead of running a program
in the emulator it pops-up a message:

"Vice error!
Extra arguments on command line: and"

I must save the prg file on d64 image and
than separately open vice to open the same
from there...

How to run files in any emulator directly from
the BasEdit.net?

(screenshoot in the attachment)

I've just made it for VIC emulation... now considering
how to do the same for c64 emulation, since last time
(after sugested BasEdit.ini settings)
it throws me an error similar to this in attachment

I'll try and than erase both my messages to not bother
much to the forum as a beginner in this kind of things...

EDIT*** 'Found it... for direct-emu launchings file
must be "initialy" saved in BasEdit folder
(beside many emu-location changes itself, founded
as in the forum itself same as abroad whole internet....)

I'm revisiting BasEdit.Net and Visual Studio 2010... Still trying to stuff abbreviations as an accepted alias to the original keyword (commands).

Last years edit accepts a second column of token words, if I keep to normal characters it works, adding end, xend etc etc will end up saving the keyword xend as the token for end when making a prg. The problem comes when trying to use the shifted characters. gO for goto places the character $CF as the shifted O - that is getting saved as $CF as it's not recognized as a command so the basic-listing says GDATA as the token $CF is interpreted as DATA.

Found two rows in the code that could be a key, there's one listing the entire alphabet as well as ($@ etc, so I added the character Ï there as well (a capital i with two dots) that's the $CF ascii character in Windows, also added a few more for the first nine abbreviation in alphabetical order for ABS ASC etc etc...

But that didn't work in the "TokenList_BasicV2_ed.txt" that has my two column list of tokennames, neither adding the lowercase ï as it seems to jump between upper and lower case characters as well. Not sure if the case changing algorithm handles these characters though

Optimal would be to have a button you could click that changed the view of all basic keywords to their abbreviated version - so it would be easier to write code for the ten lines of basic competition. Just a translation list forth and back...

The code doesn't have much commenting, the ones that are there are in German and I'm basically a total newbe to this, I can copy and paste and have some basic understanding...

Isn't there anyone with some knowledge that wants to help making BasEdit.Net a bit better? It's more than halfway in the right direction already just a little more to go.

Hehe, nice to see you've still got the passion to press on with this project man

Whenever I see posts like that, it does give me the itch to join back in too, if only I had more free time, I would love to contribute more to this project.

Ah well, hopefully my time will free up one day.

Till then, keep up your posts with your latest innovations and attempts, 'cos witnessing enthusiasm like that is infectious

Enthusiasm will last about as long as the Ten line basic competition, when programming freely without the need to press things together in long lines with abbreviations programming directly on the real machine, in WinVICE or CBM prg Studio works just as well.
Then next year... we back on square 1 again.

Main problem is that I don't quite understand the code, seems it would be an easy thing to add if one knew what the parts were doing.

It surprised me a bit that adding the mentioned characters there in the code didn't solve the problem.

I actually got Arthur to do some changes in CBM prg Studio, so perhaps that will catch up.