Forum CODE tags change - confusing?

It would appear that the forum CODE tag feature has changed recently and I find it rather confusing. Instead of getting the previous single or triple backtick, a discrete box appears on the right hand side of the edit window. I think the idea is to select the type of content you are going to paste, and then paste the content into the editor. The same thing now happens when you try to paste a URL using the ‘link’ icon. I had a right game trying to type in a code example last night.

I get what this it trying to do, but it does seem to have problems, which, if it has confused frequent visitors like me, then it must be confusing to newcomers.

The problems I find are these:

  1. There is no prompt in the drop down to indicate what one is supposed to do. If someone hasn’t encountered it before, they are going to wonder what is going on as its very different to what they might encounter on another forum.
  2. there is no indication where one is supposed to place the text being pasted - no marker, box or field. The drop-down does not seem to align with the cursor or text which further compounds matters.
  3. if you happen to paste or type the text first and select the option from the drop-down afterwards, the result can be a mess. The easiest way out is to clear the text, select CODE to make the drop-down appear, select the content type ans the re-paste the content. You can no longer just type in and highlight the text you are working with and then select the CODE icon.

I guess its still early days and its an interesting concept, but a prompt in the drop-down would at least provide a clue to the disconcerted user on their first encounter with the feature what they are supposed to do with it.

I think we may also need to modify the advice to those we are trying to help to paste code in code tags. The principle of doing so still remains true, but it no longer works like that.

Are you using the the Markdown editor or the WYSIWYG editor ?

I am using Firefox web browser on a PC or laptop and browsing forum.arduino.cc. I am not accessing the site via a mobile device or any app. Whenever you reply or create a new post it just opens an editor at the bottom of the web page. Not sure whether its markdown or WYSIWYG but I suspect the former. I didn’t realise one can switch to another editor?

BTW, I am using dark mode. Not sure whether the colour scheme exacerbates matters. Maybe its more clearly defined in the light scheme?

The clue is that the Markdown editor has a preview window to the right of the input window and the WYSIWYG editor doesn't

You switch between the two editors using the leftmost icon in the reply editor toolbar, highlighted here
image

image

That is interesting, because that is what I used to get. I now get just one window on both computers and it has an ‘A’ in the top left corner. I didn’t consciously select or choose it (although after midnight it entirely feasible that I might have unconsciously done so...) so am presuming that it must now be the default? In any case, from your example it looks like I was using the WYSIWYG editor.

if (true){
  ...
}

I just tried switching to markup and it still works like it did previously of which the above snippet, is an example.

I am curious when/how that got changed?

I wonder, if it accidentally got selected on one computer, would that have been stored in my profile so that it then appeared the same way on the other one when I next came to use it?

The WYSIWYG editor option was introduced in June this year but caused problems with code posted under some circumstances

See Anybody else noticed an influx of code formatted as individual lines?

You may have inadvertently clicked on the option to use the WYSIWYG editor

Let's put it this way, for the user (you) it's a global setting; change it on one of your machines and it will be like that on all your systems.

The "rich text editor" mode has been present on Arduino Forum for months.

The forum's default post composer mode is currently the "Markdown editor". The established information about posting code was all written for the Markdown editor, so it will be applicable to those using the composer in the default mode. I think new users are most likely to not bother changing the mode, so we should be fine so long as instructions are applicable to the default mode.

I do plan to switch the default for new users to the new "rich text editor" mode, and it would be good to review and revise instructions at that time.

In instructions targeted to new users, I would avoid the added complexity that would come from trying to provide separate instructions for each mode. Perhaps the instructions can be written in a manner that makes them equally applicable to either mode.

The advice that I usually give is as follows

In my experience the easiest way to tidy up the code and add the code tags is as follows

Start by tidying up your code by using Tools/Auto Format in the IDE to make it easier to read. Then use Edit/Copy for Forum and paste what was copied in a new reply. Code tags will have been added to the code to make it easy to read in the forum thus making it easier to provide help.

Presumably that works for both editor options. If not then I cannot think of an easier way to describe how to post code

So long as markdown is still the default, I think it makes sense to keep things simple and not overwhelm the user. I am prepared to accept that I might have accidentally switched it. If the setting is "global" for my user profile, then that also explains how it happened to change on both computers.

Its good that it did perhaps as I am now aware of it and in a better position to help if someone else encounters the same issue.

Thank you for the very quick feedback!

As the “rich text editor” accepts Markdown do we really need both options ?

The "Markdown editor" mode is very valuable to those of us who are fluent in Markdown and can more efficiently write by working with markup directly. Even though you can format your post in the "rich text editor" mode by manually typing Markdown, you still lose a lot of control. For example, if you want to adjust the formatting, you are not able to do that by editing the markup.

As I've already explained in a previous discussion, my hope is that the "rich text editor" mode will be more friendly to new users, and even to established users who have no interest in working with markup directly.

I have found that feature useful as well and been encouraging others to use it. The first example below is just by way of a quick test in WYSIWYG mode. It does work in the same way and automatically flagged the code as ‘cpp’.

The second example is from the output window. it also got flagged as ‘cpp’, however one can use the drop-down to change it to ‘bash’ or ‘shell’. I am working on Linux so ‘bash’ suits me just fine. Probably ‘shell’ on Windows? However, one thing to be additionally careful of is to make sure that the cursor is first placed in that window.

Otherwise it seems to work pretty well.

Example 1

const uint8_t hftxpin = 14;
const uint8_t sbSize = 64;
const uint8_t repetitions = 4;
const uint16_t t[4] = {2100, 3150, 350, 6500}; // t0, t1, tp, tg
uint8_t sbCnt = 0;
char serBuf[sbSize];
uint8_t pulseData[12] = {0x05, 0x1B, 0x1D, 0x19, 0x0B, 0x0D, 0x09, 0x13, 0x15, 0x11, 0x01, 0x03};
bool idconf = false;
bool inverted = true;

Example 2:

/mnt/ntfs/Data/Data/Programming/Python/HF225-Keypad/Arduino/HF225-Interface/HF225-Interface.ino:11:18: warning: ISO C++ forbids converting a string constant to 'char*' [-Wwrite-strings]
 char * version = "ArKEYP1 v0.01.11";
                  ^~~~~~~~~~~~~~~~~~
/mnt/ntfs/Data/Data/Programming/Python/HF225-Keypad/Arduino/HF225-Interface/HF225-Interface.ino: In function 'void decode(char*)':
/mnt/ntfs/Data/Data/Programming/Python/HF225-Keypad/Arduino/HF225-Interface/HF225-Interface.ino:93:12: warning: variable 'keyw' set but not used [-Wunused-but-set-variable]
     char * keyw;
            ^~~~
/mnt/ntfs/Data/Data/Programming/Python/HF225-Keypad/Arduino/HF225-Interface/HF225-Interface.ino: In function 'void loop()':
/mnt/ntfs/Data/Data/Programming/Python/HF225-Keypad/Arduino/HF225-Interface/HF225-Interface.ino:176:8: warning: unused variable 'c' [-Wunused-variable]
   char c;
        ^
Sketch uses 4994 bytes (17%) of program storage space. Maximum is 28672 bytes.
Global variables use 285 bytes (11%) of dynamic memory, leaving 2275 bytes for local variables. Maximum is 2560 bytes.

It isn't a big deal, but neither of these is appropriate. bash is only appropriate for code written in the Bash language. Likewise, shell is only appropriate for code written in the POSIX shell language.

For compiler logs, or even the content of Bash or shell terminal sessions, it is most appropriate to use plaintext (or when writing Markdown, you can use its shorter alias text for convenience). This will disable syntax highlighting entirely.

The reason a programming language identifier is not appropriate for this type of content is that this will cause random parts of the content that happen to resemble Bash or shell code to be highlighted arbitrarily. That certainly isn't the end of the world, but it also doesn't do any good and might be slightly confusing to some readers.

Ah, fair enough. I thought since the output would essentially have been generated in the Bash shell environment…. Completely missed that plaintext option (although there’s a certain gentleman that argues that there is no such thing as plaintext!), but yes, makes sense for those options to be used for a bash or shell scripting language. Was looking for logs or something like that and that seemed the closest. That’s another thing I just learned! :+1:

Noted for future reference.

Just for fun:

https://www.youtube.com/watch?v=hI-eAg3hlcM

You will never look at plaintext the same way again!

I take your point, but if there are options that behave differently then there is always going to be confusion because of the need to explain them, probably to an already confused user. KISS should be the rule

Is there an option in the Discourse setup that forces the reply editor to always start in WYSIWYG mode even if the user has previously switched to Markdown when editing their previous reply ?

If so, it would allow users fluent in Markdown to work with it directly if they want to , although I suspect that such users are few and far between

Approachability to new users is important, but we should also allow advanced users to do advanced things.

No, and I would never enable such an option if it did exist. If someone selects the Markdown editor, it is because they want to use the Markdown editor. Remembering which of the modes the user wants to use is the correct behavior.

The entire forum community has been exposed to Markdown in every post they write for over four years. GitHub users are exposed to it in every issue and pull request message they write. Markdown is a very simple language. Surely most technically minded people who have been exposed to the language regularly over the course of years will have gained fluency even if they never made any effort at learning the language formally.

I would expect that quite a few of those users would have naturally started doing a significant amount of working with Markdown directly while writing posts.

I'm not "quite a few" but part of them :wink:

I've used the buttons in the composer once to figure out what the Markdown looks like. After that I only use them when I'm lazy; most of the time I just type the Markdown.

It's was the same when this forum used BB code.

My suggested option would allow that whilst allowing new users to use the WYSIWYG editor as the default

Except when they change modes by mistake, of course, and we know that happens. I am willing to bet that the majority of users did not know that the option had been introduced

Being exposed to Markdown does not mean that most users actually use it. Most posts do not use any formatting or special layout commands and we all know how many times new users don’t use code tags

But most users don’t

Your use of Markdown is exemplary and helps clarify questions that you are asking and answers that you are giving but in practice most users just want to enter text and don’t see the need to make it look fancy

Maybe there is a task for Discourse. They should announce any changes to their framework that effects this forum using a post in Website and Forum. I do not know if @pert is aware of every new roll out of updates but we as forum users certainly are not.

I often hate it when I see changes without them being announced. Wysiwyg, font changes, changes in the style of code blocks and probably more.

Further, one of the problems for forum users (here) is that they never know if it was a change introduced by Discourse or by the administrator of the forum.