|
Perhaps. I use markdown all the time with my wiki, but I find it pretty clumsy. It is especially clumsy when working with line breaks and code. However, markdown would probably be fine for 95% of the people who use lists.
Visual Studio is an excellent GUIIDE.
|
|
|
|
|
Yuck!
Have you actually tried it? It's just yucky.
|
|
|
|
|
But what's so horrible about something like having
1. One
2. Two
3. Three
Turn into
- One
- Two
- Three
I don't think I'd want to support the full markdown syntax, but even just some basics such as lists, *...*, _..._, blockquote and a few other simple ones would help and be unobtrusive.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
Chris Maunder wrote: or we could use MarkDown
No thanks. I prefer the same language for messages, tips, articles, and everything. And I like the ability to edit them and view them outside the CP environment, in an off-line environment I'm familiar with; so HTML is my language of choice.
A few buttons to ease the most popular constructs is fine, such as the existing "code block" one. You could add a "create numbered list" and/or "create bulleted list" widget, which would insert some OL/UL and LI tags for say 7 items. The redundant ones are easily cut, but I'm not asking for any of that.
BTW: IMO there isn't an absolute need for a one-fits-all approach, if one editor is perfect for all jobs, then that's the one; if not, please consider making the choice a personal setting. (Of course this may somewhat conflict with the many people working on one message idea).
|
|
|
|
|
Luc Pattyn wrote: insert some OL/UL and LI tags for say 7 items
I like that idea.
Visual Studio is an excellent GUIIDE.
|
|
|
|
|
Luc Pattyn wrote: please consider making the choice a personal setting
That was the initial plan, until...
Luc Pattyn wrote: this may somewhat conflict with the many people working on one message idea
Exactly. It caused no end of mess.
So you don't feel the addition of automatic conversion of
* One
* Two
* Three
and
1. One
2. Two
3. Three
to UL and OL lists wouldn't be simple, unobtrusive and helpful?
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
Chris Maunder wrote: to UL and OL lists wouldn't be simple, unobtrusive and helpful?
I can't speak for Luc, but I think this is a great idea.
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
For short stuff (today's forum messages) I wouldn't mind having that, but I don't consider it a priority. I do type 1. aaa 2. bbb 3. ccc with newlines and am happy with the result already; and I don't do unordered lists, having numbers makes replying much easier.
If you implement it, I prefer separate lists to have continuing numbers, i.e. not restart at 1 (or 0 for JSOP and some).
For long stuff (articles) I would prefer not to have it; I know MS Word does it and most often makes a mess as soon as I want nested lists, lists that restart at 1, etc. Maybe it is too intelligent to guess what I really want.
For both it is important that I can create a text, preview it, edit it, do a full or partial copy/cut, then paste it again, while keeping everything as intended, i.e. it should be smart enough to either undo what was added/changed automatically, or avoid doing it twice when pasted again. One of the reasons is I do keep a copy some of my messages in a separate "database" so I can reuse them without further ado. And when I need them often enough I turn them into a little article.
|
|
|
|
|
Markdown would only ever be used within Quick Answers. The thing that attracts me to markdown is that it would never affect the raw Text/HTML you entered, and we'd only enable it for really simple things such as lists and *emphasis*.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
Some suggestions:
1. make enabling/disabling such intelligence a user choice (personal settings)
2. label your editor window with what features are enabled/disabled to make sure users know what they should expect (e.g. "markdown enabled" right on top of the edit box); if the choice can be changes locally, add checkboxes instead of labels, preferably on top of the edit box, so I see them before I start typing and scrolling.
3. if you use the name, make sure to implement the real thing; I remember you said "some parts of markdown" somewhere, don't call it markdown unless it is complete (or an official feature set if such thing exists). Same for the now gone WYSIWYG editor that wasn't really WYSIWYG as preview looked differently.
I'm not sure what is going on. Have you given up completely on all kinds of WYSIWYG editors? Do you need more than the current forum editor is offering?
I will try it if you create it, however I'm not sure at all I will use markdown or any new language. Straight HTML is my preference. That too is a moving target, but it is one I have to know anyway; so far markdown means nothing to me, I had to look it up in order to find out what you were on about.
BTW: there is 1 bug in the forum editor I stumble upon frequently however I've never reported it: insert widgets should not only insert, they also should delete any selected text like all editors do; it happens to me when fixing a < mistake: I select the < in the text, then click the < widget, and end up with <<
And the other thing that I have reported and still annoys me is the inconsistency in the smileys: does not need a space,  does
|
|
|
|
|
If we enable/disable Markdown then it probably be via a Format dropdown (Plain text, Text + Simple HTML, Text + HTML + Simple Markdown kinda thing).
Luc Pattyn wrote: Have you given up completely on all kinds of WYSIWYG editors?
Yes, for Quick Answers. Everyone complained about it so I dumped it and went back to the editor used in the forums.
If you know HTML then stick to it. I want to allow our members to just type a question and be done with it. If they want to add HTML decoration then we allow them, but we're not going to force anyone to include P or BR tags within a question just to get new lines.
For Markdown it's the same deal. Type using text. If you wish to add HTML then do that. If you wish to allow Markdown to be used then you have the option of decorating your text in a slightly different way to HTML. Instead of <b>...</b> you'd do **...**, instead of using ULs for lists you'd just prefix each line item in your list with *. Very basic.
The biggest problem that I see is entering code snippets. The article editor will stay as-is because it accepts raw HTML and provide a good deal of flexibility (balanced by our safety filters). Within a question, though, adding PRE tags is not a typical user's first thought. Markdown will treat anything indented 4 spaces as code, but to be that could be troublesome. I'm open to suggestions on how to make it easy to add code.
(and thanks for the < bug report)
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
I once (before those checkboxes got added) suggested to automatically HTML-encode everything that gets pasted inside PRE blocks, which you (rightfully I guess) rejected since code too could take advantage of bold and italics and such.
Now since you're considering a new language for formatting, I'll try a variant (may need some refinement, but it should remain simple and get published):
everything that gets pasted is:
1. checked for content (see below), and:
2a. either pasted with PRE tags around it, with automatic HTML encoding, with the correct language setting, and with untabbing (TAB becomes 1 to 4 spaces up to next multiple of 4)
2b. or pasted as is.
2a. really means a straight copy from IDE to edit box, no manual tweaking necessary.
remains to be solved: optional bold/italic/highlighting; I would accept such formatting only can be done after pasting (it is not present in my source file anyway!), with the existing widgets, and gets lost when copying again.
Content checking rules could require all of the following to be true for code:
- not sure: cursor must be on an empty line
- clipboard must hold multi-line text
- that text must start with a TAB, or two spaces, or one of a limited set of keywords which may appear at the start of a source file (imports in VB.NET, using in C#, <?PHP in PHP, etc; but what with comments, i.e. double slash, slash-asterisk, single quote, etc?)
Language recognition is more difficult. If it was a keyword that made it code, use that info. Otherwise, use the first tag. Otherwise use a user preference? Otherwise set it to "text" (or ask for it in a popup!), do not set it to a wild guess.
BTW: please discard CODE tags or make them as dumb as possible, let us push people towards PRE, not CODE tags. One reason is IMO contrast is very bad with syntax coloring on the blueish background.
Sanity check: valid code must remain valid code, i.e. a publish-copyToIDE-compile cycle must be successful, no matter what the intermediate language(s) do for formatting. [ADDED]Loosing TABS seems acceptable[/ADDED]
Ultimate test: publishing some HTML source. I think I also want two new widgets: paste as is, and paste as code; so I can force something to be code, or not to be code.
I hope/think this is rather easy for users, documentors and implementors.
PS: if you do this on QA, I think I also want it on all (remaining) forums. PRE tags are not just for code, they are useful on anything that takes advantage of a nonproportional font and a different background.
modified on Tuesday, December 1, 2009 2:44 PM
|
|
|
|
|
Wrapping everything pasted in PRE tags would cause much wailing and gnashing of teeth.
What about when a paste occurs it does a quick check to see if it may be code (looks for var, void, dim, select, // etc) and, if it thinks it's code then it pastes it not into the editor window, but into an intermediate window with "Is this a code snippet?" as the title. The user could click "No" and it would go on to paste as-is, or the user could select the language from a dropdown and click "yes" which would paste everything HTML encoded within a PRE block.
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
|
Am I missing something? I did some research (following up on your suggestion), posted an article, and sent you an e-mail. My LPCodeRecognizer[^]stuff tells text from code quite well, tries to figure out what programming language was used, and offers a test bench where you can experiment with it. I suggest you download it and give it a try.
modified on Friday, January 8, 2010 10:45 AM
|
|
|
|
|
Luc Pattyn wrote: For long stuff (articles) I would prefer not to have it; I know MS Word does it and most often makes a mess as soon as I want nested lists, lists that restart at 1, etc. Maybe it is too intelligent to guess what I really want.
IT doesn't really start making a mess until you start trying to do clever stuff this sort of list:
1
1.1
1.2
1.2.1
1.2.1.1
1
2
A
B
3
A
B
C
1.2.2
1.3
2
2.1
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
I don't ever want such complexities, and most often I don't let it concatenate the numbers. IIRC it goes all wrong when I copy one autonumbered item from one list and paste it into another list, possibly at a different nesting level; and it seems to work differently in different Word versions.
I tend to turn all automation off, it just seems unreliable. I like "what you type and click is what you see and get".
|
|
|
|
|
All our standard templates are outline numbered. Occasionally I need a numbered list in one of the sections. 
The hassle of the auto numbering occasionally splatting doesn't even come close to the horror of trying to manually keep the paragraph numbers in a 50 or 100 page document intact when making non-trivial revisions.
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
I'm not fond of outline numbered (and even automatically numbered) headers. I appreciate their power within a single document, but I can't use them to refer to some paragraph from say another word document without risking the numbering becoming stale. So I have created in the past 100+ page documents with manual numbering to make sure they are unlikely to ever change! (Of course I create them with autonumbering on, then I turn it off before the first release).
|
|
|
|
|
Cross document tracing is a PITA; but when most of my docs are guaranteed to have at least two delivered versions (pre-development for client review, and final with the shipped app) making them immutable the first time through isn't an option.
3x12=36
2x12=24
1x12=12
0x12=18
|
|
|
|
|
Just a suggestion...
I see there is "top articles" and "recent articles", but why not have a "random articles" option? Seems like a good way to get some old articles traffic. And I'm not always looking for the latest and greatest or a particular article. Sometimes, I just want to see some random articles.
Visual Studio is an excellent GUIIDE.
|
|
|
|
|
Seems this feature has already been requested. Oh well, consider this my vote for it.
Visual Studio is an excellent GUIIDE.
|
|
|
|
|
Is the new "See Also" set of links within articles enough? They aren't random - they are a list of articles that others who have read the given article have also read - but I thought it might be sufficient.
If not, let me know.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Sometimes I'm not really looking for something in particular. By seeing related articles, I would have had to already be at an article, probably via one of the other means of finding articles (recent, search, etc.). The "see also" feature is a useful one, especially when I'm really interested in a technology (e.g., WPF), but a random article feature seems like it would satisfy a different need... to explore the unknown rather than chart the path ahead. Imagine the delight of a computer science student while on Code Project and coming across (without already knowing what they are looking for and searching for it) something called "LISP" and finding out it's a language composed almost entirely of parentheses.
As an analogy, do you ever try to find interesting restaurants? I do... I like to find the holes in the wall that have something unique*, rather than the "best of the best" with good reviews. Random articles would be that "hole in the wall" experience.
*I once had a salad at a Bavarian restaurant... it was unlike any salad I'd ever had before and is highly recommended.
|
|
|
|
|
Fair enough.
Truly random, or random-where-rating-is-over-4?
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
User configurable (a drop down, a star-selection control, or a checkbox list which would for example allow a user to select both 4+ articles and unrated articles), but defaults to greater than 4? Sometimes I want to see crappy underrated articles too. If you don't have the time to make it user configurable, I'd say the initial release should be fully random (despite popular advice).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
