-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add markdown support or state that it will not be added #626
Comments
This issue has been automatically marked as stale after 90 days of inactivity. It will be closed if no further activity occurs. |
Sorry for the bump (just doing it because of the stalebot), but we would also like to know the answer to this question! |
What does "support Markdown" mean, exactly? Automatically convert Markdown syntax to formatted text as you type? |
We're looking for something that takes in markdown and produces markdown. We only convert to HTML at display time, and like this because it gives us some flexibility between content and display. We currently use (the now abandoned) https://simplemde.com/ for this. |
Hi there 👋
Yes that is something I'd be really looking forward to. |
Hello! I'm also very interested in the possibility to edit docs in Markdown that will be then outputted in HTML (once it is saved as a draft or posted). I would especially like to benefit of syntax highlighting in code samples. |
Just leaving a note to say that SimpleMDE appears to be abandoned, with its most current revision being 4 years ago, while the EasyMDE fork is being actively developed. |
For me, I'd like to have a Document to Markdown converter. So I could store Markdown text into my database and access that data from other systems or languages such as Java. I believe the data format in database should be some kind of standard and exchangeable format rather than Trix format. |
Our text is stored in Markdown format in our database. There's a nice spec for Markdown, specifically CommonMark. So while we'd like to use Trix, it's useless for our purposes without roundtrip support for Markdown. Many other sites use Markdown, including GitHub (which we're typing on right now!). And there are a lot of "likes" on this issue. In short: I think the desire to roundtrip with Markdown is a widespread desire. That may not convince you, but I'm hoping it will :-). |
Hey guys, I would like to start implementing markdown support in trix. Would a toggle between the normal editor and a markdown editor (à la reddit editor, as suggested by @justalever), be enough? I'm thinking that the serialized editor would still return HTML and would still take in HTML. Any thoughts? |
@maximedupre - I can't speak for the universe. However, we store data in Markdown (as do many others), so having a way to take & return Markdown would be what we'd want. That said, it doesn't need to be the default, just a way to configure it (possibly using some external library / plug-in). |
I also think storing markdown is the way to go, It's more portable. I guess the translation between markdown and Trix won't be a performance issue 🤔 |
I will have to parse markdown anyway, so might as well offer the possibility to pass in markdown as an initial value. I have no idea about what the performances will look like. I'll optimize later if needed. |
This pull requests adds basic markdown support: #737 |
This issue has been automatically marked as stale after 90 days of inactivity. It will be closed if no further activity occurs. |
PR #737 is still fairly active, I don't think it's appropriate to close this issue yet. |
This issue has been automatically marked as stale after 90 days of inactivity. It will be closed if no further activity occurs. |
It still looks like there's semi-recent activity on #737, I don't think it's appropriate to close this issue without a firm statement from the maintainers. |
This should not be marked closed. There's a proposed fix, and no word from the maintainers on what will actually happen. |
Modify the Gemfile so we *only* load the Rails gems we use. This reduces our memory use and attack surface. Previously in our Gemfile we just used this construct to load Rails: > gem 'rails', '5.2.4.4' # Our web framework However, that brings in some Rails gems that we never use. Bringing in unused gems can be a problem. [Rails issue #36963, "Rails 6.0.0 performance regression because of ActionText::Engine hook"](rails/rails#36963) discusses a serious problem when using Rails 6 - ActionText takes a lot more memory (so much that many people have reverted an upgrade). We don't plan to use ActionText anyway; it fails to support markdown. ActionText builds on Trix, and we have requested markdown suport ([Trix issue #626](basecamp/trix#626)) and someone has developed a pull request for some markdown support ([Trix pull request #737](basecamp/trix#737)). But those patches have yet to be accepted, and it's not clear this functionality will ever get added. Without that functionality, ActionText is not useful for many people (not just us). So we'd have a lot of pain (wasted memory) with no benefit (we can't use ActionText anyway). The StackOverflow discussion [Rails 5.2.4: How to reduce RAM use?](https://stackoverflow.com/questions/59340237/rails-5-2-4-how-to-reduce-ram-use) noted several ways to reduce RAM use, including: > Another thing you can do is to only load the rails modules you > actually use. On your config/application.rb file you'll see a > line like this require 'rails/all' that loads all rails features > https://github.com/rails/rails/blob/master/railties/lib/rails/all.rb > You can change that line to only import the features you want, like if > you don't use action_cable or active_job you can just import the rest. However, while we *could* modify `config/application.rb`, it seems much cleaner to list in the Gemfile *only* the gems we use. Then we *know* we never loaded anything else. A minor negative to this approach is that when we update our Gemfile we have to update all these gem versions in sync. Since they're released as a unit, it's possible that different rails gems won't work properly together if they use different versions. This commit adds comments to the Gemfile to specifically counter that potential problem. As a result, I think that risk is very low. Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
Modify the Gemfile so we *only* load the Rails gems we use. This reduces our memory use and attack surface. Previously in our Gemfile we just used this construct to load Rails: > gem 'rails', '5.2.4.4' # Our web framework However, that brings in some Rails gems that we never use. Bringing in unused gems can be a problem. [Rails issue #36963, "Rails 6.0.0 performance regression because of ActionText::Engine hook"](rails/rails#36963) discusses a serious problem when using Rails 6 - ActionText takes a lot more memory (so much that many people have reverted an upgrade). We don't plan to use ActionText anyway; it fails to support markdown. ActionText builds on Trix, and we have requested markdown suport ([Trix issue #626](basecamp/trix#626)) and someone has developed a pull request for some markdown support ([Trix pull request #737](basecamp/trix#737)). But those patches have yet to be accepted, and it's not clear this functionality will ever get added. Without that functionality, ActionText is not useful for many people (not just us). So we'd have a lot of pain (wasted memory) with no benefit (we can't use ActionText anyway). The StackOverflow discussion [Rails 5.2.4: How to reduce RAM use?](https://stackoverflow.com/questions/59340237/rails-5-2-4-how-to-reduce-ram-use) noted several ways to reduce RAM use, including: > Another thing you can do is to only load the rails modules you > actually use. On your config/application.rb file you'll see a > line like this require 'rails/all' that loads all rails features > https://github.com/rails/rails/blob/master/railties/lib/rails/all.rb > You can change that line to only import the features you want, like if > you don't use action_cable or active_job you can just import the rest. However, while we *could* modify `config/application.rb`, it seems much cleaner to list in the Gemfile *only* the gems we use. Then we *know* we never loaded anything else. A minor negative to this approach is that when we update our Gemfile we have to update all these gem versions in sync. Since they're released as a unit, it's possible that different rails gems won't work properly together if they use different versions. This commit adds comments to the Gemfile to specifically counter that potential problem. As a result, I think that risk is very low. Signed-off-by: David A. Wheeler <dwheeler@dwheeler.com>
This issue has been automatically marked as stale after 90 days of inactivity. It will be closed if no further activity occurs. |
There's a proposal for progress on #737, without decision. This issue shouldn't be closed, it's a proposal important to some people with a starting implementation. |
This issue has been automatically marked as stale after 90 days of inactivity. It will be closed if no further activity occurs. |
This is unfortunate. We have an issue many want & a PR that begins its implementation #737 that has neither been accepted nor rejected. If we're going to make forward progress, let's get that work going. Thanks! It's not inactive, we're in "waiting for response" mode. Comments? If there are some concerning downsides, let's hear them! |
...and this is why I'm glad I didn't choose Trix for my project (can't even remember which now or why it would ever need Markdown though). I'm sorry, I know that maintaining open source projects is hard, but the worst thing you can do is not communicate at all. It speaks a lot about the likely future of the project, and that is a shame since it still looks pretty amazing. |
Trix is a rich text editor for the web and we have no plans to add Markdown support. Sorry to disappoint!
We’re also typing in a plain ol’ I’m not interested debating this topic, and I’m not here to tell anyone that they’re wrong. I’ll just say that I’m in the same boat as John Gruber, the inventor of Markdown, who recently wrote:
NOTE: The simple WYSIWYG editing he’s talking about is Trix!
If, for some reason, I needed to store Markdown instead of HTML, I’d do it on the server:
Presumably, you’re already converting Markdown to HTML for display so doing the inverse conversion on the server doesn’t seem like much of a stretch. That’s essentially what #737 does, except the conversion all happens on the client with (even more) JavaScript. If you want the essential behavior of #737 as a “plugin” for your application, here’s an example to build off: import markdownToHtml from "https://cdn.skypack.dev/marked"
import TurndownService from "https://cdn.skypack.dev/turndown"
const turndownService = new TurndownService
const htmlToMarkdown = html => turndownService.turndown(html)
addEventListener("trix-initialize", ({ target }) => {
const inputId = target.getAttribute("md-input")
const input = document.getElementById(inputId)
if (!input) return
target.value = markdownToHtml(input.value)
target.addEventListener("trix-change", () => {
input.value = htmlToMarkdown(target.value)
})
}) <trix-editor md-input="x"></trix-editor>
<input id="x" value="**hello**" type="hidden"> And here’s a working demo of the code above (but using ✌️ |
Here is a solution with StimulusJS and without Trix! https://github.com/smcalilly/highlighter-rails/blob/master/app/javascript/controllers/editor_controller.js |
Thank you, @javan, for the closure. I think a good way to implement Markdown support in a WYSIWYG editor like Trix would be to accept Markdown input (while very much showing it), but also formatting the rich text according to the Markdown format in real time. I've already seen a similar implementation somewhere and quite liked it. However seeing how Trix is implemented that might be non-trivial. So really, it would be a support of the Markdown syntax as an input method, since you probably wouldn't be saving the Markdown after that. As an aside, is there any (easy) way to extend Trix with custom tags/attributes/whatever, like perhaps even custom components (markup consisting of several HTML tags with custom controls, etc.)? I can't find anything in the docs beyond rudimentary extensions through the few events. |
@Amunak If you use Rails, Action Text supports that. |
This still shouldn't be closed and was never resolved imo. |
Considering an author has specifically stated markdown will not be added, the issue is most certainly resolved. It might not be the answer you're looking for, but it's what the devs chose. |
give the people what they want!!!! |
@smcalilly if can't live without this feature, fork the repository and add the feature yourself. There are a number of examples on how to do it here, as well as PRs already made and denied. Yelling you, and others, want it will not convince them to add a feature they have clearly stated they will not add. |
@NilsMoller Sorry that you missed my sarcasm, I thought laying heavy on the exclamation points would convey the joke. I've already shared an example where I created a markdown text editor in this issue, but thanks for the suggestion. |
@smcalilly Tone and subtext never work over texts, I avoid that stuff entirely to prevent confusions like these. Have a good day! |
I really love the ability to type an asterisk This is perhaps not the cleanest approach but seems to be working well.
|
37signal has released Writebook which seems to use a new Markdown-based editor (not Trix) built on top of an NB: The JS code for the editor toolbar ( |
Writebook has a proprietary license: https://once.com/writebook#charge-for-books It is "source available" but not "open source" and its license "does not include the rights to publish, distribute, sublicense, and/or sell copies of the Software, source code or products derived from it.” Not sure why 37Signals doesn't want anyone to contribute to it or adapt it to their own needs, but ...it is what it is. |
DHH has stated they plan to release the House editor "as a stand-alone project" after more validation:
|
Trix doesn't support Markdown in and out, and while for many uses that's just fine, for my use-case that's a showstopper.
I'd like to see support for Markdown (specifically CommonMark) added to Trix, either directly or perhaps as some sort of plug-in. Support for Markdown was previously raised in #35 but closed without clear resolution. Similarly, there was a "roadmap"/ideas list in #31 , but that was closed without clearly noting if that's a desired capability.
If Markdown is expressly not going to be added to Trix (because the developers oppose it), I'd like that documented clearly. Otherwise I suspect this issue will keep resurfacing & wasting everyone's time.
Thanks so much for your time!!
The text was updated successfully, but these errors were encountered: