#22

Managed to refactor the keypress handling…

It doesn’t actually do anything different yet. But given that is +553 lines, -449 lines of code, I feel the need to tell people about it.

Next up tweak the way we deal with key codes and mod masks.

Then move out the implementation of each event to it’s own function, e.g. updating a pattern, the line editor.

Then maybe actually work on some features! I’m hoping to add some extra keybindings to the line editor too… e.g. C-a, C-e, C-b, C-f, C-h, C-d, C-w, M-b and M-f.

3 Likes
#23

not really related to the keypress handling, but the overall overhaul for 2.0

as part of 2.0, a consolidated ops + keyboard shortcut list with some light explanation on expanded/revised features would be really helpful. The documentation of the sweet incremental work through the v1 versions feels scattered (at least in the web, not sure about F1) through update posts and additional features to the main TT page, and might benefit from some tidying up in a rounded out 2.0 version

I’d happily volunteer to create a revised/expanded v2 .pdf w/ all the revisions, aliases, new ops and updated ii commands and some kind of web documentation if people would find that helpful

7 Likes
#24

Nice! I agree that it should be consolidated.

As a heads up, I’m posting two PDFs and a LaTeX version of Teletype Studies sometime later today. I really wanted a printable copy of those on hand.

6 Likes
#25

will take a look this weekend. confused about this part:

do you mean CTRL+… and MOD+…? what would they do?

1 Like
#26

Sorting the ops documentation out is on the list at the top, but I’m afraid I haven’t worked out the particulars yet. I know I want it to have some aspect of autogeneration.

Help is definitely welcome though. What’s your background? How do you feel about things like git, Markdown and LaTeX?

#27

They are ‘Emacs’ key bindings, and they’re very common on Unix (in bash for example). On OSX they work in every text box, though I’m not sure how many OSX users know they exist.

The C is control, the M is meta (more commonly known as alt).

  • C-a go to beginning of line
  • C-e go to end of line
  • C-b go back one character
  • C-f go forward one character
  • C-h backwards delete (not an Emacs binding, but it relates to how ASCII mod masks work…)
  • C-d forward delete
  • C-w delete a word
  • M-b back a word
  • M-f forward a word

(The last 2 don’t work on OSX)

6 Likes
#28

I would love to see this… .might mean less editing on laptop for complex scripts.

2 Likes
#29

:smiley: (though I’m a Vim guy really, but writing a modal text editor for the Teletype goes a bit above and beyond)

Actually there are 2 more too

  • C-p previous line / previous history
  • C-n next line / next history
#30

and maybe we could support multiple mappings too (unless they clash) - sorry, windows person here, so would love to use Ctrl-C/V instead of Alt-C/V, Ctrl-arrows to move between words etc etc

1 Like
#31

much more of a design background over here, but i do really enjoy organizing things :wink:

i’d be interested in trying to learn anything i can to help out, but I’m currently only familiar w/ git in a downloading files capacity, so it’ll be a bit of a learning curve

1 Like
#32

I’d like to add those too, I don’t like the Alt-C/V either.

The plan is to make it much easier to tweak, ideally all the code to do with the line editor will be in line_editor.c file, so it should be a lot easier to grok.

@tambouri Once I’ve got a plan I’ll come back to you and we can see what you’d like to help out with. Don’t worry about the git stuff, either I’ll do it, or if you’ve always wanted to learn than I’m sure myself and others here can help too.

3 Likes
#33

Let me know, i’d certainly be into giving it a try. And if you do wind up doing it, I’d be happy to collect it all into some kind of a printable document like a companion cheat sheet like the 1-page that came along w/ the v1 software but probably more than 1 page, because TT has gained some serious legs in the days since v1.0

3 Likes
#34

At least in my OSX Term, M-Left and M-Right move back and forward a word. But yes, as you say, Emacs bindings otherwise.

1 Like
#35

Had a weird crash with the first .hex that you posted… I was typing a command in the M script that was too long for the screen. When I reached the line limit, the screen just turned off and the unit froze. I tried doing it again. The second time around, the TT just froze when it reached the limit (instead of the screen turning off).

1 Like
#36

Yeah, there are some memory overflows with the line editor, particularly when inserting characters. You bug seems slightly different to the ones I’ve seen before.

It should get fixed when I rewrite the line editing code.

#37

hello! New here after picking up a teletype last week. Just beginning to dig in and loving it!! I immediately updated to v1.4.0 to gain access to the ER mode and ran in to a similar bug @trickyflemming described. Went to edit a line, went 1 character over the limit and it froze after pressing enter. Black screen the first time. Reproducible thereafter although the black screen only occurred the once. Worth opening a github issue for?

1 Like
#38

Welcome @courdek, thanks for the feedback. I believe there is a bug already…

You can update it if you want, but I’m planning on rewriting most of the code involved. I’ll try and prioritise this, but probably won’t have time till the weekend now.

1 Like
#39

Hi @sam!

How does this work factor in to the discussions about line length - either squeezing a little more space in per line, allowing lines to go beyond the screen-based limits or creating a line continuation character? Was there ever a firm decision to address this? And, if so, in what way? And, also if so, is that something that you are looking at as well?

Thx!!!

1 Like
#40

I should be able to get rid of the leading space when using : and ;, but it’s not much space saved.

If we want to go further than that it get’s a little bit more complex. There are 2 limiting factors governing line length, number of ops (12) and length of string (31?). If either are too long then it triggers an error.

The string is not saved as part of a scene, it’s reconstructed each time. So increasing the size of the string doesn’t have long term consequences, but it will require modifying the line editor to scroll horizontally.

Increasing the number of ops however will lead to an increase the size of a scene when saved, and thus has ramifications.

From your point of view, i.e. w.r.t to TXi and TXo ops, it’s the string size limit we run up against. The easiest solution would be to come up with some very short aliases (e.g. TO.P for TO.TR.PULSE). The horizontally scrolling line editor will be a bit tricker, and I’m not sure I’ll be able to do that now, but hopefully the changes I’m making will make a lot easier to do when/if we do.

1 Like
#41

I go back on forth on my point of view. :slight_smile:

One of the great things about an open-ended system like the TT is the limitations that it imposes (line length; lines per script; etc.). I am loathe to think of things “falling off the screen” and the odd UI things required to make it usable (like scrolling). That stuff just doesn’t feel right - even though I find myself wanting it from time to time.

I love the idea of the aliases as well; especially for the math operators. (I’m still giddy over this.) I’m less excited about making commands more cryptic - but I can certainly see the value in grabbing a few extra characters when needed. And, their use isn’t mandatory. :slight_smile:

Thx for the reply - and all of the hard work on the TT. :slight_smile: !

3 Likes