bugGNU nano - Bugs: bug #55054, [Request] make it possible to...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #55054: [Request] make it possible to justify a marked region

Submitter:  Benno Schulenberg <bens>
Submitted:  Mon 19 Nov 2018 10:05:08 AM UTC
   
 
Severity:  1 - Wish Status:  Fixed
Assigned to:  dolorous Open/Closed:  Closed

Jump to the original submission

Mon 25 Mar 2019 01:18:38 PM UTC, comment #58: 

Released in 4.0.

Benno Schulenberg <bens>
Group administrator
Sun 10 Mar 2019 08:33:48 AM UTC, comment #57: 

Fixed in git, commit f7f5514e plus the subsequent three.

Benno Schulenberg <bens>
Group administrator
Wed 06 Mar 2019 06:36:51 PM UTC, comment #56: 

When code isn't in master, I can't find the time to look at it, not when it's more than a single, short patch.  :|  So...  I will merge your patch set as-is, with just some tweaks to the commit messages.  I still don't agree entirely with the way it works, but once it is in master, I will look at it now and then, and can start to modify it (if I think I can improve it).  I want to merge it now (soon, when I find the time) because it makes a good dot zero feature, it doesn't need to be perfect, and because I find it silly and confusing that nano just ignores a marked region when ^J is pressed and acts as if the mark hadn't been set at all.

Benno Schulenberg <bens>
Group administrator
Wed 27 Feb 2019 07:55:47 PM UTC, comment #55: 

Attached new version 5g.  Commit 1053a3c broke 5f, so this new version is resynced with current git (de47b58).

(file #46367)

David Lawrence Ramsey <dolorous>
Group Member
Wed 09 Jan 2019 12:09:51 AM UTC, comment #54: 

Fine.  I've refactored it to break it into separate pieces.  It's now version 5f, still against git 0ae80ce.

(I was also able to add one minor cleanup to it; patch 0001 in this set could probably be applied separately.)

(file #45908)

David Lawrence Ramsey <dolorous>
Group Member
Tue 08 Jan 2019 07:08:07 PM UTC, comment #53: 

Well, as I've mentioned before, I find your prose hard to follow too.  And often it is so prolific, that I don't have the energy to read and digest it all.

Anyway, what I would have liked to see is that the "reparagraphing code" had been built up step by step, patch by patch.  But you have pressed the entire functionality into a single patch.  I would have preferred to see first a simple version, that cannot handle quoting (treating it as "words", as Pico does) and maybe only two sizes of indentation -- any limitation is fine as long as it keeps the code short and simple.  After that refinements could have been built in, each by a separate patch.  This would have made things much easier to comprehend for me.

Benno Schulenberg <bens>
Group administrator
Tue 08 Jan 2019 02:38:23 AM UTC, comment #52: 

Attached new version 5e, still against git 0ae80ce. The only change from the last version is a tweak to the check for prepending part of a lead in patch 0003; needed_top_extra is set to zero when it's not used, so the check for it is simpler, and it better matches the check for needed_bot_extra.

(file #45900)

David Lawrence Ramsey <dolorous>
Group Member
Tue 08 Jan 2019 02:01:46 AM UTC, comment #51: 

Argh.  Attached proper version of 5d.

(file #45899)

David Lawrence Ramsey <dolorous>
Group Member
Tue 08 Jan 2019 01:57:05 AM UTC, comment #50: 

Attached version 5d, still against git 0ae80ce.  The only changes from the last version are a more accurate commit message and some improved line wrapping, both in patch 0003.

(file #45898)

David Lawrence Ramsey <dolorous>
Group Member
Tue 08 Jan 2019 01:05:37 AM UTC, comment #49: 

Okay; I'd forgotten the reference in comment #8.  In any case, it's not applicable anymore, because the problems caused in 5b by doing that are not easily fixable.

If the indentation of the first line of the paragraph differs from the indentation first line of the selection, and the mark doesn't cover all of it, patching the indentation of the latter requires modifying the text outside of the mark, which means that the undo operation is three steps instead of two (cut + paste), which means that COUPLE_BEGIN/END no longer works properly.

Moving the mark to cover the beginning of the line makes the undo code malfunction somewhere (I can't figure out where), so that undoing the justify can put lines in the wrong place.  Trying to do the adjustment entirely in the cutbuffer to avoid these problems is infeasible, because what appears to be a partial indent in the selection may not be so if you look at the text outside the selection, which we can't do when it's in the cutbuffer.

In short, something that sets the text up properly but breaks undo is not desirable, and the amount of work required to fix the latter seems to be nontrivial.  So I've dropped it for now; it at least matches Pico, and a bit of odd indentation is a small price to pay at this point.

As for what you said versus implied, you are not communicating clearly here at least some of the time, and the point I keep trying to make is that ripping out code to simplify things isn't as simple as you seem to think it is when you want things to work a certain way and their working that way depends on the code you want ripped out.

Anyway, I've attached version 5c, synced against git 0ae80ce.  The only changes relative to the last version are in patch 0003.  Specifically, the indentation of the first selected line is used again (because of the aforementioned problems with the other approach), and bot_x is now compensated for when it's in the middle of a lead.  The latter was simple enough, but it required adding a needed_extra variable for the bottom line (needed_extra is renamed to needed_top_extra, and the new variable needed_bot_extra is used for this case), and your description of it as the text moving was difficult to follow until I figured it out.

(file #45897)

David Lawrence Ramsey <dolorous>
Group Member
Sun 06 Jan 2019 04:12:10 PM UTC, comment #48: 

Christ!  I didn't say that your patch set compensates bot_x when it is in the middle of a lead.  I was implying that it should.

For example, run 'src/nano +11,3 README' and type ^6 ^N ^N ^N.  Both the mark and the cursor are now two spaces away from the left edge and two spaces away from the text.  Press ^J.  The mark is still where it was: in the middle of the lead.  But the cursor has moved two spaces to the right, and has indented the subsequent text by two extra spaces.  Both effects are undesirable.  Because: if the cursor had been at the left edge, the text would not have moved; and if the cursor had been on the first letter of the text, the text would not have moved.  So, for me, the most logical thing to do is to never move the text when the cursor is somewhere in the lead.  (Except of course when what follows below applies.)

The idea that the first line of a newly created should have the same (possible deviant) lead as the first line of the original paragraph, I did mention before: in the third paragraph of comment #8.

Your patch set now correctly does this when the selection starts somewhere in the middle of a line, but not when the selection starts somehere in the lead or in the first letters of the text.  For example, give "First and foremost" two extra spaces of indentation, then start the selection at the "r" or "e" or "d" of "redistribution", select a few lines downward, and press ^J.  The line where the selection started is not made into a new, first line of a new paragraph.  Only when you start the selection at the "i" or later, is the text correctly moved to a new line and indented the same way as "First and foremost...".

Benno Schulenberg <bens>
Group administrator
Wed 02 Jan 2019 08:45:16 PM UTC, comment #47: 


> But first, let me clarify that the current patch set does not yet do
> what I would like. To show what I mean, open the README file, give the
> line that starts with "First and foremost" two extra spaces of indent,
> then select the text from "Because" to "Yuck." and press ^J. What I
> would like to see is that, in the newly created paragraph, the line
> that starts with "Because" has six spaces of indentation (copied from
> the preceding paragraph) and the rest of its lines four spaces (the
> indent that these lines already had). In this way truely a new
> paragraph is created that will not disappear when you press ^J again
> in this piece of text.


That's a good idea: intuitive, even if it doesn't match Pico exactly.  (Why didn't you mention this long before now?)  I've attached a new version 5b (resynced against git eef6b2b4), that adds this functionality to patch 0003, and refactors related bits so that there's only one new line of code added relative to the last version of patch 0003.  It also readds the indentation/bracket fixes in patch 0004, so everything's in one place again.

As for the rest...

> Also, when the user has started or ended a selection in the middle of
> a lead, then, instead of laboriously compensating the cut out
> selection for this "aberrant" selection, let's just move top_x to zero
> when it's in the middle of a lead, and move bot_x to zero when it's in
> the middle of a lead.


When bot_x is in the middle of a lead, nano doesn't compensate for anything.  (A few earlier versions of the patch set did compensate for bot_x, until I figured out that it wasn't necessary.)  You renamed the one variable involved in middle-of-the-lead adjustments to needed_extra in your version, and my version keeps that.  When renaming that variable, didn't you see for yourself that it's only used when adjusting top_x, and it doesn't affect bot_x at all?

Besides, the two blocks of code involving needed_extra handle all cases where the mark begins past the beginning of the line: both when the mark begins in the middle of the lead, and when it begins after the lead.  Simplifying them to only handle when the mark begins after the lead will not reduce the number of lines of code needed in the first block (since that will mean that needed_extra will always be initialized to lead_len, and simplifying things to the point of using lead_len directly will not reduce the number of lines, since indent_len still needs to be initialized in order to remove stray whitespace after the lead, which you said you expected), and will only reduce the number of lines of code in the second block by two (since it only shifts the string backwards by the number of characters in needed_extra; wrapping technically makes it three, but that doesn't affect the actual amount of code).  The code handling the case where the mark begins after the lead is necessary, because without it, the lead won't be accounted for at all when justifying a selection, and you said that was something you expected.

So, removing the functionality you say is unnecessary will save all of two lines.  Shifting top_x to zero when it's in the middle of a lead, as you suggest, will add two lines of code: one for the if statement comparing top_x and lead_len, and one for the actual shifting.  So if I do what you want, it will save a total of zero lines of code.

> Anyway, if you wish, you can restore the original position of the
> cursor and/or mark so that visually there is no big change, but please
> do it in a separate patch, so that it is clear how much code this
> costs.


And if I do this after the aforementioned changes, that will add more code, and you'll complain that it's "too much code", and we'll be doing this all over again.

With regard to the "second lead", you're changing your mind again, as well.  You said back in comment #20:

> Or... rather, when the first line of the paragraph is indented with an
> extra tab, this should not change the indentation of the second and
> subsequent lines of the paragraph: in this case it is four spaces and
> should stay four spaces.


...which is something that I figured out how to do in this patch set awhile ago.  If I remove second lead handling, the behavior here that you said you expected won't happen anymore.

If you want me to meet your requirements, give me requirements that make sense.

(file #45847)

David Lawrence Ramsey <dolorous>
Group Member
Tue 01 Jan 2019 07:38:15 PM UTC, comment #46: 

Ad comment #44: yes.  But my point: the whole thing takes too much code.  Things must be made simpler.

But first, let me clarify that the current patch set does not yet do what I would like.  To show what I mean, open the README file, give the line that starts with "First and foremost" two extra spaces of indent, then select the text from "Because" to "Yuck." and press ^J.  What I would like to see is that, in the newly created paragraph, the line that starts with "Because" has six spaces of indentation (copied from the preceding paragraph) and the rest of its lines four spaces (the indent that these lines already had).  In this way truely a new paragraph is created that will not disappear when you press ^J again in this piece of text.

But let's leave that for now.  In most texts written on the computer, blank lines separate paragraphs, and all lines have the same indentation.  So let's forget for now two different leads.

Also, when the user has started or ended a selection in the middle of a lead, then, instead of laboriously compensating the cut out selection for this "aberrant" selection, let's just move top_x to zero when it's in the middle of a lead, and move bot_x to zero when it's in the middle of a lead.  Personally I don't mind nano changing start and/or end point of the selection, because it shows what nano is actually doing (and how the user should ideally have made her selection).  Anyway, if you wish, you can restore the original position of the cursor and/or mark so that visually there is no big change, but please do it in a separate patch, so that it is clear how much code this costs.

Benno Schulenberg <bens>
Group administrator
Fri 28 Dec 2018 10:53:01 PM UTC, comment #45: 

Attached new version 5a.  It's resynced against git 0213f41, and all of its changes are in patch 0003: it shuffles things to make them a bit cleaner, and allocates memory a bit less often.

Specifically, the_lead is no longer allocated a blank string by default, since it should be set to that when necessary; needed_extra is no longer global to the do_justify() function, since the data it needs in order to be calculated shouldn't change before it's calculated; and the_second_lead is allocated only when necessary, and freed as soon as it's no longer needed.

(file #45764)

David Lawrence Ramsey <dolorous>
Group Member
Thu 27 Dec 2018 08:43:04 PM UTC, comment #44: 

I understand that.  My point was that there's no way to make those bits of code be entirely gone, at least not without breaking the current behavior in important ways.

David Lawrence Ramsey <dolorous>
Group Member
Thu 27 Dec 2018 08:39:55 PM UTC, comment #43: 

It wasn't a patch, it was a diff -- it was just to show what pieces of code I had expected to be gone.

Benno Schulenberg <bens>
Group administrator
Thu 27 Dec 2018 06:48:31 PM UTC, comment #42: 


> Hmm? Why is a second lead needed? The previous version of the patch
> gave all the lines of the paragraph the same lead; I expected this
> version to do the same, no extra features.


No.  The previous version of the patch gave all lines of the paragraph after the first line the lead of the second line of the paragraph, just as this one does, and as many versions before it did.

In the previous version, at the beginning of what your tweaked comments call the "uniformize the indentation" loop, note that sampleline is initialized to cutbuffer->next (the second line) before the uniformizing indentation is obtained from it.  If it were actually using the lead of the first line, it would be initialized to cutbuffer (the first line).

True, nano could be made to use the first line, but in the versions of the patch that did that (unintentionally), you've complained that justifying didn't behave the way you expected.  Not to mention, doing so would be less compatible with what Pico does.  For example:

1. In an 80x24 terminal, run:

./nano +25,1 README

2. Press Ctrl+^ to turn the mark on.

3. Press Down 7 times, so that all the extra-indented text is covered.

4. Press Ctrl+J.

The indentation of the first line ends up on the first line, and the indentation of the second line ends up on all lines after the first line.  This also mostly matches what Pico does: some double spaces are not turned into single spaces in Pico, but otherwise everything matches.  If nano is adjusted to use the same lead for everything, then this compatibility gets broken.

Also, the reason why the second lead has to copy the quoting of the first line as well as the indentation of the second line is so that it can do what you said you wanted it to do in comment #38.  If all quoting is stripped from lines (regardless of whether it matches the quoting of the first line), the quoting of the first line has to be added to the indentation of the second line in order to preserve any quoting + indentation at all past the first line.

> So I was hoping to see all the stuff in the attached diff gone.


The removed parts are the second lead bits (which I've covered above) and the handling of quoting and indentation covered partially by the mark (which I'll cover here).

Preserving the lead (quoting + indentation) of the top line of the selection is easy when the mark is at the beginning of the line (no change needed) or past the quoting (add the quoting to the beginning of the line).  When the mark is in the middle of the lead is when things get tricky, since the text has to begin with the full lead for justify to work properly.

The bits you want mostly removed are the ones that add the missing parts of the lead to ensure that the selection begins with it, and that remove the added parts afterward so that the text doesn't have the added parts in it after being justified.  True, I could remove those bits, but things wouldn't work the way you expect afterward, as your previous comments show.  For example, if the file consists of the two lines:

>>>this is
>>>a test


and you start the mark on the second ">" of the first line and cover the rest of the text with the mark, the unmarked text is:

>


and the marked text is:

>>this is
>>>a test


The "simplified" code you want blindly adds the full lead to the beginning of the first line while ignoring that part of it's already there, producing the (not-yet-justified) marked text:

>>>>>this is


This text has a lead of ">>>>>" instead of the ">>>" you'd expect.  So justifying the text will produce marked text of:

>>>>>this is a test


And the justified marked text, when pasted back into the file, will result in the complete text:

>>>>>>this is a test


when you actually want marked text of:

>>this is a test


and complete text of:

>>>this is a test


And that doesn't even account for the fact that your patch also gets rid of the routine that removes any stray whitespace covered by the mark after the lead.  For example:

1. In an 80x24 terminal, run:

./nano +9,10 README

2. Press Ctrl+^ to turn the mark on.

3. Press Down 1 time, so that a stray space after the lead is covered.

4. Press Ctrl+J.

The "simplified" code you want that doesn't remove the stray whitespace will just add it to the lead, so the lead will consist of 5 spaces instead of 4, which means that things won't work the way you expect, since the justified text will not have the same indentation of the text around it.

> (It doesn't work right, of course; I haven't thought it through; but
> it should look something like this.)


It definitely won't "work right" because you're removing parts that are necessary to make it behave the way you want, and you "haven't thought it through" because you want more and more sophisticated behavior using less and less code, which isn't half as easy as you seem to think it is.  Especially since you apparently keep changing your mind as to what you want.

Given some of your comments here, you don't seem to actually understand most of the code your patch changes.  It would be much more helpful if you did, and I would be willing to help you with that.

David Lawrence Ramsey <dolorous>
Group Member
Thu 27 Dec 2018 12:30:49 PM UTC, comment #41: 

Hmm?  Why is a second lead needed?  The previous version of the patch gave all the lines of the paragraph the same lead; I expected this version to do the same, no extra features.

So I was hoping to see all the stuff in the attached diff gone.  (It doesn't work right, of course; I haven't thought it through; but it should look something like this.)

(file #45746)

Benno Schulenberg <bens>
Group administrator
Wed 26 Dec 2018 09:35:57 PM UTC, comment #40: 

I've looked over your changes, and they still seem okay, aside from one comment wording error in git b1b2369: "Now actually break the current line, and go the next."  The last four words should be "go to the next."

Also, I've attached an attempt at your other approach, against git b1b2369.  First, find_paragraph() and justify_paragraph() now manually calculate the quote length instead of having it passed in, so that they can handle multiple quotes properly.  Second, justify_paragraph() is divided into three steps: concat_paragraph() wraps everything into one paragraph, removing the quoting of each line in the process; justify_format() is called on that single paragraph (it is unchanged); and rewrap_paragraph() is called  on the formatted single paragraph.  Note that rewrap_paragraph() needs the quoting of the first line and the indentation of the second line to tack onto the beginning of the rewrapped lines, so a justify of a marked region will save that separately now.

(file #45744)

David Lawrence Ramsey <dolorous>
Group Member
Wed 26 Dec 2018 06:48:30 PM UTC, comment #39: 

After a quick look, your changes seem okay; I'll have to test more to make sure, though.

As for the problem you think you found, it shouldn't happen.  The loop to "uniformize the quotation", as you put it, will guarantee that every line in the paragraph will contain the quoting string at its beginning and will thus be at least quote_len characters long.  The statement you note is in the loop to "uniformize the indentation", which takes place after that.  (Also, there's a typo in that comment in your version of the patch: "When there ar more than two lines".)

As for your proposed other approach, it sounds as though it could work; I'll look into it.

David Lawrence Ramsey <dolorous>
Group Member
Wed 26 Dec 2018 04:00:45 PM UTC, comment #38: 

I think I've found another problem.  To see what I mean, first get the attached version of your patch, with a few things renamed and reshuffled.  Then see this statement:

  size_t dent_len = indent_length(line->data + quote_len);

In strange cases, quote_len could be bigger that the actual length of line->data, which means that above statement would try to find an indentation in "uncharted territories", beyond the end of the string.  The same goes for sample_indent_len a few lines earlier.

But I've been thinking...  Instead of fixing that, how about a different approach?  Instead of first normalizing the amount of quotation and then the amount of indentation, how about:

First, split justify_paragraph() into two subfunctions: one that concatenates all lines of a paragraph into a single long lines, and a second that wraps this long line into a neatly formatted paragraph.  Then wrapping a marked region could be put together as follows: first determine and copy the leading part, then strip all lines from any quoting and any indentation that they have, then call the function that concatenates these lines into a single one, then prefix this single line with the leading part, and then call the function that wraps this single line into a formatted paragraph.  This saves a lot of complicated uniformizing of quoting and indentation (which the concatenating part of justify_paragraph() is going to strip again anyway), and it gets rid of spurious quoting characters in the rewrapped text when not all quoting in the selected region was the same.  What do you think?

(If you have time, please also check that the tweaks I made in master today do not contain any unintended mistake.)

(file #45742)

Benno Schulenberg <bens>
Group administrator
Wed 12 Dec 2018 11:38:27 PM UTC, comment #37: 

No problem.  Attached new version.

There were actually two problems in the old version, and the crash was only the first one:

1. When adding the quoting to the beginning of the line, the charmove() used the wrong byte count, which moved too much memory and corrupted the pointer.  Later, when adding the new indentation to the beginning of the line, the charealloc() accessed the corrupted pointer and caused the crash.  The former now uses the proper byte count.

2. When adding the new indentation to the beginning of the line, the code didn't compensate for the quoting, although removing the old indentation from the beginning of the line did.  This is fixed, so the quoting should be properly handled when adjusting indentation in all cases.

(file #45640)

David Lawrence Ramsey <dolorous>
Group Member
Wed 12 Dec 2018 06:19:22 PM UTC, comment #36: 

Thanks.

I've found a bug, though.  It happens when the selected text has quoting, and the last or the penultimate of the selected lines has one quoting character less than the others.

I could give a reproduction recipe including a regex replacement command, but it would be rather lengthy.  So, with the attached fragment, please run: src/nano +1 fragment, and type: M-A M-/ ^J.  Result: nano aborts.

(file #45637)

Benno Schulenberg <bens>
Group administrator
Tue 11 Dec 2018 12:39:11 PM UTC, comment #35: 

Okay.  Attached new version, resynced against git 38ca2a4.

(file #45629)

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Dec 2018 08:08:31 AM UTC, comment #34: 

Oops.  Forgot to push the tweak yesterday.  Sorry about that.

Benno Schulenberg <bens>
Group administrator
Tue 11 Dec 2018 12:41:07 AM UTC, comment #33: 

Argh.  The updated patch in comment #32 had whitespace errors, plus, after more thought, merging the cleanup patch might get confusing.

Attaching an updated version of your patch with the minimal changes to get it to apply and build, plus a new version of the cleanup patch on top of it.

(file #45620, file #45621)

David Lawrence Ramsey <dolorous>
Group Member
Mon 10 Dec 2018 09:16:54 PM UTC, comment #32: 

Unfortunately, it doesn't apply; it looks as though part of the cleanup patch got melded with it.  I'm attaching a fixed version (notably, with the cleanup patch melded into it).

As for the parts that start with "Adjust quoting" and "Adjust indentation", I thought the comments were enough.

The main problem is that a selection doesn't follow the same rules as all the other justified text, and modifying the text to follow those rules (in order to keep justify_paragraph() from treating quoting/indentation as text, which is bad; or treating the text following quoting/indentation as more quoting/indentation, which is worse because it deletes text erroneously) requires some work in order to behave the way you expect.

Blindly tacking the quoting/indentation onto the lines won't work properly for the lines that have proper quoting/indentation already.  The "Adjust quoting" section means that the code has to check the beginning of each line of the text to see if the quoting is there; if it isn't, the code adds the quoting there.  The same applies for indentation: the "Adjust indentation" section means that the code has to check the beginning of each line of the text (after the quoting. and starting on the second line since the first line's indentation can be different) to see if the proper indentation is there; if it isn't, the code adds the indentation there.

(file #45619)

David Lawrence Ramsey <dolorous>
Group Member
Mon 10 Dec 2018 07:40:23 PM UTC, comment #31: 

The patch works well.  But looking at it...  Oof!  Two hundred and twenty extra lines.  :(  It's a nice feature to have, but this is more than I expected.

And all this repetitious "orig_lead"... is confusing to me.  I like variables to have contrasting names.  So, I've renamed some things and reshuffled some other things.  See attached patch.  The parts that start with "Adjust quoting" and "Adjust indentation"I haven't touched yet, because I haven't yet understood them.

Oh, and the patch is rebased to master.

(file #45617)

Benno Schulenberg <bens>
Group administrator
Wed 05 Dec 2018 05:30:45 PM UTC, comment #30: 

Argh.  Attached version 4a, still against the same git version.

The only change relative to version 4 is that indentation spanning multiple lines of marked text is now handled properly again.  (The indentation adjustment was still using the leading part length instead of just the quote length, which was fixed everywhere else in version 4.)

The cleanup patch in comment #29 also still applies on top of it.

(file #45585)

David Lawrence Ramsey <dolorous>
Group Member
Tue 04 Dec 2018 08:12:11 PM UTC, comment #29: 

And regarding shift_held: its setting, plus the related screen updates, don't quite match some other text.c functions.

I think the reason edit_refresh() is called directly is a holdover from the old unjustify routine, so things could be adjusted to match.  I've done that in the attached experimental patch (on top of the patch set); does it work for you?

(I know this is a bit off-topic, but softmark handling is tied to screen updates in a sense, and I'm not sure where else to put it.)

(file #45580)

David Lawrence Ramsey <dolorous>
Group Member
Tue 04 Dec 2018 07:51:07 PM UTC, comment #28: 

Thank you.

However, I found two problems with it after more testing on my end:

1. The handling of the leading part of the text is muddled: the leading part contains both quoting and indentation, and the indentation adjustment should handle only the quoting part, but it erroneously handles all of it.

2. If the patch set can deal with extra indentation, it should be able to deal with extra quoting as well, and thus be better than Pico in that respect.

So, I'm attaching version 4, still against the same git version.  It should fix both of these issues, and also adds "shift_held = TRUE" (hopefully in the right place).

(file #45578)

David Lawrence Ramsey <dolorous>
Group Member
Tue 04 Dec 2018 06:37:20 PM UTC, comment #27: 

After a few quick tests, I don't see any surprising indentations or newlines any more.  Looking good!  Will test more, but that will take some days.

(One little thing that needs to be added: shift_held = TRUE at the end, so that a Shift-selection doesn't get canceled when the justification moves the cursor horizontally.)

Benno Schulenberg <bens>
Group administrator
Tue 04 Dec 2018 06:05:17 PM UTC, comment #26: 

Attached new version 3, still against git 55537dc.

The most important change is that, relative to the last version, the first patch is removed, since it was a kludge around the problem it was trying to solve (namely, that a line with more than two indentation types would make the justify code malfunction, and would make it delete text in some cases).  Instead, the indentation  of the selection is now manually altered so that it has only two types: that of the first line, and that of lines afterward (not counting an empty final line), just like what justify_paragraph() can handle.

This means that indentation can now be preserved more accurately when justifying a selection, and the problem mentioned in comment #23 doesn't occur then either.

(file #45577)

David Lawrence Ramsey <dolorous>
Group Member
Tue 04 Dec 2018 06:02:49 AM UTC, comment #25: 

One last update.  Attached new version 2c, still against git 55537dc. It hopefully clarifies a few comments, and properly handles one case where a newline shouldn't be added to the end of the mark (and which won't require looking outside the marked text): when the mark ends at the end of a line, no newline is added afterwards, since the line after the marked line will be the new line after the justified text is pasted back in.  Pico behaves this way as well.

(file #45576)

David Lawrence Ramsey <dolorous>
Group Member
Tue 04 Dec 2018 05:19:11 AM UTC, comment #24: 

Attached new version 2b, still against git 55537dc.  It simplifies the code, and also properly handles stray indentation when there is no quoting on a line, which previous versions didn't.

(file #45575)

David Lawrence Ramsey <dolorous>
Group Member
Tue 04 Dec 2018 03:38:39 AM UTC, comment #23: 

Also, I've found out more about why forcing justify to use the indentation of the first line when justifying a selection seems to be necessary.  There's yet another instance of the initial indent being treated as text otherwise.  If you apply my last patch set, and then comment out the force_initial_indent test at the beginning of justify_paragraph(), you'll see the problem.

To borrow from your second test, resize the terminal to 80x24, and...

Run 'src/nano --fill=-1 +9,5 README' and type: <Tab> <Shift+Down> <Shift+Down> <Ctrl+Shift+Right>. The cursor should now be on the "B" of "Because". Then press ^J.

Using the second line of indentation means that the indentation of the first line, for wrapping purposes, is calculated incorrectly: the first line has the four spaces + Tab indentation, but it ends with "does not use the GPL or ", on column 84, despite the fact that it should wrap earlier.

David Lawrence Ramsey <dolorous>
Group Member
Tue 04 Dec 2018 01:57:19 AM UTC, comment #22: 

And to be clear, trailing whitespace after the quoting + indentation is in the middle of the line, but is handled because it's immediately after the quoting + indentation; like quoting + indentation, its location is constant, as opposed to other whitespace in the middle of the line, which could effectively be anywhere.

David Lawrence Ramsey <dolorous>
Group Member
Tue 04 Dec 2018 01:49:58 AM UTC, comment #21: 

Attached a new version 2a, against git 55537dc.  It fixes a few off-by-one errors in the charmove() calls, and removes the unnecessary handling of indentation on the last line of the justified selection (only the first line is important).  Also, it should behave more like what you want, at least in one sense.  See below.

> I think nano should never create lines that consist only of trailing
> whitespace. I think that when on the line where the region starts
> there is only whitespace before the region, nano should not insert a
> newline. And when on the line where the region ends there is only
> whitespace (or EOL) after the region, again nano should not insert a
> newline. In other words: the end result should be the same as when the
> leading or trailing whitespace of the line had been included in the
> region.


The first of these should be in the new version, as long as the whitespace is after the quoting + indentation of the first line.  As in, any prepended part of the quoting + indentation is now removed after justification, since it's redundant.

The second of these is not.  It effectively changes text not covered by the mark, and text that is in an arbitrary location to boot (as opposed to the quoting + indentation, which can be accommodated because it's in a constant location, and which may indeed be all whitespace).  If you want whitespace after the paragraph removed, be sure to mark it, and then justifying will remove it; trying to do what you suggest will cause more problems than it solves.

> The line that starts with "Because" has gotten an (in my eyes)
> surprising indentation.


This is because of the way I had to fix the problem in comment #18.  It's a combination of the current justify code's inability to handle text with more than one quoting and/or more than two indentations, and, more importantly, how justifying a marked selection is supposed to treat that selection as one paragraph.  (More specifically, in order to match Pico or at least come close to it, justifying a marked selection is supposed to treat that selection as though it's one line that gets turned into a paragraph, regardless of whether it starts out as multiple lines.  Sorry for any confusion.)

The former means that text with more than two indentations will not be indented as you expect either (not shown in your case, but I've been testing it on my end).  The latter means that what you think of as the second line of the text is effectively part of the middle of the line, which means that things will have even more surprising indentation if I treat it otherwise.

As I mentioned in a previous comment, automatic quoting handling has to be disabled if the mark is on, so that lines with different quoting of a longer length don't end up with some of their text erroneously removed.  That also means that indentation handling is affected, since indentation can be part of quoting.

So, if I make justify_paragraph() use the indentation of the second line of marked text instead of the first in your case here, to try and give the paragraph the indentation you'd expect, the indentation of the first line will be passed through justify_format(), since it doesn't match the indentation of the second line and the quoting handling that would catch that case is disabled.  This will turn the tab on the first line into 4 spaces (assuming --tabsize=4), so the indentation of the first line will end up as five spaces(!) instead of a tab followed by four spaces, while the lines afterward will have an indentation of four spaces as you'd expect.  So this fixes one case, but breaks another.  Unless you want to rewrite the justify code as a whole to be more sophisticated...

Alternatively, it could match Pico more closely and keep the indentation of the first line, while dropping the indentation of all subsequent lines, but given what you've said before, I'm guessing you'd object to that.

> I think that any text that was not covered by the region should not
> have its indentation changed. I think it should be that way because
> now nano thinks that the line that starts with "Because" is part of
> the paragraph that starts with "First and foremost" -- which you can
> see when having started nano with for example --fill=121 and pressing
> ^J a second time after the above procedure.


The current behavior is consistent with what you said you wanted before: quoting + indentation at the beginning and end of the paragraph preserved on new lines before and after the marked text, even if that quoting + indentation isn't completely covered by the mark, and done as though the user had pressed <Enter> with autoindent on.  Under this logic, text not covered by the region has its indentation changed because any indentation it has is covered by the mark and therefore justified.

In this case, you've started the mark at "First and foremost".  This has no quoting + indentation itself, but the line itself has quoting + indentation of four spaces, which nano is smart enough to take into account.  You've also ended the mark at the spacing just before "Because", which means that the marked text ends in trailing whitespace, which justify_format() will remove.  The quoting + indentation of four spaces will be added after the end of the justified text (since the mark ends in the middle of the line), and "Because" will immediately follow that indentation because justifying a selection shouldn't affect text not covered by the mark.  If you don't want "Because"'s indentation changed, don't cover the two spaces before it with the mark.

> Or... rather, when the first line of the paragraph is indented with an
> extra tab, this should not change the indentation of the second and
> subsequent lines of the paragraph: in this case it is four spaces and
> should stay four spaces. (If the user wants to increase the
> indentation of the whole new paragraph, they can press <Tab> just
> before pressing ^J.)


The marked text is effectively treated as one line, so this can't be done, for the same reason that "Because" gets what you think is surprising indentation: text in the middle of the selection (after quoting + indentation) doesn't count for anything, except as something to be run through justify_format(), and trying to change that will require a massive amount of effort combined with trying to guess what the user is thinking, and the latter will likely be wrong a lot of the time.

(file #45574)

David Lawrence Ramsey <dolorous>
Group Member
Fri 30 Nov 2018 06:42:15 PM UTC, comment #20: 

Okay, the recipe from comment #15 now works as expected.  But two small issues remain.

One.  Sometimes an unexpected/unwanted newline is inserted.  For example, run 'src/nano +9,5 README', press <Ctrl+Shift+Down> and ^J and M-P.  See that nano has inserted an extra blank line before the paragraph, a line that conists only of indentation.  Exit from nano and run the same command again, and type <Ctrl+Shift+Down> <Shift+Left> <Shift+Left> ^J M-P.  See that nano now has inserted also an extra blank line after the paragraph, again consisting of only indentation.

I think nano should never create lines that consist only of trailing whitespace.  I think that when on the line where the region starts there is only whitespace before the region, nano should not insert a newline.  And when on the line where the region ends there is only whitespace (or EOL) after the region, again nano should not insert a newline.  In other words: the end result should be the same as when the leading or trailing whitespace of the line had been included in the region.

Two.  Run 'src/nano +9,5 README' and type: <Tab> <Shift+Down> <Shift+Down> <Ctrl+Shift+Right>.  The cursor should now be on the "B" of "Because".  Then press ^J.  The line that starts with "Because" has gotten an (in my eyes) surprising indentation.  I think that any text that was not covered by the region should not have its indentation changed.  I think it should be that way because now nano thinks that the line that starts with "Because" is part of the paragraph that starts with "First and foremost" -- which you can see when having started nano with for example --fill=121 and pressing ^J a second time after the above procedure.

Or... rather, when the first line of the paragraph is indented with an extra tab, this should not change the indentation of the second and subsequent lines of the paragraph: in this case it is four spaces and should stay four spaces.  (If the user wants to increase the indentation of the whole new paragraph, they can press <Tab> just before pressing ^J.)

Benno Schulenberg <bens>
Group administrator
Wed 28 Nov 2018 11:45:32 PM UTC, comment #19: 

Attached a new version, still against git 6bead05.  To avoid confusion, I'm now calling it version 2.

The only way I could figure out to fix the problem in comment #18 was to do the same thing with indentation that we do with quoting: when justifying marked text, use the first indentation found, and treat other ones as mere spacing (just as we use the first quoting string found, and treat other ones as mere characters).

Accordingly, when the mark is on, justify_paragraph() is now forced to use the first line as the sample line.  This means that, when a line has more than two indentations, it will always use the first one and ignore the others, which is at least better than changing text it shouldn't.

(file #45548)

David Lawrence Ramsey <dolorous>
Group Member
Wed 28 Nov 2018 10:23:33 PM UTC, comment #18: 

Note that, if the indentation is a mix of whitespace and tabs, this still doesn't behave properly in some circumstances when the mark ends in the middle of a line.

1. Run:

./nano +9,5 README

2. Press <Tab>, <Home>, <Shift+Down>, <Shift+Down>.

3. Press <Ctrl+J>.  This works as expected, and the initial indentation is preserved.

Now follow step 1 and step 2 again, press <Shift+Right> once, and then follow step 3.  The tab in the initial indent is incorrectly turned into a space.

David Lawrence Ramsey <dolorous>
Group Member
Wed 28 Nov 2018 10:14:13 PM UTC, comment #17: 

Attached a new version that should fix the aforementioned problem, still against the same git version.

The fix is similar to that of the quoting problem in comment #14.  justify_paragraph() can only handle two kinds of indentation: that of the first line, and that of subsequent lines.  It's recalculating the indent of every line after the sample line, and assuming that the indentation of the last line is the right one.  Marked text can have several types of quoting, and this makes justify_paragraph() incorrectly use the indentation of the last line of the selection (none), instead of the sample line's indentation (4 spaces).

The new first patch in the set corrects this by making justify_paragraph() directly use the sample line's indentation.

(file #45547)

David Lawrence Ramsey <dolorous>
Group Member
Wed 28 Nov 2018 09:18:28 PM UTC, comment #16: 

No problem.  I'll look into that last problem.

In the meantime, here's another update against the same git version that fixes different problems I found: marked text covering only one line is now properly checked for (doing so avoids unnecessary processing); and adjusted text on the top line is now properly null-terminated, just as adjusted text on the bottom line is (which  otherwise could occur on marked text covering only one line).

(file #45546)

David Lawrence Ramsey <dolorous>
Group Member
Wed 28 Nov 2018 06:54:50 PM UTC, comment #15: 

Thanks.  It now justifies correctly also when the end of the region is somewhere in the middle of a line.  But... there is one instance where it still goes wrong.  To reproduce, run:

  src/nano +11,22 README

Then type <Ctrl+Shift+Down>, to select text from "Because" until column one of the line that starts with "nano aims".  Then press ^J.  The indentation of the first line of the new pargraph is correct, but the indentation of the rest of the lines is zero.  Strange.

Benno Schulenberg <bens>
Group administrator
Wed 28 Nov 2018 02:29:19 AM UTC, comment #14: 

Attached updated version, still against git 6bead05.  It's been simplified to at least use fewer variables, although it still has a lot of code in common between the top_x section and the bot_x section.

One thing of note: it now always treats quoting characters other than those on the initial line as ordinary characters when justifying, as Pico does.  As for why this is needed, justifying can only handle one type of quoting.  Marked text can have several types of quoting, and this makes justify malfunction when a second type of quoting with a different length shows up: justifying will assume that all lines have the initial quoting, and will remove text at the beginning of lines corresponding to that same length.  If the new quoting has a different length, it will remove text that isn't part of the quoting.  (This is much worse than treating new quoting as ordinary text when justifying.)

(file #45543)

David Lawrence Ramsey <dolorous>
Group Member
Tue 27 Nov 2018 06:55:26 PM UTC, comment #13: 

When putting the mark in the middle of a paragraph and then moving the cursor down and to the start of some line, justifying the marked region works beautifully: it gets the expected indentation.

But when the end of the marked region is not at the start of a line, nano crashes.  To reproduce, run:

  src/nano +11,22 README

Then press <Shift+Down> to select one line (spread over two rows), then press ^J.  Result:

"Sorry! Nano crashed!  Code: 6.  Please report a bug."

Benno Schulenberg <bens>
Group administrator
Tue 27 Nov 2018 05:21:08 PM UTC, comment #12: 

Argh.  Yet another attempt attached, still against git 6bead05.  The only differences from the previous version are fixes for erroneous comments (wrt quoting, prepending is done to the top line, and appending is done to the bottom line), and a fix to make appending to the bottom line actually append.

(file #45538)

David Lawrence Ramsey <dolorous>
Group Member
Tue 27 Nov 2018 04:47:54 PM UTC, comment #11: 

Another attempt attached, also against git 6bead05.  The only difference from the last version is that it no longer does  unnecessary memory reallocation when there is no partial quoting + indentation on a line.

(file #45537)

David Lawrence Ramsey <dolorous>
Group Member
Mon 26 Nov 2018 11:04:57 PM UTC, comment #10: 

New attempt attached, resynced against git 6bead05.

I've looked more closely into how Pico does this, and this attempt should match Pico more closely.  Specifically, it only looks at the quoting + indentation at the start of the line, and ensures that only that is added to the lines of the resulting paragraph; any stray whitespace covered by the mark, at the top or the bottom, is ignored for purposes of indentation and removed.

However, as you brought up, Pico adds quoting + indentation to the new line before the justified text, but not the new line after it; this is still fixed, and a difference from Pico's behavior.

As for accounting for whitespace in the middle of the line where the mark begins, and treating it as indentation, I did try that, and it ended up being an overly complicated mess to work with.  The current attempt is more complex than the last one due to its adding of partial quoting + indentation and its shaving off mid-line whitespace, but it does seem to work so far in testing.  (And it's rather rough, and could probably be done somewhat more simply, but I'm focused right now on first getting something that actually works.)

(file #45535)

David Lawrence Ramsey <dolorous>
Group Member
Thu 22 Nov 2018 01:53:12 AM UTC, comment #9: 

The patch set 'doesn't change the result of the one before it' because you're trying to justify the same text you were before.  As I pointed out, if the mark doesn't cover certain text, justifying the selection won't affect it.  If you'd marked the two spaces before "Before" in your testing (in addition to the other text you were marking), you'd have found that the line after the selection would have had two spaces added, to match.

As for preserving the quoting and indentation of the line where the mark starts, and adding it to the newly justified text (as well as tacking it onto the quoting/indentation covered by the mark), I'll look into that.  I'm not in front of my development machine right now, but it sounds as though that won't be too much trouble to do, and doing it also makes much more sense than auto-correcting the mark position.

David Lawrence Ramsey <dolorous>
Group Member
Wed 21 Nov 2018 06:45:44 PM UTC, comment #8: 

Of course I do not want inter-sentence whitespace to be treated as indentation.  Including it in the region was just an idea: if it would result in the eating, removing, deleting the traling whitespace, it would have been a nice trick.  But if it doesn't work...  Fine.

However, I think that it should make no difference for the end result whether the user started the region at the first letter of a piece of text or somewhere in the the whitespace before it: the newly created paragraph should have the same indentation (for all of its lines) as the paragraph from which the first piece of text is taken.  But if selecting leading whitespace should make a difference, then it should result in extra whitespace for the first line of the new paragraph.

(Ideally, if the first line of the original paragraph has a different indentation than the rest of that paragraph, then the newly created paragraph should have the same different indentation for its first line.  But that is a refinement, and probably a big complication, and not to be considered for now.)

Your latest patch set does not change the result from the one before it: the words "Because" and "For" still sit at the left edge instead of being indented by four spaces.

Benno Schulenberg <bens>
Group administrator
Tue 20 Nov 2018 08:10:29 PM UTC, comment #7: 

I'm attaching a new version of the patch set that should do part of this.

Adding the indentation (and, by extension, quoting) of the paragraph to the tail of the paragraph in order to match the head  is a good idea.  The patch set now does this (by duplicating a bit of code from find_paragraph(), which isn't ideal, but refactoring it may produce even more code; it does at least work).

As for adjusting the mark automatically to cover the indentation of the first line, that's not done in this patch set because I'm completely opposed to that idea.

When I've used this function, it's been to specifically treat a block of text separately from the rest, which includes any quoting/indentation on the top line before the mark.  More importantly, when I mark something, I want only the marked text to be affected; having the mark adjust itself to cover text I didn't originally mark effectively overrides what I want done, plus it's extremely annoying in general to have a feature (usually incorrectly) guess what I want it to do.

In your example, if you want the indentation consisting of the two spaces before "Because" to be counted as indentation, you should cover them with the mark manually; the justify code will then see them as indentation, and you'll get the behavior you want.  Expecting nano to guess what you want and attempt to automatically mark text that you couldn't be bothered to mark is going to open up a huge can of worms in terms of usability.  Besides, if you mark the text incorrectly, now you can undo it and try again.

(file #45498)

David Lawrence Ramsey <dolorous>
Group Member
Tue 20 Nov 2018 06:52:09 PM UTC, comment #6: 

Well, inserting newlines does make the selected text into a separate paragraph.  But... it messes up the alignment of the text.  The main text in the README is indented by four spaces.  But after justifying the example region, the words "Because" and "For" start at the left of the screen, without any leading whitespace.  This is undesirable.  (If this were the behavior of a marked justification, the user would prefer to press <Enter> first so that autoindent would create the correct indentation.)

Also, the two spaces before "Because" remain at the end of the preceding line, even though I have trimblanks set.  This is a minor issue, but it would be nice if nano would not leave trailing whitespace when trimblanks is set.

I realize that this is something that is not easy to fix.  But maybe it is possible to add the detected indentation of the paragraph to the head and the tail of the cutbuffer (after it has been justified)?  And, in order to get rid of possible trailing space before the marked region, to move the top end of the region backward over any blanks before starting the justification?

Benno Schulenberg <bens>
Group administrator
Mon 19 Nov 2018 09:17:26 PM UTC, comment #5: 

I'm attaching a new patch set that should do this.  The only code changes are to patch 0001, to add newlines when necessary to the beginning and/or end of the text in the cutbuffer just before justifying it.

(Also, since you prefer Nano to be capitalized when at the beginning of a sentence, I've noticed one case in README where it isn't.  The paragraph starting at line 16 begins with: "nano aims to solve these problems".)

(file #45492)

David Lawrence Ramsey <dolorous>
Group Member
Mon 19 Nov 2018 07:43:46 PM UTC, comment #4: 

Hmm... no.  What would be most useful, in my opinion, is the behavior that Pico shows.  For example, run 'pico +11 README', then set the mark at the B of "Because", move the cursor nine lines down, to the F of "For".  Then press: ^J R.  The selected text gets reformatted into a separate paragraph -- separate from the one of which the last sentences were selected, and separate from the one of which the first sentences were selected.

One could argue that, if one wants to start a new paragraph at "Because", it is easy enough to press <Enter> before starting the selection.  But then one would have to do the same before "For".  But I am used to using Shift-selection, and pressing <Enter> would mean losing the selection.  Of course, one could press <Enter> after the justification, but...  If I just need to select the text and press ^J and nano would create a new paragraph for me, that would be convenient.  And the fact that the current patch removes the two spaces before "For" just seems wrong.

Anyway, what Pico does in this example is how I expect the justification of a marked region to work.  If I want complete lines to be justified, it is easy enough to select whole rows.

Benno Schulenberg <bens>
Group administrator
Mon 19 Nov 2018 06:41:08 PM UTC, comment #3: 

The main issue here is imitating Pico's behavior closely, but without the buggy elements, which gives us some leeway.

If I understand you correctly, the behavior you're expecting is more like that of mass indent/unindent: all lines covered by the mark (either fully or partially) get passed through justify_format(), instead of just the exact text covered by the mark?

David Lawrence Ramsey <dolorous>
Group Member
Mon 19 Nov 2018 10:27:19 AM UTC, comment #2: 

(Pico does this wrong too.  But does it right when the cursor is not fully at the end of the line.)

Benno Schulenberg <bens>
Group administrator
Mon 19 Nov 2018 10:22:56 AM UTC, comment #1: 

Attached is David's patch that adds the ability to justify a marked region, plus his two subsequent patches to clean things up.

The patch has a problem, though.  Run for example 'src/nano +1,99 NEWS', then type <Shift+Ctrl+Down> <Shift+Ctrl+Down> ^J.  See how it has added the second line and part of the third at the end of the first line.  It seems that it assumes that the point where the marked region starts is the left margin.

(file #45487, file #45488, file #45489)

Benno Schulenberg <bens>
Group administrator
Mon 19 Nov 2018 10:05:08 AM UTC, original submission:  

In modern Picos, when a region is marked and ^J is pressed, Pico asks what to do: Justify Region, Justify Paragraph, or Fix Quotelevel.  Nano should do something similar, but it should not ask any question: it should simply justify the selected region when the mark is on.

Benno Schulenberg <bens>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #46367:  justify-marked-patches-5g.zip added by dolorous (15KiB - application/zip)
file #45908:  justify-marked-patches-5f.zip added by dolorous (15KiB - application/zip)
file #45900:  justify-marked-patches-5e.zip added by dolorous (9KiB - application/zip)
file #45899:  justify-marked-patches-5d.zip added by dolorous (9KiB - application/zip)
file #45897:  justify-marked-patches-5c.zip added by dolorous (9KiB - application/zip)
file #45847:  justify-marked-patches-5b.zip added by dolorous (9KiB - application/zip)
file #45764:  justify-marked-patches-5a.zip added by dolorous (7KiB - application/zip)
file #45744:  justify-marked-patches-5.zip added by dolorous (7KiB - application/zip)
file #45637:  fragment added by bens (407B - application/octet-stream)
file #45621:  cleanup.patch added by dolorous (647B - text/x-patch)
file #45585:  justify-marked-patches-4a.zip added by dolorous (6KiB - application/zip)
file #45580:  cleanup.patch added by dolorous (647B - text/x-patch)
file #45578:  justify-marked-patches-4.zip added by dolorous (6KiB - application/zip)
file #45577:  justify-marked-patches-3.zip added by dolorous (6KiB - application/zip)
file #45576:  justify-marked-patches-2c.zip added by dolorous (7KiB - application/zip)
file #45575:  justify-marked-patches-2b.zip added by dolorous (7KiB - application/zip)
file #45574:  justify-marked-patches-2a.zip added by dolorous (7KiB - application/zip)
file #45548:  justify-marked-patches-2.zip added by dolorous (7KiB - application/zip)
file #45547:  justify-marked-patches.zip added by dolorous (6KiB - application/zip)
file #45546:  justify-marked-patches.zip added by dolorous (5KiB - application/zip)
file #45543:  justify-marked-patches.zip added by dolorous (5KiB - application/zip)
file #45538:  justify-marked-patches.zip added by dolorous (5KiB - application/zip)
file #45537:  justify-marked-patches.zip added by dolorous (5KiB - application/zip)
file #45535:  justify-marked-patches.zip added by dolorous (5KiB - application/zip)
file #45498:  justify-marked-patches.zip added by dolorous (5KiB - application/zip)
file #45492:  justify-marked-patches.zip added by dolorous (5KiB - application/zip)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dolorous (Posted a comment)
  • -email is unavailable- added by bens
  • -email is unavailable- added by bens (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 44 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-25 bens Open/ClosedOpen Closed
    2019-03-10 bens StatusIn progress Fixed
    2019-02-27 dolorous Attached File- Added justify-marked-patches-5g.zip, #46367
    2019-01-09 dolorous Attached File- Added justify-marked-patches-5f.zip, #45908
    2019-01-08 dolorous Attached File- Added justify-marked-patches-5e.zip, #45900
    2019-01-08 dolorous Attached File- Added justify-marked-patches-5d.zip, #45899
    2019-01-08 dolorous Attached File#45898 Removed
    2019-01-08 dolorous Attached File- Added justify-marked-patches-5d.zip, #45898
    2019-01-08 dolorous Attached File- Added justify-marked-patches-5c.zip, #45897
    2019-01-02 dolorous Attached File- Added justify-marked-patches-5b.zip, #45847
    2018-12-28 dolorous Attached File- Added justify-marked-patches-5a.zip, #45764
    2018-12-27 bens Attached File- Added stuff-that-should-not-be-needed.diff, #45746
    2018-12-26 dolorous Attached File- Added justify-marked-patches-5.zip, #45744
    2018-12-26 bens Attached File- Added 0001-new-feature-marked-text-gets-justified-into-a-single.patch, #45742
    2018-12-12 dolorous Attached File- Added 0001-new-feature-marked-text-gets-justified-into-a-single.patch, #45640
    2018-12-12 bens Attached File- Added fragment, #45637
    2018-12-11 dolorous Attached File- Added 0001-new-feature-marked-text-gets-justified-into-a-single.patch, #45629
    2018-12-11 dolorous Attached File- Added 0001-new-feature-marked-text-gets-justified-into-a-single.patch, #45620
        Attached File- Added cleanup.patch, #45621
    2018-12-10 dolorous Attached File- Added 0001-new-feature-marked-text-gets-justified-into-a-single.patch, #45619
    2018-12-10 bens Attached File- Added 0001-new-feature-marked-text-gets-justified-into-a-single.patch, #45617
    2018-12-05 dolorous Attached File- Added justify-marked-patches-4a.zip, #45585
    2018-12-04 dolorous Attached File- Added cleanup.patch, #45580
    2018-12-04 dolorous Attached File- Added justify-marked-patches-4.zip, #45578
    2018-12-04 dolorous Attached File- Added justify-marked-patches-3.zip, #45577

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code