livetext 0.7.3 → 0.7.4
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/README.ltx +48 -41
- data/dsl/pyggish.rb +1 -2
- data/dsl/tutorial.rb +34 -10
- data/lib/functions.rb +9 -0
- data/lib/livetext.rb +3 -3
- data/livetext.gemspec +4 -5
- metadata +4 -7
- data/test/testfiles/functions/expected-error.txt +0 -0
- data/test/testfiles/functions/expected-output.txt +0 -8
- data/test/testfiles/functions/source.ltx +0 -11
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: a235fb59eb7ecf6f6de1a4768e864635ce61fa6d
|
4
|
+
data.tar.gz: dfdde9d1220b0b9b2d6d610aaebccbff1127f8ad
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 93c9ed90b618afe54bf7a4c20e12cacd078673c51e2366ebc7fade962d74c5c5c4233ad6540214bd49e78cd8b6cdcf7a2155f24900d2c8c2ca6d30ae30b77c24
|
7
|
+
data.tar.gz: 3886234064afad88f2f7aa560806b60e58ff471b334715e5ad7f16f55451d5c2cd3eff7bf6f3babbb130353be34920662a03f186ac6c2319b3ba0864153fcb94
|
data/README.ltx
CHANGED
@@ -1,27 +1,27 @@
|
|
1
1
|
.mixin dsl/tutorial
|
2
2
|
.title Livetext: A smart processor for text
|
3
3
|
|
4
|
-
|
4
|
+
Livetext is simply a tool for transforming text from one format into another. The source file
|
5
5
|
has commands embedded in it, and the output is dependent on those commands.
|
6
6
|
|
7
|
-
|
7
|
+
Why is this special? It's very flexible, very extensible, and it's extensible _(in Ruby).
|
8
8
|
|
9
9
|
.section Why Livetext?
|
10
10
|
|
11
|
-
|
11
|
+
Livetext grew out of several motivations. One was a desire for a markup language that would permit
|
12
12
|
me to write articles (and even books) in my own way and on my own terms. I've done this more
|
13
13
|
than once (and I know others who have, as well).
|
14
14
|
|
15
|
-
|
15
|
+
I liked Softcover, but I found it to be very complex. I never liked Markdown much -- it is very
|
16
16
|
dumb and not extensible at all.
|
17
17
|
|
18
|
-
|
18
|
+
I wanted something that had the basic functionality of all my ad hoc solutions but allowed
|
19
19
|
extensions. Then my old solutions would be like subsets of the new format. This was a generalization
|
20
20
|
similar to the way we began several years ago to view HTML as a subset of XML.
|
21
21
|
|
22
22
|
.section What is Livetext really?
|
23
23
|
|
24
|
-
|
24
|
+
Here goes:
|
25
25
|
.list
|
26
26
|
It's a text transformer
|
27
27
|
It's Ruby-based (later on, more language agnostic)
|
@@ -40,76 +40,76 @@ It could possibly augment markdown, softcover, others
|
|
40
40
|
|
41
41
|
.section How does it work?
|
42
42
|
|
43
|
-
|
43
|
+
A Livetext file is simply a text file which may have commands interspersed. A command is
|
44
44
|
simply a period followed by a name and optional parameters (at the beginning of a line).
|
45
45
|
|
46
|
-
|
46
|
+
The period will be configurable later if you want to use another character. The names are (for now)
|
47
47
|
actual Ruby method names, so names such as `to_s and `inspect are currently not allowed.
|
48
48
|
|
49
|
-
|
49
|
+
At present, I am mostly emitting "dumb HTML" or Markdown as output. In theory, you can write
|
50
50
|
code (or use someone else's) to manipulate text in any way and output any format. Technically,
|
51
51
|
you could even emit PDF, PNG, or SVG formats.
|
52
52
|
|
53
53
|
. Idea: Make an RMagick DSL as an example.
|
54
54
|
|
55
|
-
|
55
|
+
It's possible to embed comments in the text, or even to pass them through to the output
|
56
56
|
in commented form.
|
57
57
|
|
58
|
-
|
58
|
+
The command `.end is special, marking the end of a body of text. Some commands may operate on
|
59
59
|
a block of lines rather than just a few parameters. (A text block is like a here-document.)
|
60
60
|
There is no method name corresponding to the `.end command.
|
61
61
|
|
62
|
-
|
62
|
+
The file extension I've chosen is `.ltx (though this may change). *Note: The source for this
|
63
63
|
README is a `.ltx file which uses its own little _(ad hoc) library (called `(readme.rb)). Refer to
|
64
64
|
the repo to see these.
|
65
65
|
|
66
66
|
.section Syntax, comments, and more
|
67
67
|
|
68
|
-
|
68
|
+
At first, my idea was to provide predefined commands and allow user-defined commands (to be
|
69
69
|
distinguished by a leading `. or `.. markers). So the single and double dots are both legal.
|
70
70
|
|
71
71
|
However, my concept at present is that the double dots (currently unused) will be used for
|
72
72
|
subcommmands.
|
73
73
|
|
74
|
-
|
74
|
+
User-defined commands may be added to the standard namespace marked with a period. They may
|
75
75
|
also be preceded by a specified character other than the period and thus stored in their own
|
76
76
|
namespace. More on that later.
|
77
77
|
|
78
|
-
|
78
|
+
When a leading period (or double period) is followed by a space, that line is a comment.
|
79
79
|
When it is follwed by a name, that name is typically understood to be a method name. Any
|
80
80
|
remaining text on the line is treated as a parameter list to be accessed by that method.
|
81
81
|
Some methods accept multiple lines of text, terminated by a `.end tag.
|
82
82
|
|
83
83
|
.section Boldface and italics
|
84
84
|
|
85
|
-
|
85
|
+
Very commonly we want to format short words or phrases in italics, boldface, or a monospaced
|
86
86
|
(fixed width) font. The Markdown spec provides ways to do this that are fairly intuitive; but I
|
87
87
|
personally don't like them. My own notation works a different way.
|
88
88
|
|
89
|
-
|
89
|
+
First of all, note that these don't work across source lines; they're strictly intra-line.
|
90
90
|
You may need (for example) an italicized phrase that spans across a newline; at present, you'll
|
91
91
|
need a workaround for that.
|
92
92
|
|
93
|
-
|
93
|
+
I find that most short items I want to format are single tokens. Therefore I use a prefixed
|
94
94
|
character in front of such a token: Underscore for italics, asterisk for boldface, and backtick
|
95
95
|
for "code font." The formatting ends when the first blank space is encountered, without any
|
96
96
|
kind of suffixed character. (This behavior may change to include certain punctuation marks as
|
97
97
|
terminators.)
|
98
98
|
|
99
|
-
|
99
|
+
Of course, there are cases where this won't work; a formatted string may contain spaces, or it
|
100
100
|
may exclude characters before the blank space. In this case, we can use an opening parenthesis
|
101
101
|
after the prefix and a closing parenthesis at the end of the string.
|
102
102
|
|
103
|
-
|
103
|
+
This means that it can be difficult to include a left paren inside a formatted token. I'm thinking
|
104
104
|
about that. It also means that a "literal" prefix character must be escaped.
|
105
105
|
|
106
|
-
|
106
|
+
This is all summarized in this example (taken from one of the testcases):
|
107
107
|
|
108
108
|
.testcase basic_formatting
|
109
109
|
|
110
110
|
.section Standard methods
|
111
111
|
|
112
|
-
|
112
|
+
The module `Livetext::Standard contains the set of standard or predefined methods. Their
|
113
113
|
names are essentially the same as the names of the dot-commands, with occasional exceptions.
|
114
114
|
(For example, it is impractical to use the name `def as a method name, so we use `_def instead.)
|
115
115
|
Here is the current list:
|
@@ -117,14 +117,22 @@ Here is the current list:
|
|
117
117
|
.dlist
|
118
118
|
`comment ~~ Start a comment block
|
119
119
|
`errout ~~ Write an error message to STDERR
|
120
|
-
`
|
121
|
-
`_def ~~ Define a new method inline
|
120
|
+
`def ~~ Define a new method inline
|
122
121
|
`set ~~ Assign values to variables for later interpolation
|
123
122
|
`include ~~ Include an outside text file (to be interpreted as Livetext)
|
124
123
|
`mixin ~~ Mix this file of Ruby methods into the standard namespace
|
125
124
|
`copy ~~ Copy this input file verbatim (no interpretation)
|
126
125
|
`r ~~ Pass a single line through without processing
|
127
126
|
`raw ~~ Pass this special text block (terminated with `(__EOF__)) directly into output without processing
|
127
|
+
`func ~~ Define a function to be invoked inline
|
128
|
+
`say ~~ Print a message to the screen
|
129
|
+
`banner ~~ Print a "noticeable" message to the screen
|
130
|
+
`quit ~~ End processing and exit
|
131
|
+
`nopass ~~ Don't pass lines through (just honor commands)
|
132
|
+
`include ~~ Read and process another file (typically a `.ltx file)
|
133
|
+
`debug ~~ Turn on debugging
|
134
|
+
`nopara ~~ Turn off the "blank line implies new paragraph" switch
|
135
|
+
`newpage ~~ Start a new output page
|
128
136
|
.end
|
129
137
|
|
130
138
|
.section Examples from the tests
|
@@ -133,7 +141,6 @@ Here are some tests from the suite. The file name reflects the general purpose o
|
|
133
141
|
|
134
142
|
.testcase hello_world
|
135
143
|
.testcase comments_ignored_1
|
136
|
-
.testcase sigil_can_change
|
137
144
|
.testcase block_comment
|
138
145
|
.testcase def_method
|
139
146
|
.testcase simple_vars
|
@@ -145,11 +152,11 @@ Here are some tests from the suite. The file name reflects the general purpose o
|
|
145
152
|
|
146
153
|
.section Writing custom methods
|
147
154
|
|
148
|
-
|
155
|
+
Suppose you wanted to write a method called `chapter that would simply
|
149
156
|
output a chapter number and title with certain heading tags and a
|
150
157
|
horizontal rule following. There is more than one way to do this.
|
151
158
|
|
152
|
-
|
159
|
+
The simplest way is just to define a method inline with the rest of
|
153
160
|
the text. Here's an example.
|
154
161
|
|
155
162
|
.code
|
@@ -177,7 +184,7 @@ the text. Here's an example.
|
|
177
184
|
were striking thirteen.
|
178
185
|
.end
|
179
186
|
|
180
|
-
|
187
|
+
What can we see from this example? First of all, notice that the part
|
181
188
|
between `.def and `.end (the body of the method) really is just Ruby
|
182
189
|
code. The method takes no parameters because parameter passing is
|
183
190
|
handled inside the Livetext engine and the instance variable `@_args is
|
@@ -187,15 +194,15 @@ initialized to the contents of this array. We usually refer to the
|
|
187
194
|
The `_args method is also an iterator. If a block is attached, that block
|
188
195
|
will be called for every argument.
|
189
196
|
|
190
|
-
|
197
|
+
We then create a string using these parameters and call it using the
|
191
198
|
`_puts method. This really does do a `puts call, but it applies it to
|
192
199
|
wherever the output is currently being sent (defaulting to STDOUT).
|
193
200
|
|
194
|
-
|
201
|
+
All the "helper" methods start with an underscore so as to avoid name
|
195
202
|
collisions. These are all stored in the `Livetext::Helpers module
|
196
203
|
(which also has some methods you will never use).
|
197
204
|
|
198
|
-
|
205
|
+
Here is the HTML output of the previous example:
|
199
206
|
|
200
207
|
.code
|
201
208
|
<h3>Chapter 1</h3>
|
@@ -205,7 +212,7 @@ collisions. These are all stored in the `Livetext::Helpers module
|
|
205
212
|
were striking thirteen.
|
206
213
|
.end
|
207
214
|
|
208
|
-
|
215
|
+
What are some other helper methods? Here's a list.
|
209
216
|
|
210
217
|
.dlist
|
211
218
|
`_args ~~ Returns an array of arguments for the method (or an enumerator for that array)
|
@@ -218,26 +225,26 @@ collisions. These are all stored in the `Livetext::Helpers module
|
|
218
225
|
`_passthru ~~ Feed a line directly into output after transforming and substituting
|
219
226
|
.end
|
220
227
|
|
221
|
-
|
228
|
+
Note that the last three methods are typically _not called in your own code. They could be,
|
222
229
|
but it remains to be seen whether something that advanced is useful.
|
223
230
|
|
224
231
|
.section More examples
|
225
232
|
|
226
|
-
|
233
|
+
Suppose you wanted to take a list of words, more than one per line, and alphabetize them.
|
227
234
|
Let's write a method called `alpha for that. This exercise and the next one are implemented
|
228
235
|
in the test suite.
|
229
236
|
|
230
237
|
.testcase example_alpha
|
231
238
|
|
232
|
-
|
239
|
+
I'll let that code stand on its own. Now suppose you wanted to allow columnar output. Let's
|
233
240
|
have the user specify a number of columns (from 1 to 5, defaulting to 1).
|
234
241
|
|
235
242
|
.testcase example_alpha2
|
236
243
|
|
237
|
-
|
244
|
+
What if we wanted to store the code outside the text file? There is more than one way to
|
238
245
|
do this.
|
239
246
|
|
240
|
-
|
247
|
+
Let's assume we have a file called `mylib.rb in the same directory as the file we're processing.
|
241
248
|
(Issues such as paths and security have not been addressed yet.) We'll stick the actual Ruby code
|
242
249
|
in here (and nothing else).
|
243
250
|
|
@@ -259,7 +266,7 @@ def alpha
|
|
259
266
|
end
|
260
267
|
.end
|
261
268
|
|
262
|
-
|
269
|
+
Now the `.ltx file can be written this way:
|
263
270
|
|
264
271
|
.code
|
265
272
|
.mixin mylib
|
@@ -275,9 +282,9 @@ end
|
|
275
282
|
I hope that worked a second time.
|
276
283
|
.end
|
277
284
|
|
278
|
-
|
285
|
+
The output, of course, is the same.
|
279
286
|
|
280
|
-
|
287
|
+
There is an important feature that has not yet been implemented (the
|
281
288
|
`require method). Like Ruby's `(require), it will grab Ruby code and
|
282
289
|
load it; however, unlike `(mixin), it will load it into a customized
|
283
290
|
object and associate a new sigil with it. So for example, the command
|
@@ -288,7 +295,7 @@ on that new custom object. I will implement this soon.
|
|
288
295
|
|
289
296
|
.section Issues, open questions, and to-do items
|
290
297
|
|
291
|
-
|
298
|
+
This list is not prioritized yet.
|
292
299
|
|
293
300
|
.nlist
|
294
301
|
Add versioning information
|
data/dsl/pyggish.rb
CHANGED
@@ -1,6 +1,5 @@
|
|
1
1
|
require 'pygments'
|
2
2
|
|
3
|
-
# noinspection ALL
|
4
3
|
module PygmentFix # Remove CSS for Jutoh
|
5
4
|
Styles = {
|
6
5
|
:c => "#408080-i", # Comment
|
@@ -104,7 +103,7 @@ end
|
|
104
103
|
|
105
104
|
# Was in 'bookish':
|
106
105
|
|
107
|
-
include PygmentFix
|
106
|
+
# include PygmentFix
|
108
107
|
|
109
108
|
def _process_code(text)
|
110
109
|
lines = text.split("\n")
|
data/dsl/tutorial.rb
CHANGED
@@ -1,11 +1,11 @@
|
|
1
1
|
require 'cgi'
|
2
2
|
|
3
3
|
def title
|
4
|
-
puts "<center><h2>#{_data}</h2></center>"
|
4
|
+
puts "<center><h2>#{@_data}</h2></center>"
|
5
5
|
end
|
6
6
|
|
7
7
|
def section
|
8
|
-
puts "<br>" * 2 + "<b><font size=+1>#{_data}</font></b>" + "<br>"
|
8
|
+
puts "<br>" * 2 + "<b><font size=+1>#{@_data}</font></b>" + "<br>"
|
9
9
|
end
|
10
10
|
|
11
11
|
def code
|
@@ -35,7 +35,7 @@ def dlist
|
|
35
35
|
_puts "<table>"
|
36
36
|
_body do |line|
|
37
37
|
# @tty.puts "Line = #{line}"
|
38
|
-
line =
|
38
|
+
line = _formatting(line)
|
39
39
|
# @tty.puts "Line = #{line}\n "
|
40
40
|
term, defn = line.split(delim)
|
41
41
|
_puts "<tr>"
|
@@ -45,11 +45,6 @@ def dlist
|
|
45
45
|
_puts "</table>"
|
46
46
|
end
|
47
47
|
|
48
|
-
def p
|
49
|
-
# puts "<p>"
|
50
|
-
_passthru(_data)
|
51
|
-
end
|
52
|
-
|
53
48
|
def inout
|
54
49
|
src, out = _args
|
55
50
|
t1 = ::File.readlines(src) rescue (abort "t1 = #{src}")
|
@@ -80,10 +75,39 @@ def inout
|
|
80
75
|
HTML
|
81
76
|
end
|
82
77
|
|
78
|
+
def put_table(src, exp)
|
79
|
+
t1 = ::File.readlines(src) rescue (abort "t1 = #{src}")
|
80
|
+
t2 = ::File.readlines(exp) rescue (abort "t2 = #{out}")
|
81
|
+
t1 = t1.map {|x| " " + x.sub(/ +$/,"").gsub(/_/, "\\_") }.join
|
82
|
+
t2 = t2.map {|x| " " + x.sub(/ +$/,"").gsub(/_/, "\\_") }.join
|
83
|
+
|
84
|
+
puts <<-HTML
|
85
|
+
<center>
|
86
|
+
<table width=80% cellpadding=4>
|
87
|
+
<tr>
|
88
|
+
<td width=50%><b>Input</b></td>
|
89
|
+
<td width=50%><b>Output</b></td>
|
90
|
+
</tr>
|
91
|
+
<tr>
|
92
|
+
<td width=50% bgcolor=#fec0fe valign=top>
|
93
|
+
<pre>#{t1}</pre>
|
94
|
+
</td>
|
95
|
+
<td width=50% bgcolor=lightgray valign=top>
|
96
|
+
<pre>#{t2}</pre>
|
97
|
+
</td>
|
98
|
+
</tr>
|
99
|
+
</table>
|
100
|
+
</center>
|
101
|
+
HTML
|
102
|
+
end
|
103
|
+
|
83
104
|
def testcase
|
84
105
|
name = _args.first
|
85
|
-
|
106
|
+
# _puts "\n<b>Test: <tt>#{name.gsub(/_/, "\\_")}</tt></b><br>"
|
107
|
+
_puts "\n<font size=+1><b>Test: </font><font size=+2><tt>#{name}</tt></font></b></h3><br>"
|
86
108
|
src, exp = "test/testfiles/#{name}/source.ltx", "test/testfiles/#{name}/expected-output.txt"
|
87
109
|
@_args = [src, exp] # Better way to do this??
|
88
|
-
|
110
|
+
# inout # Weird - only place I've done this yet.
|
111
|
+
put_table(src, exp)
|
112
|
+
_puts "<br>"
|
89
113
|
end
|
data/lib/functions.rb
ADDED
data/lib/livetext.rb
CHANGED
@@ -1,10 +1,10 @@
|
|
1
1
|
class Livetext
|
2
|
-
VERSION = "0.7.
|
2
|
+
VERSION = "0.7.4"
|
3
3
|
end
|
4
4
|
|
5
5
|
require 'fileutils'
|
6
6
|
|
7
|
-
$: << "
|
7
|
+
$: << "./lib"
|
8
8
|
|
9
9
|
require 'functions'
|
10
10
|
require 'userapi'
|
@@ -14,7 +14,7 @@ Plugins = File.expand_path(File.join(File.dirname(__FILE__), "../dsl"))
|
|
14
14
|
|
15
15
|
TTY = ::File.open("/dev/tty", "w")
|
16
16
|
|
17
|
-
require_relative "#{Plugins}/pyggish"
|
17
|
+
# require_relative "#{Plugins}/pyggish"
|
18
18
|
|
19
19
|
|
20
20
|
class Livetext
|
data/livetext.gemspec
CHANGED
@@ -1,5 +1,7 @@
|
|
1
1
|
require 'date'
|
2
|
-
|
2
|
+
|
3
|
+
$: << "."
|
4
|
+
require "lib/livetext"
|
3
5
|
|
4
6
|
Gem::Specification.new do |s|
|
5
7
|
system("rm -f *.gem")
|
@@ -15,6 +17,7 @@ Gem::Specification.new do |s|
|
|
15
17
|
./bin/livetext
|
16
18
|
./lib
|
17
19
|
./lib/livetext.rb
|
20
|
+
./lib/functions.rb
|
18
21
|
./dsl
|
19
22
|
./dsl/bookish.rb
|
20
23
|
./dsl/calibre.rb
|
@@ -62,10 +65,6 @@ Gem::Specification.new do |s|
|
|
62
65
|
./test/testfiles/example_alpha2/expected-output.txt
|
63
66
|
./test/testfiles/example_alpha2/source.ltx
|
64
67
|
./test/testfiles/fixit
|
65
|
-
./test/testfiles/functions
|
66
|
-
./test/testfiles/functions/expected-error.txt
|
67
|
-
./test/testfiles/functions/expected-output.txt
|
68
|
-
./test/testfiles/functions/source.ltx
|
69
68
|
./test/testfiles/hello_world
|
70
69
|
./test/testfiles/hello_world/expected-error.txt
|
71
70
|
./test/testfiles/hello_world/expected-output.txt
|
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: livetext
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 0.7.
|
4
|
+
version: 0.7.4
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Hal Fulton
|
8
8
|
autorequire:
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
|
-
date: 2017-03-
|
11
|
+
date: 2017-03-25 00:00:00.000000000 Z
|
12
12
|
dependencies: []
|
13
13
|
description: A smart text processor extensible in Ruby
|
14
14
|
email: rubyhacker@gmail.com
|
@@ -27,6 +27,7 @@ files:
|
|
27
27
|
- "./dsl/markdown.rb"
|
28
28
|
- "./dsl/pyggish.rb"
|
29
29
|
- "./dsl/tutorial.rb"
|
30
|
+
- "./lib/functions.rb"
|
30
31
|
- "./lib/livetext.rb"
|
31
32
|
- "./livetext.gemspec"
|
32
33
|
- "./notes.txt"
|
@@ -55,9 +56,6 @@ files:
|
|
55
56
|
- "./test/testfiles/example_alpha2/expected-output.txt"
|
56
57
|
- "./test/testfiles/example_alpha2/source.ltx"
|
57
58
|
- "./test/testfiles/fixit"
|
58
|
-
- "./test/testfiles/functions/expected-error.txt"
|
59
|
-
- "./test/testfiles/functions/expected-output.txt"
|
60
|
-
- "./test/testfiles/functions/source.ltx"
|
61
59
|
- "./test/testfiles/hello_world/expected-error.txt"
|
62
60
|
- "./test/testfiles/hello_world/expected-output.txt"
|
63
61
|
- "./test/testfiles/hello_world/source.ltx"
|
@@ -102,9 +100,8 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
102
100
|
version: '0'
|
103
101
|
requirements: []
|
104
102
|
rubyforge_project:
|
105
|
-
rubygems_version: 2.
|
103
|
+
rubygems_version: 2.2.2
|
106
104
|
signing_key:
|
107
105
|
specification_version: 4
|
108
106
|
summary: A smart processor for text
|
109
107
|
test_files: []
|
110
|
-
has_rdoc:
|
File without changes
|