Activity for jfbu
-
jfbu modified a comment on ticket #492
For a real life example where tags would have helped see this Sphinx comment. There are no tags associated to releases prior to 0.10 (EDIT: I was wrong here sorry! I did not scroll enough output of git tag on my small screen) and one has to search manually for appropriate commit messages and then check them out. And for tags since 0.10, with the exception of 0.14, they are as reported seemingly annotating some "mirrored" history, which has the commits but with other SHAs and are not direct ancestors...
-
For a real life example where tags would have helped see this Sphinx comment. There are no tags associated to releases prior to 0.10 and one has to search manually for appropriate commit messages and then check them out. And for tags since 0.10, with the exception of 0.14, they are as reported seemingly annotating some "mirrored" history, which has the commits but with other SHAs and not direct ancestors of current master tip. For example revision 5862 has two associated commits: $ git checkout docutils-0.10...
-
For a real life example where tags would have helped see this Sphinx comment. There are no tags associated to releases prior to 0.10 and one has to search manually for appropriate commit messages and then check them out. And for tags since 0.10, with the exception of 0.14, they are as reported seemingly annotating some "mirrored" history, which has the commits but with other SHAs and not direct ancestors of current master tip. For example revision 5862 has two associated commits: $ git checkout docutils-0.10...
-
Sorry for one more, but I went too fast. No there is a difference between the git commit messages. The first one (the one tagged by docutils-0.21.-2) contains git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk/docutils@9649 929543f6-e4f2-0310-98a6-ba3bd3dd1d04 whereas the one in master branch (a direct ancestor to master tip) contains git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk@9649 929543f6-e4f2-0310-98a6-ba3bd3dd1d04 i.e. former has code/trunk/docutils@9649 and latter has co...
-
The parent of docutils-0.21.2 refers to the same revision as a more direct ancestor in master branch: docutils$ git log -1 docutils-0.21.2~ commit b43eb031ecb2de7d2d1a5e4d160ebe15a0f9a7f0 Author: grubert <grubert@929543f6-e4f2-0310-98a6-ba3bd3dd1d04> Date: Tue Apr 23 18:54:26 2024 +0000 Version 0.21.2 git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk/docutils@9649 929543f6-e4f2-0310-98a6-ba3bd3dd1d04 $ git log -1 323957acb commit 323957acb17369d38bd31c81dfe543ae46ae9113 Author: grubert <grubert@929543f6-e4f2-0310-98a6-ba3bd3dd1d04>...
-
I git cloned again with https://repo.or.cz/docutils.git not git protocol and got (as expected) the same result. Notice that ab29cf78ae24a9 is indeed the doctuils-0.21.2 tag but it is not the commit or one of the commits in recent history referring to 0.21.2 release. $ git log --oneline --grep 0.21.2 0353066fb Fix headers for release 0.21.2 f344d4daf releasing 0.21.2 323957acb Version 0.21.2 6729e38e3 version 0.21.2b.dev It is as if all docutils-... tags refer to some other branch, and the origin...
-
Hello, but docutils-0.21.2 is not resolving to f344d4daf but to ab29cf78ae24 docutils$ git log --oneline f344d4daf..HEAD | wc -l 201 docutils$ git log --oneline docutils-0.21.2..HEAD | wc -l 9344 ?? git log -1 f344d4daf commit f344d4dafcd68cc9c315a4700b5f0efb5dc2e9e7 Author: grubert <grubert@929543f6-e4f2-0310-98a6-ba3bd3dd1d04> Date: Tue Apr 23 19:10:06 2024 +0000 releasing 0.21.2 git-svn-id: http://svn.code.sf.net/p/docutils/code/trunk@9651 929543f6-e4f2-0310-98a6-ba3bd3dd1d04
-
Git repo lacking tags
-
LGTM. I used no lines whatsoever in a PR at Sphinx adding latex_table_style configuration to describe there the effect of 'borderless'.
-
[DOC] borderless option said to remove borders "around" table but removes every border
-
About translating "admonition": We look for an umbrella term for the specific admonitions (attention, caution , danger, error, hint, important, note, tip, warning) and similar block elements. quick (French) thoughts: annonce: it is very different from admonition but conveys the idea of an announcement, which in practice is what the Docutils admonitions do. encart: this is from press media, it designates in particular advertisements ("encart publicitaire") panneau: here I take inspiration from being...
-
Could you check, if the changes in [r9112] help to avoid the confusion? Yes, looks good to me (with nits ;-). I checked this as a diff from a git checkout of commit 3c8063b4b59 with its parent and noticed some inserted whitespace: diff --git a/docutils/docs/ref/doctree.txt b/docutils/docs/ref/doctree.txt index 14410a4ea..ab1342a1e 100644 --- a/docutils/docs/ref/doctree.txt +++ b/docutils/docs/ref/doctree.txt @@ -424,6 +424,9 @@ Details :Analogues: ``admonition`` has no direct analogues in common...
-
[DOC] generic "admonition" directive also listed as specific
-
Sorry for noise. I now did git pull --tags and indeed tags are fetched, with some messages seemingly indicating some tags were changed upstream. From git://repo.or.cz/docutils ! [rejected] docutils-0.10 -> docutils-0.10 (would clobber existing tag) ! [rejected] docutils-0.11 -> docutils-0.11 (would clobber existing tag) ! [rejected] docutils-0.12 -> docutils-0.12 (would clobber existing tag) ! [rejected] docutils-0.13.1 -> docutils-0.13.1 (would clobber existing tag) * [new tag] docutils-0.14 ->...
-
Release tags seemingly missing from git
-
I forgot to express my Thanks for the great software by the way, I have been using for years now everyday! And as the upgrading process keeps a copy of the old version in the Trash, I had 1.4.36 immediately uvailable and been using it since. Works perfectly fine on my (antiquated?) 10.9.5 Mac OS X.
-
I confirm the freezing behaviour with 1.4.37 I reported. Source file: \documentclass{article} \usepackage[paperheight=10cm]{geometry} \begin{document} A \clearpage B \clearpage D \end{document} Steps: compile (from Emacs) to pdf and view in Skim modify B into C, recompile. Skim prompts for reloading, go there, and OK (mine is in French) go to Emacs buffer window, modify C into B, recompile. Skim prompts for reloading, OK. go again to Emacs, modify B into C, recompile. Skim remains unresponsive. Do...
-
Just wanted to report I experienced that same problem on 10.9.5. (Mavericks): jumping back to first page on auto-viewing a change. However I have seen further problems where the Skim view will not at all update and respond to changes in the pdf file. I will wait to see if the fix of the issue here also fixes that other behaviour I observed with 1.4.37 (I never had such problem with 1.4.36).
-
It does indeed; I was worried that perhaps my XeTeX from TL2018 might not have had the fix to #146 but as I could not reproduce at my locale the #146 issue, I opened this ticket.
-
Sorry about my not so good title, the exact situation is expected: buffer code: #xF0 #x9D #x92 #x9E file code: #xF0 #x9D #x92 #x9E (encoded by coding system utf-8-unix) seen: buffer code: #xED #x92 #x9E file code: #xED #x92 #x9E (encoded by coding system utf-8-unix) so "losing a byte" is not correct description.
-
higher UTF-8 character loses a byte if involved in a TeX error log
-
"unexpected indent" warning does note cite most recent mark-up construct
-
s/textwidth/linewidth/g in caret4.rst (again ...)
-
Hi Günter, can you try out this attachment. I have not done more testing but it might be ok solution.
-
caret2.rst contains some mysterious \vbox{} but this was only to reinstore some vertical space due to the quote environment being in a minipage. In general there is no reason a quote environment is last thing in the admonition, hence my method is no good for that. I have deadlines currently so I can not research that more in the immediate future (in Sphinx we use framed package not an unbreakable minipage, but this requires a lot of tuning up and I briefly tried here but could not immediately get...
-
I should have used \linewidth, not \textwidth. But I don't know to what extends admonitions are nestable in quoted environments (lists) with rst2latex.py ...
-
Can you try with attached file
-
literal block with caret symbol inside an admonition causes failed PDF build from latex
-
I had only tested with 0.14 indeed. So the issue was already solved by https://sourceforge.net/p/docutils/code/8190/, and I confirm it works for me too. I have a question: I git cloned docutils, but pip install . takes quite some time (so much so that I would not go into git bisect), and pip install -e . did not work for me. How can I install Docutils in a virtualenv and test various checkouts of the commit history?
-
I had only tested with 0.14 indeed. So the issue was already solved by https://sourceforge.net/p/docutils/code/8190/, and I confirm it works for me too. I have a question: I git cloned docutils, but pip install . takes quite some time (so much so that I would not got into git bisect), and pip install -e . did not work for me. How can I install Docutils in a virtualenv and test various checkouts of the commit history?
-
another case of smartquotes failing to distinguish open and close quote
-
ah, ok, docs is here and it says Punctuation at the end of a URI is not considered part of the URI, unless the URI is terminated by a closing angle bracket (">"). Backslashes may be used in URIs to escape markup characters, specifically asterisks ("*") and underscores ("_") which are vaid URI characters but it is not clear to me if that says that escaping is necessary if URI contains a non-letter after the underscore (as is possibly the case as reported here).
-
added note: This link_ refers to a site whose URL uses an underscore. .. _link: http://example.com/a_-b does work ok, hence docs is fine for this "linkblock". But when handling Sphinx issue I did not find immediately docs for "inline" URI, not inside a linkblock.
-
In conclusion, it seems better for smartquotes to default to off for Japanese language. If discussion confirms this (and Docutils has smartquotes off per default anyhow for all languages), I am quite willing to make PR at Sphinx to turn off smartquotes in case of Japanese language, (except if overridden by user).
-
... but of course these \" actually mean " in the defined strings. Sorry, I was busy with other things and acted mechanically when trying to reduce the problem to some small testable example. In brief, the \" are my fault there, but as you pointed out they are not relevant ;-)
-
Regarding (1) Why are you using backslash-escapes before the quotation marks? Removing them produces exactly the same output. IOW, the backslashes are useless there. the reason is that this comes from translation strings in a .po file. They use " as string delimiter, hence the \" inside (see the link at top of OP, in commented-out line). When I tried out the issue at Sphinx I left the backslashes to stick to original.
-
Space trimming from substitution happens at wrong location
1