Is it possible to get a list of all “wiki” posts? I found the other one I know (Undocumented internal macros in TeXmacs (wiki)) searching for “wiki”, but I think I found it only because it has the word “wiki” in the title.
[wiki] Assorted code snippets to customize TeXmacs' behaviour
I’ve added a “wiki” tag which can be used to signal wiki posts. I’m not sure if there is a better way to do it. Categories are mutually exclusive so if we have a “wiki” category we loose the original category of the post.
The Search function has an option to search for wiki’s as well. You can go to Advanced Search, or just enter in:wiki
in the search box. I get only two hits.
Perhaps a table of contents would be useful for this wiki post: https://meta.discourse.org/t/discotoc-automatic-table-of-contents/111143 shows one, maybe administrators can enable it? If a TOC is enabled for all posts, it could be annoying, reading the link I see that one can choose whether to enable it for each post (with default “off” I hope ).
Using this on Windows I get a “Could not concretize tuple” error. If you want I can copy by hand the whole message (I do not see how to copy it with a command).
Sorry, I can’t debug it here, as I can’t reproduce the problem.
Maybe you could test by evaluating (propose-pdf-name)
in a Scheme session. You could also try putting some display*
statements in export-to-proposed-pdf
or commenting out parts to see what goes wrong.
(propose-pdf-name)
gives the path of the file starting with a slash (e.g. /C/Users/ ...
)
The form that fails is (url-test? pdf-name "f")
with “Could not concretize tuple” and a nested tuple
construct which starts with (concat, C, tuple (concat, Users, tuple (concat, ...
.
I will investigate more tomorrow.
BTW thanks for the correction on how to enter the Meta key.
On Windows it is not possible to check the values of forms with either display
or display*
(btw what does the asterisk do?), but it will be possible to look at the value that each form takes by letting it be the output of the computation.
I investigated a bit. My impression (I have not figured out what the code does line by line) is that there is an error of the PDFHummus converter (the error message with which the snippet stops is failed to start PDF
), which may be due to the fact that concretize (pdf_file_name)
does not work with the value given by (propose-pdf-name)
.
I will investigate more, I will look at why (url-test? pdf-name "f")
causes “Could not concretize tuple”.
The url should be usually converted to string to refer to actual files in the filesystem. Normally one would use url-system
or url-concretize
to do the job. Maybe check some related scheme code to see what is the usual way to do this.
As far as I understood
the snippet works in the OS that @jeroen is using (I do not know whether that is MacOS or Linux), this means that the Scheme code is ok and in Windows something “internal” does not work well.
@pireddag Could you please try this?
(define (propose-pdf-name)
(with name (propose-name-buffer)
(if (string-ends? name ".tm")
(url->system (string-append (string-drop-right name 3) ".pdf")))))
(define (export-to-proposed-pdf)
(let ((pdf-name (propose-pdf-name)))
(if (url-test? pdf-name "f")
(user-confirm "File already exists. Really overwrite?" #f
(lambda (answ)
(when answ (wrapped-print-to-file pdf-name))))
(wrapped-print-to-file pdf-name))))
(kbd-map
("M-e p" (export-to-proposed-pdf)))
Now we get the file path with Windows-style separators:"C\\Users ...
I have seen that to make url-test?
work we need a colon after the drive letter. Then there is no “Could not concretize tuple”
error, it returns #t
if the file exists and the export works.
Ok, I am finally convinced that I have to do this
What convinced me is that url->system
would turn (current-buffer)
into a file path, while (propose-name-buffer)
uses url->unix
which removes the colon after the drive letter.
This post disappeared from the “top screen” of the forum and from my awareness as well.
Is there a way to keep it visible? I think it is essential that it be visible in order for people to be encouraged to contribute to it and to use the snippets.
Now this post is pinned globally, but, unlike Tell us the most impressive features of GNU TeXmacs!, it does not stay on top of the posts’ list.
Edit - now Tell us the most impressive features of GNU TeXmacs! is unpinned too. It might be that one needs to " Un-check ‘automatically unpin topics’ and ‘default topics automatic unpin’ in ‘Settings’ menu(admin authority required).", like https://meta.discourse.org/t/pinned-post-doesnt-show-as-lastest-when-log-in/125102 says, but I don’t have access to that setting.
Unless we don’t want these threads to be pinned at the top of the forum webpage, but I think we do.
I agree with you. If they can’t stay pinned to the top we should at least have a category called wikis
The category is there:
I don’t think that it is enough though: IMHO the posts gradually disappear from the awareness of forum users if they are not on top. Another possibility would be to create a side-bar with key posts.
I realized that we have a wiki tag but not a wiki category. But perhaps the tag is better, because in this way posts in different categories can be wiki posts.