Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Superscript/Subscript markup #1337

Closed
Tracked by #1541
vkbo opened this issue Feb 3, 2023 · 18 comments · Fixed by #1540
Closed
Tracked by #1541

Superscript/Subscript markup #1337

vkbo opened this issue Feb 3, 2023 · 18 comments · Fixed by #1540
Assignees
Labels
editor Component: Editor enhancement Request: New feature or improvement next release Note: Features planned for next release

Comments

@vkbo
Copy link
Owner

vkbo commented Feb 3, 2023

I don't mean to allow for feature creep but have those two formattings been considered for inclusion? Subscript and superscript text are not exactly uncommon, although there's the possibility of being creative with unicode for most use cases. But that kind of resourcefulness kind of eludes less technical users.

Originally posted by @tmarplatt in #1330

@vkbo
Copy link
Owner Author

vkbo commented Feb 3, 2023

I've looked at the extended markdown listed on markdownguide.org, and perhaps those are good solutions. I've added the strikethrough from there, and highlight too is a candidate.

The mentioned syntax for superscript is H~2~O for "H2O" and X^2^ for "X2". I believe that is simple and clear enough to not clutter the editor too much.

The proposed syntax for footnotes is also the one I plan to implement with a slight modification.

@vkbo vkbo self-assigned this Feb 3, 2023
@vkbo vkbo added enhancement Request: New feature or improvement editor Component: Editor labels Feb 3, 2023
@vkbo vkbo added this to the Release 2.2 Beta 1 milestone Feb 3, 2023
@johnblommers
Copy link

This is a welcomedevelopment. Even fiction writers sometimes need to use superscripts and subscripts.

@vkbo
Copy link
Owner Author

vkbo commented Feb 3, 2023

Absolutely. I occasionally find my self needing it. Luckily, I can manage most of the cases with unicode as it is usually superscript of numbers.

@vkbo vkbo added the next release Note: Features planned for next release label Oct 17, 2023
@vkbo
Copy link
Owner Author

vkbo commented Oct 19, 2023

So, I'm playing around with this. I want to add a syntax that can be used for text inline blocks of various kinds, so I'm trying out a syntax. I don't want to add a lot of weird looking ^ and ~ that non-programmers never type, so I decided to try the following

October 19{up:th}, 2023

Which renders as "October 19th, 2023"

This is pretty easy to both add a syntax highlighter regex to, and process during export. The neat thing about this syntax is that I can also use it to add formatting for bold and italic for special cases where the regular syntax doesn't work. There have been a few requests for that where someone want to only bold a part of a word.

Allowing something like this:

{b:Oct}ober 19{up:th}, 2023

Here, it would render as "October 19th, 2023", which works on GitHub, but not in novelWriter.

@vkbo
Copy link
Owner Author

vkbo commented Oct 19, 2023

Here it is in the editor:

image

The rendered version in the viewer looks like:

image

This was referenced Oct 19, 2023
@vkbo
Copy link
Owner Author

vkbo commented Oct 19, 2023

Also tagging @tmarplatt here since the feature came from another issue, and I'm not sure you're being notified.

I'd like some feedback on this before I go ahead and add a new notation we'll be stuck with! 😃

@HeyMyian
Copy link
Contributor

Thanks for implementing partial formatting. I'm not on board with arguing against ^ and ~ because non-programmers wouldn't type those symbols. The generic computer user can't handle anything other than WYSIWYG anyway. If they use novelWriter, they will already understand "weird symbols make formatting". Something like {up:script} will intimidate them as well, if not more - I think.

But it's fine by me. If the partial formatting can't be done in another way anyway, then I'm just happy for the new feature we're getting 🙂

@HeyMyian
Copy link
Contributor

Can you consider adding aliases for the (what do you call them?) commands? I'm thinking sup and sub are more intuitive, at least those are the tags in HTML.

@vkbo
Copy link
Owner Author

vkbo commented Oct 19, 2023

The problem is that super^script^ and sub~script~ are really hard to implement using regex. So is the partial emphasis. I need the processing of syntax to be really fast as each paragraph is processed by it every single time you press a key, including spell checking every word in it.

The beauty of the {xx:text} syntax is that all flavours of it can be processed by a single regex, and I only need individual regexes when running builds, when the processing time is less critical.

Yes, I can make them sub and sup instead. I just wanted to keep them short. Ideally I want a single character, but couldn't come up with suitable ones. This is all open for suggestions at the moment.

Keep in mind I want to use this notation for footnotes and endnotes as well, so it needs to consistent.

I've also considered the following notation [xx:text] instead. The benefit is that it matches the [NEWPAGE] and [VSPACE:2] and those codes.

@tmarplatt
Copy link
Contributor

tmarplatt commented Oct 19, 2023

In ANSI keyboard layouts at least, square brackets are easier to type. (Then again, in Spanish layouts it's the other way around hehe.) I would advise against curly brackets if only for breaking consistency like you mentioned.

And definitely favour clarity over brevity: sup/sub instead of the more vague up/dn. The abbreviations should be more familiar to non-programming minds coming from other word processor software.

Also it would perhaps help to know what your plans for (foot|end)notes syntax are.

@vkbo
Copy link
Owner Author

vkbo commented Oct 19, 2023

If we're opting for descriptive, I could make them:

Foo bar {footnote:This text is in my footnote.}.

I could easily support fn: as an alternative to footnote:

Alternatively, the footnote "text" could point to a reference where the footnote is defined. The latter would make it possible to have multi-paragraph footnotes.

The benefit with having the : in there, by the way (aside from consistency) is that it's possible to use **bold** and _italics_ notation in the text as : registers as a boundary.

@vkbo
Copy link
Owner Author

vkbo commented Oct 19, 2023

Ok, here's my proposed solution now. With syntax highlighting, and when I add Insert menu entries and formatting keyboard shortcuts for them, they should be simple enough to use. Here's a screenshot of the example document with the updates:

image

@vkbo vkbo linked a pull request Oct 19, 2023 that will close this issue
6 tasks
@tmarplatt
Copy link
Contributor

I could easily support fn: as an alternative to footnote:

Definitely not, especially if you're also adding syntax for endnotes (en:?). But all of that should be better discussed in its own ticket.

@vkbo
Copy link
Owner Author

vkbo commented Oct 20, 2023

I think an alternative short form can be useful if you use them a lot. It will be optional anyway.

Yes, the implementation details belong in #342, but the in-line command syntax should be the same for all these features, and this is where I'm implementing it. I think the [xx:text] syntax will work for footnotes too.

@vkbo
Copy link
Owner Author

vkbo commented Oct 20, 2023

I've given this some further thought.

An even simpler solution, that also allows nesting of formatting, is to just mimic HTML. We can't use actual HTML syntax since <x> is used for auto-replace, but we can use [x] based shortcodes like we used to on online forums back in the day.

So, this would work:

Text with super[sup]script[/sup] and sub[sub]script[/sub] and [b]nested [i]emphasis[/i][/b].

This too matches well with the [newpage] syntax that exists, and footnotes would still be [footnote:mynote] but could also allow inline footnotes like [footnote]Short footnote text[/footnote].

These shortcodes are also trivial to implement in the way the current parser works.

This will be simple to use for anyone who knows HTML, and who remember forum shortcodes. Since regular emphasis syntax in Markdown still works, these codes would rarely be needed, but when you do need complex control of the formatting, they are there. The last point is what I like the most with this. It basically bypasses the parser logic that looks for a beginning and an end of formatting syntax, and just inserts the raw formatting marker.

It is also inline with Markdown implementations that allow HTML markup when regular Markdown is insufficient.

@vkbo vkbo mentioned this issue Oct 20, 2023
8 tasks
@vkbo
Copy link
Owner Author

vkbo commented Oct 21, 2023

FYI, I made Epic #1541 to track the shortcodes work and the 4 issue tickets it will solve. General implementation details should be discussed there, and the specifics for each feature component in their respective threads.

I've implemented superscript/subscript as [sup][/sup] and [sub][/sub], and it will be included in release 2.2. I've rewritten a chunk of the parser and the output format classes too to support shortcodes in general.

@vkbo
Copy link
Owner Author

vkbo commented Nov 6, 2023

Added in #1540.

@vkbo vkbo closed this as completed Nov 6, 2023
@vkbo
Copy link
Owner Author

vkbo commented Nov 8, 2023

FYI, since there are now quite a number of formatting settings, I've added a little optional toolbar to the editor for formatting quick access. It is hidden by default,m but can be toggled with the three dots icon.

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editor Component: Editor enhancement Request: New feature or improvement next release Note: Features planned for next release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants