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

Inconsistent intendation behavior or use of "enter" with first list item #11854

Open
Julrob199 opened this issue Feb 17, 2025 · 5 comments
Open
Labels
bug It's a bug

Comments

@Julrob199
Copy link

Operating system

Linux

Joplin version

3.3.1

Desktop version info

Joplin 3.3.1 (prod, linux)

ID do cliente: <>
Versão Sync: 3
Versão do Perfil: 47
Keychain Suportada: Não

Revisão: da59aef

Backup: 1.4.2
Freehand Drawing: 2.15.0
Markdown Table: Sortable: 1.2.2
Menu items, Shortcuts, Toolbar icons: 1.1.0
Note Tabs: 1.4.0
Quick Links: 1.3.2
Rich Markdown: 0.15.1
Victor: 1.0.3

Current behaviour

There is a weird and inconsistent behavior of intendation. It started to behave differently since version <3.1.x
...

How to reproduce:
Case 1: Expected behaviour

  • Go to the end of "Dora" and type Enter three times: 1. Creates new checkpoint, 2. Intends one two the right, 3. Removes the checkpoint. This is the expected behaviour I know from < 3.1.x Joplin.

Case 2: Unexpected behaviour

  • Now go to the end of "Ant" and type Enter two times: 1. Adds new checklist item, 2. Here it is confusing: Instead of removing the list item, it creates a new blank line and shifts the new checklist item from step 1 one line downwards. Only if you press a third time enter, then it removes the list item, but then it has already created two empty lines.

First I was wondering if it has something to do with the intendation. But it happens also with "Heading 2". Case 1 applies for "Fargo", "Good" or "Hola"... so where the button enter works as expected. But case 2 happens with "Ant" or "Hola" or even "Charlie"... so always when its the first item in the list.

Use this as an example (do not use code formatting, when testing it in joplin)

# Checklist
- [ ] Ant
- [ ] Bear
	- [ ] Charlie
	- [ ] Dora

# Checklist 2
- [ ] Earn
- [ ] Fargo
- [ ] Good
- [ ] Hola

Expected behaviour

This behaviour affect ordered, unordered and checklist items.

Having different behaviours is really confusing. It disturbs the workflow imho. Sometimes I want to split a list and by one empty line. When I start doing it with the first list item I always have to clean up the left over list item, which looks then like this:

- [ ] Earn

- [ ] 
- [ ] Fargo
- [ ] Good
- [ ] Hola

Expected behaviour would be:

  1. Press enter until intended completely left
  2. Another enter removes the list item (like ordered, unordered or checklist item)
  3. Another enter just adds blank lines.

So case 1 and 3 are expected, case 2 not.

Logs

No response

@Julrob199 Julrob199 added the bug It's a bug label Feb 17, 2025
@Julrob199 Julrob199 changed the title Weird and inconsistent intendation behavior Inconsistent intendation behavior or use of "enter" with first list item Feb 17, 2025
@personalizedrefrigerator
Copy link
Collaborator

I'm linking to a related upstream CodeMirror discussion: https://discuss.codemirror.net/t/markdown-customizing-list-tightness/9003

@rabbabansh
Copy link

I tried reproducing the bug but it works as expected, can you help me reproduce this?

  1. First enter, creates a new checkbox.
  2. Second enter, pushes the new checkbox to the left (-1 intend)
  3. Third enter, removes the checkbox completely (because no more space left to reduce the intend to the left)
  4. Creates another new line.

@Julrob199
Copy link
Author

@rabbabansh: You probably reproduced the case 1, which is the expected behavior. So you did not start with a first item in a list with those steps? Can you do this again with the word Ant, Charlie or Earn by setting the coursor at the end of the word and then do your steps?

@Julrob199
Copy link
Author

I'm linking to a related upstream CodeMirror discussion: https://discuss.codemirror.net/t/markdown-customizing-list-tightness/9003

Yeah similar behavior but in this example its the last item, in joplin its the first list item with this behavior.

@rabbabansh
Copy link

@Julrob199 oh right, thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug It's a bug
Projects
None yet
Development

No branches or pull requests

3 participants