-
Notifications
You must be signed in to change notification settings - Fork 21
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
Option to use the filename as slug instead #+TITLE #27
Comments
I like the idea of adding it as a configuration switch; and the direct translation of the file name in an existing archive makes the point extremely compelling! |
Hmm, I think I may have overthought this issue; what if instead of adding a switch, we added just another property to the |
Yea! this is much better solution!
…On Tue, 2 Mar 2021, at 23:54, Lincoln de Sousa wrote:
Hmm, I think I may have overthought this issue; what if instead of adding a switch, we added just another property to the `post`? something like `file_slug`? Which would then contain the output of feeding basename of the file path into slugify. Do you think that would work for you?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub <#27 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHJJVC3NVN7XACDGZNFK3TBWQFBANCNFSM4X7FBAGQ>.
|
Just added it, try it out! 😄 |
I think this deserve a mention in https://emacs.love/weblorg/api.html#symbol-weblorg-route :) |
And thank you very much by the way! I'll be testing all the recent changes asap! |
Hey @clarete, I'm using this now. It works and, with the help of #39, I now can do what I would but I felt it a bit confusing. Look what I got:
I can't use
Where FORMAT could be a callback function, which defaults to slugified title, what allow me have a function With this in mind, every reference to Would be great to support this kind of strings in routes as well:
Well, that is what I have in mind but I'm not sure what is the best solution here or if this is too complex to implement. |
hi @semente, thank you for the PR removing the file extension; I don't know why I left it in there 😄 |
Hey @clarete! It doesn't work:
I was thinking about allowing URLs like Anyway,
And in templates
As you can see only That is how it works currently: if you use
But my proposal is to make it more flexible to fit in different use cases:
Also would be great to have a way to set a default slug format for all routes:
|
yeah, I think adopting a more flexible way of creating the slug might be a better solution. Do you think it makes sense to try to find something in common in these two issues or do you think by implementing these two separate things (this issue and #32) we'd give you that experience? Sorry for all the back and forth and thanks for all the help and feedback 😄 |
hey @clarete, sorry for the delay! You mean having a function similar to In any case, #32 still might be interesting for some use cases but I'm actually using rsync to copy other files than ".org" and that is enough for me. |
This came in my mind:
|
I think the proposal that you have here for a field for configuring the slug is the nicest one, where we can provide default functions for "replacing extension", "slugifying", "slugifying with title" etc. I think it'd be nice to implement this in terms of #32 though, just so we can do this on a per "handler" basis. (Definition of handling is described in #32) |
I like the possibility of using a post title as the slug but it would be great to support the filename as source for the "slugify" function as well. Maybe a variable
weblog-filename-slugs
and:filename-slugs
option in routes to switch to filename based slugs works great.I would to be able to rename a title without worrying about it changing the URL that might have been bookmarked or indexed already, or add a
#+SLUG
on every file. Also I would to be able to use [[file:path/to/file.org]] to link internal pages so I could browse my Org files in Emacs the same way in a web browser.The text was updated successfully, but these errors were encountered: