From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 5 Feb 2014 06:36:21 -0500 To: 9fans@9fans.net Message-ID: <9031696b55153f1092b3e564463f31fd@mikro.quanstro.net> In-Reply-To: References: <20140124124408597647.a47c0e3b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] New internal command for acme proposal (with implementations) Topicbox-Message-UUID: b6b53974-ead8-11e9-9d60-3106f5b1d025 > I believe Acme should not be extended such way. There already were a lo= t of > proposals of commands to add in Acme. > If all of them were added we would have Acme with a size like LibreOffi= ce > and a tag on half of screen. the parent said: > > I can't implement cmd as external, so I did little changes in > > original i don't believe anyone has proposed adding all of them, and it's not necessary to put every command that could be in the tag, in the tag. Edit, for exampl,e is omitted. > So let's extend Acme not by internal commands but filesystem extentions= , > may be new files, may be new messages for "ctl" files. > For example, for pointer it can be a message "pointer=3Daddr" for "ctl"= file. in spirit i agree with this. but a few more points. i've experimented with a few similer modifications, and have found that the fs interface isn't fiat=E2=80=94it reflects the structure of the code= . changes to the fs interface tend to spill out. once one thinks about major modifications, i think it becomes attractive to think about a new editor. i miss having graphics. - erik