Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #33813 > unrolled thread

Block editor with Unicode

Back to article view | Back to comp.lang.forth

Contents

  Block editor with Unicode Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-10-10 15:33 +0200
    Re: Block editor with Unicode Christian Kellermann <ckeen@pestilenz.org> - 2014-10-10 16:06 +0200
    Re: Block editor with Unicode peter.m.falth@gmail.com - 2014-10-10 07:27 -0700
    Re: Block editor with Unicode albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-10-10 15:27 +0000
    Re: Block editor with Unicode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-10-10 15:59 +0000
      Re: Block editor with Unicode jg <josefg@gmail.com> - 2014-10-10 10:37 -0700
      Re: Block editor with Unicode hughaguilar96@yahoo.com - 2014-10-10 16:27 -0700
        Re: Block editor with Unicode hughaguilar96@yahoo.com - 2014-10-10 16:30 -0700
          UTF-8 'toupper' and 'tolower' (Re: Block editor with Unicode) Marcos Cruz <null_email_so_use_my_contact_page@programandala.net> - 2014-11-10 16:46 +0000
    Re: Block editor with Unicode Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-10 11:27 -0500
      Re: Block editor with Unicode Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 00:10 +0200
        Re: Block editor with Unicode Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-10-11 04:52 -0500
    Re: Block editor with Unicode Bernd Paysan <bernd.paysan@gmx.de> - 2014-10-11 00:04 +0200
    Re: Block editor with Unicode Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-10-15 11:31 +0200
    Re: Block editor with Unicode Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-10-21 14:09 +0200
      Re: Block editor with Unicode Stefan Mauerhofer <smauerhofer@androsoft.ch> - 2014-11-11 04:10 -0800
        Re: Block editor with Unicode Matthias Koch <matthias.koch@hot.uni-hannover.de> - 2014-11-12 07:45 +0100

#33813 — Block editor with Unicode

After a blocks implementation is now in my testing pipeline, it is time to write a comfortable terminal block editor for Mecrisp-Stellaris with cursor movements and some "less purist" additions. This raises a question:

Traditionally, blocks with its 1024 bytes have been printed with 16 lines of 64 characters (or a similiar measure like 25*40 with some extra bytes free...) and this has been fine with fixed memory footprint characters. But now I am thinking on how a block editor should behave when entering UTF-8 encoded Unicode characters. Do the line break after 64 visible characters and make the last line(s) shorter ? Make the line shorter which contains the Unicode character ? See the block as flowing free-format text with explicit line break characters, simply limited to 1024 Bytes ?

I am not asking on how to implement, but mainly how you would expect the look&feel to be ! If you know an UTF-8-aware block editor already available somewhere, then please tell me, of course, but I think this is uncharted land.

Matthias

[toc] | [next] | [standalone]

#33814

Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:

> Traditionally, blocks with its 1024 bytes have been printed with 16
> lines of 64 characters (or a similiar measure like 25*40 with some
> extra bytes free...) and this has been fine with fixed memory
> footprint characters. But now I am thinking on how a block editor
> should behave when entering UTF-8 encoded Unicode characters. Do the
> line break after 64 visible characters and make the last line(s)
> shorter ? Make the line shorter which contains the Unicode character ?
> See the block as flowing free-format text with explicit line break
> characters, simply limited to 1024 Bytes ?

AIUI Chuck Moore's colorforth blocks for example don't handle linebreaks
at all, or if you want to insert them they are editor words (blue words
IIRC).

Kind regards,

Christian

-- 
May you be peaceful, may you live in safety, may you be free from
suffering, and may you live with ease.

[toc] | [prev] | [next] | [standalone]

#33815

On Friday, October 10, 2014 3:37:46 PM UTC+2, Matthias Koch wrote:
> After a blocks implementation is now in my testing pipeline, it is time to write a comfortable terminal block editor for Mecrisp-Stellaris with cursor movements and some "less purist" additions. This raises a question:
> 
> 
> 
> Traditionally, blocks with its 1024 bytes have been printed with 16 lines of 64 characters (or a similiar measure like 25*40 with some extra bytes free...) and this has been fine with fixed memory footprint characters. But now I am thinking on how a block editor should behave when entering UTF-8 encoded Unicode characters. Do the line break after 64 visible characters and make the last line(s) shorter ? Make the line shorter which contains the Unicode character ? See the block as flowing free-format text with explicit line break characters, simply limited to 1024 Bytes ?
> 
> 
> 
> I am not asking on how to implement, but mainly how you would expect the look&feel to be ! If you know an UTF-8-aware block editor already available somewhere, then please tell me, of course, but I think this is uncharted land.
> 
> 
> 
> Matthias

I have implemented UTF8 in my Forths. I have a line editor that I use for the block editor. I simply limit the line buffer to 64 bytes. If I use many extended chars the visible line will be shorter and  the line editor will not advance when the buffer is full

Peter Fälth

[toc] | [prev] | [next] | [standalone]

#33817

In article <m18nf9$3fh$1@newsserver.rrzn.uni-hannover.de>,
Matthias Koch  <matthias.koch@hot.uni-hannover.de> wrote:
>After a blocks implementation is now in my testing pipeline, it is time
>to write a comfortable terminal block editor for Mecrisp-Stellaris with
>cursor movements and some "less purist" additions. This raises a
>question:
>
>Traditionally, blocks with its 1024 bytes have been printed with 16
>lines of 64 characters (or a similiar measure like 25*40 with some extra
>bytes free...) and this has been fine with fixed memory footprint
>characters. But now I am thinking on how a block editor should behave
>when entering UTF-8 encoded Unicode characters. Do the line break after
>64 visible characters and make the last line(s) shorter ? Make the line
>shorter which contains the Unicode character ? See the block as flowing
>free-format text with explicit line break characters, simply limited to
>1024 Bytes ?
>
>I am not asking on how to implement, but mainly how you would expect the
>look&feel to be ! If you know an UTF-8-aware block editor already
>available somewhere, then please tell me, of course, but I think this is
>uncharted land.

Since 2001 or so, I've used blocks of 16 lines of 64 bytes where the
last byte is an obligatory ^J. This allows a block-file to be edited
with typical powerful programmers editors.
I would require a one to one correspondance of a byte in a block to
a glyph and shun multiple byte encodings.

But of course you want to do it from within Forth:
Also in the library of lina there is a screen editor using the old
IBM (Wordstar) control chars to move the cursor around.

A screen is copied to the video screen. When you exit, what you
see within the blue cadre, is copied back into the screen.

This editor has Wordstar compatible commands.
No function key works, only control keys.

^E ^S ^D ^X <Enter> <Tab> : Cursor up left right down. Next line. Tab.
^A ^F : Cursor word left, right.
^G ^T ^Y : Delete char, word, line.
^Z ^U : Undelete word, line.
^W ^P : Undelete word and pop. Undelete line and pop.
^J ^O : Join lines, Open (split) line.

ESC Q / ESC q : quit (abandon edit and do not update.)
ESC x (or whatever, not q): exit editing, save and update.

Word and line deletes stack up at the bottom of the screen.
^P and ^W pop this stack.
In all other case the last deleted item remains
available for multiple undeletes.

Editing outside of the blue cadre allows useful tricks.

Small sequences perform useful actions:
swap lines ^Y ^E ^P.
delete line without stacking <ret> ^E ^J ^O

Word push and pop is extremely handy in Forth.

This is my ideal for a screen editor, not only that but the
few times I had a Forth running on a virgin pc I was very
happy with it.


A trick word mentioning is transporting lines from a screen
to some other:
12 EDIT 124 EDIT

The lines stacked at the bottom deleted from 12 can be
inserted in 124.

>
>Matthias

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [next] | [standalone]

#33818

Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> Do the line break after 64 visible characters and make the last line(s) shorter ?

That's not really in the spirit of Forth.  You would have to scan all
earlier lines to find a specified line.

> Make the line shorter which contains the Unicode character ?

It will have the same 64 bytes.  It will display shorter, yes.

> See the block as flowing free-format text with explicit line break characters, simply limited to 1024 Bytes ?

May be a good idea, but is relatively far from the original blocks
idea.

Just thoughts from somebody who has not used a block editor in over 20
years.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2014: http://www.euroforth.org/ef14/

[toc] | [prev] | [next] | [standalone]

#33821

On Friday, October 10, 2014 9:02:55 AM UTC-7, Anton Ertl wrote:
> Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> 
> > Do the line break after 64 visible characters and make the last line(s) shorter ?
> 
> 
> 
> That's not really in the spirit of Forth.  You would have to scan all
> 
> earlier lines to find a specified line.
> 
> 
> 
> > Make the line shorter which contains the Unicode character ?
> 
> 
> 
> It will have the same 64 bytes.  It will display shorter, yes.
> 
> 
> 
> > See the block as flowing free-format text with explicit line break characters, simply limited to 1024 Bytes ?
> 
> 
> 
> May be a good idea, but is relatively far from the original blocks
> 
> idea.
> 
> 
> 
> Just thoughts from somebody who has not used a block editor in over 20
> 
> years.
> 
> 
> 
> - anton
> 
> -- 
> 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> 
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> 
>      New standard: http://www.forth200x.org/forth200x.html
> 
>    EuroForth 2014: http://www.euroforth.org/ef14/

What is the fascination with block editors? Unless you're developing on a very limited system, I don't really see the draw.

Does anyone ever integrate mouse usage into their block editor?

-jg

[toc] | [prev] | [next] | [standalone]

#33829

On Friday, October 10, 2014 9:02:55 AM UTC-7, Anton Ertl wrote:
> Matthias Koch <matthias.koch@hot.uni-hannover.de> writes:
> > Do the line break after 64 visible characters and make the last line(s) shorter ?
> 
> That's not really in the spirit of Forth.  You would have to scan all
> earlier lines to find a specified line.
> 
> > Make the line shorter which contains the Unicode character ?
> 
> It will have the same 64 bytes.  It will display shorter, yes.

I agree with Anton on this --- just have it display shorter when the big chars are used.

I have worked as a programmer in shop where most of the programmers were Spanish-speaking and the product was for Latin America. The rule was that all source-code and all comments had to be in English (we were in America). I think that mixing languages in source-code is a bad idea. It should be all one language (not necessarily English though, depending upon where you are).

If you require source-code (especially comments!) to be in English, you aren't really going to have very many big chars in your file. Mostly these will be string constants that will be displayed for the user of the software in their language. 

Actually, I wouldn't recommend putting string constants in the source-code anyway. I would recommend instead that all string constants be put in a file and loaded into a data-structure of some kind, and they can be pulled out of the data-structure at run-time to be displayed. The reason is that, if you do this, you can have versions of that data-structure for every language that you use (English, Spanish, etc.) --- this way you can write your program once, then if you need to support a new language (Portuguese or whatever), all you have to do is hire a translator to translate one of your existing string-constant files to the new language --- you don't have to search through your source-code looking for string constants, and you don't have to worry about them being different lengths because that issue can be automated away.

Matthias: I am planning on having UTF-8 in my 64-bit Forth. I am also planning on having a screen editor. If yours is going to be public-domain, I would be interested in using it --- I haven't even started writing one of my own, and it is not a task that I'm particularly interested in.

[toc] | [prev] | [next] | [standalone]

#33830

On Friday, October 10, 2014 4:27:34 PM UTC-7, hughag...@yahoo.com wrote:
> Matthias: I am planning on having UTF-8 in my 64-bit Forth. I am also planning on having a screen editor. If yours is going to be public-domain, I would be interested in using it --- I haven't even started writing one of my own, and it is not a task that I'm particularly interested in.

BTW: Does anybody have TOUPPER and TOLOWER functions available for UTF-8?

[toc] | [prev] | [next] | [standalone]

#34380 — UTF-8 'toupper' and 'tolower' (Re: Block editor with Unicode)

En/Je/On 2014-10-10, hughaguilar96@yahoo.com escribió/skribis/wrote:
>
> BTW: Does anybody have TOUPPER and TOLOWER functions available for UTF-8?

I wrote 'xtoupper' and 'xtolower' in 2012 for a program of mine, in
Gforth. My approach was to use a configurable translation table;
characters not in the current table are ignored unless they are ASCII.

I wrote this code as a module of a library of mine, mostly
Gforth-specific.  The code depends on other modules, and also on two
modules of Forth Foundation Library.

I wrote also 'xlowercase' and 'xuppercase' for UTF-8 strings.

I want to publish the whole library soon. Currently it consists of 199
files, and first I want to homogenize some details.

-- 
Marcos Cruz
http://programandala.net

[toc] | [prev] | [next] | [standalone]

#33819

Matthias Koch <matthias.koch@hot.uni-hannover.de> wrote:
> After a blocks implementation is now in my testing pipeline, it is time to write a comfortable terminal block editor for Mecrisp-Stellaris with cursor movements and some "less purist" additions. This raises a question:
> 
> Traditionally, blocks with its 1024 bytes have been printed with 16
> lines of 64 characters (or a similiar measure like 25*40 with some
> extra bytes free...) and this has been fine with fixed memory
> footprint characters. But now I am thinking on how a block editor
> should behave when entering UTF-8 encoded Unicode characters. Do the
> line break after 64 visible characters and make the last line(s)
> shorter ? Make the line shorter which contains the Unicode character
> ? See the block as flowing free-format text with explicit line break
> characters, simply limited to 1024 Bytes ?

The only thing which makes sense IMO is to do the line breaks after 64
bytes.  The editor itself only sees bytes, and simply emits them to
the terminal, which decodes them to UTF-8.  This will require some
clever processing when repositioning the cursor, but that's all.

Andrew.

[toc] | [prev] | [next] | [standalone]

#33827

Andrew Haley wrote:
> The only thing which makes sense IMO is to do the line breaks after 64
> bytes.  The editor itself only sees bytes, and simply emits them to
> the terminal, which decodes them to UTF-8.  This will require some
> clever processing when repositioning the cursor, but that's all.

The easiest thing to position the cursor is to print everything up to the 
cursor, emit the "save cursor" escape sequence (vt100 <esc>[s or <esc>7), 
print the rest, and then emit the "restore cursor" escape sequence (vt100 
<esc>[u or <esc>8).  This doesn't work when the screen scrolls during the 
rest of the printing, but the idea behind a block editor is that it won't do 
that ;-).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#33839

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> The only thing which makes sense IMO is to do the line breaks after 64
>> bytes.  The editor itself only sees bytes, and simply emits them to
>> the terminal, which decodes them to UTF-8.  This will require some
>> clever processing when repositioning the cursor, but that's all.
> 
> The easiest thing to position the cursor is to print everything up to the 
> cursor, emit the "save cursor" escape sequence (vt100 <esc>[s or <esc>7), 
> print the rest, and then emit the "restore cursor" escape sequence (vt100 
> <esc>[u or <esc>8).

Urgh.  :-)

Andreew.

[toc] | [prev] | [next] | [standalone]

#33826

Matthias Koch wrote:
> I am not asking on how to implement, but mainly how you would expect the
> look&feel to be ! If you know an UTF-8-aware block editor already
> available somewhere, then please tell me, of course, but I think this is
> uncharted land.

bigForth's block editor can handle UTF-8, and uses 64 pchars per line (i.e. 
the lines get shorter).

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

[toc] | [prev] | [next] | [standalone]

#33907

Thank you for your ideas and pointers !

Matthias

[toc] | [prev] | [next] | [standalone]

#34056

Here comes an Unicode UTF-8 friendly "memory editor" which handles memory blocks of desired size and geometry. I decided to follow the idea to use a fixed row byte count which displays shorter if long Unicode characters show up. Some more features can be added later, like a more sophisticated return in insert mode. Just solved UTF-8 handling this time.

Albert, thank you for the description of your Wordstar-like editor commands, some of them sound interesting and may be implemented later, altough I would stick to cursor keys.

Anton, good to know that you haven't used a block editor for quite a while, so your comments are simply what you would expect, and not too influenced by traditional editors. I would love a free format editor, but I admit this is too much of a stretch for the traditional Forth block style.

Hugh, I cannot provide toupper or tolower for Unicode because there are so many characters I have no clue of. It is perfectly possible for me to write lower/upper string conversion helpers for German or French, but mine would fail on Greek or Russian afterwards. There are special cases of characters like ß that have a valid uppercase Unicode representation, but only show up as lowercase in the wild. http://en.wikipedia.org/wiki/Capital_%E1%BA%9E You simply need to know the language to write uppercase/lowercase conversion helpers for. So in Mecrisp-Stellaris I stick to have case-insensitiveness for the traditional 7-bit ASCII characters only. I know and like the idea of having an internationalisation strings file, but as my implementation runs embedded, this would be quite a bit too much.

Two notes for ANS Forthers: Mecrisp-Stellaris has variables that are initialised on Reset and this is hardwired to 32 Bits. CLZ means "count leading zeros".

Matthias


\ Memory block editor for Mecrisp-Stellaris, Copyright (C) 2014  Matthias Koch
\ This is free software under GNU General Public License v3.

( Terminal handling routines )

: u.base10 ( u -- ) base @ decimal swap 0 <# #s #> type base ! ;
: ESC[ ( -- ) 27 emit 91 emit ;
: at-xy ( column row -- ) 1+ swap 1+ swap ESC[ u.base10 ." ;" u.base10 ." H" ;
: page ESC[ ." 2J" 0 0 at-xy ;

( Editor variables and settings )

64 constant columns  ( 64x16 is most common, 40x25 is found somethimes )
16 constant rows     ( You can set something like 128x1 for line editing )

0 variable editor-buffer
char i variable mode
0 variable x
0 variable y

( Small drawing helpers )

: border ( -- )
  0 1 at-xy
  columns 2+ 0 do [char] - emit loop cr
  rows 0 do ." |" columns spaces ." |" cr loop
  columns 2+ 0 do [char] - emit loop cr ;

: mode. columns 1- 0 at-xy mode @ emit ;
: memory. 0 0 at-xy ." Memory at: " editor-buffer @ hex. ;
: header ( -- ) memory. mode. ;

( Buffer manipulation helpers )

: where ( x y -- c-addr ) editor-buffer @ swap columns * + swap + ;
: where-cursor ( -- c-addr ) x @ y @ where ; \ Find buffer location for given x,y
: eol ( -- c-addr ) columns 1- y @ where ;

( Unicode helpers )

: count-%10-addr ( addr -- u ) \ How many %10... are in this line ?
  0 columns 0 do  over i + c@ %11000000 and %10000000 = if 1+ then loop nip ;

: count-%10-to-cursor ( -- u ) \ How many %10... are there up to the cursor position ?
  0 x @ 1+ 0 do  i y @ where c@ %11000000 and %10000000 = if 1+ then loop ;

: utf8-character-length ( c -- c u )
  dup %11000000 and %11000000 = if dup 24 lshift not clz else 1 then ;

: utf8-eol? ( -- ? ) x @ where-cursor c@ utf8-character-length nip +  columns >= ;

( Line writing helpers )

: row ( addr -- addr+columns ) dup columns type dup count-%10-addr spaces columns + ;
: character-x ( -- u ) x @ count-%10-to-cursor - ;
: cursor ( -- ) character-x 1+ y @ 2 + at-xy ;
: redraw-line ( -- ) 1 y @ 2+ at-xy 0 y @ where row drop cursor ;

( Editor Movements )

: boundX ( -- ) x @ 0 max x ! ; \ Cannot simply use columns-1 as bound for UTF-8
: boundY ( -- ) y @ 0 max rows 1- min y ! ;
: bounds ( -- ) boundX boundY ;
: left   ( -- ) begin -1 x +!  where-cursor c@ %11000000 and %10000000 <> until bounds ;
: right  ( -- ) utf8-eol? not if x @ where-cursor c@ utf8-character-length nip + x ! then ;
: up     ( -- ) character-x   -1 y +! bounds 0 x !   0 ?do right loop  ;
: down   ( -- ) character-x    1 y +! bounds 0 x !   0 ?do right loop  ;
: flushleft ( -- ) 0 x ! ;

: utf8-eol  ( -- ) flushleft begin right utf8-eol? until ;
: gotoeol   ( -- ) utf8-eol begin where-cursor c@ 32 = x @ 0 <> and while left repeat
                   where-cursor c@ 32 <> if right then ;

: previousline ( -- ) y @ 0<> if up utf8-eol then ;
: nextline ( -- ) y @ rows 1- < if flushleft down then ;
: next ( -- ) utf8-eol? if redraw-line nextline else right then ;

: left-wrap  ( -- ) x @ 0 = if previousline else left then ;
: right-wrap ( -- ) utf8-eol? if nextline else right then ;

( Editor Insert/Replace Text )

: openright ( -- )
  \ If there is an Unicode continuation byte, replace the complete trailing Unicode bytes sequence with spaces.
  columns 1- y @ where
  dup c@ %11000000 and %10000000 <>
  if drop
  else
    ( addr ) \ Save this and move address backward until the %11... byte appears.
    begin 32 over c! 1- dup c@ %11000000 and %11000000 = until 32 swap c!
 then
 where-cursor dup 1+ columns 1- x @ - move ;  \ Move the rest of the line right one character

: inserting? ( -- ? ) mode @ [char] i = ;
: togglemode ( -- ) inserting? if [char] o mode ! else [char] i mode ! then mode. ;

: character ( c -- )
    \ Drop Byte sequence if this is start of an Unicode character that won't fit anymore at current position.
  utf8-character-length x @ + columns 1+ >= if utf8-character-length 1- 0 ?do key drop loop drop exit then
    \ Open a gap for the whole Unicode byte sequence
  inserting? if utf8-character-length 0 do openRight loop then
    \ Insert the character or the complete Unicode byte sequence
  utf8-character-length 0 do i 0<> if key then where-cursor i + c! loop
  next ;

( Editor Backspace/Delete )

: del ( -- ) where-cursor dup 1+ swap columns 1- x @ - move ;
: delete ( -- ) where-cursor c@ utf8-character-length nip 0 do del 32 eol c! loop ;
: backspace ( -- ) x @ 0 > if left delete then ;

( Editor Return )

: return ( -- ) y @ rows 1- <> if ( inserting? if splitline then ) nextline cursor then ;

( Editor )

: editor ( Address -- )
  editor-buffer !                   \ Save address to edit
  page header border                \ Draw outline
  rows 0 do i y ! redraw-line loop  \ Print contents of the buffer
  0 x ! 0 y ! cursor                \ Show cursor and start to edit

  begin
    key
    dup 32 >=
    if character redraw-line
    else
      case \ Handle control characters
         8 of backspace redraw-line endof
         9 of 8 0 do right loop cursor endof \ Tab
        10 of return endof
        13 of return endof
        17 of 0 rows 3 + at-xy rdrop exit endof \ Ctrl+Q: Set cursor at the end of the editor window on exit.
        27 of
             key 91 = if \ Esc [ means CSI Sequence
                        key case
                              50 of key 126 = if togglemode then endof
                              51 of key 126 = if delete redraw-line then endof
                              65 of up endof
                              66 of down endof
                              67 of right-wrap endof
                              68 of left-wrap endof

                              70 of gotoeol endof \ End
                              72 of flushleft endof \ Pos 1
                            endcase
                        cursor
                      then
           endof
      endcase
    then
  again
;

( Testing )

columns rows * buffer: input
input columns rows * 32 fill \ Fill with Spaces
: sq ( -- ) input editor ;

[toc] | [prev] | [next] | [standalone]

#34381

Hallo Matthias

> : where ( x y -- c-addr ) editor-buffer @ swap columns * + swap + ;

I think your definition can be optimized into

: where ( x y -- c-addr ) columns * + editor-buffer @ + ;

the 2 swaps are not necessary.

[toc] | [prev] | [next] | [standalone]

#34384

Hallo Stefan,

thank you ! I include this into the next release of Mecrisp-Stellaris.

Matthias

> I think your definition can be optimized into
> : where ( x y -- c-addr ) columns * + editor-buffer @ + ;
> the 2 swaps are not necessary.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web