[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: Review Request 115544: improve highlighting of reStructuredText
From: "Stephen Kelly" <steveire () gmail ! com>
Date: 2014-02-18 15:39:19
Message-ID: 20140218153919.9975.99479 () probe ! kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Feb. 17, 2014, 9:12 p.m., Milian Wolff wrote:
> > looks good - esp. if you tested it extensively. Please add your example file to \
> > examples/syntax/highlight.rst or whatever the file extension for restructured \
> > text is.
>
> Matthew Woehlke wrote:
> Thanks...
>
> ...except (because I've mostly been looking at reST in KDevelop, which doesn't get \
> restarted as often) I just found a small bug in the last commit :-). Will update \
> and add (and maybe also improve) the example (good suggestion; thanks) and re-post. \
> But will still plan on merging as above, since the fix is also quite small.
> (That said, I'd love to get at least a statement of non-objection :-) from skelly.)
>
> Stephen Kelly wrote:
> I object generally to your idea that rebasing of work-in-progress patches 'destroys \
> history' as you claimed before. I tried to ask you how that is true, but thanks to \
> reviewboard, you didn't get that message: http://i.imgur.com/bSjHFtW.png
> I still consider it very bad to deliberately add noise like that.
>
> I have no idea if your individual commits are 'sensible', 'self contained', \
> 'complete' and free of followup-fixups, so I can't non-object :).
> Matthew Woehlke wrote:
> (https://git.reviewboard.kde.org/r/114395/#comment33485?) That case was "special"; \
> if I'd rebased, it would have significantly altered my commit. While that's not the \
> case here, I obviously don't have the general objection to merge commits that you \
> apparently do. (Squashing, on the other hand...)
> FWIW, an advantage of merging is that the merge commit clearly indicates that a \
> *series* of patches is covered by a specific review request. For a single commit, I \
> tend to favor rebasing / cherry-picking (same thing really) in general (i.e. always \
> for KDE, and wouldn't mind doing it even in projects where merges are the norm).
> If you don't know if my "individual commits are 'sensible', 'self contained', \
> 'complete' and free of followup-fixups", why don't you look at them? I already told \
> you where the branch is (rest-hl-improvements on \
> kde:clones/kate/mwoehlke/kate.git). I do try to adhere to the above principles \
> (unlike some people that feel history should be immutable, with which I actually \
> disagree rather strongly) and I'm happy to refactor them if you see anything you'd \
> prefer be done differently.
> That case was "special"; if I'd rebased, it would have significantly altered my \
> commit.
That would have been a 'good thing'. The commit was out-of-date and in a \
work-in-progress state in a work-in-progress repo. You merged the noise of conflict \
resolution from being out-of-date to being up-to-date. That is not 'history', and \
cleaning it before submitting it to the primary kate repo is not 'destroying \
history'. It is creating 'good', 'useful', 'readable' history.
I don't have a problem with merge commits in general (but I also don't accept the \
claim that the 'grouping of a series' is valuable. Look at the commits just before \
yours. It's a group by me.), but they are 'not done' in KDE. There are very few \
merges in the kate repo, and they are all noisy. The kate developers seem to be fine \
with that kind of thing, but that doesn't make it good or a good idea.
- Stephen
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115544/#review50100
-----------------------------------------------------------
On Feb. 18, 2014, 12:17 a.m., Matthew Woehlke wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115544/
> -----------------------------------------------------------
>
> (Updated Feb. 18, 2014, 12:17 a.m.)
>
>
> Review request for Kate and Stephen Kelly.
>
>
> Repository: kate
>
>
> Description
> -------
>
> There are quite some improvements; see the git log for details.
>
> @skelly, I noticed you don't have a copyright/authorship line here... should you?
>
>
> Diffs
> -----
>
> .gitlog PRE-CREATION
> examples/syntax/highlight.rst PRE-CREATION
> part/syntax/data/rest.xml 76c476a7a1f0b774ccabf0f48a518b413b9e63e4
>
> Diff: https://git.reviewboard.kde.org/r/115544/diff/
>
>
> Testing
> -------
>
> Test Content
> ------------
>
> .. code-block:: c++
> // This is C++ code
> class Foo { int bar; };
>
> .. code-block:: python
> # This is Python code
> class Foo(object):
> def __init__(self):
> pass
>
> > This: ...is a field.
> > An *exciting* field: Isn't it, though?
> > A ``literal`` like this: ...is often used in e.g. CMake documentation.
>
> > This:
> ...is also a field.
>
> > >
> I hope I am code, and not a field!
>
> > role:`text` is not a field.
> Nor is :role:`text`. But `text`:role: should also be a role.
>
> This text [here] should not be special, but [this]_ is a footnote.
> This [isn't]_ a footnote; no special characters allowed!
>
> * Let's try some indented stuff...
> > >
> I should be code!
>
> And I should *not* be code!
> * Still a list.
>
> A literal ``example``::
> Working?
>
> This *is* a .. code-block::
> ...but ".. code-block" is normal text.
>
> .. This is a comment, which should highlight things like ALERT.
> This is still the comment.
>
> This is not the comment.
>
> .. Kate doesn't seem to recognize modelines in reST, though?
>
>
> Thanks,
>
> Matthew Woehlke
>
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/115544/">https://git.reviewboard.kde.org/r/115544/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On February 17th, 2014, 9:12 p.m. UTC, <b>Milian \
Wolff</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">looks good - esp. if you tested it extensively. Please add your example \
file to examples/syntax/highlight.rst or whatever the file extension for restructured \
text is.</pre> </blockquote>
<p>On February 17th, 2014, 11:35 p.m. UTC, <b>Matthew Woehlke</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Thanks...
...except (because I've mostly been looking at reST in KDevelop, which \
doesn't get restarted as often) I just found a small bug in the last commit :-). \
Will update and add (and maybe also improve) the example (good suggestion; thanks) \
and re-post. But will still plan on merging as above, since the fix is also quite \
small.
(That said, I'd love to get at least a statement of non-objection :-) from \
skelly.)</pre> </blockquote>
<p>On February 18th, 2014, 1:10 p.m. UTC, <b>Stephen Kelly</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I object generally to \
your idea that rebasing of work-in-progress patches 'destroys history' as you \
claimed before. I tried to ask you how that is true, but thanks to reviewboard, you \
didn't get that message: http://i.imgur.com/bSjHFtW.png
I still consider it very bad to deliberately add noise like that.
I have no idea if your individual commits are 'sensible', 'self \
contained', 'complete' and free of followup-fixups, so I can't \
non-object :).</pre> </blockquote>
<p>On February 18th, 2014, 3:29 p.m. UTC, <b>Matthew Woehlke</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">(https://git.reviewboard.kde.org/r/114395/#comment33485?) That case was \
"special"; if I'd rebased, it would have significantly altered my \
commit. While that's not the case here, I obviously don't have the general \
objection to merge commits that you apparently do. (Squashing, on the other hand...)
FWIW, an advantage of merging is that the merge commit clearly indicates that a \
*series* of patches is covered by a specific review request. For a single commit, I \
tend to favor rebasing / cherry-picking (same thing really) in general (i.e. always \
for KDE, and wouldn't mind doing it even in projects where merges are the norm).
If you don't know if my "individual commits are 'sensible', \
'self contained', 'complete' and free of followup-fixups", why \
don't you look at them? I already told you where the branch is \
(rest-hl-improvements on kde:clones/kate/mwoehlke/kate.git). I do try to adhere to \
the above principles (unlike some people that feel history should be immutable, with \
which I actually disagree rather strongly) and I'm happy to refactor them if you \
see anything you'd prefer be done differently.</pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">> That case was \
"special"; if I'd rebased, it would have significantly altered my \
commit.
That would have been a 'good thing'. The commit was out-of-date and in a \
work-in-progress state in a work-in-progress repo. You merged the noise of conflict \
resolution from being out-of-date to being up-to-date. That is not 'history', \
and cleaning it before submitting it to the primary kate repo is not 'destroying \
history'. It is creating 'good', 'useful', 'readable' \
history.
I don't have a problem with merge commits in general (but I also don't accept \
the claim that the 'grouping of a series' is valuable. Look at the commits \
just before yours. It's a group by me.), but they are 'not done' in KDE. \
There are very few merges in the kate repo, and they are all noisy. The kate \
developers seem to be fine with that kind of thing, but that doesn't make it good \
or a good idea.</pre> <br />
<p>- Stephen</p>
<br />
<p>On February 18th, 2014, 12:17 a.m. UTC, Matthew Woehlke wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for Kate and Stephen Kelly.</div>
<div>By Matthew Woehlke.</div>
<p style="color: grey;"><i>Updated Feb. 18, 2014, 12:17 a.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kate
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">There are quite some improvements; see the git log for details.
@skelly, I noticed you don't have a copyright/authorship line here... should \
you?</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Test Content
------------
.. code-block:: c++
// This is C++ code
class Foo { int bar; };
.. code-block:: python
# This is Python code
class Foo(object):
def __init__(self):
pass
> This: ...is a field.
> An *exciting* field: Isn't it, though?
> A ``literal`` like this: ...is often used in e.g. CMake documentation.
> This:
...is also a field.
> >
I hope I am code, and not a field!
> role:`text` is not a field.
Nor is :role:`text`. But `text`:role: should also be a role.
This text [here] should not be special, but [this]_ is a footnote.
This [isn't]_ a footnote; no special characters allowed!
* Let's try some indented stuff...
::
I should be code!
And I should *not* be code!
* Still a list.
A literal ``example``::
Working?
This *is* a .. code-block::
...but ".. code-block" is normal text.
.. This is a comment, which should highlight things like ALERT.
This is still the comment.
This is not the comment.
.. Kate doesn't seem to recognize modelines in reST, though?</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>.gitlog <span style="color: grey">(PRE-CREATION)</span></li>
<li>examples/syntax/highlight.rst <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>part/syntax/data/rest.xml <span style="color: \
grey">(76c476a7a1f0b774ccabf0f48a518b413b9e63e4)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/115544/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic