[9fans] New internal command for acme proposal (with implementations)

[9fans] New internal command for acme proposal (with implementations)

[Uvelichitel]

	Hi 9fans. While working with large sources in acme I feeling some lack
of navigation capacity. So two new cmd. 1) 'Rev' , works precisely as
'Look' but in reverse direction. It also change behavior of right mouse
button search to search reverse. You will notice change with pointer
position and little symbol near pipe in tag. Executing 'Look' instantly
change behavior back. After all navigation 2) 'Tip' , return pointer to
last typing point. It understand 2-1 chording, so you can handy insert
selection to last insert point without snarfing, including same window.
	I can't implement cmd as external, so I did little changes in original
acme sources. I did all my best to make it accurate. Things work for me
on p9p for around a year. You can try it at
https://bitbucket.org/uvelichitel/acme. Repo contains full src/cmd/acme
dir, which you can 'mk install' and patch.diff to see changes. Any
feedback very appreciated, proposal can be implemented. In positive
case I can try to commite to p9p official repo at least.
	Best regards.

Re: [9fans] New internal command for acme proposal (with implementations)

[Uvelichitel]

On Fri, 24 Jan 2014 12:44:08 +0200, Uvelichitel wrote:
	Forget to notice, 'Tip' cmd executing with point selection, select all
text from last insertion to point. This allow you to visually select
large amount of text without 'Edit'. You can mark position as last
insert pressing 'esc' key.

Re: [9fans] New internal command for acme proposal (with implementations)

[dexen deVries]

On Friday 24 of January 2014 12:44:08 Uvelichitel wrote:
> 	Hi 9fans. While working with large sources in acme I feeling some lack
> of navigation capacity. So two new cmd. 1) 'Rev' , works precisely as
> 'Look' but in reverse direction. It also change behavior of right mouse
> button search to search reverse. You will notice change with pointer
> position and little symbol near pipe in tag. Executing 'Look' instantly
> change behavior back. 

:-/REGEX



> After all navigation 2) 'Tip' , return pointer to
> last typing point. It understand 2-1 chording, so you can handy insert
> selection to last insert point without snarfing, including same window.

Left/Right Arrow keys takes you to the position where selection (cursor) 
currently is.

if the selection covers several lines, Left takes you to beginning, and Right 
to the end.


this plays well with double-click on any open/close parenthesis/bracket/brace. 
to quickly move to the other end of code block etc.


-- 
dexen deVries

[[[↓][→]]]

Re: [9fans] New internal command for acme proposal (with implementations)

[Alexander Sychev]

[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]

Hi,

I believe Acme should not be extended such way. There already were a lot of
proposals of commands to add in Acme.
If all of them were added we would have Acme with a size like LibreOffice
and a tag on half of screen.

Here bitbucket.org/santucco/rev I have placed quick-n-dirty external
program for Acme that does the same like Rev command. It can't do only one
- to move pointer to a next found position. Yes, Acme doesn't support
setting of pointer position via filesystem. And I think this is a feature
that can be considered for addition in Acme. At least in both of your
extentions it is needed.

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=addr" for "ctl" file.

P.S. For reasons unknown for me this mail did not reach the mailing list.
This is a second attempt. Other my messages are published with a big
timeout.


On Fri, Jan 24, 2014 at 1:44 PM, Uvelichitel <uvelichitel@gmail.com> wrote:

>         Hi 9fans. While working with large sources in acme I feeling some
> lack
> of navigation capacity. So two new cmd. 1) 'Rev' , works precisely as
> 'Look' but in reverse direction. It also change behavior of right mouse
> button search to search reverse. You will notice change with pointer
> position and little symbol near pipe in tag. Executing 'Look' instantly
> change behavior back. After all navigation 2) 'Tip' , return pointer to
> last typing point. It understand 2-1 chording, so you can handy insert
> selection to last insert point without snarfing, including same window.
>         I can't implement cmd as external, so I did little changes in
> original
> acme sources. I did all my best to make it accurate. Things work for me
> on p9p for around a year. You can try it at
> https://bitbucket.org/uvelichitel/acme. Repo contains full src/cmd/acme
> dir, which you can 'mk install' and patch.diff to see changes. Any
> feedback very appreciated, proposal can be implemented. In positive
> case I can try to commite to p9p official repo at least.
>         Best regards.
>
>


--
Best regards,
  santucco

[-- Attachment #2: Type: text/html, Size: 2933 bytes --]

Re: [9fans] New internal command for acme proposal (with implementations)

[erik quanstrom]

> I believe Acme should not be extended such way. There already were a lot of
> proposals of commands to add in Acme.
> If all of them were added we would have Acme with a size like LibreOffice
> 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=addr" 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—it 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

Re: [9fans] New internal command for acme proposal (with implementations)

[Bakul Shah]

On Feb 5, 2014, at 3:36 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> once one thinks about major modifications, i think it becomes attractive
> to think about a new editor.  i miss having graphics.
If you mean mixed text and image, you will end up with some sort of structured markup language and a "word processor"!

What I want is support for complex text layout rendering (for Indian languages among others). This requires supporting OpenType fonts, not an easy task. Mac's TextEdit seems to do a decent job of this but I don't like it as an editor. 

Re: [9fans] New internal command for acme proposal (with implementations)

[erik quanstrom]

> On Feb 5, 2014, at 3:36 AM, erik quanstrom <quanstro@quanstro.net>
> wrote:
> > once one thinks about major modifications, i think it becomes
> > attractive to think about a new editor.  i miss having graphics.
> If you mean mixed text and image, you will end up with some sort of
> structured markup language and a "word processor"!

oberon certainly managed this with trivial layout.

for example, it could be as simple as an interface that allows
graphical applications inline with text.  for example,
	; lc
	clock.c
	; clock&
	[display of clock here persists until killed]
	; pwd
	/usr/quanstro/src/cmd/clock


> What I want is support for complex text layout rendering (for Indian
> languages among others).  This requires supporting OpenType fonts, not
> an easy task.  Mac's TextEdit seems to do a decent job of this but I
> don't like it as an editor.

i don't see why complex layout rendering -> opentype.  could you explain
this?

- erik

Re: [9fans] New internal command for acme proposal (with implementations)

[Bakul Shah]

On Feb 5, 2014, at 8:10 AM, erik quanstrom <quanstro@quanstro.net> wrote:

>> On Feb 5, 2014, at 3:36 AM, erik quanstrom <quanstro@quanstro.net>
>> wrote:
>>> once one thinks about major modifications, i think it becomes
>>> attractive to think about a new editor.  i miss having graphics.
>> If you mean mixed text and image, you will end up with some sort of
>> structured markup language and a "word processor"!
> 
> oberon certainly managed this with trivial layout.
> 
> for example, it could be as simple as an interface that allows
> graphical applications inline with text.  for example,
>    ; lc
>    clock.c
>    ; clock&
>    [display of clock here persists until killed]
>    ; pwd
>    /usr/quanstro/src/cmd/clock

Oh, you just want graphics display!

>> What I want is support for complex text layout rendering (for Indian
>> languages among others).  This requires supporting OpenType fonts, not
>> an easy task.  Mac's TextEdit seems to do a decent job of this but I
>> don't like it as an editor.
> 
> i don't see why complex layout rendering -> opentype.  could you explain
> this?


You need to use a font that has CTL logic built in. In complex scripts a sequence of Unicode chars will map to a single glyph. See http://en.wikipedia.org/wiki/Complex_text_layout

Re: [9fans] New internal command for acme proposal (with implementations)

[dexen deVries]

On Wednesday 05 of February 2014 08:04:04 Bakul Shah wrote:
> On Feb 5, 2014, at 3:36 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> > once one thinks about major modifications, i think it becomes attractive
> > to think about a new editor.  i miss having graphics.
> 
> If you mean mixed text and image, you will end up with some sort of
> structured markup language and a "word processor"!

does Abaco [1] support inline editing and HTTP PUT method (or PATCH)?



> What I want is support for complex text layout rendering (for Indian
> languages among others). This requires supporting OpenType fonts, not an
> easy task. Mac's TextEdit seems to do a decent job of this but I don't like
> it as an editor.


`having all the bells and whistles' doesn't make a great editor for 
programmers.


right now Acme is simple enough to be easily extensible and customizable for 
*your*  needs.
right now Acme is fast enough.
right now Acme uses fonts simple enough to be easily converted from other 
fonts.
...and the list goes on...



[1] http://lab-fgb.com/abaco/

-- 
dexen deVries

[[[↓][→]]]

Re: [9fans] New internal command for acme proposal (with implementations)

[Bakul Shah]

On Wed, 05 Feb 2014 17:39:23 +0100 dexen deVries <dexen.devries@gmail.com> wrote:
> > What I want is support for complex text layout rendering (for Indian
> > languages among others). This requires supporting OpenType fonts, not an
> > easy task. Mac's TextEdit seems to do a decent job of this but I don't
> > like it as an editor.
>
>
> `having all the bells and whistles' doesn't make a great editor for
> programmers.

CTL rendering is a a basic requirement for complex scripts, I
am afraid!  Support for it would be in font handling, not
acme. I was just saying it would nice to be able to use acme
for Indic scripts. Though I don't see it as a realistic option
at the moment for a variety of reasons.

Re: [9fans] New internal command for acme proposal (with implementations)

[Uvelichitel]

Hi dexen.

>> 	Hi 9fans. While working with large sources in acme I feeling some lack
>>of navigation capacity. So two new cmd. 1) 'Rev' , works precisely as
>>'Look' but in reverse direction. It also change behavior of right mouse
>>button search to search reverse. You will notice change with pointer
>>position and little symbol near pipe in tag. Executing 'Look' instantly
>>change behavior back.

>:-/REGEX

Sure, but it regexp search, which more expensive not literal and need
more typing. My proposal as opposite behave exactly as 'Look' and also
change behavior of right mouse
button search.

>> After all navigation 2) 'Tip' , return pointer to
>>last typing point. It understand 2-1 chording, so you can handy insert
>>selection to last insert point without snarfing, including same window.

>Left/Right Arrow keys takes you to the position where selection (cursor)
>currently is.

>if the selection covers several lines, Left takes you to beginning, and
Right
>to the end.


>this plays well with double-click on any open/close
parenthesis/bracket/brace.
>to quickly move to the other end of code block etc.

Proposal 'Tip' command operate with last insertion point, not selection
point, mean 'Tip' cmd return you where you typing after all selections
and scrolling.

Anyway thanks for feedback. Best regards.

Re: [9fans] New internal command for acme proposal (with implementations)

[Bence Fábián]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

I think these are nice additions.
Thanks for your work. I will try them out on monday.


2014/1/24 Uvelichitel <uvelichitel@gmail.com>

> Hi dexen.
>
> >>      Hi 9fans. While working with large sources in acme I feeling some
> lack
> >>of navigation capacity. So two new cmd. 1) 'Rev' , works precisely as
> >>'Look' but in reverse direction. It also change behavior of right mouse
> >>button search to search reverse. You will notice change with pointer
> >>position and little symbol near pipe in tag. Executing 'Look' instantly
> >>change behavior back.
>
> >:-/REGEX
>
> Sure, but it regexp search, which more expensive not literal and need
> more typing. My proposal as opposite behave exactly as 'Look' and also
> change behavior of right mouse
> button search.
>
> >> After all navigation 2) 'Tip' , return pointer to
> >>last typing point. It understand 2-1 chording, so you can handy insert
> >>selection to last insert point without snarfing, including same window.
>
> >Left/Right Arrow keys takes you to the position where selection (cursor)
> >currently is.
>
> >if the selection covers several lines, Left takes you to beginning, and
> Right
> >to the end.
>
>
> >this plays well with double-click on any open/close
> parenthesis/bracket/brace.
> >to quickly move to the other end of code block etc.
>
> Proposal 'Tip' command operate with last insertion point, not selection
> point, mean 'Tip' cmd return you where you typing after all selections
> and scrolling.
>
> Anyway thanks for feedback. Best regards.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2166 bytes --]