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

Bullet list indent requires two spaces, but appears indented with one space in Drafts #10966

Open
amahoneyLIT opened this issue Dec 5, 2018 · 10 comments

Comments

@amahoneyLIT
Copy link

I was previewing a message in drafts with a bullet list.

* level 1
 * level 2 (line starts with one space before the *)

In Drafts this shows level 2 being indented. But when you send to chat, there is no indent and looks like this:

  • level 1
  • level 2

I had to more carefully look at the example provided (clicking the "A" icon in chat)

* Milk
* Tea
  * Green tea
  * Black tea

to see that it uses two spaces. This results in both Drafts and the main chat showing the expected formatting.

It would also help to be provided with this example when clicking the "A" icon, as it was hard to tell that it was two spaces at first glance:

* bulleted lists
  * with sub-bullets too
  * sub-bullets start with 2 spaces
    * start sub-sub-bullets with 4 spaces
@zulipbot
Copy link
Member

zulipbot commented Dec 5, 2018

Hello @zulip/server-markdown members, this issue was labeled with the "area: markdown" label, so you may want to check it out!

@timabbott
Copy link
Sponsor Member

I think the bug here is probably that marked, the frontend-only javascript processor, needs to be configured to require 2 spaces to match the backend implementation. See https://zulip.readthedocs.io/en/latest/subsystems/markdown.html.

But I also like the idea of changing the example to be more clear.

@timabbott
Copy link
Sponsor Member

I suppose the other reasonable approach would be to use a fixed-width font for that section of the docs, which would make the spacing obvious.

@amahoneyLIT
Copy link
Author

I agree fixed width would be helpful. Though the Draft issue is also worthy of fixing, as it may be embarrassing to think your carefully crafted message looks a certain way, then after hitting send see it is not what you expect.

@gaharavara
Copy link
Collaborator

@zulipbot claim

@zulipbot
Copy link
Member

zulipbot commented Jan 25, 2019

Hello @AsociTon, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 14 days.

You can reclaim this issue or claim any other issue by commenting @zulipbot claim on that issue.

Thanks for your contributions, and hope to see you again soon!

@gaharavara
Copy link
Collaborator

@zulipbot claim

@zulipbot
Copy link
Member

zulipbot commented Feb 22, 2019

Hello @AsociTon, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 14 days.

You can reclaim this issue or claim any other issue by commenting @zulipbot claim on that issue.

Thanks for your contributions, and hope to see you again soon!

@gaharavara
Copy link
Collaborator

gaharavara commented Mar 4, 2019

for reference we have discussion here and here
The tasks would be to

  • Update code in marked.js for getting the unordered-list frontend logic corrected
  • update to fixed-width font for that section of the docs regarding ul
  • update the node-tests with a proper case including the above scenario

gaharavara pushed a commit to gaharavara/zulip that referenced this issue Mar 8, 2019
Previously, the frontend-only javascript processor didn't show the same
output as the backend, resulting in wrong output shown in drafts.

Fixes zulip#10966
@gaharavara
Copy link
Collaborator

@timabbott should I apply the fixed-width font to that particular table only or to the whole guide?

gaharavara pushed a commit to gaharavara/zulip that referenced this issue Mar 11, 2019
Previously, the frontend-only javascript processor didn't show the same
output as the backend, resulting in wrong output shown in drafts.

Fixes zulip#10966
gaharavara pushed a commit to gaharavara/zulip that referenced this issue Mar 13, 2019
Previously, the frontend-only javascript processor didn't show the same
output as the backend for unordered lists, resulting in wrong output shown
in drafts.

Fixes zulip#10966
gaharavara pushed a commit to gaharavara/zulip that referenced this issue Mar 18, 2019
Previously, the frontend-only javascript processor didn't show the same
output as the backend for unordered lists, resulting in wrong output shown
in drafts.

Fixes zulip#10966
gaharavara pushed a commit to gaharavara/zulip that referenced this issue Mar 20, 2019
Previously, the frontend-only javascript processor didn't show the same
output as the backend for unordered lists, resulting in wrong output shown
in drafts.

Fixes zulip#10966
gaharavara pushed a commit to gaharavara/zulip that referenced this issue Apr 11, 2019
Previously, the frontend-only javascript processor didn't show the
same output as the backend for unordered lists in case of odd
indentation before the bullet indicator, resulting in wrong output
shown in drafts. This is because their was no specific way to handle
odd indentation.

Fix for it was to check for odd indentation whenever bullet list is
encountered and trim a space to make it even and ideal for zulip's
markdown.

Fixes zulip#10966
gaharavara pushed a commit to gaharavara/zulip that referenced this issue Apr 11, 2019
Previously, the frontend-only javascript processor didn't show the
same output as the backend for unordered lists in case of odd
indentation before the bullet indicator, resulting in wrong output
shown in drafts. This is because their was no specific way to handle
odd indentation.

Fix for it was to check for odd indentation whenever bullet list is
encountered and trim a space to make it even and ideal for zulip's
markdown.

Fixes zulip#10966
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants