Highlighting a portion of code and/or text?

[Michael Zlatkovsky]

I am just getting started with LeanPub, having previously authored my book in a Word document.  One of the things I had there was that, in several places, in addition to the "usual" code syntax highlighting, I wanted to highlight a particular word or pattern that I am describing. See the attached images (#1, #2).

Is there any way I can achieve such effect on Leanpub?

In a similar vein, any way to achieve highlighting of a particular word within the text (for much the same effect -- to tie together a portion of a particular code sample with a particular portion of the description.

Thanks!

- Michael

[Mike Rowe]

Hi Michael,

Unfortunately at the moment we don't have support for this. The closest we come to it is the ability to mark lines as deleted using leanpub-start/end-delete/insert. Sorry for not being able to give you a better answer here.

Regards,

Mike

--
You received this message because you are subscribed to the Google Groups "leanpub" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leanpub+unsubscribe@googlegroups.com.
To post to this group, send email to lea...@googlegroups.com.
Visit this group at https://groups.google.com/group/leanpub.
To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/3a2bf193-2598-4c69-8630-873c8a60ec64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Zlatkovsky]

Is this something you envision you'll be adding in the future?  Or a "by design" / "by-cross-host-limitations" sort of limitation?  (FWIW, I think the general ability to set font colors and backgrounds, in both paragraphs and code, could be really useful).

Thanks!

On Sunday, October 23, 2016 at 9:22:07 PM UTC-7, Mike Rowe wrote:

Hi Michael,

Unfortunately at the moment we don't have support for this. The closest we come to it is the ability to mark lines as deleted using leanpub-start/end-delete/insert. Sorry for not being able to give you a better answer here.

Regards,

Mike

On Sun, Oct 23, 2016 at 12:47 PM, Michael Zlatkovsky <michae...@gmail.com> wrote:

I am just getting started with LeanPub, having previously authored my book in a Word document.  One of the things I had there was that, in several places, in addition to the "usual" code syntax highlighting, I wanted to highlight a particular word or pattern that I am describing. See the attached images (#1, #2).

Is there any way I can achieve such effect on Leanpub?

In a similar vein, any way to achieve highlighting of a particular word within the text (for much the same effect -- to tie together a portion of a particular code sample with a particular portion of the description.

Thanks!

- Michael

--
You received this message because you are subscribed to the Google Groups "leanpub" group.

To unsubscribe from this group and stop receiving emails from it, send an email to leanpub+u...@googlegroups.com.

[Peter Armstrong]

By design.

Markua represents the future evolution of Leanpub Flavoured Markdown,
and it uses the same type of approach:

https://leanpub.com/markua/read#leanpub-auto-marking-code-as-added-or-deleted

(Leanpub will support both syntaxes of course.)

Thanks
Peter

P.S. Yes, we are still working on Markua. The React storefront ships
this week, then more progress on Markua will be coming soon. Scott has
one other thing he's doing in Q4 along with Markua, and I'll talk more
about that soon enough. We actually shipped a couple features
recently, including complex table support. However, we haven't
documented what is and is not supported yet, so I just kept quiet on
that since we're all aware that the schedule has slipped on Markua.
Expect full Markua support launching sometime in Q1 2017, with notable
releases starting again in late November and December :)

On Sun, Oct 23, 2016 at 9:42 PM, Michael Zlatkovsky

> https://groups.google.com/d/msgid/leanpub/1505a4f3-ce8a-4fa1-ba01-9e854c28ed4d%40googlegroups.com.

[Michael Zlatkovsky]

Got it.  Thanks, Peter.

Just to clarify, for the lack of highlighting ability being "by design", are you referring to custom text highlighting and/or colors in the code blocks, or also in regular paragraphs down the road?  (I.e., I can imagine wanting to make a chapter title or text gray-ish, for example, to show that it is incomplete, etc.)

Thanks!

- Michael

[Peter Armstrong]

The "by design" part refers to how full code samples are handled, not
code snippets pasted in book text. Those can be made bold or italic
easily like this: **`some code`** or *`some code`*.

Here's why:

We want book code to compile. When I wrote programming books I always
ensured my code compiled*.

Authors are encouraged to use external code samples, using a nice
happy syntax to embed them. These code samples can be the full file,
so we provide support for subsetting files to only show the part
intended.

If an author is going to highlight code, we'd prefer the code
highlighting be done *in the executable code* not in some snippet
which got pasted into the manuscript. That's always error-prone to
keep current, in a "let's build a cumulative example book" especially.
(Those are the types of books I wrote, so I was definitely scratching
my own itch here.)

Because of the above, we need to ensure our annotations for start and
stop highlighting can live in comments, regardless of programming
language. Not all languages support within-line comments, but
essentially all modern languages support comments which can occupy a
single line of source code. So, making a comment which affects our
book generator, but which itself is not output in the book, is simple
to do when the directive takes the full line.

Thanks,
Peter

*except for that one super fun time when Adobe changed the namespaces
on Flex 4 after months in beta, thus breaking my book which had just
been **printed**. Hooray for ebooks.



On Sun, Oct 23, 2016 at 11:23 PM, Michael Zlatkovsky

> https://groups.google.com/d/msgid/leanpub/ea33c162-08f3-44b7-8977-ae2195331e1f%40googlegroups.com.

[Iakiv Kramarenko]

Hi Peter,

I would like to raise the topic again. As I understood, it's not possible by design to highlight the code because any code from a local code resource should be executable. So the only way would be to use comments with markua directives to highlight it. This seems logical, seems to make sense.

Yet, for me as an author, the following thing also makes sense:

- I would like to be able to use some publishing platform, that allows me to be creative, not just use the "commonly known ways" to write, but invent something new, be motivated by that, that I am not limited, and can find the way to express my thoughts in a book in a new way... find a format to explain things that I believe is good... 

Right now I am writing the book about programming and software developers for complete beginners. I am trying to find more simple way to explain things. I use color highlighting of the text and corresponding code to make it easier for newcomers to "feel" the code and "understand it". Please, look into attached screenshot to understand what I mean. 

So my questions are:

1 can I achieve this with leanpub and markua? now or in future?

2 if no, what workaround would you recommend to reflect the same "connections between text and code" (see screenshot)?

3 If it will be never possible to do a custom code highlighting, what about common text in paragraphs? It seems pretty natural to write a modern online book with highlighted text in different colors, doesn't it?

Maybe it's impossible to "tune" text in context of colors with current markua spec... But shouldn't we think on some way to achieve this in future? to give more freedom to authors?

Iakiv

понеділок, 24 жовтня 2016 р. 20:06:44 UTC+3 користувач Peter Armstrong написав:

[Peter Armstrong]

Hi Iakiv,

From looking at your above example, I'd just write the code straight in the Markua document in backticks:

Some text

```

some code

```

more text

```

more code

```

more text

If I wanted to test the code locally, I'd do some fancy things with scripts and annotations to strip out the code samples, put them in files, and run them.

Chances are you will be happier this way than using the external code sample approach...

Thanks,
Peter

P.S. Sorry about the delay in replying; your message got held up in moderation.  I've approved all future messages from you.

To unsubscribe from this group and stop receiving emails from it, send an email to leanpub+unsubscribe@googlegroups.com.

To post to this group, send email to lea...@googlegroups.com.
Visit this group at https://groups.google.com/group/leanpub.

To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/f0bc7e55-43bc-46f2-8cd0-cf975bf63661%40googlegroups.com.

[Iakiv Kramarenko]

Hi Peter, 

Seems like I explained myself wrong...

I use inline code figures. 

I am writing a book about "programming for complete beginners". What I want is to visually explain some code by using a "translation" analogy. 

For example, this code:

let addTodoOnEnter = function() {...}

I explain with the phrase:

"let there be a sub-program 'add todo on enter' that ..."

As you can see, I use colors to visually connect "corresponding" parts. I started to write my book as gitbook. There I could use html to implement code and text color highlighting. But now I have decided to switch to leanpub. And now I am looking for some option to highlight text and code in leanpub book... Question is: how can I achieve this? If not, what workaround would you recommend? Will the leanpub team put some efforts to allow such things in future? I don't know... maybe allow to create custom directives, which could enable such custom formatting, if it is not available by default... 

One workaround that I have in mind, is to use common text style instead of colors for text and "monospaced" poetry instead of inline code figure. 
For example, the following formatting:

"let **there be** *a sub-program* 'add todo on enter' ____that____ ..."

---

let addTodoOnEnter **=** function() ____{____ ... ____}____

---

will give me:

"let there be a sub-program 'add todo on enter' that ..."

let addTodoOnEnter = function() { ... }

This I believe will not work... It is much harder to understand than colors highlighting... That's why it would be so useful for me to have this feature in leanpub formatting... 

There is one more workaround... Explain the same in 4 times, not one. Using only bold for highlighting "analogy"/"translastion":

"let there be a sub-program 'add todo on enter' that ..."

let addTodoOnEnter = function() { ... }

"let there be a sub-program 'add todo on enter' that ..."

let addTodoOnEnter = function() { ... }

"let there be a sub-program 'add todo on enter' that ..."

let addTodoOnEnter = function() { ... }

And probably I even can use inline code with "new/insertion" directives, not poetry. But this style even seems to be boring for the reader... 

I saw in markua specification that I can add class attributes to spans/figures. Maybe I can then do something like:

"let [there be]{class: "red"} [a sub-program](class: "orange"} 'add todo on enter' [that]{class: "blue"} ..."

---

let addTodoOnEnter [=]{class: "red"} [function()]{class: "orange"} [{]{class: "blue"} ... [}]{class: "blue"}

---

And configure custom css for the corresponding classes. Is it possible? Or will it be possible in future?

If there would be also a shortcut for {class: "red"} like {.red} would be even more convenient... 

Sorry for a long read... I Hope I explained it better this time.

Looking forward for your answer,
Iakiv

середа, 11 липня 2018 р. 00:05:33 UTC+3 користувач Peter Armstrong написав:

[Peter Armstrong]

Ah, now I get it.  And yeah, I completely misread you before.

(By the way, I'm in your exact position: I've written a book called Programming for Kids, and I'm rewriting it from scratch as I make a Leanpub course to test & showcase our courses feature.  So, if anyone wants features for complete beginner readers, it's me!)

So, now for the bad news:

The custom attributes on span elements stuff, e.g. blah blah [stuff]{class: "red"} blah blah, does not work yet.

I'm not exactly sure what I'd do here.  Here are some examples, with a screenshot.

====

This is **some bold** and *some italic* text.

This is **`some bold`** and *`some italic`* code spans.

`this is code but you don't put formatting in here sorry`

`this is` **`bold`** `and` *`italic`* `code`

====

So, you can do a mess where you mix an match code spans, code spans that are bolded, and code spans which are italic, but it kind of looks like https://magneticpoetry.com/

I'd be tempted to just write the code as 1-3 line chunks and write words which explain it.  This is what I find myself doing in my Programming for Kids course all the time:

====

Let's learn a bit more math.

Have irb do `3-2`. The minus key, `-`, is beside the 0.

```

irb> 3-2

=> 1

```

To do multiplication, you use `*` (`shift` + `8`) not `x`.

```

irb> 3*2

=> 6

```

To do division, you use `/` (which is beside the right `shift` key). Try `6/2`.

```

irb> 6/2

=> 3

```

====

Again, I'm not so sure about what the right thing to do is though, since I'm right in the middle of a "my book and course are total garbage and I need to rewrite everything" table flip.  (Sometimes those produce good results, but sometimes they don't!)

Thanks,

Peter

To unsubscribe from this group and stop receiving emails from it, send an email to leanpub+unsubscribe@googlegroups.com.

To post to this group, send email to lea...@googlegroups.com.
Visit this group at https://groups.google.com/group/leanpub.

To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/8a8a8c50-a45e-4e4a-ac49-27ebc8c81814%40googlegroups.com.

[Iakiv Kramarenko]

Hi Peter, 

I tried to use this style:

`this is` **`bold`** `and` *`italic`* `code`

But it does not work in case of more than one line of such "formatted code". 
For example, this formatting: 

**`[id="new-todo"]`**` {`

`  width: 100%;`

`}` 

will result in

[id="new-todo"] { 

‘ width: 100%; }‘ 

Is it a bug, or by design?

Thanks,
Iakiv

середа, 11 липня 2018 р. 02:37:54 UTC+3 користувач Peter Armstrong написав:

[Iakiv Kramarenko]

Hi Peter, 

The question above is still relevant. Just I would like to share with you a bit weird workaround I have found:

the following formatting:

As we can see, the translation is quite clear:

> **The element with id="new-todo"** ...

|**`[id = "new-todo"]`**` {`

|`  width: 100%;`

|`}`

> ... **____must have____** ...

|`[id = "new-todo"] `**____`{`____**

|`  width: 100%;`

|**____`}`____**

> ... **the width of 100% of available space**

|`[id = "new-todo"] {`

|`  `**`width: 100%;`**

|`}`

 

will result in the following pdf:

The drawback is that the font is a bit smaller, and when I want to do a copy&paste, the pasted code will look like:

[id = "new-todo"] { width: 100%;

}

Regards,
Iakiv 

четвер, 12 липня 2018 р. 09:51:18 UTC+3 користувач Iakiv Kramarenko написав:

[Peter Armstrong]

Hi Iakiv,

I must commend your ingenuity here :)

However, yeah, I think the answer is to just do stuff like this:

===

Blah

```

def foo

  puts "hi"

end

```

Blah blah **`puts`** means to blah blah

===

This produces a similar effect of "you can point at the code you are explaining" with a lot less formatting.  It means you have to write more words, but that's more friendly anyway.

Thanks

Peter

To unsubscribe from this group and stop receiving emails from it, send an email to leanpub+unsubscribe@googlegroups.com.

To post to this group, send email to lea...@googlegroups.com.
Visit this group at https://groups.google.com/group/leanpub.

To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/15ed9ad2-d39b-4efb-b2b2-c7dd3fd2f563%40googlegroups.com.

[Iakiv Kramarenko]

Hi Peter, 

I am not sure it's more friendly. 

It's like "show a screenshot with completely new UI to the user and tell user to click on a tiny button among other ones" vs "show a screenshot with highlighted button and tell to click on it...". I believe that the last "highlighting" option is more friendly. 

Speaking about "more words", I would say that there are two types of people - ones like more words, and others do not. They like more concise representation, that can be read faster. I write my book for the readers of the last group. 

Unfortunately, right now even that workaround with `|` symbol did not work for me. Because it show two spaces as one (you can notice that on the provided screenshot). 

As I understood from the Markua specification, the inline poetry will support formatting text. And there is an option of poetry with monospaced=true. This can give me a better workaround, without colors, but at least with "bold/underscored/italic" formatting. 

So I can format like: 

---

**[id = "new-todo"]** {

  width: 100%;

}

---

And get:

[id = "new-todo"] {

  width: 100%;

}

Question1: Did I understood correctly how poetry formatted with hyphens will work in markua?

Question2: If yes, Do you have some estimate/feeling when this will be supported in the leanpub markua specification?

Sorry for bothering and taking your time, but as a customer of a platform which stated itself as a platform for authors ("leanpub puts authors first", "leanpub is the best way to write books", etc.), I would like to find a way to keep being creative in writing my books. 

Right now, I have to put on pause writing in leanpub, and use leanpub only as a platform of selling my books written in the gitbook platform. Waiting for the "inline poetry with formatting" markua support.

Thanks,
Iakiv

четвер, 12 липня 2018 р. 22:59:01 UTC+3 користувач Peter Armstrong написав:

[Peter Armstrong]

Hi Iakiv,

You're right that once poetry resources (https://leanpub.com/markua/read#poetry) are fully supported you could use a poetry resource + monospaced="true" to get bold and italic formatting in a monospaced code block.  Markua formatting will work in poetry:

"Note that inside a poetry resource, Markua text formatting still applies. You can’t do arbitrary Markua stuff like headings, images and tables, but you can do the text formatting like bold, italic, strikethrough, etc. So, if you want to write poetry involving asterisks and underscores, use a code block."

Once this actually works in Leanpub, we'll update https://leanpub.com/markua/read#leanpub-authors and we'll let you know as well.  

Note that your idea to use a monospaced poetry block to format code using Markua formatting is something I had not thought of.  Arguably it's more important to our current authors than, well, actual poetry.  So this raises the priority somewhat. 

At the moment we're doing performance work on courses and other high-priority stuff, so this won't be right away.  However, it may get done in the next few months.

Thanks

Peter

To unsubscribe from this group and stop receiving emails from it, send an email to leanpub+unsubscribe@googlegroups.com.

To post to this group, send email to lea...@googlegroups.com.
Visit this group at https://groups.google.com/group/leanpub.

To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/3e19180f-c086-4652-a8de-e05d22556b7f%40googlegroups.com.

[Iakiv Kramarenko]

Great! thank you, Peter! I will wait:)

пт, 13 лип. 2018 о 00:12 Peter Armstrong <pe...@ruboss.com> пише:

To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/3e19180f-c086-4652-a8de-e05d22556b7f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "leanpub" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leanpub+u...@googlegroups.com.
To post to this group, send email to lea...@googlegroups.com.
Visit this group at https://groups.google.com/group/leanpub.

To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/CAF5JboGLUdrh3C7ZF%2BCTi1q2e0Q3mYhOC0LDZRY9GvOpfYVt6A%40mail.gmail.com.

[Iakiv Kramarenko]

Finally) I had to switch to gitbook based ebook generation:) And use the "upload my book" option of leanpub. I extended the gitbook functionality with ability to understand markua poetry. Maybe a bit later, when I have time, I can publish my plugin to gitbook, if someonen would be interested in. 

So far, here is what I ended with: https://leanpub.com/intro-to-software-development 

[Iakiv Kramarenko]

Hi Peter,

You wrote last year:

> Note that your idea to use a monospaced poetry block to format code using Markua formatting is something I had not thought of.  Arguably it's more important to our current authors than, well, actual poetry.  So this raises the priority somewhat. 
> At the moment we're doing performance work on courses and other high-priority stuff, so this won't be right away.  However, it may get done in the next few months.

Any updates on progress? :)

Thank you,
iakiv

вт, 7 серп. 2018 о 21:43 Iakiv Kramarenko <yas...@gmail.com> пише:

Finally) I had to switch to gitbook based ebook generation:) And use the "upload my book" option of leanpub. I extended the gitbook functionality with ability to understand markua poetry. Maybe a bit later, when I have time, I can publish my plugin to gitbook, if someonen would be interested in. 

So far, here is what I ended with: https://leanpub.com/intro-to-software-development 

--
You received this message because you are subscribed to the Google Groups "leanpub" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leanpub+u...@googlegroups.com.
To post to this group, send email to lea...@googlegroups.com.
Visit this group at https://groups.google.com/group/leanpub.

To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/1ced9051-ee17-4f27-9ed0-a2cf2fe31631%40googlegroups.com.

[Peter Armstrong]

Markua progress is slow and steady. We actually do expect Markua
support to be fully implemented by end of 2019. In the past few
months, we have managed to spend a meaningful amount of time on it
during most months.

For the most current "what's still not built" list, see
https://leanpub.com/markua/read#leanpub-authors

Thanks :)
Peter

> To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/CAKCSiho-zNZtOG_dOi6_V2%3DHecCDmKyJAh8CM%3Djd6jgozdXiyA%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

--
Peter Armstrong
Co-founder & CEO, Ruboss

[Peter Armstrong]

P.S. In terms of Markua progress, as the implementation of various
sections is being done, I'm making small spec updates to clarify
wording or make improvements based on feedback. So, the progress of
our implementation can be sort of seen by looking at the spec commits
at https://github.com/markuadoc/markua/commits/master and seeing the
list of todos at https://leanpub.com/markua/read#leanpub-authors
shrink. Believe me, I want this done, and we are finally in the
position to get it done. As a bootstrapped startup, we can't just
work on Markua only, we also need to do things which boost revenue.
But we've now got revenue to a good place, so we can now devote more
engineering time to Markua. So this is why I can say that I do
actually expect it to be done this year...

P.P.S. Speaking of being a bootstrapped startup and revenue etc, we
now have lifetime Pro plans which are included with 3- and 6-month
shelf spots. See https://leanpub.com/shelf/buy for details :)

[Iakiv Kramarenko]

Hi Peter, 

Thank you a lot for all the work you do for authors! Looking forward to Markua finally done, that would be awesome!

Thank you for the hint with history of github commits! This helps. And it was very useful to get to know about shelfs, thank you!

iakiv

нд, 20 січ. 2019 о 23:06 Peter Armstrong <pe...@ruboss.com> пише:

To view this discussion on the web visit https://groups.google.com/d/msgid/leanpub/CAF5JboHdQW7oewmDQ1VhUO_-JzSpe9wqhroNadeDTdkO5OVyyg%40mail.gmail.com.