Cutoff for Exercisename about rtutor HOT 3 OPEN

This code concerns the automatic generation of chunk names. I don't want to have chunk names that are too long, because they are shown in a Markdown version of the problem set and also are used to name all HTML identifiers (perhaps performance goes down a bit, if all IDs are super long). I changed RTutor just now in a different fashion. Chunks are now just named with the exercise counter as a prefix instead of the 20 first characters of the exercise name. Makes more sense and the IDs are even shorter now. You also should not have any problems with your exercise names anymore.

from rtutor.

I integrated your changes and all technical aspects work fine.

I am however worried about maintainability down the line and effects on the transparency of the submission files if the course is actively in development. (Which by the way is broadly our plan: To have constant and continuous improvement on all courses to achieve maximum quality and keeping them up-to-date)

Take for example a course (or course chapter) where there exist several exercises. One of the exercises shall be expanded. This in turn makes it to long for easy digestion. It is split up in two parts. As a result all later chunks get renamed. Even though no change took place in the later exercises they can't trivially be matched across problem set versions, making it harder to analyze the submission files of a course.

Especially regarding the submission files it might be helpful to include (possibly optional) additional indicators to the chunks/Exercises (be it in sub$by.chunk, sub$by.ex and/or in sub$log.txt). One could for example include the name of the Exercise as an additional column to the data frames. I think this would be a comparatively cheap but powerful change.
Ideally one could additionally set optional names to chunks which are persistent and not subject to changes of the exercise name and earlier chunks. This would make it more time-consuming to build the problem set but a lot easier to have say graphical and in depth analyses even for problem sets which change very dynamically.

from rtutor.

I don't see that this is problematic. If you have different versions of your problem set (and continuous improvement is definitely a good idea) then you should also keep for every version the corresponding rps file and the Rmd solution file. Using the rps file you can always match the chunks to the corresponding exercises. I think that at some functions of RTutorSAGI for analysing the solutions require anyway that you provide the corresponding rps file.

from rtutor.