34

Monospaced / Unformatted Text ...

In our work a solution frequently involves code snippets.

e.g.

(defun c:PointAt ( / ename dist point )
(if (setq ename (car (entsel)))
(if (setq dist (getdist "\nEnter distance: "))
(princ
(if (setq point (_PointAtDist ename dist))
(strcat
"\nPoint: "
(vl-princ-to-string
(mapcar
'rtos
(setvar "lastpoint" point)
)
)
)
"\nPoint not on object."
)
)
)
)
(princ)
)

Posting code into a ticket thread is unsatisfactory as the rendering engine flattens (strips leading white space) all indentation.

e.g.

(defun c:PointAt ( / _PointAtDist ename dist point )
(if (setq ename (car (entsel)))
(if (setq dist (getdist "\nEnter distance: "))
(princ
(if (setq point (_PointAtDist ename dist))
(strcat
"\nPoint: "
(vl-princ-to-string
(mapcar
'rtos
(setvar "lastpoint" point)
)
)
)
"\nPoint not on object."
)
)
)
)
(princ)
)

While some solutions could be posted to a forum entry, it's not a blanket solution, nor is the rendering engine for forum posts ideal from a coder's perspective (you can edit the html direct and place [pre] code [/pre] tags but meh).

Attaching code files is overkill for solutions that involve a dozen or so lines of code.

Thoughts?

--

Unrelated ...

  • It would be great if posts and comments could be previewed before posting.
  • The ability to color text (without modifying html directly) would be nice.

Having said all this ... zendesk kills ... outstanding product!!

  • Michael

84 comments

  • 0

    MP, thanks for the positive feedback!

    We've just improved the WYSIWYG engine, so editing posts should now look 100% like the final rendered version - hopefully this makes a preview function obsolete.

    Internally, we use Zendesk for a lof of our coding stuff - and we use pastie.org for code snippets, which works very well. White space indentation is very shaky when working with HTML. Anybody else have thoughts on this?

  • 0

    What setting have you found pastie.org best used for within zendesk? I'd love to see GeSHi integrated within the Zendesk editor http://qbnz.com/highlighter/

  • 0

    I believe the original requests still stands - it's the comments fields within ticket threads that need some level of formatting support.

    I certainly believe that comments threads should be kept simple, but adequate support for code snippets is really quite important.

  • 0

    Ticket threads appear in emails, which is why special styling probably won't work satisfactory. Pastie.org (and the like) ensure superior styling, and works qua links in all channels.

  • 0

    OK, but what UI facilities would you provide for users. Please describe what Pastie.org is, how it is used, and show how it renders in a ticket thread.Thanks.

  • 0

    With pastie.org, you simply paste in the code (any language), and get an URL back. Try it a http://pastie.org. The URL is inserted in the ticket text and points to a nicely fullscreen formatted version of your code, complete with syntax highlighting and indentions. 

  • 0

    I have tried this (using MP's the original example above). This seems to be the link produced: <<script src='http://pastie.org/330787.js'></script>

    Whilst this renders in a topic (I've escaped it here to show the link), it doesn't in ticket thread it escapes automatically.

  • 0

    Just enter the link in a ticket comment, and it should be linked automatically.

  • 0

    OK, I've worked through this and it transpires that the use of Pastie's in ticket comments threads is limited to providing a URL link back to Pastie site to render the formatted code. This Pastie method is further compromised as the link takes you away from ZD i.e. you look at the code without the surrounding context of the ticket & thread.

    I appreciate the limitations/benefits of the simplified ticket comments - so the conundrum stands. We'd still  like a way to paste code snippets into comment threads so they are rendered in the flow of the conversation.

    Note: I still think it is a smart idea to delegate complex code format rendering to a web service.

     

  • 0

    I think this is partly a UI problem - when you are typing a comment, it uses a monospaced font, therefore you assume that it's going to stay monospaced.  Then you submit it and it changes to proportional, and throws away the layout.

    You have broken the user model - it doesn't do what the user expects it to do.

    I agree that being able to put <pre> content into a comment is absolutly vital.

    I also understand why it's currently throwing away the whitespace - that's what happens in HTML.

    Ideally it would be great to have the same WYSIWYG editing for comments as for forum posts.

    If you're not going to implement WYSIWYS for comments, could you at least change the textbox font to proportional?

  • 0

    Pastie isn't a solution that works well for the reasons listed above.  I would suggest a few syntax highlighting libraries:

    http://pradador.com/code/lighterjs/

    http://code.google.com/p/syntaxhighlighter/

    I personally prefer the first option as the setup is very easy and requires no configuration so it would be very easy to allow end users to add syntax highlighted snippets just by adding a class to their pre tag.

    This is a hot topic for us as we are starting to use zendesk for a technical user knowledge base and single color pre tags don't cut it.

    For the comment about what to do with email sent out containing a snippet, I think a best effort solution works.  Include the pre in the HTML encoded body and drop it for the text encoded body.  Let the email client handle it.

  • 0

    Just want to second the above comments and ask if there's been any improvements on this front since May.  We really need to be able to send <pre> formatted code snippets to our customers, and the pastie solution is really not workable (especially for many small snippets, interespersed with comments.  Even just supporting <pre> would be a big win for us.

    Thanks for listening.

  • 0

    This is a major concern - surprised I hadn't noticed until now!  We send code snippets and XML snippets relatively frequently in discussions with customers.  Being able to generate a well-formatted snippet for the customer, and them not being able to read it in-line, with proper indentation, looks very bad!

     

    Atlassian's WIKI offers an the ability to supply a {noformat} delimiter for such things - which would at least help in the times one answers directly from the GUI. 

     

    What is an ETA on providing a solution for this problem?

  • 0

    For the record, if such a "{noformat}" delimiter were respected in email ticket updates, that would solve most of our problems as well. 

  • 0

    Sorry to harp, but just wanted to say again that this is a big issue for us.  Our helpdesk interaction is almost entirely email-based, and often questions and aswers are peppered with lots of little code snippets (so pastie.org is really not a solution).  Again, just some way to <pre></pre> in email would be sufficient.  To be clear, this is the only big problem we have with Zendesk, so you guys are miles ahead of most software we use, but still it'd be really great to get this change.

  • 0

    Hey guys,

    Thanks for the responses, and apologize for the delay.  We understand your concerns, and we heard you.  Let me make sure the team is aware of this, and I'll get back to you when I have an update

    Sorry for the inconvenience

    Regards

    -amy

    Zendesk Support

  • 0

    Thanks and keep it alive!! This issue is the principle reason I don't have a paid account.

  • 0

    +1. Please make everything monospaced.

    We're talking about e-mails after all.

  • 0

    This issue remains the deal breaker for us. Pastie.org is not a solution, all code/data/posts/yada need to be integral to the service.

  • 0

    This is a showstopper for us also - I would expect an HelpDesk product for use with tech companies to be able to support this requirement.

    Any update on when if ever this is going to be supported?

  • 0

    I Agree we too need to know when this is supported.

  • 0

    Same for us -- all we want is that the whitespace stops being stripped as the ticket reply is added to the zendesk system -- the pastie.org is far too complicated for our clients -- all they want is just to send us a little snippet of code that we can look at and we want to send snippets back.

    Furthermore, with python, its not just a formatting issues, its actually breaking the code which is even worse :) 

  • 0

    This is not marked with a "Planned" tag -- does that mean its part of your "ticket inbox" (since 2008?)? Or that you have decided to not to do this?

    Curious since this is really becoming quite a big problem for us - clients are getting annoyed when we have to ask them over and over again to attach files instead of just pasting 20 lines of code into the ticket etc. And with python there is no way to just "fix" the formatting automatically - basically, information is lost at the point the whitespace is truncated and the code snipped many times becomes useless, unless its super small.

    I might be totally wrong here - but it sounds like a pretty simple thing to just stop stripping the white space from the content as its being stored in zendesk? 

  • 0

    I may be wrong but it looks like anything that you put into Pastie is made public. This is therefore not an option as we would be violating license conditions, we cannot afford to have private API's and code leak into the public domain.

  • 0

    My customers frequently and bitterly complain that this problem makes Zendesk unusable for them. Here's the most recent example (out of many):

    The whole purpose of a system like Zendesk is to facilitate the exchange of technical information, and it's absurd to suggest I should have to jump through hoops to make good its fundamental deficiencies in this regard.

    My attitude to this issue is that you are requiring me to use a technical communication system that fails in its most basic function, that of transmitting messages correctly. For heaven's sake, this system cannot transmit a chunk of code without mangling it beyond all recognition. It is astounding that you adopted this system, but it is even more astounding,
    and depressing, that there are programmers on this earth who are so badly educated that they do not know what a tab character is for. And that they work for a company producing technical communication software! The programmer responsible for this mess must have a brain so small that it doesn't even move his hind legs properly.

  • 0

    Issue is 2+ years old.

    That says so much about zendesk I don't have to add any ranting.

  • 0

    Just wanted to add that this comes up every day for us as well.  One note on pastie.org:  a 'pastie' is an ok solution for outgoing mail from agents (athough it gets pretty unwieldy when you have lots of snippets interspersed with text.  But pastie.org really doesn't help at all with incoming mail from users.  After someone who's having trouble with your software goes to the trouble to send you the block of error text it spews, it really doesn't go over well for support (us) to write back and ask them to do it all again but use pastie.org this time.

  • 0

    I just checked with them where on the roadmap this sits and the answer is "nowhere". Their support staff advised me to keep watching this thread for updates... 

  • 0

    the dog ate the original request

  • 0

    They certainly lost our business based because of this missing functionality.

Please sign in to leave a comment.