git add -p toolview

[Milian Wolff]

On Donnerstag, 30. April 2020 14:51:27 CEST Jonathan Verner wrote:
> Hi,

Hey!

> I've been working on a toolview to stage and commit changes to git.
> The motivation for this follows below. I am now in a stage where the
> toolview is already useful and would be happy for some feedback. I've
> created a merge request on invent.kde.org:
> 
> https://invent.kde.org/kde/kdevelop/-/merge_requests/128
> 
> (or do I need to create a review request on Phabricator?).

Gitlab is fine. And thanks for your contribution! The screenshots look very 
promising already. I know that quite a few people have asked for this. I'm a 
heavy user of `git add -p` on the command line myself too.

> Currently I
> included the full history, so that the merge request has quite a few
> commits. I am not sure if this is prefered or whether I should rewrite
> the history squashing the commits to reduce this number.

Do what fits you best, but once we merge I'd like to keep a clean history. 
I.e. try to create separate individual commits that make up an atomic change, 
while being as small as possible. Below e.g. you are mentioning changes to 
some of the existing libraries - these could be done in separate patches then 
e.g. to one bigger patch that introduces the new toolview itself.

<snip>

> Questions
> 
> ---------------
> 
> 
> - Is there a way to get to the results of the semantic highlighting
> (ideally in the form of a list of attributes for given source lines)?
> I didn't find out how to copy semantic highlighting over to the diff;
> right now I open the source document, create a moving range and use it
> to access line attributes which I then copy over to the the diff;
> however, this only gives me basic syntax highlighting (even if the
> source document is already fully semantically highlighted...).

Hmm good question! This is all handled in CodeHighlighting (kdevplatform/
language/highlighting/codehighlighting.cpp) which hasn't been touched in years 
and could quite probably use some cleanup.

But potentially you would be better of with creating two temporary files for 
the A/B version. Then we'd need to find a way to reliably create a parse job 
for those using whatever language that is used for the source file, and then 
ensure the same compile flags etc. pp. are also used.

This would ensure that both versions get highlighted properly. Otherwise you'd 
only ever have one correct highlighted version (the newer one, B), or?

Cheers

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20200430/fbe845b9/attachment.sig>