-
-
Notifications
You must be signed in to change notification settings - Fork 49
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
Fix issue #271 (Allow -- in titles) #331
Fix issue #271 (Allow -- in titles) #331
Conversation
Merged. Thank you! Though now we need to think how best to design this to make it opt-in for users who want more flexibility with the file-naming scheme. Maybe it is too early to add a user option, given the planned changes you are working on, but it is something to consider once things have settled. |
Is it not already opt-in? Currently, with the default sluggification as it is, it is not possible to have consecutive hyphens in a file name title. If users disable the title sluggification, that's when they are allowed to type any title that they want, including the "-----" if they want. I think that "disabling all sluggification" to mean "allow as much flexibility as possible in file name components" is intuitive. |
This reflects the change made by Jean-Philippe Gagné Guay in pull request 331: <#331>.
Actually, I am not sure I understood your point about an opt-in option. I think we should impose as few rules as possible to the file naming scheme when sluggification is disabled. Then, with the default sluggification, we "impose" some defaults. Here are the strict rules of the file naming scheme (without sluggification), as they currently stand:
I think we should aim for as much flexibility as possible when sluggification is disabled. Then, through sluggification, users can impose further rules on their file name components. |
From: Jean-Philippe Gagné Guay ***@***.***>
Date: Fri, 26 Apr 2024 21:57:31 -0700
Actually, I am not sure I understood your point about an opt-in
option. I think we should impose as few rules as possible to the file
naming scheme when sluggification is disabled. Then, with the default
sluggification, we "impose" some defaults.
Here are the strict rules of the file naming scheme (without sluggification), as they currently stand:
- No dot character except for the extension.
- No consecutive delimiter characters (-,_,=) in the components, except for the title which accepts multiple hyphens.
- No delimiter character at the end of a component (to prevent conflict with a possible next component).
I think we should aim for as much flexibility as possible when
sluggification is disabled. Then, through sluggification, users can
impose further rules on their file name components.
I agree with the flexibility part. What I am not understanding is the
intent: how would the user input the multiple dashes in this scenario.
Is it by configuring 'denote-file-name-slug-functions'?
I just want to make sure what the expectation is to document things
accordingly.
…--
Protesilaos Stavrou
https://protesilaos.com
|
There are 2 cases:
Yes, a user would need to disable the default sluggification through this option to be able to input "--" in titles. I think we only need to document the rules of the file naming scheme (in my previous comment) and the default sluggification. |
From: Jean-Philippe Gagné Guay ***@***.***>
Date: Fri, 26 Apr 2024 23:08:48 -0700
[... 4 lines elided]
> Is it by configuring 'denote-file-name-slug-functions'?
Yes, a user would need to disable the default sluggification through this option to be able to input "--" in titles.
I think we only need to document the rules of the file naming scheme (in my previous comment) and the default sluggification.
All good, thank you! Let's leave the documentation for the end then.
…--
Protesilaos Stavrou
https://protesilaos.com
|
A pull request to fix issue #271. Has no impact on users that keep the default sluggification. Those that don't are allowed to have consecutive hyphens in titles. We do not remove them.
The fontification does not need to be updated. It handles this correctly already.