RetroBSD

Hi ibara,

Oops. Gotta get right compiler . Looking at target.mk looks like gcc used for pic32 is 4.5.1?

/usr/local/pic32-tools/bin/pic32gcc --version --> ...4.5.1 ... v1.30-20110506

Running on older Knoppix -- kernel 2.6.31.2 ... Nov 10, 2009.

Wiz

There's a newer toolchain available at the github repo.

_________________
@__briancallahan on Twitter

Hi friends,

I've merged it into the master branch. Works fine on pic32sim.

Brian, thanks!
PS: a few thoughts to 1.6 binary:

Why the first character (within a line) has got index "0"? Would not "1" be nicer?


What about such a smoother arrangement of the info bar, for example:

When the user blinks to the info bar, he sees "Yes, I am still working with the file rc, at line 3, char 15 (starting at 1) and it is about a fifth of the whole stuff I have to check out today.. and I am using version 1.6 if someone asks me..

_________________
Pukao Hats Cleaning Services Ltd.

Did I forget to bump the version number on that binary? I'll upload a new tarball later today.


This is what GNU Emacs does. In fact, I intentionally modeled it after GNU Emacs because I don't think emg should deviate from GNU Emacs (where it can) since that would actually lose one of the benefits of emg (so that emacs people don't have to learn a new editor just to work with RetroBSD). This is also part of the historicity of Mg.


This loses the buffer name, which can be different than the file name.

_________________
@__briancallahan on Twitter

It might be the Emacs has been developed by HAL, but we, humans, say "the first character on the line.."


Then for example:

That arrangement requires an additional line of code for calculating the number of "=" based on the lenght of the file/buffer names

PS: I am using emg frequently with retrobsd, the only functionality I use is ctrlXctrlS and ctrlXctrlC (except moving with cursor throughout the text and using buttons Space/Enter/Del/Backspace) and I am very happy with it (copy and paste is offered by the terminal program itself)...

_________________
Pukao Hats Cleaning Services Ltd.

Hi ibara,

EMG is one cool editor. I am not sure I would have suggested line numbers given the increase in size?

Which suggests another approach rather than storing the text to be edited directly into memory.

My understanding of the WordStar editor was that it kept pointers to text lines rather than text itself in memory? Thus it could edit very much larger files. Maybe others can further clarify this.

Also WordStar was small and ran well in small computers.

So I guess what I am suggesting is that we look into adding some sort of similar capability to emg.

There may be other editors with open source that pieces could be copied from?

EMG is great. I use it everyday

Wiz

So I have an idea to reduce the size of emg a bit.

Question: what is the longest filename length in the RetroBSD source tree? Right now, emg is creating a whole lot of statically allocated arrays of size 80. That takes up a lot of space. If we know the longest filename, we can just make the size ((longest filename) + 1).

For example, reducing the filename array size to 32 results in a binary size of 40108, which is a savings of 2192.

This is not the greatest of code shrinkings, but it's hard to not want to make emg as small as possible.

_________________
@__briancallahan on Twitter

Hi Ibarra,

Great idea. Did you mean line length? If so 32 chars would be worth a try. Long lines could auto-wrap to the next line on loading. Or you could find lines by starting from the beginning of one large buffer and counting line-feeds.

There can be more than one version. I use emg-1.3 mostly. When I need line numbers to locate the bad line I use emg-1.6. This works pretty well.

Lots of fun .

Wiz

No, I mean the length of the name of the file emg can read in.
Like when you use C-x C-f

_________________
@__briancallahan on Twitter

Hi Ibara,

How about a script:

1. Change filename to something very short --> a.

2. Edit file called a. --> emg a

3. Change filename back to original with or without backup.

Maybe I missed something?

Wiz

That's not the right approach. That's extremely tedious and error prone.
I'm going to set the filename array size to something that I think is sensible in the next emg version and let the complaints file in.
Lack of complaints means that I got it right

_________________
@__briancallahan on Twitter

Hi ibara,

THE final test.

Does the user use it!

I use it .

Wiz

When we talk the file_name only (the path exclusive) I think 16 would be ok. Also compile it mips16, the speed is not extremely important with editors, I think

_________________
Pukao Hats Cleaning Services Ltd.

Yep, editors typically don't need many CPU cycles. Also, icache and similar solutions might help increase the amount of available data memory.

It already is being compiled with -mips16 by default (unless you've been turning it off, but then that's on you )

_________________
@__briancallahan on Twitter

Hi Ibara,

How about the editor telling us how much space is available/used for the currently open text file.

For me the multiple buffer stuff is confusing, but a write the selected portion of the current file to the filesystem would be nice.

Also a single command to search again would be more intuitive.

I use emg everyday .

Wiz

I don't like this. More logic = larger binary. I think that's antithetical to the primary goal of emg: be small.


I don't like the "write the selected portion of the current file to the filesystem" either. Reducing multiple buffers to a single buffer could be worthwhile and probably save a whole lot of space.


I'm thinking of ways to shrink the search functionality down. Nothing I love just yet.



Of course, my opinion can always be swayed with a good diff.

_________________
@__briancallahan on Twitter

Hi Ibara,

I could be swayed by a good diff....

Point well taken.

I should try to understand the emg source. In particular how much space is available for the file. I guess this is approximately 90k - size of emg? But it would be nice to know the real numbers. I observe that a 24k file croaks emg-1.6.

For me, ctrl-l is the choice for search again.

Can the multiple buffer stuff be a conditional compilation option easily? And maybe some other 'features'?

I too STRONGLY want emg to be small, simple and easy to hack.

I keep wondering about some of the early DOS editors? 4k RAM could do a lot. Wordstar with all its bells and whistles ran on 640k pcs. Not to mention the cpm stuff . There were a lot of sources available back then!

Wiz

Other than emg source itself, you could look at the original source for Ersatz Emacs (from which emg heavily derives): http://hunter.apana.org.au/~cjb/Code/
You can also look at Mg sources. mg1a, mg1b, and mg2a sources can all be found with a quick search. You can also view OpenBSD's Mg source:
http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mg/
or if you have cvs:
cvs -danoncvs@<your openbsd mirror>:/cvs checkout -P src/usr.bin/mg

These are all public domain sources (OpenBSD's Mg extensions are ISC licensed but the base editor is public domain), so you can uproot any of them wholesale if you'd like for emg.


^l is screen refresh (again, I like the idea of finger compatibility with big GNU Emacs). Why not use something that's currently unused? ^j doesn't have anything assigned to it.

_________________
@__briancallahan on Twitter