search

glushchenko / fsnotes

Notes manager for macOS/iOS
https://fsnot.es
MIT License
6.37k stars 468 forks source link

Cannot fully load text at once #1639

Closed pretzpockey closed 10 months ago

pretzpockey commented 10 months ago

Description

The editor view cannot load text fully at once, scroll to bottom quickly won't stop at the end of content, meanwhile the content seems to be appended more, and get another chance to scroll to the bottom.

https://github.com/glushchenko/fsnotes/assets/109065892/b26d3df8-673c-4efc-9810-4cbc0d700b41 issue

To Reproduce

Create a note with the text below, open another note and then go back to the one created just now, scroll down quickly to the bottom to reproduce this issue.

TEXT BEGIN

---
title: CommonMark Spec
author: John MacFarlane
version: '0.30'
date: '2021-06-19'
license: '[CC-BY-SA 4.0](http://creativecommons.org/licenses/by-sa/4.0/)'
...

# Introduction

## What is Markdown?

Markdown is a plain text format for writing structured documents,
based on conventions for indicating formatting in email
and usenet posts.  It was developed by John Gruber (with
help from Aaron Swartz) and released in 2004 in the form of a
[syntax description](http://daringfireball.net/projects/markdown/syntax)
and a Perl script (`Markdown.pl`) for converting Markdown to
HTML.  In the next decade, dozens of implementations were
developed in many languages.  Some extended the original
Markdown syntax with conventions for footnotes, tables, and
other document elements.  Some allowed Markdown documents to be
rendered in formats other than HTML.  Websites like Reddit,
StackOverflow, and GitHub had millions of people using Markdown.
And Markdown started to be used beyond the web, to author books,
articles, slide shows, letters, and lecture notes.

What distinguishes Markdown from many other lightweight markup
syntaxes, which are often easier to write, is its readability.
As Gruber writes:

> The overriding design goal for Markdown's formatting syntax is
> to make it as readable as possible. The idea is that a
> Markdown-formatted document should be publishable as-is, as
> plain text, without looking like it's been marked up with tags
> or formatting instructions.
> (<http://daringfireball.net/projects/markdown/>)

The point can be illustrated by comparing a sample of
[AsciiDoc](http://www.methods.co.nz/asciidoc/) with
an equivalent sample of Markdown.  Here is a sample of
AsciiDoc from the AsciiDoc manual:

  1. List item one. + List item one continued with a second paragraph followed by an Indented block. + ................. $ ls .sh $ mv .sh ~/tmp ................. + List item continued with a third paragraph.

  2. List item two continued with an open block. +

    This paragraph is part of the preceding list item.

a. This list is nested and does not require explicit item continuation. + This paragraph is part of the preceding list item.

b. List item b.

This paragraph belongs to item two of the outer list.


And here is the equivalent in Markdown:

  1. List item one.

    List item one continued with a second paragraph followed by an Indented block.

    $ ls *.sh
$ mv *.sh ~/tmp

    List item continued with a third paragraph.

  2. List item two continued with an open block.

    This paragraph is part of the preceding list item.

    1. This list is nested and does not require explicit item continuation.

      This paragraph is part of the preceding list item.

    2. List item b.

    This paragraph belongs to item two of the outer list.

The AsciiDoc version is, arguably, easier to write. You don't need to worry about indentation. But the Markdown version is much easier to read. The nesting of list items is apparent to the eye in the source, not just in the processed document.

Why is a spec needed?

John Gruber's canonical description of Markdown's syntax does not specify the syntax unambiguously. Here are some examples of questions it does not answer:

  1. How much indentation is needed for a sublist? The spec says that continuation paragraphs need to be indented four spaces, but is not fully explicit about sublists. It is natural to think that they, too, must be indented four spaces, but Markdown.pl does not require that. This is hardly a "corner case," and divergences between implementations on this issue often lead to surprises for users in real documents. (See this comment by John Gruber.)

  2. Is a blank line needed before a block quote or heading? Most implementations do not require the blank line. However, this can lead to unexpected results in hard-wrapped text, and also to ambiguities in parsing (note that some implementations put the heading inside the blockquote, while others do not). (John Gruber has also spoken in favor of requiring the blank lines.)

  3. Is a blank line needed before an indented code block? (Markdown.pl requires it, but this is not mentioned in the documentation, and some implementations do not require it.)

    paragraph
    code?

  4. What is the exact rule for determining when list items get wrapped in <p> tags? Can a list be partially "loose" and partially "tight"? What should we do with a list like this?

    1. one

2. two
3. three

    Or this?

    1.  one
    - a

    - b
2.  two

    (There are some relevant comments by John Gruber here.)

  5. Can list markers be indented? Can ordered list markers be right-aligned?

     8. item 1
 9. item 2
10. item 2a

  6. Is this one list with a thematic break in its second item, or two lists separated by a thematic break?

    * a
* * * * *
* b

  7. When list markers change from numbers to bullets, do we have two lists or one? (The Markdown syntax description suggests two, but the perl scripts and many other implementations produce one.)

    1. fee
2. fie
-  foe
-  fum

  8. What are the precedence rules for the markers of inline structure? For example, is the following a valid link, or does the code span take precedence ?

    [a backtick (`)](/url) and [another backtick (`)](/url).

  9. What are the precedence rules for markers of emphasis and strong emphasis? For example, how should the following be parsed?

    *foo *bar* baz*

  10. What are the precedence rules between block-level and inline-level structure? For example, how should the following be parsed?

    - `a long code span can contain a hyphen like this
  - and it can screw things up`

  11. Can list items include section headings? (Markdown.pl does not allow this, but does allow blockquotes to include headings.)

    - # Heading

  12. Can list items be empty?

    * a
*
* b

  13. Can link references be defined inside block quotes or list items?

    > Blockquote [foo].
>
> [foo]: /url

  14. If there are multiple definitions for the same reference, which takes precedence?

    
[foo][]

In the absence of a spec, early implementers consulted Markdown.pl to resolve these ambiguities. But Markdown.pl was quite buggy, and gave manifestly bad results in many cases, so it was not a satisfactory replacement for a spec.

Because there is no unambiguous spec, implementations have diverged considerably. As a result, users are often surprised to find that a document that renders one way on one system (say, a GitHub wiki) renders differently on another (say, converting to docbook using pandoc). To make matters worse, because nothing in Markdown counts as a "syntax error," the divergence often isn't discovered right away.

About this document

This document attempts to specify Markdown syntax unambiguously. It contains many examples with side-by-side Markdown and HTML. These are intended to double as conformance tests. An accompanying script spec_tests.py can be used to run the tests against any Markdown program:

python test/spec_tests.py --spec spec.txt --program PROGRAM

Since this document describes how Markdown is to be parsed into an abstract syntax tree, it would have made sense to use an abstract representation of the syntax tree instead of HTML. But HTML is capable of representing the structural distinctions we need to make, and the choice of HTML for the tests makes it possible to run the tests against an implementation without writing an abstract syntax tree renderer.

Note that not every feature of the HTML samples is mandated by the spec. For example, the spec says what counts as a link destination, but it doesn't mandate that non-ASCII characters in the URL be percent-encoded. To use the automatic tests, implementers will need to provide a renderer that conforms to the expectations of the spec examples (percent-encoding non-ASCII characters in URLs). But a conforming implementation can use a different renderer and may choose not to percent-encode non-ASCII characters in URLs.

This document is generated from a text file, spec.txt, written in Markdown with a small extension for the side-by-side tests. The script tools/makespec.py can be used to convert spec.txt into HTML or CommonMark (which can then be converted into other formats).

In the examples, the → character is used to represent tabs.

Preliminaries

Characters and lines

Any sequence of [characters] is a valid CommonMark document.

A character is a Unicode code point. Although some code points (for example, combining accents) do not correspond to characters in an intuitive sense, all code points count as characters for purposes of this spec.

This spec does not specify an encoding; it thinks of lines as composed of [characters] rather than bytes. A conforming parser may be limited to a certain encoding.

A line is a sequence of zero or more [characters] other than line feed (U+000A) or carriage return (U+000D), followed by a [line ending] or by the end of file.

A line ending is a line feed (U+000A), a carriage return (U+000D) not followed by a line feed, or a carriage return and a following line feed.

A line containing no characters, or a line containing only spaces (U+0020) or tabs (U+0009), is called a blank line.

The following definitions of character classes will be used in this spec:

A Unicode whitespace character is any code point in the Unicode Zs general category, or a tab (U+0009), line feed (U+000A), form feed (U+000C), or carriage return (U+000D).

Unicode whitespace is a sequence of one or more [Unicode whitespace characters].

Expected behavior

No response

FSNotes version

6.4.1

macOS/iOS version

13.6

Additional context

No response

gingerbeardman commented 10 months ago

IIRC this is a concession from an old performance problem. It was either load the whole text and suffer poor performance in certain usage, or no performance problems but have this oddity with progressive loading of text.

pretzpockey commented 10 months ago

IIRC this is a concession from an old performance problem. It was either load the whole text and suffer poor performance in certain usage, or no performance problems but have this oddity with progressive loading of text.

Thanks! Yes it looks like something progressive, perhaps it's the result of balancing.

And I tried to solve it by ensuring the layout for the whole character range, it works for me. However for the long text, it takes long time to be ready.

gingerbeardman commented 10 months ago

I can reproduce.

  1. Create a note with the text of Commonmark Spec
  2. open another note
  3. and then go back to the one created just now
  4. scroll down quickly to the bottom to reproduce this issue
pretzpockey commented 10 months ago

I can reproduce.

  1. Create a note with the text of Commonmark Spec
  2. open another note
  3. and then go back to the one created just now
  4. scroll down quickly to the bottom to reproduce this issue

Thanks @gingerbeardman I tried to disable allowsNonContiguousLayout from storyboard and the problem is gone. I think what you said at the beginning makes a lot of sense!

BTW do you know if there's any benefits from that option? Thanks again!

gingerbeardman commented 10 months ago

Basically, without it there are delays with certain edits.

Origin

Personally, allowsNonContiguousLayout never seemed like the right solution to the problem. It was the quickest and easiest with some known side-effects. Maybe it's time to look at it again?

glushchenko commented 10 months ago

Hi guys! At some point we need to migrate the core editor to textkit2. I hope someday.